0

Due to several customer reasons our product needs to support Basic Auth as primary authentication mechanism with client's service account.

We are using Bcrypt to store customer's password in our DB, however Bcrypt (combined with Basic Auth) is quite slow on our servers. As far as I understand this is behavior by design, however there are cases when customer will be calling our API extensively and therefore Bcrypt would dramatically increase our response time (unfortunately this is a crutial customer criteria).

To tackle this problem I have found solution by using HMAC as in memory cache for all sucessfull passwords. In summary it would goes like this:

  • Take from basic auth username and password
  • HMAC(salt, username|password) where salt is 16 urandom bytes created at application startup
  • check whether created HMAC has exists in memory cache
  • if yes -> authenticate else -> check bcrypt mechanism with username and password and if successful store given HMAC hash into cache

So far this solution performs well with high throughput, however I am no security expert and therefore other opinion would be appriciated. So here are my questions

A) Is there some other solution with basic auth which would be better?

B) Is described solution HMAC -> BCRYPT secure?

5
  • I see point B already addresses by the very question you got the idea from. To cite "... caching bcrypt output is no worse than storing plaintext passwords in RAM, which is usually fine". The main issue I see is that the in-memory cache is not automatically invalidated if the password was changed or the user deactivated, so one either need to take explicitly care of it or limit the associated risk by keeping a timestamp on the cached data or similar. May 7 at 6:26
  • Are you using TLS for transport ? I don't know about your customer's requirements but say they are stuck with with a rudimentary API automation scheme (curl or whatever), maybe upgrading to digest authentication is still possible. Caching computationally-intensive results sounds reasonable to me.
    – Anonymous
    May 7 at 21:00
  • You should make sure that your cached values have a short lifetime, so authentication is checked regularly. Other than that, I don't see an issue.
    – xsrf
    May 8 at 16:16
  • @xsrf - Can you please advise what short lifetime are we talking about? 1 minute, 1 hour? As far I can see, there could be an issue in case when password would be changes. But since these are service accounts such situation will be rare... May 10 at 12:41
  • I can't, that depends on your application and what you think is acceptable. After you changed the password or disabled the account, access will still be possible for the lifetime of the cache. (This is the same with most session based systems) It also depends on how much load you want to save. If you application usually has 10 requests per second per user, then a lifetime of only 10s will already save you 99% load. On the other hand, if you usually have only one request every 5min, a lifetime of 5min won't help anything. Use the shortest lifetime that still saves enough load.
    – xsrf
    May 10 at 13:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.