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

111–120 of 321 posts

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

#111

Post by EGreg »

marcosdumay wrote: post #97
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.

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.

That's why you spawn worker processes and servers. Evented IO is way faster than threads as NGinX and Node have shown.

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

#112

Post by neals »

rcconf wrote: post #9

If you're using node.js and you use these hashing methods, your entire server is going to pause for 0.5 seconds on a login because it runs on a single thread. Goodbye to all of your server performance. You can create a worker system, or use a child process to solve this problem, but most of these articles never mention it

I find that using the original bcrypt node module is hard to build consistently, I often have trouble getting it built on various systems. I switched to bcryptJS which is a drop-in JS implementation.

Anybody here that knows if any of these is a valid replacement? https://nodejs.org/api/crypto.html

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

#114

Post by jordonias »

gist wrote: post #110
[deleted] wrote: post #102

Earlier quoted context omitted.

[deleted]

I don't think you should out them publicly. Are you interested in having them improve their security model [1] or do you want to have what they have they done out in the open so that others can try to social engineer them and their customers might suffer the consequences? [1] If so, tell them about this in a way that will get their attention without causing their customers or them any harm.

You're correct. I'll contact them.

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

#115

Post by ngrilly »

balls187 wrote: post #65
rehevkor5 wrote: post #54

Earlier quoted context omitted.

The article inaccurately describes generating a password hash & using it as "storing a password".

My point is simply if you can avoid storing user credentials, avoid storing their credentials. For many services, the most valuable data they contain happens to be the user credentials that the service uses to authenticate the identity of the user. If you assume that users share their credentials across multiple services, if your system is attacked, and you improperly stored their credentials, you've caused way more…

I agree that it's better to avoid storing user credentials, but what do you suggest instead to authenticate the user?

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

#117

Post by codahale »

brazzledazzle wrote: post #91
[deleted] wrote: post #82

Earlier quoted context omitted.

[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."

"You know the law: two men enter, one man leaves."

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

#118

Post by sinatra »

From previous discussions about this topic, I had noted down the following best practices:

Passwords should be scrypt'ed on client, and then, the server should generate a SHA256 hash of the scrypt'ed hash and store that in DB.

- Running CPU & memory heavy scrypt hashing on the client side will allow us to use bigger hashing work-loads.

- EDIT: Removing the MITM point, because as many said, that's the job of TLS anyway.

- External brute force attackers will have to take the burden of heavy hashing. No DOSing through scrypt.

- Storing SHA256 hash instead of scrypt hash on DB means even if DB is stolen, attackers can't use stolen scrypt hashes to authenticate any client.

I would love to get others' feedback on this. EDIT: Found the reference: https://news.ycombinator.com/item?id=9305504

Post reply on HN