Hi Christian, > but what if the server stored the password in a sha256(md4(password)) > hash and then when it received the md4 hash from the client, hashed that > with sha256 to compare to?
It doesn't receive the MD4 hash, which is only a part of the calculation of EAP-MSCHAPv2 (the NT password hash). The actual value that's transmitted (ChallengeResponse) and has to be verified (by doing the same calculation) also incorporates random challenges (see RFC 2759 [1] for details). Which is why the only thing you can store instead of the plainttext password is the NT hash (ntlm secrets in swanctl.conf). > The Server can send any fake md4 hash across the network to the client > (unless the client does its own check of the hash)... It does, the server sends its an AuthenticatorResponse, which incorporates the client's response and the random challenges (including one provided by the client) to prove it knows the password. So the EAP method does provide mutual authentication, however, a weak version because the server is authenticated after the client. Which means a MITM could attack a weak client password, which is why the server should be authenticated via IKEv2 pubkey authentication first (i.e. EAP-only authentication is not allowed for EAP-MSCHAPv2). EAP-MSCHAPv2 can also be tunneled in another EAP method (e.g. EAP-TTLS or EAP-PEAP) to authenticate the AAA server first. There are, of course, several other EAP methods based on passwords, with much stronger algorithms and some of them don't require plaintext passwords. The problem is that common clients (as those built-in Windows and Apple OSes) don't support them (and neither does strongSwan actually). Regards, Tobias
