Hi Christian, On Tue, July 14, 2015 10:50 am, Christian Huitema wrote: [snip] > The draft is short and clear enough, but it acknowledges a pretty big > security issue: "the salted > password from a compromised database can be used directly to impersonate > the client-- there > is no dictionary attack needed to recover the plaintext password." > > That's a pretty big caveat, but there are still some advantages over > operating with unsalted passwords. The draft aligns server side password > management for EAP-pwd with standard industry practices, which is good. > In case of server compromise, the immediate effect of the compromise is an > attack on the already compromised server, and the per-user salt make > password discovery harder. The security section should be expanded to > explain this tradeoff.
Yes, it's a big caveat and, as I mentioned, I'm trying to be as blunt as possible about it. I have updated the Security Considerations to include the point you are making about server compromise and the per-user salt still making password recovery harder. > Nits: > > - in the abstract, missing "not" in " but did (not?) include support for > salted passwords." Nice catch. An -02 version has been posted. Would you please take a look and let me know whether it satisfactorily addresses your comments? regards, Dan. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
