Advice on user authentication? | Hacker News Reader

Advice on user authentication?

4 pointsjsjenkins1688 comments

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

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?

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.

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.

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

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

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.

Just wondering, but why the bias against SSL?

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

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.

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.

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.

Reply on news.ycombinator.com