Hi Joe, On Sun, August 16, 2015 9:33 pm, Joseph Salowey wrote: > Hi Dan, > > I read the latest version of the draft (-02) and it looks mostly good to > me. some comments: > > I think you want to change the RFC references in the abstract from RFC > 2751 > to RFC 2759.
Yes, good catch! I am not referring to the "Signaled Preemption Priority Policy Element." :-) > One question I have is there any reason why you specify the input of the > hash function as password | salt instead of the other way around? Is this > the way it is done in practice? I actually asked whether this was how it was done in eduroam and did not get definitive answer back. When I poked around in the results of a "how to hash passwords" query there were a few examples that had code and they did it that way. If you know of a counter example, please speak up while the cement has yet to dry. regards, Dan. > Thanks, > > Joe > > On Thu, Aug 13, 2015 at 2:35 PM, Dan Harkins <[email protected]> wrote: > >> >> 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. >> >> >> _______________________________________________ >> saag mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/saag >> > _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
