Mozilla's BrowserID aims to simplify authentication on the Web

Jump to latest Follow Reply
Status
Not open for further replies.
Mozilla has developed a new technology called BrowserID that allows the browser to manage the user's identity and simplify the process of creating new accounts and logging into websites.

<a href='http://arstechnica.com/web/news/2011/07/mozillas-browserid-aims-to-simplify-authentication-on-the-web.ars'>Read the whole story</a>
 
Click to expand...
Sort by date Sort by votes
L

Lliwynd

Ars Centurion
243
Subscriptor++
  • #3
    The article alludes to this at the end when talking about mobile devices, but doesn't outright say it: If you have *multiple* devices that you want to all use the same identity, how will that work? There will have to be some way of sharing the private key. And then the security of that private key will be the minimum of the security of all the devices it is on.

    I also wonder if this is related to http://www.nist.gov/nstic/

    In general I think the web could do with improved identity management. I haven't seen a compelling solution yet though. I'm not sure that adding yet another 'almost-right' solution will help.
     
    Upvote
    0 (0 / 0)
    S

    segphault

    Ars Tribunus Militum
    2,428
    Subscriptor++
  • #4
    Lliwynd":y1hrk4ow said:
    The article alludes to this at the end when talking about mobile devices, but doesn't outright say it: If you have *multiple* devices that you want to all use the same identity, how will that work? There will have to be some way of sharing the private key. And then the security of that private key will be the minimum of the security of all the devices it is on.
    Click to expand...

    The system doesn't require each user to have only one unique key. You can log into the provider on as many devices as you want and it just generates more keys that will work. There will also obviously have to be some way for the user to invalidate keys when they have been compromised. That's one of those aspects of the system that is sort of an understood requirement, but the mechanism isn't fully specified yet.
     
    Upvote
    0 (0 / 0)
    E

    elanthis

    Ars Centurion
    200
    Subscriptor
  • #5
    Lliwynd":34pkb97l said:
    The article alludes to this at the end when talking about mobile devices, but doesn't outright say it: If you have *multiple* devices that you want to all use the same identity, how will that work? There will have to be some way of sharing the private key.
    Click to expand...

    From my reading of what little text there is, this is not the case. Each browser/device can have its own public/private key pair. Sites identify users by their email address. The public key is given to the site so that it can (via the third party server) verify the identity.

    Even if a provider offers only a single key, that's handled by the user logging in on each device (once per device) to the provider, which hands a key pair to the browser.
     
    Upvote
    0 (0 / 0)
    F

    Faramir

    Ars Legatus Legionis
    36,356
    Subscriptor
  • #10
    From the spec:
    To verify the identity certificate, Relying Parties must have the issuer's public key. This key can be distributed prior to usage, or can be discovered dynamically at runtime.
    Click to expand...

    That sounds like a good job for DNS, which in turn is another good reason to get going with DNSSEC. Getting used to serving public keys out of DNS also brings us one step closer to eliminating certificate authorities.
     
    Upvote
    0 (0 / 0)
    V

    variable455

    Ars Praetorian
    585
  • #12
    "That will get really complicated and sort of ugly, but the problem could eventually be solved better by having the underlying operating system itself implement BrowserID and store the keys in a central keyring."

    nope. don't like this at all. assuming the whole point of this feature is to minimize the number of times you have to enter a pwd, it seems kind of risky to let the OS authenticate for you (if your laptop gets stolen, for example).. if the keyring on your machine needs a pwd.. then all you're doing is subbing a local pwd for the one you'd otherwise enter directly on the site.
     
    Upvote
    0 (0 / 0)
    S

    SeanJW

    Ars Legatus Legionis
    10,276
    Subscriptor++
  • #13
    variable455":uzz11il5 said:
    "That will get really complicated and sort of ugly, but the problem could eventually be solved better by having the underlying operating system itself implement BrowserID and store the keys in a central keyring."

    nope. don't like this at all. assuming the whole point of this feature is to minimize the number of times you have to enter a pwd, it seems kind of risky to let the OS authenticate for you (if your laptop gets stolen, for example).. if the keyring on your machine needs a pwd.. then all you're doing is subbing a local pwd for the one you'd otherwise enter directly on the site.
    Click to expand...

    Which people are already doing every day. Keychain in OS/X stores browser user/pass pairs. Browsers have their own keystores, optionally with password protection. It's already done ad-hoc with 1Password and KeyPassX and similar... none of which are foolproof or used consistently.
     
    Upvote
    0 (0 / 0)
    M

    Merovingian

    Ars Praetorian
    441
  • #15
    One of the inherent problems with having centralized ID management is privacy. In this case the privacy has simply moved to the email provider (an odd peer in the process). I suppose that decentralizes things because you can use multiple email addresses, but it's still unlikely to satisfy the privacy advocates.

    Perhaps someone could use their browser to specify an alternative validation target? It would create possible man-in-the-middle attacks without further effort--the browser could have its alternate validation target modified--but would be one step in that direction.
     
    Upvote
    0 (0 / 0)
    E

    elanthis

    Ars Centurion
    200
    Subscriptor
  • #16
    variable455":3h7zvu6f said:
    then all you're doing is subbing a local pwd for the one you'd otherwise enter directly on the site.
    Click to expand...

    Except that password is never, ever stored on individual sites. So the next time AnonSec or whatever they're calling themselves these days goes out and hacks 100 popular sites that you just happened to use, they don't also get the password for all your sits.

    Plus, if you use more than one site a day (like most of us), then you only need to log in with your password once instead of ten bazillion times.

    Also also, I'm so freaking sick of creating accounts on sites it's not even funny. Every ****ing site on the Internet asks me to enter my email and a password and then wait for a verification and then click a link in my email to go to another page to finally log in so I can finally click "Like" on a post of a funny picture of a llama.
     
    Upvote
    0 (0 / 0)
    B

    bblfish

    Seniorius Lurkius
    6
  • #17
    It is very much worth comparing BrowserID with WebID, http://webid.info/ , which is being developed in a W3C incubator group. WebID also uses public/private key cryptography - though it uses the TLS stack. It is arguable that one could have both use exactly the same keychain certificates as well the same assertions on the web as argued on the WebID mailing list here: http://ur1.ca/4phv9 . There is still some learning of the respective protocol implementations details on each side, but the gains would be very great. WebID over TLS would provide very strong security, BrowserId with WebID assertions works better with legacy sites that cannot add TLS.
     
    Upvote
    0 (0 / 0)
    B

    BronekK

    Ars Centurion
    246
    Subscriptor++
  • #18
    Faramir":2mwglbxq said:
    From the spec:
    That sounds like a good job for DNS, which in turn is another good reason to get going with DNSSEC. Getting used to serving public keys out of DNS also brings us one step closer to eliminating certificate authorities.
    Click to expand...

    good idea, but this requires protocol for serving certificates over DNS(SEC).
     
    Upvote
    0 (0 / 0)
    B

    bblfish

    Seniorius Lurkius
    6
  • #19
    BronekK":31w55wcn said:
    Faramir":31w55wcn said:
    From the spec:
    That sounds like a good job for DNS, which in turn is another good reason to get going with DNSSEC. Getting used to serving public keys out of DNS also brings us one step closer to eliminating certificate authorities.
    Click to expand...

    good idea, but this requires protocol for serving certificates over DNS(SEC).
    Click to expand...

    Yes, that is what the IETF DANE working group is developing.
    http://datatracker.ietf.org/wg/dane/charter/

    This is pointed to in what is perhaps the "WebID and Browsers"
    http://www.w3.org/2011/identity-ws/pape ... webid.html
     
    Upvote
    0 (0 / 0)
    L

    leonwid

    Ars Scholae Palatinae
    1,287
    Subscriptor++
  • #20
    I have the feeling a step is missing in the explanation. If I send MY identity certificate signed with MY private key, without any input from the server, that bucket of bits could be re-used by the server to pose as me.

    I would think that a manual login step, like openId, on a trusted provider would be necessary, or perhaps the signing of the identity certificate on the browser side with a site certificate, so that the bucket of bits cannot be reused for other sites.
     
    Upvote
    0 (0 / 0)
    G

    grumpy2

    Ars Scholae Palatinae
    1,278
  • #21
    leonwid said:
    I have the feeling a step is missing in the explanation. If I send MY identity certificate signed with MY private key, without any input from the server, that bucket of bits could be re-used by the server to pose as me.

    Suppose you generate a unique certificate for each site. One which contains the domain name of the site? :)
    Click to expand...
     
    Upvote
    0 (0 / 0)
    B

    bblfish

    Seniorius Lurkius
    6
  • #23
    grumpy2":1vq2pqyp said:
    leonwid":1vq2pqyp said:
    I have the feeling a step is missing in the explanation. If I send MY identity certificate signed with MY private key, without any input from the server, that bucket of bits could be re-used by the server to pose as me.

    Suppose you generate a unique certificate for each site. One which contains the domain name of the site? :)
    Click to expand...
    Click to expand...

    I am not 100% sure but I think the private key does not leave the browser. There is a more detailed technical explanation of BrowserId here: http://lloyd.io/how-browserid-works . This is the same as the way http://webid.info/ works, though we have always been using the html5 specified keygen element (it has existed since the beginning of TLS nearly, but was only recently specified)
     
    Upvote
    0 (0 / 0)
    Haravikk

    Haravikk

    Ars Praefectus
    4,047
  • #24
    This is a technology that I'm very interested, but I do think that calling it BrowserID is a bit restrictive; if the idea is for e-mail service providers to hold public keys, then this could easily be extended into an e-mail verification standard as well, by having your e-mail client sign e-mails using your private key, and people receiving the e-mail can then fetch your public key to decrypt the signature, or even the entire message, in order to validate your identity.

    If that could then become a standard, then we could leave behind insecure password logins (which, let's be honest, a lot of companies have already proven they are incapable of handling with even the most basic of security precautions such), as well as unvalidated e-mail, which could allow spam to be largely eliminated by making it possible to verify the identity of the sender; given how easy it is to fake the from address in an e-mail, this really should have been a standard long before now.
     
    Upvote
    0 (0 / 0)
    I

    IvorB

    Ars Centurion
    267
  • #27
    "It is a decentralized authentication system allows the Web browser to manage the user's identity"
    Missing "that".

    "The website then obtains the user's public key from the identity provider and uses it verify the authenticity of the provided identity information."
    Missing "to".

    Interesting article but please proofread before posting. It is irritating to see such basic proofing errors and takes away from the impact of an otherwise excellent article.
     
    Upvote
    0 (0 / 0)
    I

    Icaria

    Ars Praetorian
    571
  • #28
    This is as bad as the Facebook/Google account bullshit now pervading the net. Get your one login compromised and you lose everything.

    If people want to be lazy shits, they can use the same username/password everywhere on the net as it is and live with the consequences. Hell, that's arguably less of a risk: you might be able to pull someone's plain text password from a poorly engineered site but you'd have to know what other services they use.
     
    Upvote
    0 (0 / 0)
    K

    kruzes

    Ars Tribunus Militum
    1,660
  • #31
    Icaria":jybel6wc said:
    This is as bad as the Facebook/Google account bullshit now pervading the net. Get your one login compromised and you lose everything.
    Click to expand...
    If you're concerned about the security of your Google account, get a smartphone and turn on two step authentication. I'd rather use that system for pretty much everything, than have to remember a bazillion passwords.
     
    Upvote
    0 (0 / 0)
    F

    fjpoblam

    Ars Scholae Palatinae
    1,414
  • #32
    Mozilla doesn't want dependence upon the email provider, with the resulting security/privacy breach at the email provider end. From what it seems though, since the mechanism described is stored locally (client-end), I wonder whether browser makers would have to agree *before* cross-browser support could be achieved. Yesterday, I saw Mozilla's description of how Browserid differs from Openid: http://bit.ly/pdFpJE

    (Or do I mis-read and would the userid would be stored purely at the logonid holder's end?)
     
    Upvote
    0 (0 / 0)
    I

    Icaria

    Ars Praetorian
    571
  • #33
    kruzes":kic4c1sb said:
    Icaria":kic4c1sb said:
    This is as bad as the Facebook/Google account bullshit now pervading the net. Get your one login compromised and you lose everything.
    Click to expand...
    If you're concerned about the security of your Google account, get a smartphone and turn on two step authentication. I'd rather use that system for pretty much everything, than have to remember a bazillion passwords.
    Click to expand...
    Yeah but I'd have to get a smartphone. And I'm not that worried, given that I use very few Google services and have several accounts.
     
    Upvote
    0 (0 / 0)
    ColinABQ

    ColinABQ

    Ars Tribunus Angusticlavius
    6,238
    Subscriptor++
  • #35
    Enough with these variations on a theme - it needs to end. Every single new entrant, no matter how attractive it may seem, is just hurting us with fragmentation and user confusion, resulting in no successful and ubiquitous implementation of ANY such scheme. OpenID, WebID, BrowserID, the NISTIC and W3C things; this API, that API; this sort of cert, wait - that sort of cert, wait - we use no cert; it's based on a mail address, no - it's based on a user ID, no - it's based on a key fob, no - it's based on DNS ... Fucking stop already. We need an enforcer of sorts to JUST PICK ONE and ram it down the rest of the world's throat. Mozilla can't do it; their competitors will go in other directions due to the "not invented here" syndrome, with some "our way is better because ..." salt on it. Even if other vendors kinda-sorta agree, and kinda-sorta implement it, they'll each just have to put their own little spin on it in some way. No browser or OS vendor can do it, for those reasons, with proprietary implementation details tossed in here and there. No independent party can do it, due to all of the above, with distribution and adoption struggles, implementation details, and endless debate about the relative security of each scheme holding us all back. (If that were not the case, we'd be there already.)

    So, who can do it? Who can JUST PICK ONE and make us use it? The feds. I know they are working on it - or on something - and we need them to escalate and accelerate those efforts. I don't care if they hand it off to NIST or W3C or to some other party - they just need to do it and end this carnival of counterproductive clowning.
     
    Upvote
    0 (0 / 0)
    K

    KitsuneKnight

    Ars Scholae Palatinae
    1,216
  • #37
    ColinABQ":296prv9h said:
    So, who can do it? Who can JUST PICK ONE and make us use it? The feds.
    Click to expand...

    HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA!

    What an excellent way to get nobody to support a mechanism!

    The reason we don't have a universal scheme to replace passwords is, by and large, no ones come up with one that doesn't have massive issues (such as working horribly poorly for non-web apps, or putting too much trust in a single entity). 'JUST PICK ONE' is a horrible reason to do something. It's better to spend time coming up with the RIGHT system, than to just rush and implement a horribly broken system that'll never be supported correctly, and has many known (and unknown) fundamental issues.
     
    Upvote
    0 (0 / 0)
    ColinABQ

    ColinABQ

    Ars Tribunus Angusticlavius
    6,238
    Subscriptor++
  • #38
    Icaria":6nt4dezy said:
    Good god, I hope the above post is a troll.
    Click to expand...

    It is not a troll, thanks. I am just very frustrated and disillusioned with the entire field of user authentication. Perhaps you could untroll it a bit more constructively by telling us how you think such things should work, including who should design it, direct it, standardize it, and broker it.
     
    Upvote
    0 (0 / 0)
    ColinABQ

    ColinABQ

    Ars Tribunus Angusticlavius
    6,238
    Subscriptor++
  • #40
    KitsuneKnight":dbwkg3q6 said:
    ColinABQ":dbwkg3q6 said:
    So, who can do it? Who can JUST PICK ONE and make us use it? The feds.
    Click to expand...

    HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA!

    What an excellent way to get nobody to support a mechanism!
    Click to expand...

    Yes, I know. I hate pointing in that direction - but it is more than clear that there's just no other direction to point in right now. Again, if there were, we'd be there already.

    The reason we don't have a universal scheme to replace passwords is, by and large, no ones come up with one that doesn't have massive issues (such as working horribly poorly for non-web apps, or putting too much trust in a single entity). 'JUST PICK ONE' is a horrible reason to do something. It's better to spend time coming up with the RIGHT system, than to just rush and implement a horribly broken system that'll never be supported correctly, and has many known (and unknown) fundamental issues.
    Click to expand...

    I agree, to an extent. My point was that it is more than obvious that our hands must be forced. If the first generation isn't perfect, there can be a second and a third. Sometimes JUST PICK ONE is the only way to get off high-center. That's where we are.

    Look at it like the selection of AES was, with the NIST directing it. There is now a standard, and a reference implementation. If your implementation does not produce exactly the same output as the reference implementation, given identical input, well, sorry, you don't get to play. This needn't be any different.
     
    Upvote
    0 (0 / 0)
    Status
    Not open for further replies.
    Jump to latest Follow Reply
    Jump to latest Follow Reply