3 ms·

Isn't this exactly what Mozilla Persona [1] does? EDIT: In fact, Persona goes one better. Persona has the browser act as an intermediary between your e-mail pr

Isn't this exactly what Mozilla Persona [1] does? EDIT: In fact, Persona goes one better. Persona has the browser act as an intermediary between your e-mail provider and the site that you're logging in to, so that the e-mail provider doesn't get to see the source of the authentication request, and the site that you're authenticating with doesn't get any further details beyond your e-mail address. [1] http://www.mozilla.org/en-US/persona/ http://www.mozilla.org/en-US/persona/

bapi 13y ago
Yes Persona do it. Better.
Groxx 13y ago
The intermediary part is a blessing and a curse. If the site you're logging into doesn't directly verify with your email provider, then if anyone gets your temporary signing token they can log in anywhere you use Persona, and you have no way to revoke it or even prevent future ones until the token expires naturally. Even if this is mere seconds, it's plenty of time for a scripted attack to try hundreds or thousands of sites[1]. This is noticeably unlike OpenID / OAuth[2] / many name/password systems, where you can revoke access to specific tokens / sites on the ID provider, and where many username/password sites reject all old cookies after you change your password. Anyone with your token / cookie / etc will immediately lose access with this, and the provider can prevent new sites from using old login info. [1]: and remember that they don't "phone home" to the Persona provider, so there can't be any rate limiting. virus -> botnet -> millions within seconds is totally possible, if unlikely and costly. [2]: yeah, OAuth ain't an ID system. same basic structure though.
- fmarier 13y ago
  I think you might be confused with how Persona works, it's not quite like OAuth. There is no "token" in Persona, we have keys and assertions. The first step is for your browser to generate a public and secret keypair. Then you send the public key over to the identity provider to get it signed. Once it's signed, you use your secret key (which never leaves your browser) to sign an assertion. The assertion contains your signed public key and an expiration, but it's also tied to an audience (i.e. the URL of the site you're logging into). That's what you send to the site you're trying to log into. So if that site tries to impersonate you on a different website using the assertion you just gave it, it won't work because it can't change the audience that's inside the assertion (that would break the signature on the assertion). If the audience doesn't match, no other site will accept it. Of course if a site steals your secret key from localStorage, then it's game over. However if you find a way to do this, then you've got yourself a browser 0-day :)
  - Groxx 13y ago
    Or you just have a virus that searches the RAM where the browser sits. Or a deliberately compromised browser. You're right, Persona is safe from e.g. MITM attacks. Really, it's a good structure, I like it. But as usual, a virus means game over, and in Persona's case its structure means game over in a uniquely crippling way that you really can't protect against. That's the tradeoff for your provider not being able to watch where you log in. If I never reuse my passwords, or use e.g. an external tool (something like a yubikey, though I can't speak to that one in particular), the worst a virus can do is steal one site at a time. If a virus steals my OAuth token, it can be revoked. If someone gets my OpenID login details, hopefully my provider would notice something is up when requests start coming fast and furious, and start rejecting them. And all of that is just as secure against MITM as Persona if I run it through SSL. This is of course assuming no 0-day on the device / my webcam to snap a photo of where I wrote down all my passwords on post-its and stuck them on my laptop. But browser 0-days aren't all that rare, and viruses certainly aren't.
    - fmarier 13y ago
      One thing to note as well is that if a virus steals your email password, then you're a bit screwed too because that can, in most cases, be used to reset your password on other sites. As we've seen with a bunch of high-profile compromises, the email account is already an extremely valuable target for attackers. Another good reason to enable 2-factor auth there!
      - Groxx 13y ago
        Yes, but, if you change your password / answer your security questions to get back in you get control back. Now say they get your Persona email account, and get the signing material from it once. They can now log in everywhere until that material expires. There's nothing you can do about it. THAT is very different. There's a small thing you could do to mitigate this, but really only self-hosted email has it as an option: change the email server's keys. You would be able to block logins to any site which has not cached those keys. But no big provider would do it for you, since it would break everyone's currently-live keys, and from what I can remember they recommend that sites using Persona login cache the keys[1]. So any site you had logged into may very well have cached them, and not even perform a web request, and still allow the malicious login. -- The only real way to dial back this damage is to limit the lifetime of the original signature. Make it too short and slow internet connections can't log in anywhere, and browsers have to continually request new assertion-signing data. Make it too long and you let attackers try many, many, many more sites. [1]: I can't find this on the Persona/BrowserID site :/ maybe it was in a presentation somewhere. Anyway, it's inherently cache-able material, and it is a great selling point - server-side web requests are painfully slow.
