ericelliott / credential

Easy password hashing and verification in Node. Protects against brute force, rainbow tables, and timing attacks.
MIT License
347 stars 28 forks source link

Due to the large number of iterations, Its consuming the full CPU usage. #81

Closed mansa-dev closed 6 years ago

mansa-dev commented 6 years ago

Hi there, I am using this library for my project, and till now everything is fine. But, now the project is going to live mode and I have done the load testing of my site. When I had tested my site with 100 users and only 8 users were able to login simultaneously. However, it's not using the system RAM but consumes 100% CPU. Thereafter no user was able to Login. Please suggest me what to do?

Thank You!

tjconcept commented 6 years ago

Unless you suggest some kind of bug exists, you can only do two things: decrease the number of iterations or increase CPU capacity.

ericelliott commented 6 years ago

User auth intentionally consumes lots of CPU to prevent hackers stealing passwords by brute force.

You absolutely should NOT decrease the number of iterations. It is NOT SECURE. The default values have not been updated in a while and are already too fast.

My recommendations in order of preference:

  1. Use a third party with more resources to handle user authentication (Auth0, Google, etc...)
  2. Use a dedicated box for authentication, separate from your application. Use a large CPU option from your host.

If you don't have the resources to handle the CPU costs you don't have the resources to properly manage user authentication, and you should use a 3rd party provider for user auth.

mansa-dev commented 6 years ago

Thank you @ericelliott and @tjconcept for your response. I have done some debugging in the code and found that Iteration method is returning too many iterations (more than 5 lacs). Also, the iterations are directly proportional to the time. So the number of iterations is increasing every minute. I have also done some R&D on ideal iterations for the SHA1. I have found that it should be minimum 10,000. So would that be okay if we randomly generate the iterations between 10,000 and 50,000? Please let me know your thoughts on it.

ericelliott commented 6 years ago

@mansa-dev To keep on top of progressing CPU power and hacker bot-net growth, work time should double at least every 2 years, so it sounds to me like that 10k recommendation was horribly outdated, which is why iteration value changes over time automatically in credential.

If it changes too much over time, that's a bug we need to look into. You can test that directly using the iterations function here.

If that function is broken, we can file this as a bug.

When I wrote this book in 2013, the recommendation was 80k iterations, which allowed an attacker using nothing but a stock MacBook to try 100 hashes every 15 minutes -- in 2013. That would make such an attack impractical.

These days, lofi hackers use rigs packed with GPUs to hash in parallel. Serious hackers use botnets with hundreds of thousands of slave nodes to hash in parallel. Even in 2013, that could improve hash power by orders of magnitude, so they could check 100k hashes every 15 minutes -- which is plenty of power to discover common passwords if they pair brute force with dictionaries and try the most common passwords first -- so even if you follow best practices with iterations, you're still leaving users vulnerable.

Today, iterations should be somewhere in the neighborhood of 320k+.

mansa-dev commented 6 years ago

Hello @ericelliott, Sorry for the late reply. I have checked that function and found that the iterations are increasing over time. It's occurring due to this piece of code.

dateNow = function dateNow () { var date = Date.now(); // taking current date timestamp and using as power of 2 if (minimalMsSinceEpoch < date) { return date; } return minimalMsSinceEpoch; }

You can test the iterations here https://codepen.io/nitin-dev/project/editor/AqOzkY.

ericelliott commented 6 years ago

When I use the actual code directly from the library, it seems to work as expected. Iterations do increase gradually over time, but using a sane work value (like 1), the results fall into about the right range for 2018 (just now it gave me 524,030).



I see what you did. You replaced the current date with a VERY FAR FUTURE DATE.

I suspect in the very far future, that will be a correct number of iterations, considering quantum computing may make password cracking 10,000x faster in the next 5-10 years. =)
ericelliott commented 6 years ago

This is working as expected.