|
|
|
|
|
|
by chowells
1637 days ago
|
|
|
Your analysis seems to overlook an important detail in that first bullet point - dictionary attacks are only feasible when the KDF is fast. Authentication servers tend to require the KDF to be fast so they aren't constantly performing a denial of service attack on themselves. What people are looking for is a way to make the combined KDF slow by pushing most of the work to the client side. If this succeeds, you have made dictionary attacks very difficult without making your authentication process a denial of service vector. The web browser ecosystem makes this a pretty hard task, unfortunately. You need fallbacks that weaken the process to the point where it is basically useless in a lot of cases. But the goal of a client/server split in the KDF is actually quite sensible. The client side does the large amount of work to protect users from dictionary attacks. The server side does a relatively much smaller amount of work to protect itself from being easily exploited if its hashes are exfiltrated when the hashes aren't themselves vulnerable to dictionary attacks. |
|
|
I would wonder though -- there's obviously a practical limit on user experience for waiting for computation, and is there really fast enough implementations available to the browser within that limit that would foil what a dedicated attacker could compute in proper hardware for a dictionary attack? You'd also have to consider if it's really that expensive to just throw more hardware at a server side hash. I guess it'd depend on the browser, whether the attack is targeted, and how big the attacker's budget is that you're considering.
Either way, if this was the goal and the team considered those factors then still felt it was worth the effort of doing so I would think it seems reasonable, though it's probably not something I'd make standard practice in my own apps.