benatkin 13y ago
> the site that you're authenticating with doesn't get any further details beyond your e-mail address But Mozilla's servers (or the email provider, but I don't expect to see any significant uptake of this feature) get information in the HTTP requests, whether they like it or not, and they're based in the US.
- fmarier 13y ago
  Right now, you're right and that's because of the temporary centralized components: 1. JavaScript shim 2. include.js 3. Centralized verifier 4. Fallback identity provider However, we've designed the protocol so that all of these pieces (necessary to bootstrap the system) will go away over time. #1 will go away once we have native support in the browser (some of our developers have starting working on this). #2 will go away once we make include.js self-hostable, which we are definitely planning to do. #3 will no longer be needed once sites can use local verification libraries, which we have started writing. #4 can already be avoided if you put up your own identity provider (several people have done so).
- nileshtrivedi 13y ago
  You can run your own Persona identity provider.
fmarier 13y ago
It's definitely in line with what Persona does. After all, Persona evolved from the "Verified Email Protocol" (https://wiki.mozilla.org/Labs/Identity/VerifiedEmailProtocol https://wiki.mozilla.org/Labs/Identity/VerifiedEmailProtocol). Right now, our fallback identity provider (for email providers without native support) requires that people set a password to avoid having to confirm their email every time. However, we're currently exploring the idea of making the password optional and letting users click an email link at every login, just like the author of that article suggests. I don't think it works for everyone, for example some people read their email on a different device, but it would certainly work for those who always keep their webmail open in a tab.

bapi 13y ago

Yes Persona do it. Better.

Groxx 13y ago

The intermediary part is a blessing and a curse. If the site you're logging into doesn't directly verify with your email provider, then if anyone gets your temporary signing token they can log in anywhere you use Persona, and you have no way to revoke it or even prevent future ones until the token expires naturally. Even if this is mere seconds, it's plenty of time for a scripted attack to try hundreds or thousands of sites[1]. This is noticeably unlike OpenID / OAuth[2] / many name/password systems, where you can revoke access to specific tokens / sites on the ID provider, and where many username/password sites reject all old cookies after you change your password. Anyone with your token / cookie / etc will immediately lose access with this, and the provider can prevent new sites from using old login info. [1]: and remember that they don't "phone home" to the Persona provider, so there can't be any rate limiting. virus -> botnet -> millions within seconds is totally possible, if unlikely and costly. [2]: yeah, OAuth ain't an ID system. same basic structure though.

