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

161–170 of 321 posts

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

#161

Post by lazyjones »

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

> You can create a worker system, or use a child process to solve this problem, but most of these articles never mention it

Or you can do the bcrypt() inside your (PostgreSQL) database and add an extra layer of security by not directly exposing the hash (or even the whole password table) to the web server process (i.e. write a password check SQL function and allow only calling it, no direct table/column access).

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

#162

Post by astockwell »

I believe the Ruby example is incorrect: When checking a password's validity, you must use a constant-time comparison or else you are exposing a vulnerability to side-channel timing attacks.

There is an open issue in Coda Hale's bcrypt repo about this: https://github.com/codahale/bcrypt-ruby/pull/119

My stance on posting "best practice" articles is: you must follow all best practices in them.

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

#163

Post by matthewowen »

stronglikedan wrote: post #133
jayeshsalvi wrote: post #113

By not storing them https://medium.com/the-story/signing-in-to-medium-by-email-a...

> Why is it telling me I created a new account instead of logging me into my existing account? > Email addresses on Medium are case-sensitive. Wow. Is there ever any possible benefit to this? (Serious question)

The local mailbox portion (bit before the "@") of email addresses is case sensitive.

In practice, most email providers don't actually honor that, and so in practice it's a bad move. It is technically correct though.

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

#164

Post by sarciszewski »

astockwell wrote: post #162

I believe the Ruby example is incorrect: When checking a password's validity, you must use a constant-time comparison or else you are exposing a vulnerability to side-channel timing attacks. There is an open issue in Coda Hale's bcrypt repo about this: https://github.com/codahale/bcrypt-ruby/pull/119 My stance on posting "best practice" articles is: you must follow all best practices in them.

> I believe the Ruby example is incorrect

Unfortunately, there's nothing I can do about that, unless someone can point me to an alternative that uses a constant-time comparison.

I've left a comment on the pull request so that, hopefully, it can be merged.

> (and likely others)

Which others?

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

#165

Post by novaleaf »

novaleaf wrote: post #107
dsp1234 wrote: post #78

Earlier quoted context omitted.

Note that bcrypt.hash just calls bcrypt.hashSync anyways[0]. So there it's still going to stall exactly the same amount. edit: Looks like it depends on which version you use. 'npm install bcrypt'[1] gives a version which supports true async usage (via V8 async callbacks in native code) 'npm install bcrypt-nodejs'[2] gives a pure JS version which I linked to. Which is the top search result for 'nodejs bcrypt' [0] - ht…

lol at pure js KDF's

wow that's some serious downvotes. Why? a 1 second KDF function on a GPU will take upwards of a minute in javascript

... and conversely a 1 second KDF in Javascript will be trivial to crack brute force. There is no point in it.

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

#166

Post by astockwell »

sarciszewski wrote: post #164
astockwell wrote: post #162

I believe the Ruby example is incorrect: When checking a password's validity, you must use a constant-time comparison or else you are exposing a vulnerability to side-channel timing attacks. There is an open issue in Coda Hale's bcrypt repo about this: https://github.com/codahale/bcrypt-ruby/pull/119 My stance on posting "best practice" articles is: you must follow all best practices in them.

> I believe the Ruby example is incorrect Unfortunately, there's nothing I can do about that, unless someone can point me to an alternative that uses a constant-time comparison. I've left a comment on the pull request so that, hopefully, it can be merged. > (and likely others) Which others?

After re-reading the others in depth, all other examples appear to use appropriate comparison methods (knowing nothing of the underlying implementations). I've updated my comment to clarify.

I see your team is actively posting on the bcrypt-ruby issue #119 as we speak, so I guess I'd say wait for the PR to merge, or manually implement the approach they've outlined to secure compare: https://github.com/codahale/bcrypt-ruby/pull/119/files

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

#167

Post by Klathmon »

novaleaf wrote: post #165
novaleaf wrote: post #107

Earlier quoted context omitted.

lol at pure js KDF's

wow that's some serious downvotes. Why? a 1 second KDF function on a GPU will take upwards of a minute in javascript ... and conversely a 1 second KDF in Javascript will be trivial to crack brute force. There is no point in it.

where are you getting those numbers from?

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

#168

Post by kijin »

VincentEvans wrote: post #150

Serious question: What about using a Public/Private key encryption to store the password? - Private key is stored in a secure place. Offline for all i care; printed on a piece of paper; memorized and swallowed. - When user creates the account - password is padded with salt, then a public key is used to encrypt it. The resulting encrypted form is stored, along with the salt. - When user attempts to authenticate - the…

Where do you store the public key?

If you store it on the server alongside the encrypted password and salt, you're effectively using a bigger salt with a weird hashing algorithm that hasn't been vetted by any expert for the specific purpose of password storage.

If you store it on the client side, the user needs to supply the public key whenever he tries to authenticate. This has the effect of making the salt much bigger, but you don't need to use public keys to achieve the same effect. If you can trust the user to store a public key, you can trust him to store any large chunk of random bits.

So apart from the virtually useless fact that you might be able to decrypt the password with the private key (why would you even want to do that, instead of just resetting it?) your method seems to offer no real benefit compared to simply using larger salts with argon2/scrypt/bcrypt/whatever.

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

#169

Post by girvo »

herbst wrote: post #155
Joeri wrote: post #88

Earlier quoted context omitted.

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…

I know thats what i ment with usually you give a fuck, i dont know any way you could run PHP single threaded on a server (i mean there sure is). But its something common you learn when you programm in the other languages i mentioned. I dont think it could get a real issue in a real environment, except someone really wants to fuck with you. But the some fail2ban on to fast requests should fix this easily as the hashes…

> i dont know any way you could run PHP single threaded on a server

Using `php -S 0.0.0.0:80 index.php` would do it!

Post reply on HN