8 ms·

The Definitive Guide To Website Authentication

319 points by moonlighter 15y ago

deleted 15y ago
[deleted]
arethuza 15y ago
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?
- frekw 15y ago
  As far as I know, Nordic Edge (http://nordicedge.com/ 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.
yread 15y ago
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...
- wisty 15y ago
  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.
- JVerstry 15y ago
  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.
  - yread 15y ago
    that's what I'm trying to say, too. I meant that you're not safe even with DH and have to use SSL
  - rjbond3rd 15y ago
    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.
    - JVerstry 15y ago
      Absolutely, authentication is not bullet-proof. That's why certificate authorities have to invalidate certificates from time-to-time.
      - rjbond3rd 15y ago
        True, and of course they can only revoke the ones they know are fake. And the browser/client has to respect the revocation list.
- tptacek 15y ago
  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/ http://www.duosecurity.com/
  - stephenemslie 15y ago
    Thanks for the two-factor suggestion and the recommendation. Duo looks excellent.
    - tptacek 15y ago
      Duo is Dug Song and Jon Oberheide. You really couldn't find a better team to get your back on authentication.
      - lhnn 15y ago
        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.
  - drivebyacct2 15y ago
    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 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.
dublinclontarf 15y ago
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).
- tptacek 15y ago
  Javascript RSA is not a good thing to suggest to developers looking to improve the security of their login system.
  - dublinclontarf 15y ago
    Because?
    - ptomato 15y ago
      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.
      - dublinclontarf 15y ago
        This argument again.
ristretto 15y ago
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.
- wisty 15y ago
  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?
- bct 15y ago
  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.
  - tptacek 15y ago
    How could this have been solved easily 15 years ago?
    - buro9 15y 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.
      - 15y ago
markkum 15y ago
You should look at two-factor authentication solutions to solve many of these issues. For example https://www.mepin.com 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.
tptacek 15y ago
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.)
- euroclydon 15y ago
  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?
  - div 15y ago
    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.
whichdan 15y ago
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_cookie_best_practice/ http://fishbowl.pastiche.org/2004/01/19/persistent_login_coo...
charlieok 15y ago
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
moonlighter 15y ago
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?
mcantor 15y ago
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.

319 points by moonlighter 15y ago

deleted 15y ago

[deleted]

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?

frekw 15y ago
As far as I know, Nordic Edge (http://nordicedge.com/ 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.

yread 15y ago

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

wisty 15y ago
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.
JVerstry 15y ago
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.
- yread 15y ago
  that's what I'm trying to say, too. I meant that you're not safe even with DH and have to use SSL
- rjbond3rd 15y ago
  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.
  - JVerstry 15y ago
    Absolutely, authentication is not bullet-proof. That's why certificate authorities have to invalidate certificates from time-to-time.
    - rjbond3rd 15y ago
      True, and of course they can only revoke the ones they know are fake. And the browser/client has to respect the revocation list.
tptacek 15y ago
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/ http://www.duosecurity.com/
- stephenemslie 15y ago
  Thanks for the two-factor suggestion and the recommendation. Duo looks excellent.
  - tptacek 15y ago
    Duo is Dug Song and Jon Oberheide. You really couldn't find a better team to get your back on authentication.
    - lhnn 15y ago
      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.
- drivebyacct2 15y ago
  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 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.

dublinclontarf 15y ago

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

tptacek 15y ago
Javascript RSA is not a good thing to suggest to developers looking to improve the security of their login system.
- dublinclontarf 15y ago
  Because?
  - ptomato 15y ago
    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.
    - dublinclontarf 15y ago
      This argument again.

ristretto 15y ago

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.

wisty 15y ago
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?
bct 15y ago
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.
- tptacek 15y ago
  How could this have been solved easily 15 years ago?
  - buro9 15y 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.
    - 15y ago

markkum 15y ago

You should look at two-factor authentication solutions to solve many of these issues. For example https://www.mepin.com 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.

tptacek 15y ago

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

euroclydon 15y ago
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?
- div 15y ago
  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.

whichdan 15y ago

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_cookie_best_practice/ http://fishbowl.pastiche.org/2004/01/19/persistent_login_coo...

charlieok 15y ago

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

moonlighter 15y ago

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?

mcantor 15y ago

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.