[<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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
