4

I developed an application that is similar in concept to an FTP server. There are several hundred user accounts, and it uses bcrypt to store hashed passwords.

All user passwords are randomly-generated 128-bit v4 GUIDs.

One feature of my application causes many concurrent logins. When this happens, bcrypt dominates performance profiles and degrades the user experience. I want to reduce CPU load by replacing bcrypt with a less CPU-intensive hash function.

Web applications use bcrypt for passwords instead of much weaker hashes (e.g. single-round SHA-1, or even ROT13) so that offline cracking is suddenly nontrivial.

But, since an FTP-server-alike application just reads/writes files on the local disk, any attacker with access to the login database will have this local disk access anyway. So I don't think offline hash-cracking is a credible threat.

That just leaves online bruteforce, but since I'm lucky to have a guarantee of strong passwords (128-bit v4 GUIDs), that's really infeasible too.

So I think in this situation it's safe for me to downgrade the hash security to something significantly weaker (e.g. single-round SHA-1, or even ROT13).

My question is:

Have i forgotten something? Is this analysis wrong?

Improve this question
7
  • 1
    Reversing ROT13 is trivial. Also, you can reduce the strength of bcrypt. Why not do that?
    – forest
    Commented Jun 29, 2018 at 2:07
  • @forest ; Sure, and bcrypt with work factor 0 or 1 also has the benefit of automatically using a random salt. But something even weaker uses even less CPU. My question is - is it still safe in this situation?
    – mappu
    Commented Jun 29, 2018 at 2:46
  • The weaker it is, the less secure it is. Make it as computationally expensive as you can without it bogging down your systems. Absolutely do not use a single hash. Only use something like bcrypt. On a similar note, have you considered trying to find a solution to the concurrent logins rather than making the KDF faster? For example, have the initial login do the bcrypt computations and then provide a cookie (or whatever equivalent you have with the protocol you are using) that allows authentication for subsequent connections.
    – forest
    Commented Jun 29, 2018 at 2:47
  • @forest ; I think this situation is sufficiently unique (e.g. strong passwords) that I am questioning the value of blanket statements like that. I agree with addressing the underlying problem; but it's like a thundering-herd of initial login attempts after server boot. A cookie won't help (unless it's cached on disk through server boot, where it could be stolen in the same way as a weaker hash).
    – mappu
    Commented Jun 29, 2018 at 2:54
  • Oh wait, I just re-read your question and saw that each password was a randomly generated 128-bit value. If it has a 128-bit keyspace (i.e. each bit has a 50% chance of being a 1), then there is no need to use a KDF. Just hash it with a single round of SHA-1 (or even MD5!). You don't even need a salt.
    – forest
    Commented Jun 29, 2018 at 2:56

1 Answer 1

Reset to default
4

A 128-bit GUID v4 has 122 random bits. According to RFC 4122 § 4.4, six of the bits are fixed, with 122 remaining bits being random. Assuming the random number generator source you use is cryptographically secure, a key generated in this way will have a keyspace of 2122, which is plenty. If it is used as a key to authenticate to your service, you do not need to bring it through a slow KDF. Slow KDFs are designed to make weak human-generated passwords slightly harder to break. If the key is already too large to break, the only thing required when deriving the hash is the use of a one-way function. You can safely pass the key through a single round of SHA-1 or even MD5 (these hashes are vulnerable to collisions, but not preimages which are what matter in the context of password hashing). You do not need to use a salt either, since each key will already be be distinct.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .