check_oem_password: incorrect password length (456509439).
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,
> > 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
> 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
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
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