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

How to Safely Store Your Users' Passwords in 2016

paragonie.com

Post reply on HN
Print view View original

91–100 of 321 posts

Re: How to Safely Store Your Users' Passwords in 2016

#91

Post by brazzledazzle »

[deleted] wrote: post #82
Someone1234 wrote: post #70

Earlier quoted context omitted.

> 3DES is a block cipher. MD5 is a crytographic hash. 3DES is both a block cipher and a cryptographic hash. At least UNIX thought so in the 1990s as many MANY people were storing UNIX passwords in 3DES, DES, MD5, and similar. > Neither of them are password hashes. 25 years of computing history would disagree with you. MD5 was the defacto standard for password hashing for almost fifteen years. But no doubt you'd playi…

[deleted]

I think everyone is getting a little to emotionally invested here. Might be a good time to take a step back and detach a bit. Apologies for interrupting your conversation, I just don't like seeing everyone going for each other's throats on HN.

"Be excellent to each other."

Re: How to Safely Store Your Users' Passwords in 2016

#92

Post by sarciszewski »

Joeri wrote: post #88
herbst wrote: post #79

Earlier quoted context omitted.

Wouldnt this happen with pretty much anything that is not threaded by default? Clearly with PHP you give a fuck, but i assume its not different with Ruby, Python, Go, ASP or anything else. You just usually use them threaded.

PHP is usually deployed in a FastCGI multiprocess setup, so the server will keep handling requests on the other processes while the hashing process is blocked. I wonder whether threading really saves you, given that there are only so many cores in a system and password hashing is CPU heavy. Naively it seems a DoS would involve sending as many parallel requests as there are cores, which is not a lot and can easily be…

The blog post that HN is reading is served by PHP-FPM + nginx, without any extra special features to handle the load of an unexpected "oh hey we made it to the front page of HN".

It's also hosted on a relatively cheap VPS.

Re: How to Safely Store Your Users' Passwords in 2016

#94

Post by tptacek »

serge2k wrote: post #76

> PBKDF2 (nearly everyone except FIPS agrees this is the worst of the acceptable options) is that true?

Only in the most technical sense: cycle for cycle, PBKDF2 gets you the smallest amount of protection from that group of password hashes. PBKDF2 is still vastly better than non- password hashes like salted SHA.

Re: How to Safely Store Your Users' Passwords in 2016

#95

Post by Justsignedup »

Wish there was a site where it lists algorithms and gives a table, and an ability to compare it to x years ago:

algorith | fairly safe difficulty (all variables) | very safe difficulty without incurring too much performance cost.

pbkdf + sha1 | completely unsafe | completely unsafe

pbkdf + sha2 | 100000 | ...

pbkdf + sha256

bcrypt

scrypt

argon2

Re: How to Safely Store Your Users' Passwords in 2016

#96

Post by Someone1234 »

[deleted] wrote: post #82
Someone1234 wrote: post #70

Earlier quoted context omitted.

> 3DES is a block cipher. MD5 is a crytographic hash. 3DES is both a block cipher and a cryptographic hash. At least UNIX thought so in the 1990s as many MANY people were storing UNIX passwords in 3DES, DES, MD5, and similar. > Neither of them are password hashes. 25 years of computing history would disagree with you. MD5 was the defacto standard for password hashing for almost fifteen years. But no doubt you'd playi…

[deleted]

> This is a really dumb semantic argument. You're arguing over the meaning of what I said upthread. I will spell it out for you:

No, I'm not. And never was.

Someone replied to me splitting hairs over the term. I never even brought it up.

Did you reply to the right post?

Re: How to Safely Store Your Users' Passwords in 2016

#97

Post by marcosdumay »

herbst wrote: post #79
lukev wrote: post #11

Earlier quoted context omitted.

I think this says more about node.js than it does about the proper way to secure a password.

Wouldnt this happen with pretty much anything that is not threaded by default? Clearly with PHP you give a fuck, but i assume its not different with Ruby, Python, Go, ASP or anything else. You just usually use them threaded.

Yes. That's why nearly every web framework is threaded by default. That includes everything you'll find in Ruby, Python, Go, or ASP.

Not serializing IO, but them stopping every worker just because one of them has some hard work to do is not a sane working model for web backends.

Re: How to Safely Store Your Users' Passwords in 2016

#98

Post by tptacek »

Justsignedup wrote: post #95

Wish there was a site where it lists algorithms and gives a table, and an ability to compare it to x years ago: algorith | fairly safe difficulty (all variables) | very safe difficulty without incurring too much performance cost. pbkdf + sha1 | completely unsafe | completely unsafe pbkdf + sha2 | 100000 | ... pbkdf + sha256 bcrypt scrypt argon2

PBKDF2-SHA1 is safe.

That's the problem with a chart like this. The gradation will go from "completely unsafe" salted hashes to "very much safe enough" with only marginal changes after that.

Another problem is that these functions are all parameterized, so the chart needs to capture the safety level at specific parameters.

Re: How to Safely Store Your Users' Passwords in 2016

#99

Post by sarciszewski »

tptacek wrote: post #98
Justsignedup wrote: post #95

Wish there was a site where it lists algorithms and gives a table, and an ability to compare it to x years ago: algorith | fairly safe difficulty (all variables) | very safe difficulty without incurring too much performance cost. pbkdf + sha1 | completely unsafe | completely unsafe pbkdf + sha2 | 100000 | ... pbkdf + sha256 bcrypt scrypt argon2

PBKDF2-SHA1 is safe. That's the problem with a chart like this. The gradation will go from "completely unsafe" salted hashes to "very much safe enough" with only marginal changes after that. Another problem is that these functions are all parameterized, so the chart needs to capture the safety level at specific parameters.

It would make for a good interactive "chart", perhaps. Whereby, as long as your sliders aren't all the way to the left, the chart is mostly green.

Re: How to Safely Store Your Users' Passwords in 2016

#100

Post by [deleted] »

Someone1234 wrote: post #96
[deleted] wrote: post #82

Earlier quoted context omitted.

[deleted]

> This is a really dumb semantic argument. You're arguing over the meaning of what I said upthread. I will spell it out for you: No, I'm not. And never was. Someone replied to me splitting hairs over the term. I never even brought it up. Did you reply to the right post?

[deleted]
Post reply on HN