Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Storing Passwords Securely

throwingfire.com

Post reply on HN
Print view View original

91–100 of 144 posts

Re: Storing Passwords Securely

#91

Post by untog »

stickfigure wrote: post #71
dekz wrote: post #67

Earlier quoted context omitted.

This naively assumes that your entire userbase uses those services and would like to attribute their Google (et al) account with your service. This may not always be the case. Someone has to store the passwords, it would be good if there was a way you could be assured your data at rest was safe.

If you believe your userbase will object to Google/Twitter/FB, use BrowserID. Personally, I never feel particularly secure when typing passwords into text boxes on random PHP forms. On the other hand, I feel fairly confident that the folks at FB, Google, Twitter, and Mozilla know how to store a password and secure their infrastructure.

What's the browser support level of BrowserID at this point? How does BrowserID transfer between the different browsers I use? Can I log in using BrowserID on my phone?

Re: Storing Passwords Securely

#92

Post by tptacek »

tveita wrote: post #88
tptacek wrote: post #58

Earlier quoted context omitted.

No, not assuming that. It has nothing to do with the specific steps. To see why, try to imagine a scenario where there could be an operator== timing attack on a password hash . It feels sometimes like people hear about the idea of timing attacks and then want to see them everywhere.

> try to imagine a scenario where there could be an operator== timing attack on a password hash Sure, that's simple. You're leaking information about the password hash to the attacker, which they can use to speed up an attack where they have large offline resources but are limited in their online guessing capacity. Let's e.g. assume we have an unsalted hash, but the system limits us to one guess per second. The passw…

Does this sound remotely plausible to you? In all of /usr/share/dict/words, there are four (4) 4-byte prefix collisions of SHA1 hashes - 0.0016% of all the entries. That 4-byte prefix is just 1/5th of the total size of the SHA1 hash.

Re: Storing Passwords Securely

#93

Post by wtracy »

stickfigure wrote: post #75
Dylan16807 wrote: post #70

Earlier quoted context omitted.

Salts are not secret. They make you run unique calculations per attacked password and do absolutely nothing else. You might feel like adding a hidden component but it won't noticeably help security and it's not a salt.

Furthermore, it's important that the salt be unique per password . If you had a single common salt in your code, then two users with the same password would produce the same hash.

Every salt example I've run across until now used the same salt for every password in the database. Obviously I can disregard those examples!

Thanks for bringing this up--the concept of salt makes a lot more sense to me now.

Re: Storing Passwords Securely

#94

Post by pmylund »

romaniv wrote: post #89
ghshephard wrote: post #74

Earlier quoted context omitted.

I mean this in the most polite and professional manner possible, please take five minutes and read http://codahale.com/how-to-safely-store-a-password/ . It will explain why "salts are useless for preventing dictionary attacks or brute force attacks." The entire article is excellent - and every colleague who I've ever pointed at it, has come away nodding their head and seeing the light. The key-takeway (but please, re…

So here is a question that I've asked and received no good answer. Why size of the salt doesn't matter? Wouldn't salt be used in every hash computation? Wouldn't large (megabytes) salt slow down this computation and require more memory to perform it? I'm not advocating the use of large salt as opposed to specialized functions, I'm just curious as to why it doesn't work. The article doesn't explain that.

It's not that the size doesn't matter; it's just that it's not as significant. It becomes very, very hard to compute rainbow tables after just a few random bytes. No matter how long the salt is, it doesn't do anything to prevent somebody from trying to guess the original input for a given digest using a brute force approach, though. So usually the salt has less than e.g. 256 bits of entropy just because it takes up less space.

