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

Project Euler Returns

projecteuler.net

Post reply on HN
Print view View original

61–70 of 104 posts

Re: Project Euler Returns

#61

Post by e12e »

taeric wrote: post #23
bellerocky wrote: post #22

Earlier quoted context omitted.

> "Account recovery will no longer be possible." A site that purports to teach is incapable of learning of how to strike a balance between securing confidential information and making it possible to recover an account. This is a solved problem. If my bank can have a password recovery system, a site about numbers can have one too. > " With respect to this issue it is quite possible that some members will have genuinel…

To be fair, your bank likely has a bit more money to throw at this problem. I would think in this case the entire point is not so much to help them secure stuff, but an attempt to remove them as a target for hacking in the first place.

> To be fair, your bank likely has a bit more money to throw at this problem.

I suppose they could charge 1 USD for (lifetime) membership and store the last four digits of your credit card in lieu of a username, so that they could easily look up the salt that gives the salt with witch they've hashed your email... ;-)

(Would require that you could supply the last digits of your possibly expired credit card, when you lost the password ten years hence ...)

Re: Project Euler Returns

#62

Post by jgeralnik »

sp332 wrote: post #59
SkyMarshal wrote: post #53

Earlier quoted context omitted.

A little off topic, but is there any reason to still be talking about salted hashes when we have bcrypt and scrypt these days? Seems like an anachronism.

An attacker can pre-compute hashes of common passwords for common settings of bcrypt/scrypt. With a salt, they have to start from scratch every time.

