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

Re: Ask YC: Best Practices for User Authentication

#31

Post by tptacek » Sun, Jun 01, 2008, 3:36 PM UTC

huhtenberg wrote: post #18

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…

Name one.

Re: Ask YC: Best Practices for User Authentication

#32

Post by tptacek » Sun, Jun 01, 2008, 3:39 PM UTC

notauser wrote: post #28

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 acce…

"Wire-sniffing passwords" is far more difficult than redirecting traffic. I think you're totally off.

CHAP, by the way, is a bad protocol. It's mutual-auth challenge-response, and there are a bunch of gotchas to implementing it. Even the trivial challenge-response protocols proposed on this message board are better for web auth than CHAP.

(Edit: apart from my tone [heh], I wonder if readers are recoiling from the idea that something they can do on the command line with "tcpdump" is "hard". If you're trying to collect 1000 passwords, which machine do you crack to see 1000 sessions?)

Re: Ask YC: Best Practices for User Authentication

#33

Post by tptacek » Sun, Jun 01, 2008, 3:51 PM UTC

ComputerGuru wrote: post #26

ben_h wrote: post #24

Earlier quoted context omitted.

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.

Uh... and the page that includes the JS, which is part of your app... comes from where?

Re: Ask YC: Best Practices for User Authentication

#34

Post by tptacek » Sun, Jun 01, 2008, 4:05 PM UTC

johnm wrote: post #25

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/d…

Stay away from SRP. Browsers don't support it natively, and there are (so far as I can tell) no peer-reviewed libraries for it for the major web stacks. SRP is easy to get wrong.

Re: Ask YC: Best Practices for User Authentication

#35

Post by tptacek » Sun, Jun 01, 2008, 4:08 PM UTC

DaniFong wrote: post #17

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

I know you're just trying to add a layer here, but if you think this through, you'll probably see that GreaseMonkey does not win against content-controlled Javascript for its own site. Firefox has had a hard enough time just keeping content-controlled Javascript from breaking into Chrome.

As a simple example, note the fact that the "when the password should be sent" signal originates from content-controlled JS, which controls the DOM. Note also that with same-origin out of the picture, the content-controlled JS can choose to send the password whenever it wants.

Re: Ask YC: Best Practices for User Authentication

#36

Post by gommm » Sun, Jun 01, 2008, 6:43 PM UTC

markbao wrote: post #30

theg wrote: post #29

Earlier quoted context omitted.

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.

The only usefulness of the salt is if somebody steals your database and uses a rainbow table to try to get the passwords. If you don't have salts for each users, then a pre-generated rainbow table for sha1 based on common passwords is going to be very efficient at getting the passwords for each account. If you use salt however, you are protected from the use of pre-generated tables since the attacker has to brute force all the combinations for each user. If you use sha1 or md5 it's still not too secure since sha1 and md5 are fast to calculate and getting faster with this : http://nsa.unaligned.org/hw.php

Read http://www.matasano.com/log/958/enough-with-the-rainbow-tabl... from tptacek, it's very informative...

Of course, the big problem with the javascript way explained here is that you send sha2(nounce + sha2(password+salt)) This means, that anybody who get access to the database can send sha2(nounce + hash_from_database) So basically in this case using salt in the database prevent people from getting the password too easily (so it sorts protects the attacker from getting a password associated with an email address that he could try later on paypal), but it doesn't protect the account in any way...

And for those who think that it's unlikely for anybody to get access to the database, it happened to the reddit guys...

Re: Ask YC: Best Practices for User Authentication

#37

Post by gommm » Sun, Jun 01, 2008, 6:58 PM UTC

jrockway wrote: post #3

You've basically reimplemented HTTP Digest auth, although not quite as well. The problem with your implementation is that the server needs to know the cleartext password. With digest auth, the server never has the clear password, (only a digest thereof) although it can use the digest to authenticate to other services with the same digest. It doesn't really matter though, since passwords are very insecure and users kn…

The problem is that most users are not programmers, are not at all interested in computer security... So, no maybe most people here would not use an important password for yc news... But the average user doesn't think about this and knowing this can you really say that it's there fault for not being educated on computer security?

Anyway, since you do the right thing: SSL + bcrypt, good but don't say it's the user problem if the system gets compromised...

Re: Ask YC: Best Practices for User Authentication

#38

Post by DaniFong » Sun, Jun 01, 2008, 6:59 PM UTC

tptacek wrote: post #35

DaniFong wrote: post #17

Earlier quoted context omitted.

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

I know you're just trying to add a layer here, but if you think this through, you'll probably see that GreaseMonkey does not win against content-controlled Javascript for its own site. Firefox has had a hard enough time just keeping content-controlled Javascript from breaking into Chrome. As a simple example, note the fact that the "when the password should be sent" signal originates from content-controlled JS, which…

Sure, it's not meant to be foolproof. I only wanted sometime to secure the login for the large number of sites taking passwords with plaintext. Right now it's completely a statistics game -- you can just stand outside someone's wireless network capturing packets. If it's insecure or WEP, you'll be able to recover the key, then grepping through with password=_ will eventually give you a password to use on their favorite sites.

I do think security is a matter of degree. And currently authentication is but a few removed from wide open.

Re: Ask YC: Best Practices for User Authentication

#39

Post by tptacek » Sun, Jun 01, 2008, 7:07 PM UTC

DaniFong wrote: post #38

tptacek wrote: post #35

Earlier quoted context omitted.

I know you're just trying to add a layer here, but if you think this through, you'll probably see that GreaseMonkey does not win against content-controlled Javascript for its own site. Firefox has had a hard enough time just keeping content-controlled Javascript from breaking into Chrome. As a simple example, note the fact that the "when the password should be sent" signal originates from content-controlled JS, which…

Sure, it's not meant to be foolproof. I only wanted sometime to secure the login for the large number of sites taking passwords with plaintext. Right now it's completely a statistics game -- you can just stand outside someone's wireless network capturing packets. If it's insecure or WEP, you'll be able to recover the key, then grepping through with password=_ will eventually give you a password to use on their favori…

This is why app developers should be using SSL. I have no smart-assed responses to an HTTPS login screen. No ad hoc hashing schemes required.

Re: Ask YC: Best Practices for User Authentication

#40

Post by thaumaturgy » Sun, Jun 01, 2008, 7:08 PM 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?

Can we have it both ways? Transmit a password-equivalent over the wire, without compromising the security of the password database?

How about using a cryptographically strong hash on the client side, transmitting that hash to the server, and then having the server perform another cryptographically strong hash on the hash it receives, and compare that against its database? This way, the server isn't storing the passwords in the clear anywhere, and there is still at least some protection against having users' passwords picked out of the air -- even, I think, during the user's initial registration.

I realize that any client-side code designed to do this can be compromised by a man-in-the-middle attack, forcing the user's password out into the open. This isn't meant to be perfect security, it's just meant to provide one extra layer of protection for the individual user's password(s), without compromising the database as a whole.