Re: beep+sasl+srp draft issues
Simon Josefsson <[email protected]>
| Newsgroups | gmane.ietf.sacred |
|---|---|
| Message-ID | <[email protected]> |
Stephen Farrell <[email protected]> writes: > Dale, > >> > - We want to hash the userid in case the user types her >> > password into the "username" box. We could do this above >> > SASL-SRP or else could try get the SASL-SRP draft to include >> > the trick itself (I prefer the latter). Any opinions? >> >> preference 1) skip it. do appropriate UI checking in the client >> >> preference 2) send in hash(user-id) as part of SASL-SRP authenticated login >> sequence. > > Ok - that's three opinions (more?) A minor point, but since SRP was designed to counter dictionary attacks, the hash(user-id) "fix" might end up being less secure than SRP, since you then can perform dictionary attacks on the hash(user-id) value that is transfered. This would probably only be a practical problem if servers' blindly start to swap username/password to "help" clueless clients/users, instead of failing. Perhaps that wasn't the intention, and that servers MUST fail if they encounter swapped username/password fields. My point is that the hash(user-id) fix adds complexity that might obscure what is really going on. Maybe either ignore the problem, or treat both username and password as sensitive information, instead of chosing a weak scheme for one of the fields (username).