Is it wise to use OpenID (from Google or Yahoo) to log-into a website instead of a username+password login if that website doesn't have an SSL certificate installed?
Just to make things clear, installing an SSL certificate is not possible because there is no dedicated IP address for web hosting.
Any other suggestions for secure login?
It would be safer to user OpenID if the site being logged in to does not support SSL than using a username and password. As long as the OpenID provider supplies SSL, then all that will be sent in the clear (ie, that a man in the middle could get) would be the submission of the ticket indicating that you are who you say you are to the server.
It would only be useful to someone trying to compromise your account on the unsecured site that you are logging in to. Depending on configuration, it is likely that they would not be able to reuse the ticket to log in in the future as well, where as a username and password combination could be used indefinitely in to the future.
I just wanted to correct this misconception:
Just to make things clear, installing an SSL certificate is not possible because there is no dedicated IP address for web hosting.
While this may be what your hosting provider has told you, it is not a fundamental property of SSL/TLS and in most hosting environments is not true.
The misconception stems from the fact that the Host: header of an HTTP request is encrypted within the SSL stream and hence for many years the only way to distinguish which SSL certificate should be used on a server that hosts multiple websites was to have one IP address per SSL certificate.
To address this problem, SNI was created as an extension to SSL/TLS. If both the client and the server support SNI, any number of SSL certificates can be served from a single IP address. SNI was first practical in 2008 and is quite widely supported these days but you should check the clients you actually see on your website against the list of supporting clients in the Wikipedia article.
If a request is made where either the server or the client do not support SNI, the behaviour of Apache is to choose the first SSL certificate in its config and use it. This will cause a warning in the browser but if the user chooses to ignore the warning an encrypted connection will still be made, albeit negotiated with the wrong certificate.
For the sake of accuracy/completeness, in the above case eavesdropping would be possible by someone who had access to the private key of the default SSL cert in your Apache configuration but since they would require root privileges on the same box where your cert is stored I don't see this as a significant threat. Teaching your users to ignore SSL host mismatch warnings is not a good practice anyway and suggesting they upgrade to a more modern browser/OS is much better from a security perspective.
