OpenIDSolving the OpenID phishing problem
Most of the arguments I hear against OpenID are based on mis-understandings of the specification, but there is one that can’t be ignored: OpenID is extremely vulnerable to phishing.
Phishing attacks work by tricking a user in to visiting a replica of the login page for a service, usually through a spam e-mail. OpenID compounds the problem by training users to use login forms that they have been redirected to by untrusted sites. A malicious site could easily redirect to a proxy that copies the login form from the user’s identity provider, and the vast majority of users would be none the wiser—a classic man-in-the-middle attack. Ben Laurie’s OpenID: Phishing Heaven describes this problem in more detail.
I have a proposal for identity providers which I think could dramatically reduce the risk of phishing, without mandating a client-side plugin.
When an OpenID consumer application redirects a user to their identity provider there are three possible outcomes:
- The user is already logged in to their identity provider but has not previously used the application in question. Show them a “Do you want to share your identity with X?” confirmation prompt.
- The user is already logged in to their identity provider and has previously stated that they always trust this application. Redirect them straight back without any further steps.
- The user is NOT already logged in to their application provider. Show them the provider’s login form.
Phishing attempts target the third one, and that’s where identity providers can fight back. Instead of displaying the login form directly, providers should show a page that looks something like this:
To log in, please navigate to login.example.com. The page your are currently viewing should contain no links; if there are any links or this text is changed in any way you may become a victim of online identity theft.
Identity providers should never display their authentication interface directly on the page shown to a user after an OpenID redirect, or even provide a link to it. They should instead use that page to inform their users about the dangers of online identity theft. Educating users is a demonstrably flawed strategy in computer security, but forcing them to learn how to browse to the login page themselves should be far more effective than just displaying a warning notice.
It’s important that the login page URL be short, distinctive and memorable. This is a good rule of thumb for all applications, not just OpenID providers.
This proposal certainly isn’t 100% fool-proof, but I doubt that any solution to phishing ever could be (someone can always invent a better fool). The effectiveness of the approach could be dramatically increased by disciplined usability testing of the instruction page itself.
I don’t know of any identity providers that currently do this, but delegation makes switching providers trivial and security is likely to emerge as a key way for them to compete. There’s plenty of scope for innovation here.
If there are any holes in my thinking I’d love to hear about them in the comments. Update: Tons of smart comments on this one.
I'll repeat what I mentioned on the general list here in case some folks find this and not the other discussion.
One of the greatest strengths of OpenID is the ability for website operators to lower the barrier to engagement ... User shows up, user enters OpenID, user is then immediately participating in discussion/posts/comments/etc. I'm afraid this proposal takes away from that by forcing the user to lose the "flow" ... Of course its that "flow" that is the problem in terms of phishing.
What if the OP cataloged where you just came from and then presented the screen that you mention? The user is asked to navigate via a bookmark or entering the URL in the location bar and then upon logging in is presented with a link back to the site they just came from. Then the user can quickly engage and the site can still kick of the SREG mojo instead of having to go _back_ to the site in question to re-initiate the login.
Would that work or am I missing something obvious?
I should have made that more clear - the idea is definitely that the landing page starts a session or sets a cookie to record which site the user is in the process of logging on to. Once they've manually completed the login step the identity provider can provide a link to complete that authentication.
Hopefully most users will be logged in to their identity providers most of the time, so it will actually be quite rare for them to see the landing page (though hopefully not so rare that they don't learn to tell the difference between it and a phishing attempt).
Cor, that'd be really annoying, wouldn't it? "Now type this URL in." I admit that there aren't really any other ways around the phishing problem, but it's still pretty darn annoying.
I also fear that your point that seeing the login screen is "hopefully not so rare that they don't learn to tell the difference between it and a phishing attempt" is...optimistic, to say the least. People are likely to not see their landing page enough to identify it properly, especially since (were I a phisher) I'd make the fake landing page say something like :
Type 'login.example.com' into your URL bar, or click here to do the same: <a href="http://phisher.org/">login.example.com</a>
Whether you are logged in already or not is irrelevant. I can design my blog with an OpenID but secretly redirect to my own page which will perform a MITM attack.
My fake page will simply show the page as if the user were logged out. Most users will not question why they are logged out and will log back in.
I actually came up with my own idea for distributed OpenID based on DNS. OpenID simply replaces an email address with a URL and both are cheap enough to be worthless. Ownership of a domain isn't as cheap. However, I figured that the population of domain name owners would be too small to make it worthwhile.
I did come up with a solution to the problem though: simply display on the landing page a large image based on the IP of the user (this only works with static IP users - a cookie may be an alternative for dynamic IP users).
The image should also have the message: "if this image looks different, you could be the victim of a phishing attack. Please check... blah blah blah".
Charles Darke - 19th January 2007 15:35 - #
An alternative is to show the:
"Do you want to share your identity with X?" confirmation prompt.
and then when they click on "yes", show a session timed out page and ask them to re-authenticate to a fake page.
Charles Darke - 19th January 2007 15:39 - #
Would it really deter users? Typing 'login.example.com' once a day doesn't seem like a huge barrier to entry to me, and understanding the reason behind it I'd much rather use a provider that protected me in that way than one that didn't.
Providers could even offer it as an option, defaulted to "On" since the people who are the most vulnerable to phishing are least likely to go clicking around in their account preferences.
The joy of delegation is that the market can decide.
Charles: that confirmation prompt attack is really neat. The attacking site would need to know enough to replicate the identity provider's internal interface, so a good defence could be to show the user a bunch of information that they had previously set (things like their custom background colour, a photo of themselves, "Welcome back, XXX") - basically the same kind of approach used for seals on some login pages.
The thing is, if I were a phisher, I'd sign up for my own accounts on the various providers and fetch the login screen and customise on the fly.
OR
I would put a "welcome to our redesigned page, I hope you like..."
On the typing in an URL. Let's say I direct you to a fake log in page anyway. Would the average user still type in the URL unprompted or would they just log in? What if you put a message: "to make it easier to log in, we've re-desgined..."
Charles Darke - 19th January 2007 15:52 - #
Verisign already helps thwart this problem by showing a picture that you give them when you initially sign up for PIP. Since their website runs over https, I think this is a good compromise.
Charles: definitely lots of angles for attack, but like I said there's no way to guard against phishing that's 100% fool-proof. Heck, most people will give you their password in exchange for a chocolate bar. The challenge is to give people the best possible chance of protecting themselves, and hopefully instill just a little bit of security knowledge in to them at the same time.
@Chris
Interesting. Looks like a user provided variant of my idea above (based on IP or random cookie).
The thing is, when do they show this picture and can the attacker get hold of it? Is it ultimately cookie based?
Charles Darke - 19th January 2007 16:03 - #
@Simon
I guess security will always be hard and humans will always be the weak point.
One question is "why use openid at all?" In it's present form, I see very little benefit of using it. Simply let people post without logging in.
Charles Darke - 19th January 2007 16:11 - #
Chris: Verisign don't show the user-supplied graphic on the login screen. Only on the "do you trust this site?" screen.
So users can still provide password data to the phisher site with nothing amiss.
It seems to me that typing 'login.example.com' the first time they try OpenID would cause a vast majority of people to never use OpenID again.
I'd also use such a provider, but this isn't about us the early adopters. We need to appeal to the masses, and having them type in URLs beyond their OpenIDs simply won't work. Marcin virtually quoted (unknowingly) my earlier words about user deterrence on the mailing list.
Not sure why my last 2 comments are not showing up. Test.
Charles Darke - 19th January 2007 16:33 - #
Have you looked at banks' anti-phishing measures? It's fairly common, these days, for them to allow (or even require) users to select a customized image that will be shown to them whenever the bank thinks that they are trying to log in. They do remember IP address, and this does require an extra step if you're coming in from an IP they don't recognize --- but since the user "name" in OpenID is supposed to be a URI unique to that particular user, it may be that the OpenID provider wouldn't even need to check the IP address in order to figure out how to show whatever customizations are appropriate for that user's login page...
Robert Thau - 19th January 2007 17:23 - #
Dmitry: I completely agree - but the nice thing about this is that they don't have to type it in the first time they try OpenID because they'll already be logged in (they get logged in when they first create their OpenID, and the chances are they'll try it out before their cookie expires). My hope is that once they've experienced the joy of single sign-on once they won't be put off by typing the login URL manually once in a while.
For me the killer feature of OpenID is not having to set up new usernames and passwords for every site, and one extra small hoop to jump through when my session expires doesn't affect that.
Robert: showing a unique image based on the requested OpenID wouldn't work, as the phishing site could still scrape the custom login page (it knows their OpenID).
Simon: A little off topic, but you brought it up. I doubt that most users are dumb enough to hand over their password for a chocolate bar. The infamous survey would only have merit if the passwords were only later checked to see if they were valid. I suspect most people are smart enough to lie for a free chocolate bar.
Simon: I think you're enormously underestimating how annoying it would be to have to type in a URL, I have to say. Bear in mind that lots of people don't even know what the address bar is, and think that Google's search box is where you type URLs. Since OpenID isn't just aimed at the cognoscenti (although it is at the moment, because there's not yet widespread support), you have to cater for that sort of thing.
I feel like a naysayer now.
Agreed on the point that Robert's idea won't work, though (I was about to post that until I noticed you'd done it already :))
I like the idea that Gabe Wacob floated; hook support into the browser and everytime someone opens their browser, they login to their OP at that time.
Stuart, you're not a naysayer, you're helping improve the strawman. :)
I think it's true that most people don't get the difference between a link and a search.
I wish browsers implemented something like ssh's known_hosts: "You're connecting to site X under SSL for the first time. If this is unexpected, you may be the victim of a phishing attack. Proceed?"
If that were in place, you could have a landing page explaining this dialog in any browser, with a link to the login page (after the warning).
Eh, perhaps we should all start using client certs. ;-)
Some of the solutions that would help to prevent this phishing/mitm attack:
-passpet (the browser identifies well known sites for the user),
http://passpet.org/
-phishmarks (the browser uses previously set cookies to show some visual indication that the domain is not being phished)
http://www.docuverse.com/blog/donpark/2004/02/22/s ecure-ui-phishmarked-password-field
http://blog.monstuff.com/archives/000199.html
The problem comes down to making sure the user knows what he's typing his password into.
Some great guiding principles on this problem can be found at
http://www.ischool.berkeley.edu/~ping/sid/
Question: what is planned in Firefox 3 to support OpenID? Will it help with the issues mentioned in this thread (typing long url, phishing threat)
Julien Couvreur - 19th January 2007 20:22 - #
Yes, it would really deter users. Users give up at a very precipitous rate, with every additional task you ask them to accomplish. And that's when they're logging into sites that they already like.
"Please type in login.example.com" cannot be the future of identity. Just can't be. And what if the malicious site says "Please type logintopaypal.ro"? I don't see the win here.
IMO we should let OpenId providers innovate to mitigate phishing. Sites that are popular, with good user education and additional security measures (like security images) will hopefully win.
Instead of typing in the ID provider's URL, why don't they provide a bookmarklet?
Call it "Login into this site as [myopenidname]". The js could make a note of the current URL, and tack it onto the id providers' appropriate login page. No typing needed.
The bookmarklet would only be dragged and dropped into bookmarks while signing up, and would be easily accessible from there on.
Nato Welch - 19th January 2007 21:44 - #
Simon: Correct. Ouch. Back to the drawing board...
Robert Thau - 19th January 2007 22:22 - #
Julien: the phishmark thing won't help. The phishing site knows what your OpenID is and can therefore screen-scrape the login page from your actual provider. If it's relying on cookies, then you have to be able to assert that you'll never ever lose your OpenID cookie, which means that you'll never see the login page for your actual provider (because if it can store a cookie it'll store the one that logs you straight in, not one that remembers your phishmark) and so you'll never see the phishmarked login screen! Any time you see the login screen for your actual provider you (by definition) don't have a cookie and therefore the site can't show an appropriate phishmark.
I have to agree with others that something like this would be a deterrent to users. Users are lazy. Take me for example - I have about 30 domains and two servers that could easily be set up for the purpose but I haven't bothered setting up an OpenID yet.
Also, I have a philosophical objection to this - I hope that the future of the web isn't reading URLs on a page and typing them. Reminds me of my bad old days working in IT, when people would routinely ask for help with tasks that involved printing out a long list of data and then typing it in to another application...
Clever choice of phishing URLs could fool just about anyone, too. Besides, someone would just make a bookmarklet or Greasemonkey app that turns the "please type" message into a link, defeating the entire purpose...
Michael Moncur - 20th January 2007 11:22 - #
(A postscript after creating an openID so I'd know what I was talking about)
Couldn't a service like MyOpenID or Livejournal solve this problem by offering a browser toolbar/plugin that would present the openID signin in a non-webpage format? That would make it difficult to fake, and could be made reasonably secure.
I normally think various (ebay, paypal, etc) "anti-phishing" toolbars are ridiculous, but with something that is providing me benefits across hundreds of sites, installing a browser component wouldn't be a big deal.
Of course that's probably way more of a mental leap than typing a URL, but at least you'd only have to do it once. And hopefully, years down the line, non-expert users would have it all done for them when they signed up with an ISP that provided them an OpenID and a customized browser.
I think nato's idea is the only one that really works.
It actually saves typing, too, so should probably be introduced as a part of the standard for openid anyway.
and the "redirect to password screen from untrusted site" model is so badly broken anyway that it should be removed forthwith.
bob - 20th January 2007 14:49 - #
downsides to nato's idea that spring to mind:
to which I'd say:
1:- no point in having the most popular authentication scheme in the world if it is badly flawed. Security has to be more important than popularity in this case
- not a problem for early adopters, and if it proves popular, provision could be included in the browser itself to streamline it for mass use
- cart before horses/early optimisation - get the thing secure and in widespread use with early adopters before worrying about finessing and second guessing the usability for the mass audience
- For the foreseeable future, openid is a sophisticated user thing anyway - is designed to save time when you have memberships at lots of sites, and are adding new sites all the time.
2:bob - 20th January 2007 15:08 - #
bob: there is, however, an argument that OpenID won't be the most popular system if it never gets off the ground, and it'll never get off the ground if there are barriers in the way like "you have to install this bookmarklet first". My dad would see a bookmarklet as confusing and weird, and the "drag it to your bookmarklet bar" step as installation.
Not that I have a *solution*, of course. Naysayer, remember.
I think the main problem is that people will become less suspicious and might not detect phishing attacks. This is because they will now be used to seeing login box of their IdP and they realize that they may get to see it from any website that accepts OpenID.
In the traditional scenario, if one got login box of say Yahoo, on some other website which is not owned by Yahoo, one will definitely get suspicious. Now he will be used to such requests and might become less careful and hence more prone phishing.
Interesting OpenID provider, who doesn't use usernames & passwords for authentication: http://openid.xmpp.za.net/
Instead, it uses Jabber for authentication. You enter your Jabber address and a temporary key. Then the server sends you an instant message including that temporary key. If you respond to the message with "OK", then you're in!
sil: I agree the bookmark step will deter a chunk of the mass market.
However, I think openid is a long way before that point, and there is a healthy mass of users who will not have a problem with it (early adopters, technical types, and active web users who collect lots of site logins, who would really benefit).
Once it has proven its value and security, then obstacles to true mass market adoption will be better understood, and things like integration with browsers might be an option.
I think compromising the security now for an anticipated problem that is at least 3-4 years down the line is wrong.
Who knows, the next big youtube might require everybody to install bookmarklets for some reason, and the education of the mass market will have been done for us, and we'll look back and laugh at what we were worried about.
If we were talking about downloading and installing an exe or something, I can see there might be more of an argument that it was the wrong way to go, but it's a good, simple piece of standard web technology.
bob - 20th January 2007 21:52 - #
I think the bookmark idea is a good one, so I fleshed it out a bit at http://usablesecurity.com/. What do you think?
Ka-Ping Yee - 21st January 2007 00:19 - #
Charles Darke - 21st January 2007 01:28 - #
Ping: really like that - explaining it in terms of bookmarks makes much more sense, and including bookmark in the name of the service is a really nice touch.
Charles: Orange (a UK mobile phone company) did exactly the same thing to me. Completely insane.
Second the motion for a Pet Name tool. In addition to passpet, there's http://petname.mozdev.org/
When I see the MyOpenID signin page, I just look for the green light (literally--there's a textbox for the friendly name which turns green if the site matches).
I'm trying to address the phishing problem in a different way.
Let's assume that OP should authorize users only in the case when they send a special cookie that is intended to tell the OP endpoint that it is accessed directly from the user's browser. The cookie is a SHA hash of a random data, it is issued for an authorized user only. That cookie is not intended to authorize a client in any way, but it is associated with the user id and this association is used to track the things that will follow, when the cookie will be used.
The cookie should be one-time, and it starts "working" only after some time, to prevent the phisher itself to obtain a cookie just before the OpenID authentication process starts and fool the OP endpoint, pretending the cookie is sent by the real user browser. The premature use of the cookie should be treated as a suspicious operation, and the user should be notified somehow that he is possibly the victim in a cat-and-mouse game. After the successful authentication, the cookie should be reset (so, after the successful OpenID auth, the second would be possible after some time).
The important part is, when the user that was just authenticated is not the user that the cookie was issued for, the OP should do something like banning the user that the cookie was for, resetting the authenticated user's password and notifying the user that he was very possible a phisher's victim.
I see some drawbacks. The first is that the user's browser could be used legally by someone else, and the cookie is issued for that person, so, after the successful login, that person would be innocently banned. The second is that in case when the cookie is not set, the OP site should somehow tell the user how to obtain the permission to authenticate him using OpenID and this OP (that means how to obtain the necessary cookie). That part itself is subject to social engineering, because it needs user to log in. The solution would be your proposal to educate users to open pages themselves, but I'm not sure, because the page can easily be altered by the MITM...
"providers should show a page..."
That's NOT the attack vector, it's not a solution. It's not a bad /idea/, but it's NOT a solution.
The attack vector is to take the content from known interesting blogs that people reply to. You then provide the option for commenting. You then *only* allow people to sign in using OpenID, and redirect them to a phishing version of their usual site.
No matter what the original trusted (you assume) site does, you can't control malevolence on sites. The next step beyond that is to target code that incorporates OpenID verification, but has some kind of remote execution exploit to hardwire a redirect in place.
The phishers can then also host their collation on similar sites (people already target insecure, old, non-updated installations of gallery for example to host the phishing mechanism for example), and work forward from there. (I actually do look at phishing sites occasionally out of curiosity)
As for throw away OpenIDs? I didn't have this ID until I decided to write this reply, so you can't even be sure it's me... That's not really a problem with Open ID of course :)
I haven't got a solution to it right this instant, but I am pretty sure that in practice, trusting an unknown blog to send you to your OpenID account to confirm your login *is* a phisher's dream...
Step 1 install blog engine on someone else's old and buggy (and hence not checked for security) installation of an old version of Application.php (as they do today, who needs resources?). Step 2, do the same for a phishing version of an open id server. Step 3, harvest posts that will be viewed as interesting. Step 4, wait for id to slowly trickle in.
Given how automatable that is, sadly, this is more realistic I think than many would hope.
Heck you could easily collapse it all and just proxy the real OpenID on the phishing blog, and only "support" a number of "trusted" openID servers. "Sorry, we only support livejournal OpenIDs", if given an OpenID for someone you don't have a fake for, and then the piece de take is to ask them to give details to register on the site instead (the likelihood of them using the same password as for their OpenID is extremely high...) !
The problem with trying to fix the OpenID _providers_ is that the problem with these things is never the good guys...
After all, the problem isn't "does the site believe you who you say you are", the problem is "do I trust YOU enough to say this is where you can confirm my ID which you will send me to".
As far as I can see, OpenID seems to have similar attack vectors to someone phoning you up and saying
"Hi, I'm ... from Orange, can you provide me with the phone number of your authenticator before we talk?"
"Hi, I'm ... from your authenticator, I'm sorry, we've not spoken before, can I confirm your username/password please"
"OK, back over to alter-ego 1, so, what did you want to say?"
You have to remember: a sufficiently high number of users *never* look at the location bar, which is why phishing works in the first place.
To reiterate, the problem is not the valid OpenID providers, the problem is the untrusted sites asking for authentication against an OpenID. A malicious site would *always* redirect someone to a version of their site that says they're not logged in. Fixing the providers does NOT fix the problem. (Which sucks ... I _really_ like the *idea* of OpenID)
Sorry. :-(
I had registered at pip.verisignlabs.com and they ask the users to upload a picture of theirs. When trying to login to the Identity provider the user can verify whether it's a authentic page or a phishing one by looking for his image. The posing website has little chances that it will be able to get hold of your picture upload with the Identity provider. I think that's a good thinking.
Debashish - 22nd January 2007 19:11 - #
Here's my solution:
http://digitalconsumption.com/forum/A-simple-solut ion-to-OpenID-phishing-attacks
I use my IP address instead of a password and use client certificates as a fall back when my laptop is roaming.
Even if you are redirected to a hostile server, they can't phish you as there's no password. What's more, you're alerted to the phishing attempt.
Charles Darke - 23rd January 2007 01:14 - #
My OpenId has a service called SafeSignIn which adds a picture and also then asks you to put you ID password in again when you login.
Regarding the whitelist i have written a longer post onthe idea of connecting XFN blogrolls with hcards and Openid on www.vecosys.com
How about using OTPs for bi directional authentication?
If the server displayed a OTP first on the login form, which the user can confirm before entering user, pass and client otp.
The otp generator would have to be based in part on the ip address, to prevent scrapping grabbing the correct value.
Ren - 19th February 2007 02:14 - #
I read abotu passfaces nto long ago. They have a face recognition (not at all what you are thinking) system to avoid phising for OpenID:
http://webwebusability.wordpress.com/
I semi like the OTP solution. My bank uses a fairly simple otp solution where they send me a little piece of laminated paper with 80 different "question" "answer" combinations. Then every time I try to log in or do anything in my webbanking system Im asked for a one time code from the little piece of paper.
At login Im also asked for a username and password.
So even if the phisher gets his hands on my username password and OTP he wont be able to use the info for anything since he wont have the OTP.
This is a fairly easy solution to implement, but it is also an extra layer of complexity for the user.
This extra complexity is accepted by everyone using the webbanking system because its their money we are talking about!
But since its "only" openID some users maybe won't like the extra complexity.
As someone earlier mentioned we are early adobters and therefore we are ready to accept complexity. We have to teach people that their online identity is as important as their homebanking infos.. How do we do that?
Hmmm just read a bit on Wikipedia about OTPs again, and of course the phisher would be able to hijack a session. In the time of that session he would be able to do some damage :-(
So something like what my bank does where its every time i try to change something Im asked for a OTP, would be the OTP solution. Then comes the problem of extra complexity once again. People like security as long as its easy. We need to be absolutely sure that the session belongs to who it says it belongs to. Even if the session is "only" hijacked until next time you log in, the session is still hijacked and you are compromised. Without a safety on changes the phisher could potentially change your info and get the openID provider to send him a new piece of paper with OTPs.
So OTPs in itself doesnt stop phishing but they might limit the damage done from phishing..
Do I make any sense?
I tried out all the open id providers you have mentioned in your list on how to incorporate openid on blog (http://simonwillison.net/2006/Dec/19/openid/)
None of them prevent phishing in the way you prescribed.
I am relatively new convert to OpenId and am using wordpress for it and they seem to have incorporated your suggestion. I am not sure if you are associated with them and guided them towards it or they were just inspired but seems they deserve kudos.
Cheers
Ali
The cookie thing could be made to work, I think, by having the user's browser accept a cookie with no expiry date or an expiry date far in the future when they initially sign-up for an OpenID account.
Then, if the site that is trying to authenticate tries to run a man-in-the-middle attack, the user's browser won't send the special cookie because the URL will be different, so the man-in-the-middle can't forward the information that's in it.
So you just have the log-in page/log-in link page/whatever display something that tells the user that it didn't see their cookie, and that they should manually return to the OpenID Provider site. (Yes, by typing its URL.)
For most people, this should happen very rarely, if at all, because the cookie will remain set unless they deliberately delete it or change web browser.
Another good defence against phishing is to display (to the user) the names of the last few sites the user logged-in from, the times of the log-ins, and the address of the machine that they were using at the time. That way, when the user logs in via a legitimate site (which will be pretty common, right?), they'll see unexpected entries in the list. OK, so that's a way to *detect* phishing rather than preventing it altogether, but it still limits the damage they can do.
The problem is that there's no security system in the world that will protect the ignorant or lazy user. So the OpenID provider has a system in place that uses cookies to display custom images and Safe SignOn like MyOpenID. That's great. (I use those features.) But, all you have to do is present a phishing site that displays a message saying "Welcome to our new site design" or "As a part of a new security measure, we require you to re-enter your password" or simply display the login page the way it would look if the user was on a different computer without the special cookie. The ignorant/lazy user will enter his password without blinking an eye.
Security conscious users would not be fooled by such a phishing scheme. But, we're not really talking about how to protect ourselves, are we?
I think the best solution would be to give up the "re-direct to login" part of OpenID. If the user goes to a site that supports OpenID, after entering his URI, it should re-direct him to his OpenID provider. If he is logged into his provider, it should present him with the "do you want to trust this site?" prompt used currently. If he is logged in and trusts the current site, he should be seemlessly re-directed back to the site using OpenID without further ado. If he is not logged in, he should see a message telling him to use his login bookmark or click the login button on his toolbar, or whatever. If the OpenID provider NEVER provided a login page without the use of a special bookmark or browser toolbar, then the user would be less easily lulled into think it is "normal" to enter his password into a site he has been re-directed to.
True, the ignorant/lazy user could still be fooled. The page with the "use your bookmark/toolbar button to login" message could have a "click this special link" phishing message. But, at least if the user is trained to login through some other procedure and NOT simply being re-directed to a login page, that will bring the phishing potential closer to what it is currently.
What would be great would be if browsers would implement OpenID support directly. They could have a little box where you enter your OpenID that performs the traditional OpenID login process. We could train users to ONLY enter their password through the browser login method. Then, once the user has a session cookie set by their provider and they are logged in, they won't need to enter a password until they close and re-open the browser. If they were prompted for it at any time other than after entering it into the special browser-OpenID-box then they would (should) know it is a phishing attempt.
Notes about the above idea:
- should support all OpenID providers by checking the URI to determine the provider and then loading that provider's login page
- should display the user's OpenID URI somewhere on the browser itself and have a "change" or "logout" button that takes the user back to his provider (and preferably directly to his provider's logout page, which would need to be included in the OpenID spec)
- should NOT have an option to remain persistent across browser sessions. That is, if a user logs into a computer at a friend's house, school lab, cybercafe, etc. the browser should not have a way of retaining the login. It should use session cookies set by the OpenID provider and not some browser based method of retaining the login.
I'm sure others can improve on or critique these suggestions. It seems to me that the benefit of OpenID is NOT being re-directed to your provider's login page; it is a once per-session login which will then let you easily use your single OpenID at any number of supporting sites.
I just trust of my openid provider (myopenid.com), just if my Firefox fill automatically the username and pass in the myopenid.com login page.
When I don't see my login info filled I start to hesitate.
The OpenID provider could offer CardSpace as an alternative to logging in with username + password. That's a great way to combine the strengths of OpenID and CardSpace.
Mathias - 10th April 2007 03:24 - #
a simple approach would be to set a personailzed question in openid, which the user defines himself. on the login page of openid the user is not confronted with a password to enter, instead with a question he has to answer, which he in persona defined before. no way for phisching. what about that step for an easy solution?????
okay, a phisching site could grab that question too... just didnt quite think it to the end... only solution would be that each site that uses openid hast to be put on some whitelist, so that openid checks the referer. but can be spoofed too, i agree. no easy solution for this scenario...
the only real step to this is check the users ip or certifcate, i agree... sry i ddnt read all the comments before ;)