Perl programmers should try this module: Crypt::ScryptKDF I have been using it for a while now
And with DBIx::Class it is almost easier to do it right[1] than wrong.
[1] https://blog.afoolishmanifesto.com/posts/do-passwords-right/
How to Safely Store Your Users' Passwords in 2016
181–190 of 321 posts
Re: How to Safely Store Your Users' Passwords in 2016
#182I 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…
Same thing happened to me, my local credit union emailed me my password. They ensured me that they use "bank-level encryption". Of course I didn't get into the difference between one- and two-way encryption with the teller, or that email isn't secure. We live in an age where this should be unacceptable. Why aren't there financial security laws yet?
It's so infuriating because I've worked at companies doing digital commerce before, and PCI compliance and certification is quite onerous. But at the end of the day credit card numbers still aren't as sensitive as bank logins, yet there are no security standards on bank logins! It's crazy.
Re: How to Safely Store Your Users' Passwords in 2016
#183Hashicorp's Vault (vaultproject.io) is also an excellent way of controlling access to secrets and back ends, such as PostgreSQL.
It's worth spending the time to learn, implement, and integrate into the security best practices you should already be deploying.
Re: How to Safely Store Your Users' Passwords in 2016
#184Bad 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…
The project from the article is https://github.com/ncb000gt/node.bcrypt.js
There, the encryption is handled asynchronously, the event loop is yielded while the calculations take place in a C extension.
Re: How to Safely Store Your Users' Passwords in 2016
#185I believe that the safest way is not to save them. Instead, outsource this to a few select OAuth providers which you and your customers are willing to trust.
Re: How to Safely Store Your Users' Passwords in 2016
#186I 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…
Same thing happened to me, my local credit union emailed me my password. They ensured me that they use "bank-level encryption". Of course I didn't get into the difference between one- and two-way encryption with the teller, or that email isn't secure. We live in an age where this should be unacceptable. Why aren't there financial security laws yet?
[deleted]
Re: How to Safely Store Your Users' Passwords in 2016
#187Earlier quoted context omitted.
Same thing happened to me, my local credit union emailed me my password. They ensured me that they use "bank-level encryption". Of course I didn't get into the difference between one- and two-way encryption with the teller, or that email isn't secure. We live in an age where this should be unacceptable. Why aren't there financial security laws yet?
It's so infuriating because I've worked at companies doing digital commerce before, and PCI compliance and certification is quite onerous. But at the end of the day credit card numbers still aren't as sensitive as bank logins, yet there are no security standards on bank logins! It's crazy.
PCI compliance is pretty interesting. It's been many years since I worked in an e-commerce shop but I seem to remember that it even described physical security layers i.e., dictating the placement of door hinges to server rooms.
Re: How to Safely Store Your Users' Passwords in 2016
#188Bad 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…
More specifically, any functions that end in Sync should be avoided. Unfortunately a lot of people think that these functions are a simple way to "not have to deal with callbacks", which is not correct...
It's not correct?
Is there any reason not to use the Sync functions if you're not writing a web server and don't particularly care for performance?
Re: How to Safely Store Your Users' Passwords in 2016
#189> PBKDF2 (nearly everyone except FIPS agrees this is the worst of the acceptable options) is that true?
Only in the most technical sense: cycle for cycle, PBKDF2 gets you the smallest amount of protection from that group of password hashes. PBKDF2 is still vastly better than non- password hashes like salted SHA.
You say that "PBKDF2 is still vastly better than non-password hashes like salted SHA", but is PBKDF2 (with >10,000 iterations using SHA512 and a random salt, for example) secure enough?
Re: How to Safely Store Your Users' Passwords in 2016
#190If 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).
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 the hashing process into the web server.