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.
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 (
- 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.