Open runvnc opened 11 years ago
@ithkuil Incorrect, read here: http://stackoverflow.com/questions/2772014/is-sha-1-secure-for-password-storage
Realistically if attackers have managed to steal your database to mount these attacks you have bigger problems. Moreover the more computationally expensive the password function is the easier to overwhelm the server. Which happens more often: DDOS attacks that run servers out of bandwidth/memory/computation or issues with stolen password hashes?
Hmm.. you are directing your reply to me.. I wish you had made that argument against the guy who crucified me in the thread about this.
@ithkuil Yes that was directed at you. There are a lot of people who are just "OMG OMG" about this. And in a way.. they are right in that bcrypt IS better. But bcrypt is WAAAAY slower. I think at level 12 it takes 1/3 of a second to hash a small password. In a single threaded environment like node... that's a terrible plan if you want something to scale.
it's all about the tradeoffs...
Now, if the bcrypt library can unload that hashing to a different thread or something behind the scenes with a callback, that's a bit better. But I still couldn't use max-security bcrypt on a site with a lot of user traffic/logins going on regularly.
Now maybe you can help me. I'm having the damnedest time getting this thing to create and then verify a password. did you run into any issues?
nevermind, got it working lol.
But bcrypt is WAAAAY slower.
Not necessarily. A work factor of 0 will have only one iteration, just like the default in this library.
In a single threaded environment like node
Node.js as a runtime is not exclusively single-threaded. Sure, it can only run a single "subroutine" (JavaScript functions, etc.) at a time, but it doesn't stop Node.js itself from spawning off multiple threads.
that's a terrible plan if you want something to scale.
That shouldn't be an argument against why an application can't scale (depending on the context of the word "scale", but here, I'll assume you meant the act of scaling the application across a cluster in response to an increase in load). Ironic to your earlier statement, Node.js' community-enforced style of preferring asynchronous code is far more suitable at avoiding the need to scale, and thus avoiding the associated cost, unlike--for example--Rails.
Now, if the bcrypt library can unload that hashing to a different thread or something behind the scenes with a callback, that's a bit better.
(In case you are wondering why I'm commenting on a two-year-old issue; I'm helping out for a project, and was surprised that it is using password-hash
instead of bcrypt, and wanted to see what algorithm is being used underneath. Looks to me like an iteration-based HMAC
Years later I'm also going to reply to this. The point of password hashing is for it to be slow.
If you are worried about DDoS attacks on your server because of either
then you are solving the problem with the wrong tools.
Use bcrypt or use argon2d and configure it for your tolerances. don't use this library.
So I built a module that uses password-hash and posted a link in reddit.com/r/node http://www.reddit.com/r/node/comments/1psqwd/loginmongo_a_simple_mongodbbased_backend_for/ and apparently that person believes that unless I use bcrypt or the like its worthless. I used sha256 as the algorithm specified for your module. Is there another algorithm I could pick for that option which would be adequate without having to change this to use bcrypt?