Re: sa password
- From: "Richard Mueller [MVP]" <rlmueller-nospam@xxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 29 Nov 2007 15:00:01 -0600
I have not attempted to crack hashes, although the article linked earlier
claims it can be done. My point was not that you must handle numbers of that
size, but that in theory it could require that many operations. Actually,
that many brute force guesses. Per Bruce Schneier in "Applied Cryptography"
(Chapter on "One-Way Hash Functions"):
===== quote ==========
Assume that a one-way hash function follows all of the properties listed
above and the best way to attack it is by using brute force. It produces an
m-bit output. Finding a message that hashes to a give hash value would
require hashing 2^m random messages. Finding two messages that hash to the
same value would only require hashing 2^(m/2) random messages. A machine
that hashes a million messages per second would take 600,000 years to find a
second message that matched a given 64-bit hash. The same machine could find
a pair of messages that hashed to the same value in about an hour.
===== quote ==========
Do the math, it works out. All of this assumes that all messages are equally
likely. If we reduce the universe of possible messages to all upper case,
this can make an attack easier. The article linked before claims this makes
the task possible. However, the SQL Server 2000 hashes are 160-bit. A brute
force attach, even if we know the password is all upper case, is not
feasible. However, the article linked (now that I read it more carefully)
uses a dictionary attack. It assumes a file of possible upper case
passwords. My recollection is that passwords can be up to 128 characters. If
your password is in the dictionary file you're toast. But with a long enough
secure password (letters, numbers, symbols, no words) I doubt it could be
cracked in a reasonable time.
--
Richard Mueller
Microsoft MVP Scripting and ADSI
Hilltop Lab - http://www.rlmueller.net
--
"thejamie" <thejamie@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:6AC1FFC3-8DA7-4013-A5D7-06E13A4D7F4A@xxxxxxxxxxxxxxxx
The size of this number causes an arithmetic overflow. There must be
something interesting in the mechanics if the number to crunch it must be
bigger than the system can handle.
select POWER(2,128) (over 340 undecillion)
That's a big number. It would seem the system would be unable to handle
the
number internally.
Just curious, how big a system would be required to crack the hash, and on
what order of magnitude would something like that cost?
--
Regards,
Jamie
"Richard Mueller [MVP]" wrote:
First I mispelled attack as attach throughout my previous post. I also
mispoke a bit. The 2^64 and 2^80 I referred to is the number of trial
input
strings that must be hashed in order to expect to find any two that
match.
This is the so called "birthday" attack. This is much easier than finding
an
input that hashes to one specific hash value. The number of input strings
you would expect to have to try is closer to 2^128 and 2^160. Except that
the universe of possible passwords is greatly reduced if you know that
all
characters are uppercase.
--
Richard Mueller
Microsoft MVP Scripting and ADSI
Hilltop Lab - http://www.rlmueller.net
--
"Richard Mueller [MVP]" <rlmueller-nospam@xxxxxxxxxxxxxxxxxxxx> wrote in
message news:%237OeIsjIIHA.1208@xxxxxxxxxxxxxxxxxxxxxxx
A hash function converts a variable length input stream (a password in
this
case) to a fixed length value. The function is sometimes called one-way,
which means it should be easy to create the hash but very difficult to
determine the input (in this case a password) from the hash. It should
be
easier to do a brute force search of all passwords to find one that
produces the same hash. A good hash function produces very different
hashes
even if the input is only slightly different, and has few collisions,
meaning cases where two inputs produce the same hash value, and produces
values that appear random.
The SHA algorithm referred to in the article you link produces a
160-bit
hash, hence the 40 character hash strings (actually 20 hexidecimal
characters). This is better than MD5 which produces a 128-bit hash. A
brute force attach of an MD5 hash would require 2^64 operations, which
is
feasible, but a brute force attach of an SHA hash would require 2^80
operations, which is more difficult.
The article you linked is disturbing. Knowing that the second hash is
limited to uppercase characters makes a brute force attach much easier.
Does anyone know why an upper case version of the password should be
saved? Are there any cases where the password is not case sensitive?
Note the article only applies to SQL Server 2000.
--
Richard Mueller
Microsoft MVP Scripting and ADSI
Hilltop Lab - http://www.rlmueller.net
--
"CLM" <CLM@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:5AF336F9-8C05-4D38-B1DD-BEC79DBEA0A5@xxxxxxxxxxxxxxxx
Nevermind. I just found this sobering article all about it!
http://www.nextgenss.com/papers/cracking-sql-passwords.pdf
"CLM" wrote:
Sorry, but what do you mean by password hash??
"Ben Nevarez" wrote:
The password hash is stored on the master database and only
sysadmin
has
access to it.
You can use some tools to find out the password but depending on
its
complexity it can take days or weeks. But you need to have the
password hash
first.
Hope this helps,
Ben Nevarez
Senior Database Administrator
AIG SunAmerica
"CLM" wrote:
Let's say that you create an instance - and I'd be curious of the
answers for
both 2000 and 2005 - in Mixed Mode. If I remember right, the sa
password is
stored on disk but is encrypted. Is that encryption really that
powerful?
Isn't this a huge security risk? Given a few days, couldn't any
decent
cracker break one password that is decrypted?
.
- References:
- Re: sa password
- From: Richard Mueller [MVP]
- Re: sa password
- From: Richard Mueller [MVP]
- Re: sa password
- From: thejamie
- Re: sa password
- Prev by Date: Re: Granting xp_cmdshell permission to SQL Login
- Next by Date: RE: Can user view objects they only have select permission on?
- Previous by thread: Re: sa password
- Next by thread: Re: sa password
- Index(es):
Relevant Pages
|