bcrypt and scrypt are always salted (it's part of their algorithms - there is not such thing as unsalted bcrypt/scrypt)

Re: Project Euler Returns

#63

Post by ntpl »

e12e wrote: post #60
stouset wrote: post #46

Earlier quoted context omitted.

A salted hash would completely eliminate any ability to look up accounts by email address, since you would have to hasn't the email against the salt for every account in the database until you landed on the correct one.

Hello? Lets say you have 5 billion accounts, in salted sha1. According to openssl speed sha1, you'd take less than 38 minutes on my ancient desktop to look up an email, on average half that. If the shoe fits, send the email, if not don't? Sure having another field to match on (eg: username) for locating the correct salt would be good -- but it's certainly not infeasible to do a brute force search (probably want to qu…

Taking unnecessarily long to handle a lookup request might leave server very vulnerable to DDoS attacks leveraging this "account recovery" option, I think.

Even worse, an invalid email would take the longest possible time, every time.

And since this is only an email address we are talking about, a global salt + more stretching (like runamok mentioned above) could be secure enough while still providing faster lookups.

Re: Project Euler Returns

#65

Post by stouset »

e12e wrote: post #60
stouset wrote: post #46

Earlier quoted context omitted.

A salted hash would completely eliminate any ability to look up accounts by email address, since you would have to hasn't the email against the salt for every account in the database until you landed on the correct one.

Hello? Lets say you have 5 billion accounts, in salted sha1. According to openssl speed sha1, you'd take less than 38 minutes on my ancient desktop to look up an email, on average half that. If the shoe fits, send the email, if not don't? Sure having another field to match on (eg: username) for locating the correct salt would be good -- but it's certainly not infeasible to do a brute force search (probably want to qu…

38 minutes to log into your account seems excessive. Remember, this isn't just for password resets — it's to look up an account in the database by email address.

Re: Project Euler Returns

#66

Post by stouset »

sp332 wrote: post #59
SkyMarshal wrote: post #53

Earlier quoted context omitted.

A little off topic, but is there any reason to still be talking about salted hashes when we have bcrypt and scrypt these days? Seems like an anachronism.

An attacker can pre-compute hashes of common passwords for common settings of bcrypt/scrypt. With a salt, they have to start from scratch every time.

No. No, they cannot.

Re: Project Euler Returns

#67

Post by Arnor »

runamok wrote: post #58
stouset wrote: post #46

Earlier quoted context omitted.

A salted hash would completely eliminate any ability to look up accounts by email address, since you would have to hasn't the email against the salt for every account in the database until you landed on the correct one.

You could have one of two approaches. 1. Don't use a per user salt and just use a global salt. You can counteract this decrease (a bit) in security by increasing the key stretching part of your hashing algorithm. or 2. Require the user to submit their email address AND username and store the salt in the user's record. I agree with someone up there that email address != password. It's refreshing to see someone that gi…

I had a visceral reaction to "global salt" (I've always heard this called: "pepper") because it's so insecure for passwords, but I guess it's not as bad for email addresses. In the case of passwords, we find that a global salt is fairly ineffective because too many people use common (stupid) passwords like "password." If 10% of the hashes are the same, you can probably figure out what that hash means pretty quickly. We don't have this overlap problem with emails so it's less scary.

Still, simply storing the create time or a randomly generated salt right on the user table is more secure than using a global salt.

Re: Project Euler Returns

#68

Post by Arnor »

ntpl wrote: post #63
e12e wrote: post #60

Earlier quoted context omitted.

Hello? Lets say you have 5 billion accounts, in salted sha1. According to openssl speed sha1, you'd take less than 38 minutes on my ancient desktop to look up an email, on average half that. If the shoe fits, send the email, if not don't? Sure having another field to match on (eg: username) for locating the correct salt would be good -- but it's certainly not infeasible to do a brute force search (probably want to qu…

Taking unnecessarily long to handle a lookup request might leave server very vulnerable to DDoS attacks leveraging this "account recovery" option, I think. Even worse, an invalid email would take the longest possible time, every time. And since this is only an email address we are talking about, a global salt + more stretching (like runamok mentioned above) could be secure enough while still providing faster lookups.

Of course, you could protect from the DDoS by maintaining a secondary application server which connects to a slave database. Then the requests for account recovery wouldn't impact the rest of the system. :)

Re: Project Euler Returns

#69

Post by runamok »

Arnor wrote: post #67
runamok wrote: post #58

Earlier quoted context omitted.

You could have one of two approaches. 1. Don't use a per user salt and just use a global salt. You can counteract this decrease (a bit) in security by increasing the key stretching part of your hashing algorithm. or 2. Require the user to submit their email address AND username and store the salt in the user's record. I agree with someone up there that email address != password. It's refreshing to see someone that gi…

I had a visceral reaction to "global salt" (I've always heard this called: "pepper") because it's so insecure for passwords, but I guess it's not as bad for email addresses. In the case of passwords, we find that a global salt is fairly ineffective because too many people use common (stupid) passwords like "password." If 10% of the hashes are the same, you can probably figure out what that hash means pretty quickly.…

Right but in this case you would essentially have to use every salt from every user to hash the submitted email and say "aha user 123,456 has a salt and hashed email which matches the submitted email of foo@example.com" which is why I suggested method 2. I am user "Arnor" and my email is "foo@example.com". Ok, your salt is #@$%@#$%DGDFfdgdawer.

If your hashing algorithm is appropriately "expensive" the scan all user salts would not work.

Re: Project Euler Returns

#70

Post by e12e »

stouset wrote: post #65
e12e wrote: post #60

Earlier quoted context omitted.

Hello? Lets say you have 5 billion accounts, in salted sha1. According to openssl speed sha1, you'd take less than 38 minutes on my ancient desktop to look up an email, on average half that. If the shoe fits, send the email, if not don't? Sure having another field to match on (eg: username) for locating the correct salt would be good -- but it's certainly not infeasible to do a brute force search (probably want to qu…

38 minutes to log into your account seems excessive. Remember, this isn't just for password resets — it's to look up an account in the database by email address.

Ah, fair point. So we agree they need a (possibly not unique) user name too. [edit: note this is for 5 billion accounts, on a 10 year old cpu. So for 500.000 accounts, it would be ~1 seconds (average 0.5). Still probably too long for log-in (or particularly log-in failure feedback)).]
Post reply on HN