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

Re: Ask YC: Best Practices for User Authentication

#21

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

tptacek wrote: post #11

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?

You can store a hash of the password in the DB as opposed to the password itself. The only time the actual plaintext password needs to be passed is at registration time, and even then you could add another hash step to get rid of that. What you can't get rid of is having to transmit something that is equivalent to the password at registration time, but you can at login time. The nonce (and a transaction id) let you construct a system that isn't susceptible to replay attacks.

Re: Ask YC: Best Practices for User Authentication

#22

Post by brfox » Sun, Jun 01, 2008, 5:46 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.

I'm no expert... but what if just the javascript was served via https? Maybe somebody ought to put an MD5 javascript library on an https server as a public service. Or would js hashing still be vulerable since the man-in-the-middle could change the nonce or something?

Re: Ask YC: Best Practices for User Authentication

#23

Post by gojomo » Sun, Jun 01, 2008, 5:50 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?

This is the general idea behind the Stanford 'PwdHash' approach and associated browser extension [1].

[1] http://crypto.stanford.edu/PwdHash/

Re: Ask YC: Best Practices for User Authentication

#24

Post by ben_h » Sun, Jun 01, 2008, 6:18 AM UTC

brfox wrote: post #22

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.

I'm no expert... but what if just the javascript was served via https? Maybe somebody ought to put an MD5 javascript library on an https server as a public service. Or would js hashing still be vulerable since the man-in-the-middle could change the nonce or something?

If you're going to serve Javascript over SSL, you need a full SSL setup including a valid certificate, etc. If you have that, you may as well just serve the login form itself over HTTPS, redirecting back to HTTP after logging the user in, and forget the Javascript altogether.

Re: Ask YC: Best Practices for User Authentication

#25

Post by johnm » Sun, Jun 01, 2008, 8:20 AM UTC

In practical terms, just use HTTPS with rooted certs. It's not expensive for basic usage. And, if you're just doing a for-fun project you can always use self-signed certs.

If you want to go deeper down the rabbit hole check out SRP: http://srp.stanford.edu/

In terms of dealing more securely with data on your server, check out the book, Translucent Databases ( http://www.amazon.com/Translucent-Databases-Peter-Wayner/dp/... )

Re: Ask YC: Best Practices for User Authentication

#26

Post by ComputerGuru » Sun, Jun 01, 2008, 9:06 AM UTC

ben_h wrote: post #24

brfox wrote: post #22

Earlier quoted context omitted.

I'm no expert... but what if just the javascript was served via https? Maybe somebody ought to put an MD5 javascript library on an https server as a public service. Or would js hashing still be vulerable since the man-in-the-middle could change the nonce or something?

If you're going to serve Javascript over SSL, you need a full SSL setup including a valid certificate, etc. If you have that, you may as well just serve the login form itself over HTTPS, redirecting back to HTTP after logging the user in, and forget the Javascript altogether.

He means someone set up a a JS library over HTTPS on a server for _others_ to use. Like you would grab a JS library off of Google's HTTPS servers and use that on your non-SSL pages.

Re: Ask YC: Best Practices for User Authentication

#27

Post by swombat » Sun, Jun 01, 2008, 11:54 AM UTC

SA wrote: post #20

dfranke wrote: post #7

Earlier quoted context omitted.

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

Please don't spam your URL, especially not as your signature. That's (very) bad form.

Re: Ask YC: Best Practices for User Authentication

#28

Post by notauser » Sun, Jun 01, 2008, 2:04 PM 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.

Attacks that require an in-flight rewrite of the client side element of the authentication method are several orders of magnitude more difficult than wire sniffing for passwords, which is not an insignificant barrier when we are talking about a 15/30 minute at-the-coffee shop attack window.

Wire sniffing won't work in a properly implemented scheme as the server doesn't trust the client in any way. All it does is accept transactions that contain appropriate authentication tokens that can be independently verified by the server. This means that your attack would need to insert a hook into the JavaScript to push the contents of any password field to a box under the attacker's control.

(Assuming there is a shared secret between server and client (eg, a password set up over SSL) then CHAP can provide authentication without the shared secret ever being available on the wire without it being (salted+hashed). The language used to implement the system makes no difference (provided you have a good source of random numbers available on at least the server, and a strong hash function). Even if you can't do SSL to set up the password this still has value over plain text, as it allows people to set up passwords on trusted connections (corporate LAN, wired ISP) and not expose them on untrusted networks (coffee shop wifi) to the most common form of attack - passive logging.)

Re: Ask YC: Best Practices for User Authentication

#29

Post by theg » Sun, Jun 01, 2008, 3:16 PM 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.

Your method for storing the passwords server-side is actually not very secure. Hashing the passwords without a unique salt is not a secure way to store them.

For one thing, every user with the password of 'secret' will have the same hash in your database. Secondly, if I were to steal all of your password hashes, I would just have to compute sha2 of every 6-8 (or whatever password length you are using) character string. With a 32 character salt, I would have to compute a sha2 of every 38-40 character string, making my job a more time consuming.

Re: Ask YC: Best Practices for User Authentication

#30

Post by markbao » Sun, Jun 01, 2008, 3:20 PM UTC

theg wrote: post #29

markbao wrote: post #15

Earlier quoted context omitted.

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.

Your method for storing the passwords server-side is actually not very secure. Hashing the passwords without a unique salt is not a secure way to store them. For one thing, every user with the password of 'secret' will have the same hash in your database. Secondly, if I were to steal all of your password hashes, I would just have to compute sha2 of every 6-8 (or whatever password length you are using) character strin…

The thing with a salt is that - would you include the salt in the Javascript hashing system? like sha2(nonce + sha2(password + hash)) ? If so, then the salt isn't really that useful - you can then just compute sha2 of 6-8 letters + salt.