Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 24 May 2011 20:02:53 +0200
From: magnum <rawsmooth@...dband.net>
To: john-dev@...ts.openwall.com
Subject: Re: jumbo-1 SSE testing

On 2011-05-24 06:47, JFoug wrote:
> As for original MSSql, there are 2 salted SHA1 hashes stored within the
> same PW hash. They are very similar. We only compute one, and I am
> wondering if this is not enough, and we really are not 'cracking' the
> password. However, I do not know how MSSql uses it, so I am not 'sure'.
>
> What is stored is a salt (4 byte), and 2 SHA hashes. The hashes are:
> sha1(unicode(pass).salt).sha1(unicode(uppercase(pass)).salt) We compute
> the 2nd one, in john. Are we 'sure' we are getting the password (i.e. is
> sql server case insensitive?) Or is this like getting an NTLM from a
> pair of cracked LM keys. We have the letters, but have to brute the
> case. If SQL server is case sensative (the information appears to be
> there), then we should crack using upper case, then brute out the 'real'
> password.

Yes, it's similar to LM vs NT:

Older SQL servers stored two hashes (with no separator between them), 
one of which from uppercase, and both using same salt and same 
algorithm. Newer servers (likely from SQL Server 2005 and on) only store 
the case-sensitive one of the hashes.

The mssql format takes a complete old-style hash, but uses only the 
"upper case" half of it. This format is good as-is, it doesn't need a 
prepare() function.

The mssql05 format was written to take the newer-style hash, which is 
only the case-sensitive half of the old-style. Feeding it with new-style 
hashes, this format needs no prepare() function either. But I just added 
a prepare() function to it, so it *can* take the case-sensitive part of 
the old format as well. Patch posted soon to wiki.

magnum

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