Sure, a very large salt might slow down the first iteration a little (but not necessarily subsequent ones, and it wouldn't require more memory, at least with most hash functions), so you're almost always better off just stretching the key--then you save the storage costs too.

Re: Storing Passwords Securely

#95

Post by turnersr »

daeken wrote: post #64
tptacek wrote: post #13

Earlier quoted context omitted.

You are going to have a hard time finding a professional cryptographer who will look at scrypt and say that it's risky. These are KDFs, not message authentication codes; they aren't risky constructions. If you have no other choice but to iterate SHA1 many thousands of times, that's still better than what most apps do, and in the grand scheme of things almost "ok". scrypt is fine. If you have a library that supports i…

> If you have no other choice but to iterate SHA1 many thousands of times, that's still better than what most apps do, and in the grand scheme of things almost "ok". While I won't recommend people simply iterating a hash many times, I also won't slap people down for it anymore. In the grand scheme of things, there are a billion more likely routes of attack than someone breaking your 20000-rounds-of-SHA1 hashes.

Out of curiosity, what do you recommend people use?

Re: Storing Passwords Securely

#96

Post by stickfigure »

untog wrote: post #91
stickfigure wrote: post #71

Earlier quoted context omitted.

If you believe your userbase will object to Google/Twitter/FB, use BrowserID. Personally, I never feel particularly secure when typing passwords into text boxes on random PHP forms. On the other hand, I feel fairly confident that the folks at FB, Google, Twitter, and Mozilla know how to store a password and secure their infrastructure.

What's the browser support level of BrowserID at this point? How does BrowserID transfer between the different browsers I use? Can I log in using BrowserID on my phone?

It's good. I use it (dual-auth with FB) in a production system (https://www.voo.st/) and it works great from every browser I've tried so far, including iOS and Android.

The biggest UX issue is currently the up-front email roundtrip for new accounts. In the long run this experience will improve considerably when primary identity providers support the protocol directly. In the short run it's still not bad.

Re: Storing Passwords Securely

#97

Post by DanBC2 »

stickfigure wrote: post #50
pmylund wrote: post #46

Earlier quoted context omitted.

OpenID and OAuth really did a lot, but there's just nothing called "don't use passwords." Fingerprint readers suck. Anything biometric that doesn't suck costs too much, and 99% of people don't have them. A good KDF is not bad in comparison to a centralized authentication server considering other factors. Someone, somewhere will be storing user passwords/digests for the foreseeable future. And they will do it incorrec…

Sure, but the number of those people should become vanishingly small over time. HN is full of web developers rolling unnecessary username/password solutions. The fact that this is such a hot issue - as opposed to esoterica like TCP frame size - shows that far too many developers are homebrewing solutions rather than outsourcing.

Fravia used to talk about dongle protection. He was impressed with some of the dongles and the libraries, saying that they were basically secure. But he was not impressed with the ways that companies implemented those dongle protections - sometimes not bothering with any of the advanced features and just using a stupidly simple "dongle present? then run software, otherwise show nag screen" test.

Would this be a problem with hashing libraries? Are there any that require very little knowledge for people to implement them correctly?

Re: Storing Passwords Securely

#98

Post by tveita »

tptacek wrote: post #92
tveita wrote: post #88

Earlier quoted context omitted.

> try to imagine a scenario where there could be an operator== timing attack on a password hash Sure, that's simple. You're leaking information about the password hash to the attacker, which they can use to speed up an attack where they have large offline resources but are limited in their online guessing capacity. Let's e.g. assume we have an unsalted hash, but the system limits us to one guess per second. The passw…

Does this sound remotely plausible to you? In all of /usr/share/dict/words, there are four (4) 4-byte prefix collisions of SHA1 hashes - 0.0016% of all the entries. That 4-byte prefix is just 1/5th of the total size of the SHA1 hash.

Why, yes, it's eminently doable. Even a single byte will let you discard 255 out of 256 attempts, and as you kindly point out, 4 bytes would be enough to uniquely identify almost any word in the standard dictionary.

Feel free to peruse some SHA-256 hashes with slightly above six bytes of fixed prefix - several orders of magnitude more difficult to find than a mere 32 bits partial collision: http://blockexplorer.com/

Now you can argue about how likely it is for an attacker to actually bother to find and exploit such a weakness, and how a salt would mitigate the severity and so forth, but the takeaway here is that this attack can be trivially and permanently defeated by using a timing independent comparison function.

Re: Storing Passwords Securely

#99

Post by lhnn »

wtracy wrote: post #93
stickfigure wrote: post #75

Earlier quoted context omitted.

Furthermore, it's important that the salt be unique per password . If you had a single common salt in your code, then two users with the same password would produce the same hash.

Every salt example I've run across until now used the same salt for every password in the database. Obviously I can disregard those examples! Thanks for bringing this up--the concept of salt makes a lot more sense to me now.

Ya, that's silly.

A common and simple password setup is hash(username+password) or hash(private_account_attribute+password).

Also, use bcrypt/scrypt/similar.

Re: Storing Passwords Securely

#100

Post by tptacek »

tveita wrote: post #98
tptacek wrote: post #92

Earlier quoted context omitted.

Does this sound remotely plausible to you? In all of /usr/share/dict/words, there are four (4) 4-byte prefix collisions of SHA1 hashes - 0.0016% of all the entries. That 4-byte prefix is just 1/5th of the total size of the SHA1 hash.

Why, yes, it's eminently doable. Even a single byte will let you discard 255 out of 256 attempts, and as you kindly point out, 4 bytes would be enough to uniquely identify almost any word in the standard dictionary. Feel free to peruse some SHA-256 hashes with slightly above six bytes of fixed prefix - several orders of magnitude more difficult to find than a mere 32 bits partial collision: http://blockexplorer.com/…

The "timing leak" here does not uniquely identify any word in the dictionary; the attacker is on the opposite side of the problem. This attack is implausible.
Post reply on HN