vdbergh
vdbergh
Ideally there should be a salt in the db. Otherwise this scheme is still vulnerable to a rainbow table attack.
I haven't really studied the PR but do you keep track which passwords are hashed and which aren't? This will necessary for future db conversion. I am also thinking that...
> > I haven't really studied the PR but do you keep track which passwords are hashed and which aren't? This will necessary for future db conversion. > > Hashed...
I read that it is recommended that hashing takes at least 0.5s CPU time to deter a brute force attack. That is huge of course if it has to happen...
Are there serious issues with caching the hash?
> > Are there serious issues with caching the hash? > > Hash cached worker side? We already write the password in the config. No. Just maintaining a dictionary on...
> > No. Just maintaining a dictionary on the server with { password: hash} . Then the hash for every password has to be computed only once (until the server...
Yes I know of course. I just suggested a standard design pattern (https://en.wikipedia.org/wiki/Memoization) to make it simple (no code changes would be necessary).
IMHO memoizing the hash function is harmless. It is just an implementation detail.
The hash function is supposed to take 0.5s of CPU time. Of course this has a substantial effect on the overall CPU time use as authentication is done with every...