You can clone with
If I'm understanding and testing BrowserID correctly, it assumes that the person sitting in front of the browser is the person who registered the BrowserID. When I log in to the demo site it does not ask for the password I set up; it simply presents a list of BrowserIDs that are registered with the browser, and when I pick one, it immediately logs in using that ID.
I can see the benefit of simplicity associated with this, but I believe it is insecure for many use cases. Quite apart from public shared terminals, I don't tend to associate 'access with my computer' with 'ability to access all my site accounts'. I have my password manager set to lock after ten minutes, so people who sit down in front of my computer can't just access all my current old-world site logins, and a similar timeout for my SSH key. I rather suspect that many people and organizations have a similar approach.
BrowserID should at least make it possible for the password to be required for each login. This still brings a significant benefit over one-identity-per-site - you don't have to go through a sign up process and then wait for the verification email to arrive for every damn site you sign up for.
The idea is to not use any password at all. You can protect yourself by locking the computer when you're away and use different user accounts for each user in the same computer.
As I said, there's still a significant advantage to BrowserID even if it does use a password (I suppose it would rather be a passphrase for the RSA key). To me, entering a password is no real inconvenience at all, but filling out a big form and waiting for a confirmation email to arrive are.
A further problem with un-protected keys is highlighted by this comment on a story about the system: http://forums.theregister.co.uk/post/1120710 . If the key is not passphrase-protected then my identity is only as secure as my browser, and all browsers have been subject to vulnerabilities forever. If a vulnerability in the browser allows an attacker to retrieve my private key from the browser's storage, my identity is now entirely compromised. If the key had a passphrase, this attack vector would be mitigated.
If the attacker has access to your computer, they can just as easily install a user script that scrapes the contents of every page and posts it back to a server along with your session ID, completely transparently to you. Making the argument that a password is necessary to protect against in-person attacks is like saying that a bank needs to start locking its front door during business hours to keep people from just wandering into the open vault. Once you've got access to a computer, that person's identity is effectively already in your possession.
matt: 'just as easily' is a stretch. I'm thinking mainly of casual attacks - or even inadvertent ones - by non-skilled people, here. in case you haven't looked at facebook lately, lots of people find this just hilarious, but they're probably not skilled enough to do a more sophisticated attack.
I think that particularly in the case of BrowserID, this is not a "vulnerability," per-se. It's the same scenario if you check the "Remember Me" box on your Facebook account, or use the Remember Password feature of any browser. And if your session hasn't expired and you're still logged in, you're still wide open (BrowserID or not).
The sheer nature of the web makes it impossible to enforce identity at a more granular level than secured user profile (i.e.: Firefox profiles). Even if the authentication was built into the browser (as BrowserID will be), the same problem persists.
The thorough fix to your solution would be requiring the user to enter his or her password every time they wanted to do something. Post to your wall? Enter your password. Change a setting? Enter your password. View non-public information? Password. But this would be too extreme. It puts authentication in front of convenience. So it comes down to making a trade-off. Are you willing to sacrifice the peace of mind of knowing that person using your computer (whether you or someone else) isn't going to do anything "bad" for the ability to take advantage of any number of convenience functions (remember my password, remember me, session cookies, etc.)?
Perhaps a more sane solution would be to respect the browser's "Do Not Track" flag. If it's set, then local data regarding identity should not persist. This would require you to perform a full BrowserID authentication (password and email) every time you want to log in, but it would certainly solve the problem.
again, speaking personally, I'm perfectly happy to enter email address and password every time I log in anywhere. It's the waiting-for-authentication-email-and-clicking-on-link step that's a drag, and BrowserID's main benefit for me is avoiding that. Your proposal seems reasonable, though a bit obscure (I'm not sure I'd expect the 'do not track' setting to affect identity behaviour).
Where do we stand with this now that we have a couple new UI flows (one on beer site, one on BrowserID server) that require a password?
Thanks everyone for bringing up this issue. We'll keep this issue in mind, especially as we discuss stronger proofing options.
Note that once browsers have native BrowserID support, they'll almost certainly tie it to the same security they use around remembered passwords, such as Firefox's "master password" approach.
Would it be possible to make it something the website has control over? I'm not too fussed if someone manages to break into my myfavouritebeer account, but I do care if someone gets onto the admin panel for windows azure for example. Could we make the browser have an option to request a newly validated token, requiring the password to be re-entered. Together with the required-email option, this would let us create similar flows to how Facebook works if you want to edit who is an admin on a page, or edit key settings on your profile.
This would then look a little like:
It's important that the server also checks that the assertion is fresh (i.e. created within the last few minutes)
@ForbesLindesay what you're asking for there is what some folks call "Levels of Assurance." We are thinking about how to do that properly, e.g. requesting an ID for the purpose of a large purchase, which would then cause a password reprompt. No clear design on this yet, but we welcome ideas and needs just like yours!
Cool, I really look forward to seeing what you come up with.
We have added this using the experimental_forceAuthentication: true option to navigator.id.request. Note: this only works if the user is using an address backed by the fallback IdP. Closing.