Comment by chacham15 | Hacker News Reader

Comment by chacham15 | Hacker News Reader

Parent Full thread

> Yes, realistically you can only add at most ~30 bits of security to a password.

This sentence makes no sense to me. tptacek, correct me if I'm wrong, but Im pretty sure you can increase w to be as large as you want (i.e. the keyspace is large enough that youll be waiting years for a singular hash to finish before you wrap the whole keyspace). The only problem is that you force legitimate users to wait as well.

Let make up an extreme example to illustrate, you set w so that a hash takes 1 years - 1 day to compute on the clients machine. Also, they change passwords every year. (Yes, this is absurd because it means that the client can only work one day a year). Now, lets assume that he uses one of five-hundred passwords. If the attacker has 100x the compute power of the client, he will only have a 20% chance of getting the correct password. And that is with only roughly 9 bits of entropy.

Take anything 'pbsd writes to the bank. The problem here is that adding enough cost to add significantly more difficulty than that to a password quickly takes you to places where the real-world cost is infeasible.

(He's not arguing against using KDF-like constructions to store password authenticators).

I've actually wanted to ask you about: https://news.ycombinator.com/item?id=8088253 but I cant reply yet. If that ever actually became an issue, could it be solved by instead having the client send (2 ^ w) - 1 rounds of the hash and having the server do the last round? My reasoning is that the client would have to brute force the full hash space if they wanted to reverse only the last round instead of trying to brute force the password.

one possible reason this doesn't work: A limit on the number of iterations for a password hash is the amount of latency the user is willing to accept, which is (approximately) constant regardless of whether those iterations are computed on the client or the server

> The only problem is that you force legitimate users to wait as well.

I think that's what he meant when he said "realistically". In the reply I posted the quoted text points out that for busy auth servers, it increases potential for DoS.

Zzz. This is a trope. Many of the largest app providers in the world use adaptive hashes to store passwords. All of them are DoS targets.

Reply on news.ycombinator.com