"How to Safely Store a Password in 2016" Don't. Unless it's 100% absolutely necessary. If you must, continue reading on.
[deleted]
How to Safely Store Your Users' Passwords in 2016
121–130 of 321 posts
Re: How to Safely Store Your Users' Passwords in 2016
#122From 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?
Re: How to Safely Store Your Users' Passwords in 2016
#123From 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 scrypt calculation, a MitM can replace the code to exfiltrate the user's plaintext password. It doesn't make sense for the threat model.
Re: How to Safely Store Your Users' Passwords in 2016
#124Bad idea to use bcrypt.hashSync in Node.js. I hate that so many tutorials use that one instead of the correct bcrypt.hash with a callback. This is Node.js for that 200 ms where you are hashing that password nothing else runs, no requests, everything stops. Here is the correct way to use bcrypt in Node.js: bcrypt.genSalt(10, function(err, salt) { if (err) return; //handle error bcrypt.hash(clearPassword, salt, functio…
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…
And 'npm install bcrypt' is the package linked to from the article.
Re: How to Safely Store Your Users' Passwords in 2016
#125From 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.
Re: How to Safely Store Your Users' Passwords in 2016
#126I called my bank the other day and they asked over the phone for my password. This isn't a bank I often use, I only currently have a loan through them so I've never used the login on the website. I said I don't remember setting a password. They gave me a hint about the characters in the password and I was able to remember the password based on their hint. I verbally said the password character by character and they c…
I don't know much about what sort of security compliance banks must implement, but surely that's in violation of something? What country?
Re: How to Safely Store Your Users' Passwords in 2016
#127It would be great if, in 2020, or sooner, but probably later, the answer is "don't use passwords any more. They are deprecated components of society."
I think there's always going to be a need for an authentication mechanism that relies on user memory only
Re: How to Safely Store Your Users' Passwords in 2016
#128From 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…
> MITM attacks won't get access to unencrypted fields.
A MITM would let you hijack the JS that controls scrypt/SHA-256, so you're already at game over. You've got to deliver that to the user in some fashion (TLS!); this isn't a real win for your approach.
> External brute force attackers will have to take the burden of heavy hashing.
If the attacker is trying targeted access to a site the only thing that's relevant is the time they have to expend - the hash is opaque. If they have the hash from, say, a DB theft, they're already going to have to take that burden. Your approach doesn't seem to add anything.
> 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'm not sure what that means. If you steal my scrypt hash for example.net, how do you use that to authenticate me to example.net?
Your approach pushes out complexity to the clients and doesn't seem to win us anything.
Re: How to Safely Store Your Users' Passwords in 2016
#129From 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…
You're putting a lot of faith in the client.
Re: How to Safely Store Your Users' Passwords in 2016
#130I called my bank the other day and they asked over the phone for my password. This isn't a bank I often use, I only currently have a loan through them so I've never used the login on the website. I said I don't remember setting a password. They gave me a hint about the characters in the password and I was able to remember the password based on their hint. I verbally said the password character by character and they c…
I don't know much about what sort of security compliance banks must implement, but surely that's in violation of something? What country?
United States