1

Isnt Secure Remote Password Protocol (SRP) pretty much client side hashing? Argon2 the winner of the PHC also allows for client side hashing. How do these systems avoid the plaintext equivalence problem?

Several questions/answers poo poo this

I largely agree with these answers, but if there are major implementatoins going down this road, how are they avoiding this problem?

Argon2 - "Argon2 allows the server to carry out the majority of computational burden on the client in case of denial-of-service attacks or other situations. The server ultimately receives a short intermediate value, which undergoes a preimageresistant function to produce the final tag."

https://eprint.iacr.org/2015/387.pdf (unnamed method) - "For now ignore the issue of the salt coming from the server to the client and consider how this solution satisfies the requirements above"

SRP uses something like Diffie–Hellman to avoid the problem

Both #1 (Argon2) and #2 (the unnamed pdf method) seem to suffer from pass the hash don't they?

user10008
  • 4,315
  • 21
  • 33
Jason Coyne
  • 1,583
  • 2
  • 10
  • 10

2 Answers2

3

Argon2 the winner of the PHC also allows for client side hashing.

Note that this is an additional feature, and doesn't make Argon2 to a fully fledged authentication protocol. The PHC has awarded it as password hashing algorithm, not as authentication protocol.

Isn't Secure Remote Password Protocol (SRP) pretty much client side hashing?

For SRP, the hashing happens on the client, yes. This allows for key stretching to not happen on the server, but on the client, making it easier to protect the server from DoS attacks.

How do these systems avoid the plaintext equivalence problem?

I guess by "plaintext equivalence problem" you mean the ability to mount replay attacks.

These are prevented in #2 by using TLS. This is actually ok, if you are targeting the web browser, because here, if MITM can modify TLS plaintext traffic, they can already get the plaintext password by changing the HTML/JS code.

SRP prevents replay attacks by server and client chosing random values (called a and b by RFC 2945) for every login session, and making the exchanged messages depend on those.

Community
  • 1
user10008
  • 4,315
  • 21
  • 33
  • I agree 100%, but want to add that there is still value in "`the server never sees the user’s plaintext password`" in that if a user uses the same password for multiple websites (which many people still do), then a compromise of one server does not compromise their other accounts. – Mike Ounsworth Aug 08 '15 at 05:41
  • This is pretty much what followed the quoted sentence. Removed the quote, because it is only easy to misunderstand, but not plainly wrong. – user10008 Aug 08 '15 at 06:07
  • more than just replay attacks. If the hashing is done client side, then if there is a database "hash" leak, you have in fact leaked the password haven't you? (unless you rehash on the server again. I suppose even a weak server hash is ok though, because the chance that you are going to guess the already hashed value as your guessed plaintext is very slim) – Jason Coyne Aug 08 '15 at 14:47
  • No, on database leaks only hashes are exposed, not the password itself. It doesn't matter if client or server hashes, as long as one of them does. But yes, you have to watch out, people could use the leaked value for imposting users. – user10008 Aug 09 '15 at 12:24
  • @user10008 I was speaking somewhat mloosely. Yes, I realize only the hash leaks, but as far as the server is concerned, the hash is the password. An attacker can pass that hash through and get in just fine, therefore it becomes the password. – Jason Coyne Aug 10 '15 at 19:03
0

"Secure Remote Password Protocol (SRP)" isn't "pretty much client side hashing" since SRP is a candidate PAKE protocol, so with it, the alleged server shouldn't be able to learn enough to log in.
Those systems don't "avoid the plaintext equivalence problem" since the login process just
consists of two messages and the server's message is predictable, although they mitigate
it somewhat, since the "short intermediate value" is not enough for a standard login.

  • #1 and #2 are argon and the unnamed pdf method. as far as I can understand in the docs for them, they pass a hash over, and the server does more work, but some MITM could capture that has or whatnot? :( – Jason Coyne Aug 08 '15 at 02:45
  • That's correct. ​ ​ –  Aug 08 '15 at 02:50