We’re seeing extreme variance with Springs implementation of bcrypt under load. 10ms when not under load and over 10seconds when under moderate load for a 15 work factor. Any experience with this anyone? (please RT)
@manicode Hey Jim, is the implementation explicitly creating an instance of SecureRandom to share between multiple calls? If not it eats up cpu quite hard.
@manicode Does it happen when encoding a new password or when checking against a given hash?
@manicode @Sempf FWIW, I think @securityfu gave the same answer I would have. Can you query your entropy pool to ascertain the state (it’s a /dev/random vs /dev/urandom issue)
@manicode Agree w/ many of the comments Does happen when encoding or matching? If matching its expected that once the number of concurrent users exceeds the number of cores it gradually degrades other users since they will be queued longer and longer to be processed
