I'm part of the Paragon Initiative Enterprises team and have access to edit the blog. If you have any questions (AMA) or would like to suggest any additions, please let me know.
How to Safely Store Your Users' Passwords in 2016
81–90 of 321 posts
Re: How to Safely Store Your Users' Passwords in 2016
#82Earlier quoted context omitted.
> I literally don't understand what it is you're getting at. I truly hope this will help then: https://paragonie.com/blog/2015/08/you-wouldnt-base64-a-pass... "Password hashing" is its own compound noun. The acceptable algorithms (as defined in the blog post this HN thread is about) take care of this for you. > Anyone using 3DES, MD5, or similar is likely vulnerable to timing attacks, and they're definitely still in…
> 3DES is a block cipher. MD5 is a crytographic hash. 3DES is both a block cipher and a cryptographic hash. At least UNIX thought so in the 1990s as many MANY people were storing UNIX passwords in 3DES, DES, MD5, and similar. > Neither of them are password hashes. 25 years of computing history would disagree with you. MD5 was the defacto standard for password hashing for almost fifteen years. But no doubt you'd playi…
[deleted]
Re: How to Safely Store Your Users' Passwords in 2016
#83Earlier quoted context omitted.
> For some reason the article completely fails to link to libsodium: https://download.libsodium.org/doc/ The "bindings for most programming languages" link goes to the libsodium documentation, but I'll add a link in more contexts.
The article offers specific advice for Java-without-libsodium, but it offers no such specific advice for Java-with-libsodium. There would appear to be three distinct Java bindings of libsodium.
(I'm not ignoring your comment, I'm currently debating whether to update it to include libsodium example code or to write a separate post for that.)
Re: How to Safely Store Your Users' Passwords in 2016
#84Earlier quoted context omitted.
Do the async methods actually execute on a thread pool though? Or do they use enough async methods internally to periodically release the main thread enough to keep it responsive? From a quick glance at the source, the answer to the first is no.
This one is truly async, it uses a libuv managed thread pool.
[deleted]
Re: How to Safely Store Your Users' Passwords in 2016
#85Bad 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…
BUT NODE.JS IS NON BLOCKING?!?@?!?!?!
Kidding.
Re: How to Safely Store Your Users' Passwords in 2016
#86Earlier quoted context omitted.
Can you expand on this idea? What type of authentication method would replace it? (One that can't be directly linked to the person obviously).
I'm optimistic for the use of physical tokens instead of passwords. In my work environment, a lot of authentication is based on physical token possession plus a password just as a guard against lost devices (password validated by the token, not by the service). These kinds of systems aren't technically very complex but there hasn't been a lot of traction for them outside of corporate environments. The result is that…
I would love a replacement for passwords, but i dont think hardware based solutions are practical enough yet. It is a Gadget more i need to take with me, and even more make sure that it connects with any device i have.
The worst part for me would be loosing that thing, in the end i would need alternative login methods anyway to be sure i dont lock myself out.
Classic Authy on a Smartwatch would be the simplest method i could live with that comes to my mind.
Re: How to Safely Store Your Users' Passwords in 2016
#87Earlier quoted context omitted.
> I literally don't understand what it is you're getting at. I truly hope this will help then: https://paragonie.com/blog/2015/08/you-wouldnt-base64-a-pass... "Password hashing" is its own compound noun. The acceptable algorithms (as defined in the blog post this HN thread is about) take care of this for you. > Anyone using 3DES, MD5, or similar is likely vulnerable to timing attacks, and they're definitely still in…
> 3DES is a block cipher. MD5 is a crytographic hash. 3DES is both a block cipher and a cryptographic hash. At least UNIX thought so in the 1990s as many MANY people were storing UNIX passwords in 3DES, DES, MD5, and similar. > Neither of them are password hashes. 25 years of computing history would disagree with you. MD5 was the defacto standard for password hashing for almost fifteen years. But no doubt you'd playi…
To be honest I'd probably interpret them as being antagonistic if the same statements were directed at me (and quoting never helps either) but I think if you take a charitable interpretation it doesn't read that way. I think it's just a direct/technical challenge/debate sort of reply and it's really easy to read into those when you're on the receiving end of them.
Re: How to Safely Store Your Users' Passwords in 2016
#88Earlier quoted context omitted.
I think this says more about node.js than it does about the proper way to secure a password.
Wouldnt this happen with pretty much anything that is not threaded by default? Clearly with PHP you give a fuck, but i assume its not different with Ruby, Python, Go, ASP or anything else. You just usually use them threaded.
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 done from a single machine.
Re: How to Safely Store Your Users' Passwords in 2016
#89Here's yesterday's discussion for the exact same post (maybe the duplicate search failed this time?)
Re: How to Safely Store Your Users' Passwords in 2016
#90I had no idea that PBKDF2 had fallen so much in recent years. I still remember the 1Password team extolling its virtues five years ago: https://blog.agilebits.com/2011/05/05/defending-against-crac...
Questions like these are why I don't love the Password Hashing Competition.
In reality, PBKDF2 is fine. It's not the best thing you can use, in the same sense as AES is probably not the absolute best round-for-round, cycle-for-cycle cipher you can use, but it gets the job done.
The answer for "what password hash should I use" can accurately be summed as "put bcrypt, scrypt, Argon2, and PBKDF2 on a dartboard, and then throw a dart".
In 1PW's case, PBKDF2 is even more reasonable, because 1PW actually needed a KDF, and bcrypt is not an especially good KDF.