bcrypt work factor is killing our poor Heroku box

[rix0rrr]

We have bcrypt at the default work factor of 12, which is a bit steep for our single-core Heroku box.

Right now, any bcrypt hash operation takes about ~300ms:

$ time python -c 'import bcrypt; bcrypt.hashpw(bytes("asdf1234", "utf-8"), bcrypt.gensalt())'

real    0m0.354s
user    0m0.340s
sys 0m0.012s

Keeping in mind that the box has only a single processor and so can only do one thing at a time, 3 logins/signups/password resets/any bcrypt operation will block anyone else from submitting a program to the web server or doing anything else for a full second [0]. This is already leading to noticeable load and latency spikes on the metrics dashboard.

Yes, we could spring for more cores, but we're on a bit of a budget and would like to stretch our single-core machine as far as it'll go.

We should reduce the work factor of the bcrypt operations to something more reasonable, like 9:

~ $ time python -c 'import bcrypt; bcrypt.hashpw(bytes("asdf1234", "utf-8"), bcrypt.gensalt(rounds=9))'

real    0m0.084s
user    0m0.080s
sys 0m0.000s

This is going to require some code to check the load factor of a user's existing salt and regenerate, re-hash and re-store their password if their current salt does not match our current desired work factor.

[0] Not entirely of course, because we have a couple of threads running and not all work is purely CPU-bound, some of the work is I/O bound like reading files from disk or reading things from DynamoDB... but the core work of the Hedy server is compiling code which is also CPU bound so we're definitely contending with the main purpose of the web app.

[fpereiro]

Hi @rix0rrr !

This can definitely give some oxygen to the Heroku box. While I'd rather use the default load factor and I think we'll have to get multiple cores sooner than later, it could be worth to do this in the meantime.

If I understand correctly, the implementation would require:

• Determining the desired load factor in the config (I'd put it in config.py).
• The signup & change password logic would use the desired load factor when computing a hash.
• On user login, we'd check if the current load factor of the password matches the desired one. If it doesn't, we recompute the hash and update it on the database. The reason for doing this on login is that for recomputing hashes we need the original password, which we by design don't store.

[Felienne]

@fpereiro Yes those are exactly the steps that are needed Happy if you can take this up!

[fpereiro]

@Felienne will do!