Ask YC: Best Practices for User Authentication • Hacker News Board

Re: Ask YC: Best Practices for User Authentication

#11

Post by tptacek » Sun, Jun 01, 2008, 3:49 AM UTC

tlrobinson wrote: post #2

Hashing the password on the client with a nonce provided by the server and checking on the server is good for login, but not registration. The server still needs the password (or a hash of the password and a salt) in order to compute the login hash for comparison. The only truly secure way (that I can think of) is some sort of public-key encryption, either SSL or some JavaScript library.

I'm on my second glass of wine right now, and Erin is glaring at me, but help me understand how the server avoids needing the password plaintext at every login to figure out what the challenge-response needs to be?

Re: Ask YC: Best Practices for User Authentication

#12

Post by tptacek » Sun, Jun 01, 2008, 3:50 AM UTC

DaniFong wrote: post #8

markbao wrote: post #4

Earlier quoted context omitted.

That's very true. Damnit. Not sure how I'm going to fix that. I've looked into public-key encryption, and unless if I generate a new public and private key for every request to login, replay attacks are still possible.

If you hash the password on the clientside, say, and then use that as the password in your scheme throughout, then you don't need to transmit the password in cleartext, ever.

This is a win because, even though you're sending something password-equivalent over the wire, at least you're not exposing a password that's used on other applications?

Re: Ask YC: Best Practices for User Authentication

#13

Post by curiousgeorge » Sun, Jun 01, 2008, 3:53 AM UTC

huh? whatever you do on the client machine you're still open to a man in the middle attack . hashing passwords simply make it more difficult for eavesdroppers to figure out the original password, and keep people from passing potentially sensitive information across the net in cleartext.

use SSL for things you need to keep secure, like credit card payments. If you can't set that up, outsource stuff to a payment provider like Paypal until you get your house in order. Otherwise be more clear about your security concerns in your write-up, so people know WHAT you are trying to solve instead of HOW you are trying to solve... something.

Re: Ask YC: Best Practices for User Authentication

#14

Post by DaniFong » Sun, Jun 01, 2008, 3:55 AM UTC

tptacek wrote: post #12

DaniFong wrote: post #8

Earlier quoted context omitted.

If you hash the password on the clientside, say, and then use that as the password in your scheme throughout, then you don't need to transmit the password in cleartext, ever.

This is a win because, even though you're sending something password-equivalent over the wire, at least you're not exposing a password that's used on other applications?

Precisely. For all the hackers ignoring it, there stands the simple fact: people reuse passwords over and over again, for bank accounts, email, and everything else. I don't know what the stats are, but I'd bet if you randomly query people in, say, your or family, you'll find quite a few. At least I did.

So while capturing a password over HTTP and replaying it gives access to someone's karma in a site like this, once you actually know the plaintext password you could, for many people, use it to break into otherwise secure sites (even using SSL), like gmail. This has serious reprecussions.

Finding a password over the wire is just like finding password: in a closed drawer. Sure, you don't know what it's for, but were you malicious, you'd be able to try a host of different places.

Re: Ask YC: Best Practices for User Authentication

#15

Post by markbao » Sun, Jun 01, 2008, 3:58 AM UTC

tptacek wrote: post #10

Also: any security scheme based off a simple hash function is going to require you to store cleartext passwords on the server side, meaning that any SQL injection vulnerability compromises, say, 10,000 user passwords.

Actually, I made a mistake in the diagram. The password will be hashed first, then the sha2(nonce + sha2(password)). Passwords will be stored server-side as sha2(password).

Can't update the post now, though.

Re: Ask YC: Best Practices for User Authentication

#16

Post by jsjenkins168 » Sun, Jun 01, 2008, 4:37 AM UTC

As was pointed out by tptacek, this approach is not secure because the javascript can be rewritten in transit. Also consider that javascript-based hashing will be extremely slow and could interfere with the user experience if the browser bogs down. And IE may show an error that performance is slow on your site.

There just is no way around it, the only way to be secure is use SSL to share secrets when you register. From then on you can just transmit an authenticator (stored in a secure cookie) comprised of an expiration timestamp, any identifying user data (like userID), and a non-malleable MAC digest of the expiration and userID. Doesn't protect against replay but it helps to enforce a short expiration for the authenticator. With this approach you'll only need to use SSL for the initial login.

This is the best explanation of web authentication I've encountered on the net [PDF]:

http://prisms.cs.umass.edu/~kevinfu/papers/webauth_tr.pdf

Re: Ask YC: Best Practices for User Authentication

#17

Post by DaniFong » Sun, Jun 01, 2008, 4:47 AM UTC

jsjenkins168 wrote: post #16

As was pointed out by tptacek, this approach is not secure because the javascript can be rewritten in transit. Also consider that javascript-based hashing will be extremely slow and could interfere with the user experience if the browser bogs down. And IE may show an error that performance is slow on your site. There just is no way around it, the only way to be secure is use SSL to share secrets when you register. Fr…

Depending on who you are, you could guard against javascript being rewritten by a man in the middle attack by running, say, a greasemonkey script that figures out when a password should be sent and hashing with the server domain automagically, so long as you can cache it locally. In this way, admins could secure clients against having their passwords stolen without any effort on the part of web-app writers, or users. Even a browser, say, Firefox, could do some version of this.

Really, digest authentication solves the same problem, but hardly anyone uses it.

Re: Ask YC: Best Practices for User Authentication

#18

Post by huhtenberg » Sun, Jun 01, 2008, 5:34 AM UTC

tptacek wrote: post #9

No security scheme delivered over Javascript is going to make a difference in a security audit. Your auditor is going to tell your prospective customer that anybody who controls the DNS, routing, the network, ARP, the browser --- or 10 other places --- can rewrite the Javascript in transit. If you can't do SSL, just do plaintext passwords. It means you're being open with your users about the risk.

Technically speaking, the first thing any decent security auditor will tell you is that certain security mechanism making or "not making a difference" depends solely on a threat model.

Challenge-response authentication protects against passive attacks (such as sniffing). Rewriting Javascript in transit implies an active attack scenario. In a majority of cases, yes, the active attacks are a part of a threat model, but there are deployment scenarios where they are not.

Re: Ask YC: Best Practices for User Authentication

#19

Post by boucher » Sun, Jun 01, 2008, 5:39 AM UTC

markbao wrote: post #15

tptacek wrote: post #10

Also: any security scheme based off a simple hash function is going to require you to store cleartext passwords on the server side, meaning that any SQL injection vulnerability compromises, say, 10,000 user passwords.

Actually, I made a mistake in the diagram. The password will be hashed first, then the sha2(nonce + sha2(password)). Passwords will be stored server-side as sha2(password). Can't update the post now, though.

This is basically what we do.

Re: Ask YC: Best Practices for User Authentication

#20

Post by SA » Sun, Jun 01, 2008, 5:42 AM UTC

dfranke wrote: post #7

markbao wrote: post #6

Earlier quoted context omitted.

No difficulty in implementing SSL, but I'm a student and don't have much money. Granted, this is a temporary solution until I'm able to get some money together for a dedicated IP and SSL cert.

You can do SSL very cheaply these days. GoDaddy has certificates for $15/year. Dreamhost gives you a dedicated IP for an extra $4/month.

Given the fact that how cheap it is these days to get SSL certificates and static IPs I would take the route of SSL rather than going thru this untested (read: not well tested) route of JavaScript encryption.

http://www.hitlinkz.com