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

211–220 of 321 posts

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

#211

Post by joveian »

dudus wrote: post #125
sinatra wrote: post #118

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 anywa…

I learned very early on to never trust the client. An infected machine cold just not encrypt the password and now you have a database where infected clients just got sha256. That is if course easily broken with brute force or even rainbow tables.

An infected machine would more likely steal the password, then still run the scrypt. Why make it easier for someone else to steal it too?

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

#212

Post by jimktrains2 »

tptacek wrote: post #191
jimktrains2 wrote: post #171

Earlier quoted context omitted.

By iterating over all passwords? That seems like the definition of a good password storage if that's the only way! I mean, you can make the same complaint against anything; it's meaningless by definition. Sure, public-private pairs are more difficult (to impossible) to brute force once they're so long, but srp, bcrypt, pbkdf2 &c are pretty good when you want/need a password. Srp being superior in that your secret nev…

I'm not following you. The whole point of a password hash is to (1) admit only that one brute-force attack, and then (2) to slow that attack down as much as possible. SRP gets you (1), but is inferior to every other modern password hash on (2). SRP is better on (2) than other PAKEs (it's an "augmented" PAKE because it tries to slow down brute force), but password hashes have (2) as their whole objective, and total de…

> but password hashes have (2) as their whole objective,

Only until that was what people cared about. How long, and how many still, use single-round md5 and sha for password storage?

SRP is an old algorithm -- it could be strengthened significantly with little love. (Similar as to how took a little care from the community for bcrypt, pbkdf2, &c have become the "norm" over md5.)

> SRP isn't buying you anything

SRP is buying you the ability for the server to never have the password, a secret value you're handing someone else!

> SRP is a bad call for virtually all projects. Or, maybe a better way to say that is, "if you have to ask, don't use SRP."

I still feel like you're throwing the baby out with the bathwater. Just because something can be updated and hasn't (like using a weak hash like md5), doesn't mean the core concept is bad (using a 1-way hash function).

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

#213

Post by theIV »

swang wrote: post #203
NickNameNick wrote: post #190

Earlier quoted context omitted.

Congratulations, now there are plaintext passwords in your server logs... I did exactly what you are suggesting on a project some time ago - deferred to the database to do the password hashing and comparison to the stored hash. Unfortunately, the server query logs contained the query parameters. So did some of the database logs when running at elevated log levels. We quickly decided that was unacceptable, and moved t…

I don't see how moving to the web server would prevent that if you were logging passed req body or query parameters since they would be posted in plaintext (hopefully) over a https connection.

I'm not sure but I'm assuming this has more to do with Postgres' WAL than it does filtering logs. I've never used this side of Postgres though, so just a guess.

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

#214

Post by tptacek »

jimktrains2 wrote: post #212
tptacek wrote: post #191

Earlier quoted context omitted.

I'm not following you. The whole point of a password hash is to (1) admit only that one brute-force attack, and then (2) to slow that attack down as much as possible. SRP gets you (1), but is inferior to every other modern password hash on (2). SRP is better on (2) than other PAKEs (it's an "augmented" PAKE because it tries to slow down brute force), but password hashes have (2) as their whole objective, and total de…

> but password hashes have (2) as their whole objective, Only until that was what people cared about. How long, and how many still, use single-round md5 and sha for password storage? SRP is an old algorithm -- it could be strengthened significantly with little love. (Similar as to how took a little care from the community for bcrypt, pbkdf2, &c have become the "norm" over md5.) > SRP isn't buying you anything SRP is…

No, it isn't. It's storing verifiers with the same power for attackers as scrypt, except that scrypt's verifiers are harder to crack.

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

#215

Post by ecoffey »

paulddraper wrote: post #207
dheera wrote: post #206

Earlier quoted context omitted.

I also hate the stupid security questions used to identify you which they always claim "add security". In almost all cases they decrease security. Where did you spend your honeymoon? What was the name of your first pet? What is the name of the street where you grew up? For any given person, a LOT of people know the answer to these kind of questions. Also, I hate it when people use date of birth to verify identity. Me…

I'm not saying I disagree, but how would you verify identity over the phone?

You can still have the question. But my answer is a random 32 character string of alphanumerics :)

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

#216

Post by minitech »

swang wrote: post #203
NickNameNick wrote: post #190

Earlier quoted context omitted.

Congratulations, now there are plaintext passwords in your server logs... I did exactly what you are suggesting on a project some time ago - deferred to the database to do the password hashing and comparison to the stored hash. Unfortunately, the server query logs contained the query parameters. So did some of the database logs when running at elevated log levels. We quickly decided that was unacceptable, and moved t…

I don't see how moving to the web server would prevent that if you were logging passed req body or query parameters since they would be posted in plaintext (hopefully) over a https connection.

“query parameters” here are the parameters passed to PostgreSQL. That is, "SELECT * FROM users WHERE password_hash = get_hash('P4ssw0rd')" is being logged, not "?password=P4ssw0rd".

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

#217

Post by dheera »

ecoffey wrote: post #215
paulddraper wrote: post #207

Earlier quoted context omitted.

I'm not saying I disagree, but how would you verify identity over the phone?

You can still have the question. But my answer is a random 32 character string of alphanumerics :)

I algorithmically generate the answers to the security questions with:

     answer = PBKDF2(hmacsha1, password + question, "", 100000, 16)
This is also incidentally the basis for how I generate unique passwords for every service except banks, communication, and other sensitive things. I want a different password on every website and don't want to trust any password-remembering software I didn't write. The same function works fine for generating answers to secret questions.

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

#218

Post by viraptor »

peterjlee wrote: post #120
jayeshsalvi wrote: post #113

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

I forget my passwords all the time so clicking on 'forgot password" is already my primary way to login on many sites I don't use often.

That works as long as the website has this functionality. One day you'll miss it... and end up writing to Bram Moolenaar, explaining why you forgot your password (http://www.vim.org/account/forgot_password.php)

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

#219

Post by minitech »

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.

I just measured it, and native bcrypt seems to be about 5× as fast as bcryptjs. As long as the time for one hash is more than 0.0001 s, you’re doing pretty well as far as password storage goes, so a pure JavaScript bcrypt is bad mostly because it’s blocking on Node and not because it’s too slow to be useful.

Please don’t pull numbers out of nowhere.

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

#220

Post by Vintila »

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…

I'd been considering something similar, never really made a PoC though.

How about this: User provides their public key when they signup. To authenticate, server produces a nonce and sends to the client, client signs the nonce with private key and sends the result, server verifies signature with public key.

Post reply on HN