Hacker News new | comments | show | ask | jobs | submit login

Yeah, I don't think a KDF makes arbitrarily bad passwords OK. They just move the needle and thus increase the cost of the attack. In many cases, the derived key can be cached by the legitimate user, so you can throw a few seconds at it on the user's machine.

10000 * 1s = ~2 hours cpu time, but that's a terrible password -- common words plus 3 digits means 1000 * 10000. 26^6 * 1s = ~10 years CPU time -- a few thousand bucks on EC2 -- that's getting better for what is still a pretty weak password. In any case, straight MD5s are super-fast. At 1e5-1e6 MD5s/second or more on a modern CPU, paying the compute cost for a 1 cpu-second KDF can be several orders of magnitude stronger than MD5(password+salt).




Yeah. But really, I was hoping someone had come up with a way to make something like client certs usable. a six character completely random password (even if it's all lower-case without punctuation) is a damn sight better than your average password.

Can you tell me more about allowing the user to cache the derived key within the context of web applications? that would mitigate the limitation I was describing (where how slow you made the password check was limited by what delay a user would tolerate when logging in.)


I don't think this is really suitable for web applications. Javascript really sucks at crypto (due to the lack of suitable data types), and requiring Java wouldn't fly with too many people (Flash is sort of in-between, I guess?). There is a very large constant factor here, so and since the whole point of this key derivation stuff is to make an attacker work harder...




Applications are open for YC Winter 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: