Re: SRP protocol plaintext equivalence query

From: Bill Unruh (unruh@string.physics.ubc.ca)
Date: 02/20/03 

From: unruh@string.physics.ubc.ca (Bill Unruh)
Date: 20 Feb 2003 19:45:53 GMT

lijivnews@yahoo.com (Lijiv Khil) writes:

]I don't understand what is meant by plaintext equivalence in
]SRP protocol. The SRP paper (at http://srp.stanford.edu/) states that,
]"Abstract..., Finally, user passwords are stored in a form that
]is not plaintext equivalent to the password itself, so an attacker
]who captures the password database cannot use it directly to
]compromise security and gain immediate access to host"

]The author says that /etc/passwd mechanism is plaintext
]equivalent.

Ie, if one obtains the data sent across say the net to verify the
password, can one directly use that to verify one's self to the other
side. With /etc/passwd, one can either send the password itself, or one
could send the hash itself. But anyone capturing that hash could use it
in the same way to verify themselves.

]In the /etc/passwd mechanism a Hash(password,salt) is stored in the
]password file. In SRP, a verifier (g^x mod n) where x =
]Hash(Password,salt).

]Isn't it the case that in both cases if the password database
]is compromised, a user can launch a dictionary attack to find the
]correct password?

Yes, but that is not the question.

]Also, it is not clear to me how SRP is superior to challenge-response.
]In both cases, a successful dictionary attack can be launched if the
]password database is compromised. Can someone clarify what exactly is

Perhaps, but a successful dictionary attack cannot be launched on the
contents of the communications between the two sites.

]meant by plaintext-equivalence in this context? Also, what are the
]attacks against which SRP is not vulnerable in comparision with
]/etc/passwd and challenge response?

Challenge response can be replayed. Challenge response allows the
challenger to obtain the password if the challenger did not know it
befor, and does not verify the challenger to the respondent.
/etc/password is completely open to password sniffing, whether the
original password is sent or if the hashed version is sent.