thanks. I've swapped over to using NTLM hashes Regards,
Christian Salway IT Consultant Tel: 07463 331432 christian.sal...@naimuri.com <http://www.naimuri.com/> <http://www.naimuri.com/> > On 14 May 2018, at 10:13, Tobias Brunner <tob...@strongswan.org> wrote: > > 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