Password Synchronization

[Simon Hyde]

On Thu, 25 Dec 1997 05:57:15 +1100, you wrote:

[chop]
>>user: lkcl
>>password: foo
>>
>>if (strequal(unixcrypt(lmcrypt(foo)), getunixlmpasswd(lkcl)))
>>...
>
>Regardless of how it's done, it'll take too many CPU cycles to do, for a
>production machine. Basically, what is asked for is a crack process on the
>SMB passwd, to be run each time the passwd changes. Even if it is strictly
>limited to passwd change events, consider the CPU cycles involved when
>doing the initial passwd-crack run for a 1000-user database. Yes, it's
>certainly do-able, on a short-run basis, but it can not happen in
>zero-time. Even using the DBM approach I mentioned earlier, the DBM spacee
>required will be measured in the 10's of GB, or larger (I haven't actually
>run the exact calculations).
>
>>about the only way i can think of that would get around this one is to
>>modify the unix login system to go _via_ the 16 byte lm hash:
>>
>
>This is certainly unacceptable. As was pointed out earlier, the SMB passwd
>is definitely crackable.
>
You don't see what he is suggesting:

In order to make it possible to authenticate an NT encrypted passwd against
the Unix passwd database you don't actually need to store the NT encrypted
passwd, you can simply encrypt the (already) NT encrypted password and
compare this against the Unix password file, ie you alter login to do:

text passwd -> NT encrypted passwd -> unix encrypted ( NT encrypted passwd)

and then compare this value with the password file

This would remove the problem of NT passwords being too easy to decrypt and
still give you the possibility of validating NT encrypted passwords.