I'm not sure, but it may be better to take the chance that the user has only one password, than to give that user an OpenID account and remove all doubt.
With OpenID, your password is only ever entered in one place: the OpenID provider's login page. When another site wishes to authenticate you it redirects you to your provider where you enter your password then get redirected back to the original site along with a token proving you have authenticated and granted authorization to the site.
The most important thing is that you use a provider that you trust.
A good OpenID provider can actually help prevent phishing and identity theft. For example, myopenid.com (and probably others) lets you select a personalized image that is displayed whenever you're prompted for your password (much like Bank of America and other banks' "SiteKey") and you're supposed to train yourself to never enter your password unless you see the correct image, to prevent phishing (though most of us are smart enough to look at the URL too). They also provide a comprehensive log of every site which has authenticated using your account, so if your password has been compromised it is very easy to find out.
By the way, OpenID doesn't require you authenticate to your provider with a password. It could be done via a SecurID token, or even biometrics. Passwords just happen to be the simplest and most common method.
Is OpenID more secure than my solution? I mean, it's obviously less convenient and harder to understand, but perhaps it would be more secure.
I guess you could argue that my passwords are sometimes sent in the clear, when the site I'm logging into doesn't have HTTPS. Fair enough, but I wouldn't think that the marginal additional security of OpenID would matter too much in that scenario. Sites which don't support HTTPS can hardly be relied upon to be careful with my data, anyway.
Plus, once you're logged into your OpenID provider, you don't have to enter your password for any sites which you already trust, until you log out. That's part of the advantage of a single sign-on system.
"Sites which don't support HTTPS can hardly be relied upon to be careful with my data, anyway." -- so, the vast majority of sites? People are going to use these sites either way. Most users don't even know what HTTPS is.
While it's unlikely an OpenID provider would sell out to DoubleClick, etc, if you're paranoid it's also very easy to use your personal website URL as a portable OpenID (it's literally two extra HTML tags in your homepage's header). You can either run your own provider using a simple prepackaged solution, or do what I do and just delegate to another provider, which you can easily change in the future with a quick edit of you homepage's header. Here's mine:
<link rel="openid.server" href="http://www.myopenid.com/server" />
<link rel="openid.delegate" href="http://tlrobinson.myopenid.com/" />
I agree OpenID is a little difficult to understand (as evidenced by some of the comments here) but it's actually very easy to set up a simple OpenID (many people already have one and don't know it... all AOL, Technorati, LiveJournal, WordPress, and some other accounts are OpenIDs) and not too much harder to set up a delegated OpenID or run your own provider.
Here's a great little article by Sam Ruby: http://www.intertwingly.net/blog/2007/01/03/OpenID-for-non-S...
I suggest everyone look into OpenID a little more before completely dismissing it.
I think that users do need to be educated to not enter their passwords until they're redirected to their identity provider (and to confirm their "SiteKey" if the provider supports it). But it hardly "teaches users to fall prey to identity theft".
The fact is that most users end up using the same passwords over and over again. Most websites (ecommerce and banks excluded) don't bother using any sort of encryption for logging in at all.
OpenID goes a long way to lessen those risks. Additionally, integration into browsers could eliminate the risk of phishing.