

Advice on user authentication? - jsjenkins168

Does anyone have advice on an good approach for secure user authentication? Basically, I am looking for the best method without using SSL (if possible).<p>What I'm thinking now is when a user logs in, send the username and pass as plain text (or is there somehow a way to hash in javascript?) via an asynchronous call, then server side perform a hash on the string and compare it to what is stored in the database. If successful, return logged in status to the browser. Then it is assumed that session is authenticated. Are there other considerations to be mindful of?<p>Or what about using SSL for the initial handshake, and then use normal HTTP once the user has been authenticated? This way the login text is sent securely, but then the SSL connection can be closed to free resources and improve speed. No protection against main-in-the-middle attacks, but that's probably ok.<p>Security for this is not critical, but probably more so than other projects I've worked on in the past so I would like to have all bases covered. I figured this site was a good place to tap some expert knowledge.
======
mdakin
Take a look at the paper "Dos and Don'ts of Client Authentication on the Web"
by Kevin Fu et al. [1]

You should respect your users and always transmit their passwords over an SSL
connection during the authentication process. Also only keep a hash of the
password on your server. People tend to recycle passwords and by following
those two recommendations you help them out quite a bit.

If you follow the paper's advice and mint a Fu Cookie it will have a finite
lifetime and contain neither the user's password nor any other sensitive info.
Thus for many applications it is not that bad to send it unencrypted over the
network.

[1] <http://pdos.csail.mit.edu/papers/webauth:tr.pdf>

~~~
jsjenkins168
Excellent, this is exactly what I was looking for. Thanks.

~~~
mdakin
You're welcome!

Forgive me if this is obvious but there is one corner case worth mentioning
with the Fu Cookie approach. The Fu Cookie authenticator expires. Be sure to
consider what happens if this expiration happens in the middle of some complex
user-operation. Ideally you will save the user's state, reauthenticate and
then automatically resume the interrupted operation. It is possible to do this
all using cookies or hidden form fields rather than maintaining a data-
structure (or closure ;) ) on the server-side. If you do use cookies/form
fields consider HMACing the operation-state data in the same manner that you
HMAC the Fu Cookie authenticator.

------
epi0Bauqu
Just wondering, but why the bias against SSL?

~~~
jsjenkins168
Oh, not biased at all. Just mindful of the additional overhead and
computational load it places on the server. It can be very significant, as the
paper below indicates:

<http://www.bsc.es/media/389.pdf>

~~~
epi0Bauqu
Sorry to suggest that you were biased. Bad diction on my part. I didn't mean
it like that.

That link isn't working for me, but, from experience, I really don't think
using SSL just for authentication will hamper your server resources that much.

~~~
jsjenkins168
I actually assumed the same thing. The computational load is intense in the
handshake process, but then not really much more so afterwards. But if every
user is re-authenticating each time they log into the site, the server can
fall flat on its face very quickly. The issue is compounded if the client has
a connection timeout. As the server load increases and response time starts to
exceed the defined timeout, the client sends more connection requests,
increasing server load exponentially. Its like a snowball effect. Check out
the graphs in the paper from my previous reply and you'll see what I'm talking
about.

I like mdakin's proposed solution b/c it apparently alleviates the need for a
connection request each time the user logs in. At least until the cookie
expires.

~~~
epi0Bauqu
The link still isn't working.

But this is not an assumption on my part. It is from experience. At my last
startup, we ran the entire most everything over https because it yielded
better sign up numbers and payment conversions (pre-payment page). We had at
some points over 50K people signing up daily (and of course many many more
hitting the initial sign up page and current users logging in and clicking
around). The registration # is to give you an idea of scope. All of this still
ran fine one dual CPU machine, i.e. all the https didn't hit the server too
hard to where it mattered.

So I guess I'm not disputing https takes a lot more CPU than http, but in the
aggregate, with a decent machine, it just isn't going to matter. This is
especially true if you just do it for authentication, and yes I was thinking
of the same cookie process as described by mdakin when making the original
comment.