fmarier 13y ago
I think you might be confused with how Persona works, it's not quite like OAuth. There is no "token" in Persona, we have keys and assertions. The first step is for your browser to generate a public and secret keypair. Then you send the public key over to the identity provider to get it signed. Once it's signed, you use your secret key (which never leaves your browser) to sign an assertion. The assertion contains your signed public key and an expiration, but it's also tied to an audience (i.e. the URL of the site you're logging into). That's what you send to the site you're trying to log into. So if that site tries to impersonate you on a different website using the assertion you just gave it, it won't work because it can't change the audience that's inside the assertion (that would break the signature on the assertion). If the audience doesn't match, no other site will accept it. Of course if a site steals your secret key from localStorage, then it's game over. However if you find a way to do this, then you've got yourself a browser 0-day :)
- Groxx 13y ago
  Or you just have a virus that searches the RAM where the browser sits. Or a deliberately compromised browser. You're right, Persona is safe from e.g. MITM attacks. Really, it's a good structure, I like it. But as usual, a virus means game over, and in Persona's case its structure means game over in a uniquely crippling way that you really can't protect against. That's the tradeoff for your provider not being able to watch where you log in. If I never reuse my passwords, or use e.g. an external tool (something like a yubikey, though I can't speak to that one in particular), the worst a virus can do is steal one site at a time. If a virus steals my OAuth token, it can be revoked. If someone gets my OpenID login details, hopefully my provider would notice something is up when requests start coming fast and furious, and start rejecting them. And all of that is just as secure against MITM as Persona if I run it through SSL. This is of course assuming no 0-day on the device / my webcam to snap a photo of where I wrote down all my passwords on post-its and stuck them on my laptop. But browser 0-days aren't all that rare, and viruses certainly aren't.
  - fmarier 13y ago
    One thing to note as well is that if a virus steals your email password, then you're a bit screwed too because that can, in most cases, be used to reset your password on other sites. As we've seen with a bunch of high-profile compromises, the email account is already an extremely valuable target for attackers. Another good reason to enable 2-factor auth there!
    - Groxx 13y ago
      Yes, but, if you change your password / answer your security questions to get back in you get control back. Now say they get your Persona email account, and get the signing material from it once. They can now log in everywhere until that material expires. There's nothing you can do about it. THAT is very different. There's a small thing you could do to mitigate this, but really only self-hosted email has it as an option: change the email server's keys. You would be able to block logins to any site which has not cached those keys. But no big provider would do it for you, since it would break everyone's currently-live keys, and from what I can remember they recommend that sites using Persona login cache the keys[1]. So any site you had logged into may very well have cached them, and not even perform a web request, and still allow the malicious login. -- The only real way to dial back this damage is to limit the lifetime of the original signature. Make it too short and slow internet connections can't log in anywhere, and browsers have to continually request new assertion-signing data. Make it too long and you let attackers try many, many, many more sites. [1]: I can't find this on the Persona/BrowserID site :/ maybe it was in a presentation somewhere. Anyway, it's inherently cache-able material, and it is a great selling point - server-side web requests are painfully slow.

benatkin 13y ago

> the site that you're authenticating with doesn't get any further details beyond your e-mail address But Mozilla's servers (or the email provider, but I don't expect to see any significant uptake of this feature) get information in the HTTP requests, whether they like it or not, and they're based in the US.

fmarier 13y ago
Right now, you're right and that's because of the temporary centralized components: 1. JavaScript shim 2. include.js 3. Centralized verifier 4. Fallback identity provider However, we've designed the protocol so that all of these pieces (necessary to bootstrap the system) will go away over time. #1 will go away once we have native support in the browser (some of our developers have starting working on this). #2 will go away once we make include.js self-hostable, which we are definitely planning to do. #3 will no longer be needed once sites can use local verification libraries, which we have started writing. #4 can already be avoided if you put up your own identity provider (several people have done so).
nileshtrivedi 13y ago
You can run your own Persona identity provider.

fmarier 13y ago

It's definitely in line with what Persona does. After all, Persona evolved from the "Verified Email Protocol" (https://wiki.mozilla.org/Labs/Identity/VerifiedEmailProtocol https://wiki.mozilla.org/Labs/Identity/VerifiedEmailProtocol). Right now, our fallback identity provider (for email providers without native support) requires that people set a password to avoid having to confirm their email every time. However, we're currently exploring the idea of making the password optional and letting users click an email link at every login, just like the author of that article suggests. I don't think it works for everyone, for example some people read their email on a different device, but it would certainly work for those who always keep their webmail open in a tab.