A phishing attack is possible where a fake browserID dialogue is launched

[graingert]

A phishing attack is possible where a fake browserID dialogue is launched.

To allow the user to distinguish between a real browserID auth dialogue and a phishing dialogue do what many banks and sites like Yahoo do and allow the user to set a secret string or image for browserID to respond with.

This is only needed for the shim and when a site is not a browserID auth provider/primary

[graingert]

This would require a cookie on the users machine, because otherwise the phising site can just request it from browserid.org

[benadida]

unfortunately those site images have shown to be fairly useless for actually preventing phishing: users don't check them. The main defense here is going to be some amount of device fingerprinting and notifying the user (maybe) when they log in from a new device. The better solution will be a trusted UX once BrowserID is integrated into the browser. We're also looking into 2-factor auth.

For now, I'm going to close this issue as I don't think we'll ever fully get rid of the phishing risk.

[graingert]

Device fingerprinting will not protect from this kind of fraud, because the phishing site will simply not trigger the check. I do agree that trusted ux is the best solution, but feel that some thought should be made for securing the shim.By all means leave this issue closed for the time being.

-------- Original message -------- Subject: Re: [django-browserid] A phishing attack is possible where a fake browserID dialogue is launched (#58) From: Ben Adida
To: tagrain@gmail.com CC:

unfortunately those site images have shown to be fairly useless for actually preventing phishing: users don't check them. The main defense here is going to be some amount of device fingerprinting and notifying the user (maybe) when they log in from a new device. The better solution will be a trusted UX once BrowserID is integrated into the browser. We're also looking into 2-factor auth.For now, I'm going to close this issue as I don't think we'll ever fully get rid of the phishing risk.--- Reply to this email directly or view it on GitHub:https://github.com/mozilla/django-browserid/issues/58#issuecomment-5060985

[benadida]

I mean something else by device fingerprinting: I mean that our servers will recognize that the client is different (IP, special cookie, other properties, etc.) and trigger a more involved authentication dance.

[benadida]

note: if you have specific ideas for further securing the shim, I'm all ears of course! I'm pessimistic given the literature, but creative solutions are welcome!

[graingert]

I'm still not sure how this fingerprinting will stop a phishing site. The phishing site will simply look like a regular auth dialogue box, except that it posts the email and password to another site.I guess device fingerprinting would prevent an attacker using those credentials once obtained.

-------- Original message -------- Subject: Re: [django-browserid] A phishing attack is possible where a fake browserID dialogue is launched (#58) From: Ben Adida
To: tagrain@gmail.com CC:

I mean something else by device fingerprinting: I mean that our servers will recognize that the client is different (IP, special cookie, other properties, etc.) and trigger a more involved authentication dance.--- Reply to this email directly or view it on GitHub:https://github.com/mozilla/django-browserid/issues/58#issuecomment-5061066

[benadida]

That's exactly it, the idea is to prevent those credentials from being used once obtained without further auth.

Again, it's not clear that this is the best solution, but it's one potential solution.

[graingert]

The best solution is to educate users that they should check to see that the are on browserid.org The usual instruction for users however is to type out manually any site they wish to authenticate to, this is not the standard route with browserID

-------- Original message -------- Subject: Re: [django-browserid] A phishing attack is possible where a fake browserID dialogue is launched (#58) From: Ben Adida
To: tagrain@gmail.com CC:

note: if you have specific ideas for further securing the shim, I'm all ears of course! I'm pessimistic given the literature, but creative solutions are welcome!--- Reply to this email directly or view it on GitHub:https://github.com/mozilla/django-browserid/issues/58#issuecomment-5061075

[Osmose]

(The real reason this should be closed is that this should be an issue on mozilla/browserid, not django-browserid. :P)

I like Ben's idea of triggering extra auth, like an email notification, when a login from an unrecognized IP occurs. If a phishing site tries to login with stolen credentials, BrowserID should prompt them to confirm login via an email that asks the user if they want to trigger a login, and warns them that their account may be compromised if they did not trigger the email themselves.

Checking the URL is useful for BrowserID because the browserid.org popup shows the URL box as well as the security lock, signifying that you are on the correct domain and that domain has a valid SSL certificate.

[graingert]

Sorry about posting this in the wrong section, I must have fumbled the URL. Can this issue be moved?

[graingert]

This was removed from Osmose's post but I think it's useful here:

If you run a site with BrowserID, one useful thing to do is to use a Content Security Policy that prevents JS from untrusted domains from running. This will help reduce the likelihood of someone trying to trigger a fake popup when the user logs onto your site, reducing the chance that they will legitimately think the fake BrowserID popup is real (this goes for any XSS, really).