check_oem_password: incorrect password length (456509439).

Andrew Bartlett abartlet at
Wed Oct 1 06:59:23 GMT 2003

On Wed, 2003-10-01 at 16:44, Дейтер Александр Валерьевич wrote:
> > I cannot change user password from Win2k workstations with ctrl+alt+del,
> if
> > length of the current password is more than 14 symbols.
> I search this topic on google and found this acticle:
> .....
> With LM, password hashes were split into two separate 7-character hashes.
> This actually made passwords more vulnerable because a brute-force attack
> could be performed on each half of the password at the same time. So
> passwords that were 9 characters long were broken into one 7-character hash
> and one 2-character hash. Obviously, cracking a 2-character hash did not
> take long, and the 7-character portion could usually be cracked within
> hours. Often, the smaller portion could actually be used to assist in the
> cracking of the longer portion. Because of this, many security professionals
> determined that optimal password lengths were 7 or 14 characters,
> corresponding to the two 7-character hashes.

Well, I'm not sure 7 is any better than 8 - as long as it is truly
random.   It is effectively 2 independent passwords.

> NTLM improved the situation some by using all 14 characters to store the
> password hash. While this did make things better, NT dialog boxes still
> limited passwords to a maximum of 14 characters; thus the determination that
> passwords of exactly 14 characters are the optimal length for the best
> security.
> But things are different with newer versions of Windows. Windows 2000 and XP
> passwords can now be up to 127 characters in length and so 14 characters is
> no longer a limit. Furthermore, one little known fact discovered by Urity of
> is that if a password is fifteen characters or longer,
> Windows does not even store the LanMan hash correctly. This actually
> protects you from brute-force attacks against the weak algorithm used in
> those hashes. If your password is 15 characters or longer, Windows stores
> the constant AAD3B435B51404EEAAD3B435B51404EE as your LM hash, which is
> equivalent to a null password. And since your password is obviously not
> null, attempts to crack that hash will fail.

Does windows prevent attempted logins with this 'null' password?

What happens when you do s 'net rpc samsync' on that user - do we get
back 'NO PASSWORD' into our smbpasswd file, or that particular constant?

I'm hoping we get 'NO PASSWORD'

Otherwise this is a big security hole, not a feature...  (and I'll need
to add extra logic into various bits of samba to cope with such
braindead things)

Andrew Bartlett

Andrew Bartlett                                 abartlet at
Manager, Authentication Subsystems, Samba Team  abartlet at
Student Network Administrator, Hawker College   abartlet at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url :

More information about the samba-technical mailing list