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

81–90 of 144 posts

Re: Storing Passwords Securely

#81

Post by SCdF »

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.

On the other other hand, I don't really like the idea of 1) tying all my accounts to Google (what happens when I want to get rid of my Google account? Or my Google account gets locked?) or 2) having Google / FB be aware of other websites I log into,

Re: Storing Passwords Securely

#82

Post by jp_sc »

pud wrote: post #69

The article says to give each password its own unique salt and then store the salt (as well as the salted hash) in the database. This seems like a bad idea to me. If a hacker gets access to the salted passwords, in this case he'll probably figure out how to get access to the salts too. I figure if the salt is stored in the code (or a config file...) rather than the database itself, at least it's two different hacks t…

The individual salts are added only to prevent an attack with a list of pre-calculated hashes. You could also store another common salt ("pepper"?) in the code.

Re: Storing Passwords Securely

#83

Post by stickfigure »

SCdF wrote: post #81
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.

On the other other hand, I don't really like the idea of 1) tying all my accounts to Google (what happens when I want to get rid of my Google account? Or my Google account gets locked?) or 2) having Google / FB be aware of other websites I log into,

BrowserID specifically addresses these concerns.

Re: Storing Passwords Securely

#84

Post by romaniv »

Dylan16807 wrote: post #79
rorrr wrote: post #65

> MD5, SHA-1, SHA-256, SHA-512, et al, are not "password hashes." By all means use them for message authentication and integrity checking, but not for password authentication. Bullshit. MD5 is just fine, as long as you use the salt. Here, hack this: MD5(password + salt) = "b520542710812f347432232b2a1fba83" salt = "MD5 rules"

MD5 is 'fine' for very long passwords. How many of your users have very long passwords? MD5 does nothing to make it hard to blaze through billions of possibilities.

Theoretically and even practically, MD5 has other issues. It susceptible to collisions:

http://www.mscs.dal.ca/~selinger/md5collision/

Re: Storing Passwords Securely

#85

Post by cperciva »

AgentConundrum wrote: post #49
sillysaurus wrote: post #7

I know I won't be able to easily convince anyone of this, but I thought I'd mention... Colin Percival's "scrypt" password hash is: 1) production-ready (and has been for a long time) 2) superior to bcrypt, as it is designed to be expensive in both CPU and memory (hence, scrypt is "memory-hard", whereas bcrypt is not) I don't have time to go into further detail. I encourage you to check it out. It's quite simply "the f…

I think I answered my own question, but I'll ask anyway - why does memory intensiveness matter?

For a "worst-case" attacker -- one who can fab his own ASICs -- cost is proportional to the area of silicon used. RAM takes up die area, and it's something commodity systems have plenty of.

Basically it's a matter of "what do we have which they would have to pay extra for".

Re: Storing Passwords Securely

#86

Post by damncabbage »

pud wrote: post #69

The article says to give each password its own unique salt and then store the salt (as well as the salted hash) in the database. This seems like a bad idea to me. If a hacker gets access to the salted passwords, in this case he'll probably figure out how to get access to the salts too. I figure if the salt is stored in the code (or a config file...) rather than the database itself, at least it's two different hacks t…

Upvoting you for asking the question.

Too often people assume one way or the other (and come up with their own hare-brained password encryption scheme, defending it from all-comers).

Re: Storing Passwords Securely

#87

Post by [deleted] »

pud wrote: post #69

The article says to give each password its own unique salt and then store the salt (as well as the salted hash) in the database. This seems like a bad idea to me. If a hacker gets access to the salted passwords, in this case he'll probably figure out how to get access to the salts too. I figure if the salt is stored in the code (or a config file...) rather than the database itself, at least it's two different hacks t…

[deleted]

Re: Storing Passwords Securely

#88

Post by tveita »

tptacek wrote: post #58
indygreg2 wrote: post #35

Earlier quoted context omitted.

Assuming all the steps in the article are followed, yes, you are correct. I still think any article talking about verifying credentials is obligated to mention that string comparison could be an attack vector. Like I said, it plants a seed. And, I've seen way too many naive implementations where it is needed (like simple token-based auth systems) to know that this seed needs to be spread a lot more.

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 password is hashed, then compared with ==, taking some variable time we'll assume can be measured.

We use an iterated timing attack to discover a prefix of the password hash, then run an offline dictionary or brute force attack using that prefix. Passwords that match the known part of the hash are tried online, potentially revealing more of the hash as we go.

> It feels sometimes like people hear about the idea of timing attacks and then want to see them everywhere.

When it comes to side channel attacks, "vulnerable" is the default state.

Re: Storing Passwords Securely

#89

Post by romaniv »

ghshephard wrote: post #74
rorrr wrote: post #65

> MD5, SHA-1, SHA-256, SHA-512, et al, are not "password hashes." By all means use them for message authentication and integrity checking, but not for password authentication. Bullshit. MD5 is just fine, as long as you use the salt. Here, hack this: MD5(password + salt) = "b520542710812f347432232b2a1fba83" salt = "MD5 rules"

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.

Re: Storing Passwords Securely

#90

Post by pmylund »

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…

How does this matter given a proper avalanche effect?
Post reply on HN