0

Consider a web application that:

  • uses HTTP Basic Auth over HTTPS, and therefore needs to validate a password (an API Key) on every request
  • and needs to handle a substantial load
  • has very few distinct users
  • the user is given a password and cannot change it (besides requesting a new one), so we can provide randomly generated password

Now, following best practices suggests using a slow hashing algorithm designed for passwords for password storage, e.g. scrypt/bcrypt/Argon2/etc. These are by definition CPU (and/or memory) intensive, which means many more $s are spent on password validation than application logic.

I observe that the passwords are likely to be permanently stored in clear text in memory anyway, because they are being sent in clear text (base64-encoded) as part of every request*. Thus, protecting against application memory attacks appears futile.

Now, to speed up validation, I was considering:

  • Storing passwords on disk/in DB using a password hashing algorithm (scrypt/bcrypt/Argon2 etc)
  • When a password is received by the webapp, and successfully validated, we have effectively "decrypted"/reversed the hashed password. Now this could be stored in memory using e.g. salted SHA256 for future validation, which would be much less CPU intensive.

Can anyone spot any issues with the analysis or approach?

* Yes, there's a slight possibility that the web application framework does something really clever to dispose of secrets very shortly after validating them. This is using Spring Boot (Java) - I somehow doubt this is the case.

m01
  • 101
  • 2
  • 4
    Are the passwords always random with at least 128 bits of entropy and they can't be changed by users? If so, you really only need a single iteration, see [here](https://security.stackexchange.com/q/169320/151903). – AndrolGenhald Mar 20 '19 at 21:32
  • 1
    I second this, a key derivation function is a way to increase usability for memorable passwords at the sacrifice of computing effort. A 128 bit key generated with a _cryptographically secure_ random number generator is not crackable through even a single unsalted strong hash. – J.A.K. Mar 20 '19 at 21:40
  • Yes, we are in control of the user passwords and can generate them from a cryptographically secure random number generator - I clarified this in the question – m01 Mar 20 '19 at 21:56

0 Answers0