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

131–140 of 321 posts

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

#131

Post by [deleted] »

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.

[deleted]

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

#132

Post by tptacek »

jimktrains2 wrote: post #106
tptacek wrote: post #12

Earlier quoted context omitted.

SRP still stores crackable password verifiers, and is tricky to implement safely.

Crackable in what way? Of course the core of it could be upgraded, but the idea is sound. Sounds like you could say the same thing about using a DES-based hash. "Don't Hash! It's weak!" is throwing the baby out with the bath water.

In exactly the same way as any other password hash is cracked.

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

#133

Post by stronglikedan »

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)

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

#134

Post by Kiro »

alextgordon wrote: post #119
jayeshsalvi wrote: post #113

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

So there's no password option? That's horrible, means you can't use it with incognito mode (because you'd have to receive an email each time)

You can use the link in incognito. Why wouldn't you?

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

#135

Post by sinatra »

sarciszewski wrote: post #123
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…

How are you going to calculate the scrypt hash, client-side? Doesn't that scrypt hash then become the password, from the server-side application's perspective? How are you storing the salt for the user if your server only knows about a SHA-256 hash. > MITM attacks won't get access to unencrypted fields. That's TLS's job. If you, for example, are building a web app and you're delivering Javascript to perform the scryp…

Very valid questions. Let me try to answer them and let's see if those answers are valid or not.

Yes, the scrypt hash just becomes the password for the server. However, this password is going to be unique and almost impossible to guess. Salting this password on server side doesn't give us any additional benefits. The server can store the salt that the client used, though.

Yes, the MITM point was minor. Just another minor security benefit on top of TLS (which takes the majority of the burden of securing against it). So, maybe I shouldn't even mention this point.

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

#136

Post by Justsignedup »

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.

My goal was to create a chart of:

algorith | a safe set of parameters | a VERY safe set of parameters but needs strong hardware

Maybe a 4th column of "unsafe if difficulty is below"

This could be something updated yearly or whatever to help people figure out what things they need to move towards. If they see that their currently used settings are below the unsafe line, they will know it's time to upgrade.

Example: I use PBKDF2-SHA1 at difficulty of 11k iterations. Is that number still within the "probably okay" list, or is that in the "I can hack any password on your list in 15 minutes"

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

#137

Post by owenmarshall »

sinatra wrote: post #135
sarciszewski wrote: post #123

Earlier quoted context omitted.

How are you going to calculate the scrypt hash, client-side? Doesn't that scrypt hash then become the password, from the server-side application's perspective? How are you storing the salt for the user if your server only knows about a SHA-256 hash. > MITM attacks won't get access to unencrypted fields. That's TLS's job. If you, for example, are building a web app and you're delivering Javascript to perform the scryp…

Very valid questions. Let me try to answer them and let's see if those answers are valid or not. Yes, the scrypt hash just becomes the password for the server. However, this password is going to be unique and almost impossible to guess. Salting this password on server side doesn't give us any additional benefits. The server can store the salt that the client used, though. Yes, the MITM point was minor. Just another m…

>Yes, the scrypt hash just becomes the password for the server. However, this password is going to be unique and almost impossible to guess. Salting this password on server side doesn't give us any additional benefits.

I don't even your threat model.

Can you walk us through how you see this working?

Client takes 'crappypassword' as input, sends p = scrypt('crappypassword')

The server stores SHA256(p)?

EDIT: misread what you said. is this correct?

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

#138

Post by Strilanc »

sarciszewski wrote: post #123
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…

How are you going to calculate the scrypt hash, client-side? Doesn't that scrypt hash then become the password, from the server-side application's perspective? How are you storing the salt for the user if your server only knows about a SHA-256 hash. > MITM attacks won't get access to unencrypted fields. That's TLS's job. If you, for example, are building a web app and you're delivering Javascript to perform the scryp…

I think the idea is that the scrypt hash does become the password, but it's a better password. A password with a lot more entropy (kinda). The increased kinda-sorta entropy makes the use of a slow key derivation function on the server side unnecessary, so SHA-256 becomes sufficient.

Not sure how I feel about it.

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

#139

Post by sinatra »

vincentdm wrote: post #122
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…

Very interesting. Is there a reference implementation or discussion you can link to?

I'll try to find the discussion. EDIT: Here's the discussion - https://news.ycombinator.com/item?id=9305504

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

#140

Post by sarciszewski »

Strilanc wrote: post #138
sarciszewski wrote: post #123

Earlier quoted context omitted.

How are you going to calculate the scrypt hash, client-side? Doesn't that scrypt hash then become the password, from the server-side application's perspective? How are you storing the salt for the user if your server only knows about a SHA-256 hash. > MITM attacks won't get access to unencrypted fields. That's TLS's job. If you, for example, are building a web app and you're delivering Javascript to perform the scryp…

I think the idea is that the scrypt hash does become the password, but it's a better password. A password with a lot more entropy (kinda). The increased kinda-sorta entropy makes the use of a slow key derivation function on the server side unnecessary, so SHA-256 becomes sufficient. Not sure how I feel about it.

I feel that this is needlessly dangerous, personally.

How are the salts managed? This detail is important. SHA256(scrypt(password, constant_value_instead_of_salt)) is going to produce collisions in the stored hash.

Post reply on HN