check_oem_password: incorrect password length (456509439).

Andrew Bartlett abartlet at samba.org
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:
> 
> http://www.securityfocus.com/infocus/1554/
> 
> .....
> 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
> SecurityFriday.com 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 pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet at samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net
-------------- 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 : http://lists.samba.org/archive/samba-technical/attachments/20031001/6ee82893/attachment.bin


More information about the samba-technical mailing list