Hacker Newsnew | comments | show | ask | jobs | submitlogin
The Definitive Guide To Website Authentication (stackoverflow.com)
319 points by moonlighter 1298 days ago | comments



From the first answer

> 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...

-----


I'm a security professional focusing on exactly this issue and you are exactly correct.

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:

http://www.duosecurity.com/

-----


Thanks for the two-factor suggestion and the recommendation. Duo looks excellent.

-----


Duo is Dug Song and Jon Oberheide. You really couldn't find a better team to get your back on authentication.

-----


Though they might be the best people, and though I have Duckduckgo on my side, it might be useful to post a citation.

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.

-----


Why would I want to use this instead of using Google Authenticator with RFC4226 or TOTP (http://tools.ietf.org/id/draft-mraihi-totp-timebased-06.txt) ?

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.

-----


It's not tied to a Google account, it has a better end-user experience, a better developer experience, and an extremely credible team behind it. That said, if you were using Google Auth and I assessed your application, I wouldn't ding you for using it.

-----


Google Authenticator isn't tied to a Google account, and developing for it involves implementing a single algorithm.

-----


Well the Google Authenticator application is just an implementation. I can use any TOTP generator to get access to my Google Account, or alternatively if I use the PAM module they've provided, I can use whatever I want to generate my codes to log in to my Linux machine. It just so happens that they use this mechanism for their two factor auth for Google Accounts.

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.

-----


http://www.rcdevs.com/products/openotp/compare.php

https://tiqr.org/

-----


Yep, if it's not https (including all sources and iframes) you can get some nasty JS injected into the page, and you can't do anything about it.

-----


No, that is not exactly true. If you use SSL, there will be authentication. Eve-in-the-middle cannot craft certificates or feed the browser with her fake certificates. No 3rd party HTML/Javascript/whatever code can change this. So there is a higher level of security with SSL.

-----


Definitely true but this scenario worries me:

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.

-----


Absolutely, authentication is not bullet-proof. That's why certificate authorities have to invalidate certificates from time-to-time.

-----


True, and of course they can only revoke the ones they know are fake. And the browser/client has to respect the revocation list.

-----


that's what I'm trying to say, too. I meant that you're not safe even with DH and have to use SSL

-----


I'm just a few paragraphs in and already this definitive guide is getting you flunked in audits. It's not a question whether you should disable autocompletes on password fields; it's an audit point.

(It is, as an aside, also a terrible idea to ask users to store their passwords in browser autocomplete dictionaries.)

-----


I'm confused. Aren't password fields treated differently than say, my zip code, when stored by browsers? Firefox and Chrome have pretty sophisticated credential storage facilities with syncing and master password protection.

Can you really even call browser password storage "autocomplete"? Doesn't the browser see a password field and use the credential storage mechanism?

-----


I suppose in OSX passwords can be stored to the keychain which is encrypted, but really, how many people just allow their browser access to their keychain without ever prompting them after the first time ?

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.

-----


I'd be interested in hearing how other people on HN implement persistent logins. I'm currently working on it, following "Charles Miller's Persistent Login Cookie Best Practice"[1], but hearing some other opinions/techniques would be great.

[1] http://fishbowl.pastiche.org/2004/01/19/persistent_login_coo...

-----


It would be nice to see something about federated security using something like SAML - if you are a large enterprise and you have multiple SaaS providers you really want external services to be using your own internal directory (which is likely to be MS Active Directory) for authentication.

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?

-----


As far as I know, Nordic Edge (http://nordicedge.com/) provides solutions to quite easily make your SaaS app SAML enabled to login via a remote AD/IDP, but all their products are proprietary.

-----


I posted this on the StackOverflow page. I'll put it here too. Apologies if it is too long.

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-Session

-----


It is a little frustrating that, when the Stack Overflow community attempts to come up with a "definitive guide to website authentication", people inside and outside the community see the attempt more as a coatrack for their own blue sky proposals than as an opportunity to codify best practices.

The 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've been frustrated for a long time by the lack of browser support for strong authentication with a good user experience. Form-based authentication always felt like a terrible hack. That's the only dog I have in this fight.

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.

-----


No, I'm just ranting, because HN is where I rant. It's good that you care about this stuff. If anything, it's the crazy SRP stuff in the original proposal that really sets me off. It is, in the end, frustrating that nobody (myself included!) wants to buckle down and write up all the boring details of how to do secure authentication today.

-----


SRP is cool stuff, but if we're going to do SRP I would be more interested in doing it right.

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.

-----


I actually would say it's relatively good as hacks go. It does a pretty good job of keeping the end goals in mind while dealing with some really tough obstacles. For one, it's browser agnostic, which makes the system much more manageable for all involved. In addition, it doesn't rely on people using the same copy of the same browser each time they sign in for any significant part of its functionality, and minimizes security risks if multiple people use the same browser. There's no way a browser-based solution could address any of those problems in the foreseeable future, if ever, and that not only would create huge headaches for developers, but would also alienate significant portions of users who still use public systems for at least some of their internet access.

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.

-----


Mainly, I hate the proliferation of passwords, and I hate typing those passwords in all the time. I'd rather consolidate those down into a handful of distinct purpose-specific identities that I have some ownership and control over.

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.

-----


You should look at two-factor authentication solutions to solve many of these issues. For example https://www.mepin.com is a two-factor authentication service free to integrate and use for the websites. It supports standard OpenID interfaces, so no proprietary integrations needed.

-----


What about "Keep me logged in for x days"... any opinions on it? It certainly has its own fair share of security issues, if implemented incorrectly. Given that more sites now allow logins via FB, G+, Twitter and what have you, is this still relevant?

-----


This is an admirable hack of SO's intended use. It would be great if there was a site that actually afforded this particular use case. Wikis are too open-ended. Perhaps something in the middle.

-----


There is also authentication using RSA keypairs, ALA glbse.com, they require all requests to the server to be signed by the private key (there is a JavaScript and Python client).

-----


Javascript RSA is not a good thing to suggest to developers looking to improve the security of their login system.

-----


Because?

-----


I'm pretty sure Thomas is tired of explaining why again and again, but short version is that the javascript environment (in a browser) is such that one can quite reasonably claim that it is impossible to implement crypto securely in it.

-----


This argument again.

-----


8 out of the 12 issues posed are about passwords. Clearly we need a better alternative there that could be incorporated into the browser. I think mozilla's browserid is a very pragmatic idea that deserves some attention.

-----


How many username/password forms are there on the web? Millions? They function basically identically, but they all had to be written (or at least configured) independently. It's outrageous when you think about it, as if every language required you to write your own string library before you start coding.

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.

-----


How could this have been solved easily 15 years ago?

-----


He doesn't mean that a solution existed 15 years ago, just that a significantly smaller number of applications would have been impacted by a solution coming into existence 15 years ago, than if one appeared now.

I still like the idea of certificates in browsers authenticating me. But almost nothing out there that I use has the implemented.

-----


Say we adopted certificate authentication. What happens when you want to get your mail from a friend's machine, or log in somewhere to print a boarding pass from a kiosk?

-----


I would hope that certificates are also paired with USB encryption tokens, and I could insert the one from my (physical) key ring and access the mail as usual. And once I'd withdrawn my token that access would be denied as expected.

-----


So now, when we log into machines, we have to carry special physical tokens? That's not realistic. You can thus see one of the reasons we didn't standardize on cert auth.

-----


that's not unrealistic at all. I carry my keys with me all day, yet i only use them for a few seconds per day. On the other hand, given the risks of interception, i think the best is to have a centralized password system that will require frequent password changes.

-----


Many tens of millions of people log into web applications every day, and you are proposing that they all somehow be issued PKI certificates and USB fobs, and that that be the primary way they get access to their data.

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.

-----


The Department of Defense uses smart cards with X.509 certificates. I am not aware of all the details of this deployment, but I think they have millions of users.

-----


A decent UI on top of HTTP authentication would have been an improvement, and it's something that more sophisticated systems can be built on top of while maintaining compatibility.

-----


No, a better UI HTTP authentication would have been a setback.

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.

-----


> HTTP auth doesn't make backend authentication code easier to write.

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.

-----


HTTP auth has literally nothing to do with where the backend code for authentication lives. In our forms-auth world, there already are quite a few authentication libraries.

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.

-----


Surely Digest Auth is a UI ontop of HTTP authentication? The browser does the work - there is absolutely no need for millions of hand rolled web login forms.

-----


Digest authentication isn't a UX change to HTTP Authentication; it's an inferior mechanism to protect credentials in flight (most real web apps use TLS to do this now, which is vastly superior) that happens to mandate weak password storage on the serverside.

-----


Definitely. It solves issue number 1: users have too many passwords, so they just use "password1" as the password. The worst offender I've seen is the Apple Store. You need upper case, lower case, and numbers; and you don't notice this until you've already failed. What's the bet that a significant number of users just use their name (capitalized), followed by their date of birth?

-----




Applications are open for YC Summer 2015

Guidelines | FAQ | Support | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: