The Definitive Guide To Website Authentication
stackoverflow.com
stackoverflow.com
> The only (currently practical) way to protect against login interception (packet sniffing) during login is by using a certificate-based encryption scheme (e.g. SSL) or a proven & tested challenge-response scheme (e.g. the Diffie-Hellman-based SRP).
I'm no security expert but if you take into account man in the middle attack where the attacker can actually change the page/javascript you're not safe even with DH. Attacker can just drop all your fancy code and send the password in the clear and intercept it later...
1. Get a signed cert from a recognized CA (fraudulently - not impossible).
2. Hijack the DNS (e.g., get their GoDaddy password, or point them to a DNS server you control)>.
3. The user is directed to the fake server with the fraudulently obtained cert, and does not receive a warning.
It is, notably, not enough to safeguard the JS code with HTTPS/TLS (which, if you do that, SRP is of virtually no utility anyways). To protect the Javascript runtime, you'd also need to ensure that no element of the page was ever cached from a non-HTTPS connection, that no element of the page is currently fed from a non-HTTPS connection, and that the page is free from any and all DOM or CSS corruption issues.
Obviously, you'd also need to implement SRP safely, which very few people do; more than half of the SRP implementations I've ever tested have been trivially bypassed due to math flaws.
SRP is a terrible suggestion for generalist devs and for authentication in a web setting. If you want to do something advanced, go two-factor; I like Duo Security, which will be easier for you to integrate than SRP anyways:
EDIT: To practice what I preach: Duo Song has made an impressive network sniffer and some other cool stuff, and Jon apparently is a security guru who, among other things, has found several security related Android bugs.
Looks like Duo has more options for receiving the code as well as the ability to enable manual approve/deny for another user role. It also looks like a private service I have to rely on though.
I definitely hear you on the better user/dev experience. That's very clear from the variety of methods and slick screenshots they've got.
(It is, as an aside, also a terrible idea to ask users to store their passwords in browser autocomplete dictionaries.)
Can you really even call browser password storage "autocomplete"? Doesn't the browser see a password field and use the credential storage mechanism?
It's possible to simply "show password" for any of the stored sites using your browser's settings menu. At least for Chrome on Windows this is the case.
[1] http://fishbowl.pastiche.org/2004/01/19/persistent_login_coo...
Actually, it would be pretty nice if someone could offer this as a easy to use service for people building enterprise oriented SaaS apps. Is anyone already doing this?
I think BrowserID[1] (or perhaps more precisely, the Verified Email Protocol[2]), the recent effort by Mozilla's Identity Team[3], deserves a mention here. I'll summarize it this way:
1. Mozilla is a nonprofit with values[4] that align well with finding good solutions to this problem.
2. The reality today is that most websites use form-based authentication
3. Form-based authentication has a big drawback, which is increased risk of phishing. Users are asked to enter sensitive information into an area controlled by a remote entity, rather than an area controlled by their User Agent (browser).
4. Since browsers are implicitly trusted (the whole idea of a User Agent is to act on behalf of the User), they can help improve this situation.
5. The primary force holding back progress here is deployment deadlock[5]. Solutions must be decomposed into steps which provide some incremental benefit on their own.
6. The simplest decentralized method for expressing identity that is built into the internet infrastructure is the domain name.
7. As a second level of expressing identity, each domain manages its own set of accounts.
8. The form account@domain is concise and supported by a wide range of protocols and uri schemes. Such an identifier is, of course, most universally recognized as an email address.
9. Email providers are already the de-facto primary identity providers online. Current password reset flows usually let you take control of an account if you can prove that you control that account's associated email address.
10. The Verified Email Protocol was proposed to provide a secure method, based on public key cryptography, for streamlining the process of proving to domain B that you have an account on domain A.
11. For browsers that don't support the Verified Email Protocol (currently all of them), mozilla provides a shim which implements the protocol in client-side javascript.
12. For email services that don't support the Verified Email Protocol, the protocol allows third parties to act as a trusted intermediary, asserting that they've verified a user's ownership of an account. It is not desirable to have a large number of such third parties; this capability is intended only to allow an upgrade path, and it is much preferred that email services provide these assertions themselves.
13. Mozilla offers their own service to act as such a trusted third party. Service Providers (ie Relying Parties) implementing the Verified Email Protocol may choose to trust Mozilla's assertions or not. Mozilla's service verifies users' account ownership using the conventional means of sending an email with a confirmation link.
14. Service Providers may, of course, offer this protocol as an option in addition to any other method(s) of authentication they might wish to offer.
15. A big user interface benefit being sought here is the "identity selector". When a user visits a site and chooses to authenticate, their browser shows them a selection of email addresses ("personal", "work", "political activism" etc) they may use to identify themselves to the site.
16. Another big user interface benefit being sought as part of this effort is helping the browser know more about the user's session[6] -- who they're signed in as currently, primarily -- so it may display that in the browser chrome.
17. Because of the distributed nature of this system, it avoids lock-in to major sites like facebook, twitter, google etc. Any individual can own their own domain and therefore act as their own identity provider.
This is not strictly "form based authentication for websites". But it is an effort to transition from the current norm of form based authentication to something more secure: browser supported authentication.
[1]: https://browserid.org/
[2]: https://wiki.mozilla.org/Identity/Verified_Email_Protocol/Latest
[3]: http://identity.mozilla.com/
[4]: http://www.mozilla.org/about/manifesto.en.html
[5]: http://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_10.pdf
[6]: https://wiki.mozilla.org/Identity/Verified_Email_Protocol/Latest-SessionThe fact is that BrowserID, like SRP (which the SO community itself inexplicably waded into), is not an authentication best practice. It's a proposal that doesn't even have widespread support in the deployed software of its sponsor. Even without getting into the pro's and con's of BrowserID, the simple fact is that if absolutely everything broke Mozilla's way, it would still be many years before a significant number of users would be using it securely.
I really don't want to debate BrowserID here, most particularly because I don't have a strong opinion about it. But isn't it weird how even the Stack Overflow people themselves can't look at a challenge like this without spinning off into deep space on sky-pie crypto answers?
I certainly didn't want to frustrate anybody by posting what I did. If you like, I will delete what I posted on the StackOverflow page. Just say the word.
I think that would mean having browsers support a standard SRP protocol binding (eg http://www.ietf.org/rfc/rfc5054.txt) and then really nailing the browser user interface.
I could see using SRP as an alternative to private keys, or as a strong "something you know" factor in addition to private keys (a "something you have" factor) in order to establish ownership of an account.
However, this doesn't strike me as a credible first step in getting through the aforementioned "deployment deadlock" issue.
Completely aside from that, I'm not sure I see why you think browser support would be so much better of a solution, aside from having a more uniform interface. Combating phishing is primarily an issue of being intelligent about what sites you give your information to. Any decent form-based authentication system will send the data in an encrypted form, which will be as secure as data encrypted by the browser's built-in authentication system. Just having the browser as a middleman doesn't help if your data gets sent to or intercepted by the wrong people, and Firefox, at least, already has a good system for warning users about malicious sites.
Also, you wrote: "Just having the browser as a middleman doesn't help if your data gets sent to or intercepted by the wrong people".
Actually, having the browser more directly involved does help with this, because it can use strong authentication when negotiating a TLS session.
By "strong authentication", I mean the authentication protocol has security features which make it useful over an untrusted network in the presence of eavesdroppers or even active adversaries looking to pull off a man-in-the-middle attack.
Client certificates are a good example of this and are supported by today's browsers but there are UX problems there.
It's not that the forms-based system doesn't work. I just think it could be a lot better.
Just consider how much easier it is today to stay in a "walled garden" social network than to be an active commenter on a large number of independent blogs.
The system smells; the problem is being solved in the wrong place.
The sad thing is that 15 years ago this could have been solved easily. Now any solution has an uphill struggle.
I still like the idea of certificates in browsers authenticating me. But almost nothing out there that I use has the implemented.
You should talk to someone who manages fob deployments at a Fortune 500 company. These are environments supporting hundreds or thousands of users, not millions, and virtually all those users are highly paid, not fixed-income retirees. In particular, ask them about how easy it is to handle lost, damaged, and stolen fobs.
Clearly, we weren't going to standardize on everyone getting a certificate on a USB key --- even had USB keys actually been feasible 15 years ago.
HTTP auth doesn't make backend authentication code easier to write. In virtually all apps, it doesn't obviate the need to do session management, or solve the user demand for "remember me" cookies.
What it does do is shoehorn applications into a single inadequate login UX, one that (almost at the protocol level) is not amenable to basic security measures like gracefully logging out sessions.
Clearly there's quite a bit more wrong with HTTP auth than that (for instance, it does a terrible job of handling errors, it doesn't handle "forgot password", &c &c) but I'm not particularly interested in the counterfactual argument of what could have been had browser vendors only built a "good" version of it.
The fact remains that even the hypothetically "good" version of HTTP auth would at best be only marginally better than what we have now, and would leave all the hard problems this "definitive guide" is trying to address still on the table.
It makes it easier to shove into a library or middleware.
Most of the issues you list are UI problems that could have been solved with a non-modal login prompt, a "remember this login" option, and a "stop sending the Authentication header" button.
My point isn't that existing HTTP auth schemes are great, because they're not (even if they weren't saddled with a terrible UI). It's that migrating from those mediocre schemes would have been easier than migrating from the mediocre schemes we're using now will be.
I just disagree flat-out that HTTP authentication would have done anything to make the problems this guide is trying to grapple with easier. And in the meantime, HTTP auth as it exists in the standards today adds problems.