11–20 of 321 posts
If 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
Or, we could move to not storing passwords at all, viz client certs and SRP.
Anyone have a good explanation of why, in the Python example, they recommend `hmac.compare_digest` instead of `==` for comparison? Is there something obvious I'm missing here?
== in python will stop comparing after the first character mismatch. You can use that fact to test byte by byte your password knowing that the more good characters you have, the longer the comparison will take, which is called a timing attack. hmac.compare_digest is a constant time compare, in that no matter if there is a match or not, it will take the same amount of time.
If 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
I think this says more about node.js than it does about the proper way to secure a password.
If 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
I think this says more about node.js than it does about the proper way to secure a password.
Earlier quoted context omitted.
== in python will stop comparing after the first character mismatch. You can use that fact to test byte by byte your password knowing that the more good characters you have, the longer the comparison will take, which is called a timing attack. hmac.compare_digest is a constant time compare, in that no matter if there is a match or not, it will take the same amount of time.
Timing attacks aren't useful against password hashes, but avoiding them is a good habit to be in.
So if the timing attack has told you that the first letter of the hashed version is 'A' then you find another password from the table that hashes to AAxxx, ABxxx, etc.
Obviously that depends on you being able to precompute all the passwords in a consistent way as the hash being used.
Along the same lines - could you use a timing attack to figure out a salt? I guess it's near impossible?
Earlier quoted context omitted.
I think this says more about node.js than it does about the proper way to secure a password.
Wasn't Node's big draw early on (aside from the fact that it's JavaScript) the fact that everything is supposed to be asynchronous? I'm actually surprised this is a problem.
If 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
If 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
Earlier quoted context omitted.
Timing attacks aren't useful against password hashes, but avoiding them is a good habit to be in.
Would it still let you sneak in if the hash was rubbish? Say it was just a simple md5 of the password. If you could do a timing attack you could use rainbow tables of the hashes and whittle down the the possible set of passwords really quickly, right? So if the timing attack has told you that the first letter of the hashed version is 'A' then you find another password from the table that hashes to AAxxx, ABxxx, etc.…
I was going to develop this into an exploit tool, called TARDIS (backronym for Timing Attack to Remotely Dispel the Illusion of Security) against, e.g. Piwik, Oxwall, and other products that still use MD5 passwords. The main reason I didn't was: No free time to build it and tune it against the internals of various programming languages' == implementations.