
The Definitive Guide To Website Authentication - moonlighter
http://stackoverflow.com/questions/549/the-definitive-guide-to-website-authentication/
======
yread
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...

~~~
tptacek
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/>

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

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

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

------
tptacek
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
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
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
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...](http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice/)

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

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

~~~
tptacek
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?

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

~~~
tptacek
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_.

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

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

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

------
dublinclontarf
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
Javascript RSA is not a good thing to suggest to developers looking to improve
the security of their login system.

~~~
dublinclontarf
Because?

~~~
ptomato
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
This argument again.

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

~~~
bct
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
How could this have been solved easily 15 years ago?

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

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

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

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

