On 056, 02 25, 2008 at 12:57:19PM +0200, Timo Sirainen wrote:

On Feb 24, 2008, at 11:21 PM, hever@web.de wrote:

...

I'm not sure what NTLM version is used as default by authentication between Outlook and dovecot and I couldn't find it out with a packet sniffer.

I think its NTLMv2 but I'm not sure so I'm asking here.

I know that NTLMv1 is not secure against a man in the middle.

I didn't write the NTLM code, but as far as I understand it, NTLMv2 is used if both client and server negotiates it. But then again I'd think a MITM could force v1 to be negotiated and then attack that, so it doesn't seem all that secure that way either.. Maybe it's prevented in some way.

I think the password hashes also affect this somehow. Maybe NTLM passwords work for v2 and LM passwords for v1?

Maybe Andrey can shed some light into this? :)

Ugh, I need to recall all this crap myself first :)

Actually there is 4 authentication submethods inside the NTLM: LM - server nonce only, highly vulnerable to MITM and rogue server attacks; NTLM - different algorithm, almost equally vulnerable as LM today; NTLM2 - server and client nonce, but MITM can force downgrade to NTLM/LM; NTLMv2 - server and client nonce, MITM can't force downgrade.

NTLM password hash is required for NTLM, NTLM2 and NTLMv2.

NTLMv2 can not be negotiated. It must be explicitly enabled on the client side by setting registry key below to at least 3.

Win9x: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\LMCompatibility WinNT: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\LMCompatibilityLevel

If you want more info about ugly NTLM internals, you can find them here: http://ubiqx.org/cifs/ and here http://davenport.sourceforge.net/ntlm.html

Dovecot uses logic outlined below to handle all this insanity:

1. If we have only LM password hash, try LM authentication; 2 If client sends LM response only (some very old clients do it), try LM too;
2. If NTLMv2 is guessed (using client response length), try NTLMv2;
3. If NTLM2 was negotiated, try it;
4. Otherwise try NTLM.

Best regards.

-- Andrey Panin | Linux and UNIX system administrator pazke@donpac.ru | PGP key: wwwkeys.pgp.net

On 062, 03 02, 2008 at 06:55:09AM +0200, Timo Sirainen wrote:

On Wed, 2008-02-27 at 12:46 +0300, Andrey Panin wrote:

...

Actually there is 4 authentication submethods inside the NTLM: LM - server nonce only, highly vulnerable to MITM and rogue server attacks; NTLM - different algorithm, almost equally vulnerable as LM today; NTLM2 - server and client nonce, but MITM can force downgrade to NTLM/LM; NTLMv2 - server and client nonce, MITM can't force downgrade.

NTLM password hash is required for NTLM, NTLM2 and NTLMv2.

NTLMv2 can not be negotiated. It must be explicitly enabled on the client side by setting registry key below to at least 3.

So this basically means that unless NTLMv2 is explicitly enabled on client side, NTLM auth is insecure because MITM can force a downgrade?

Yes. Without NTLMv2 MITM can force downgrade to plain NTLM and then try dictionary attack with predefined server nonce.

Would there be a point in adding a setting to make Dovecot allow only NTLM2/NTLMv2, so a MITM-downgrade would only fail the authentication? For example mechanisms = NTLM enables NTLM2+v2 and mechanisms = NTLM NTLM1 enables both?

This will be good for security, but bad for backward compatibility. Separate parameter (something like Windows LMCompatibilityLevel) perhaps ?

BTW. I hope you don't mind I added your mail to wiki with small modifications: http://wiki.dovecot.org/Authentication/Mechanisms/NTLM

It's ok :)

-- Andrey Panin | Linux and UNIX system administrator pazke@donpac.ru | PGP key: wwwkeys.pgp.net