Hacker News Reader

Comment by kurthr | Hacker News Reader

You say that the LastPass protocol is subject to hash replay attacks (my description). I'd be surprised if there wasn't some time dependent pepper (e.g. challenge/response) in the hash, since this seems like a huge vulnerability, and storage of the hash allows for off-line attacks. Normally, I'd think diffie-hellman for this.

View on HN

No, there is nothing. The complication with challenge/response schemes is that the server doesn’t know the master password – it only has that one hash, so it’s always comparing against it. There are PAKE protocols which work around this issue, but LastPass didn’t implement any of them (probably for historical reasons already, I think LastPass is older than most of these approaches).

Normally, it isn’t such a huge vulnerability. TLS encryption is there, so nobody should be able to catch that hash in transition. And even if they did, the most sensitive data is encrypted so that you still need the master password. Still, this is rather suboptimal.

Can you explain how PAKE would help here? Going just off Wikipedia, it is a key-establishment protocol "based only on their knowledge of a shared password". So I would expect that the shared password is the master password or its hash and the parties are the user and the LP server. So wouldn't using PAKE require the server to know your master password or its hash? That sounds the same as before. Is the idea that they both know the hash only transiently (instead of the server knowing it persistently as it does today) and then establish some other key which they use after that?

No, modern PAKE protocols work without the server actually knowing the password. The server has a “verifier” that lets them tell whether the client’s response to a given challenge is correct. I’m no expert on this topic but https://blog.cryptographyengineering.com/2018/10/19/lets-tal... is a good start.

Reply on news.ycombinator.com