|
Posted by =?Utf-8?B?VG9ueSBQYXRyaWFyY2hl on July 6, 2005, 2:36 pm
If you were Registered and logged in, you could reply and use other advanced thread options
Another newbie question ... Why bother hashing a password?
If you have a strong protocol such as CHAP plus encryption, your actual
password should be secure from listeners etc. If you don't, your hash number
is just as vulnerable -- and all the attacker really needs is the hash
number.
If the attack is brute-force/dictionary based or physically on the server,
isn't a hash (especially an integer) even easier to crack than a
symmetrically encrypted strong password?
--
Tony Patriarche
|
|
Posted by =?Utf-8?B?VG9ueSBQYXRyaWFyY2hl on July 6, 2005, 2:55 pm
If you were Registered and logged in, you could reply and use other advanced thread options
On 5/18, Valery Pryamikov quoth: "The sole reason of existence of hash
functions
is that they can get data of arbitrary length and return a fixed number."
That makes sense, but is that really the only reason??
--
Tony Patriarche
--------------------------------------
Another newbie question ... Why bother hashing a password?
If you have a strong protocol such as CHAP plus encryption, your actual
password should be secure from listeners etc. If you don't, your hash number
is just as vulnerable -- and all the attacker really needs is the hash
number.
If the attack is brute-force/dictionary based or physically on the server,
isn't a hash (especially an integer) even easier to crack than a
symmetrically encrypted strong password?
--
Tony Patriarche
|
|
Posted by Karl Levinson, mvp on July 6, 2005, 9:28 pm
If you were Registered and logged in, you could reply and use other advanced thread options
the actual password across the network, because once a password is captured,
it is difficult to prevent a kind of "replay attack" where the password is
used over and over by an attacker to authenticate. An authentication
credential is ideally modified in some way that is unique to that instant in
time.
Many cryptography experts have been thinking long and hard about the best
ways to protect authentication credentials, and NetBIOS is not the only
protocol that hashes passwords. Keep in mind that NetBIOS and LM "hashing"
were not exactly invented by Microsoft but by IBM, and are kept around
because to remove these now would break authentication with previous
versions of Windows. Linux and Unix shadow password files also use hashes
and have the same problem with people being able to brute force them,
replace or delete them. Encrypted passwords are not only vulnerable to the
same attacks as hashed passwords [replay, brute force], they are also
additionally vulnerable to attacks on the encryption / decryption keys,
giving an additional venue for attack compared to hashing.
One problem with symmetric encryption is that if you wanted to use it to
encrypt the passwords on the disk, so that you don't have passwords stored
in clear text, then you would presumably have to store the decryption keys
on the server, both on the disk and probably in memory where an attacker
with the admin / system-equivalent privileges to grab the SAM would probably
also be able to get the decryption keys.
A more controversial question is "why does MS not add salt to its hashes."
Adding salt would help prevent pre-compiled hash "rainbow table" attacks.
MS has some somewhat convincing arguments why they have made this decision,
but I'm not entirely sure I agree. Slowing down a rainbow hash seems like a
nice thing to try to do IMHO.
The argument against adding salt as I understand it is that 1) longer and
more complex passwords makes salt somewhat irrelevant and 2) if someone has
admin privileges on your domain controller to be able to grab the SAM, then
you've got bigger problems that salt isn't going to fix. I'm not saying I
totally agree with this, but both of these arguments could also just as
easily be used in response to your suggestion to use encryption instead of
hashing.
> Another newbie question ... Why bother hashing a password?
>
> If you have a strong protocol such as CHAP plus encryption, your actual
> password should be secure from listeners etc. If you don't, your hash
number
> is just as vulnerable -- and all the attacker really needs is the hash
> number.
>
> If the attack is brute-force/dictionary based or physically on the server,
> isn't a hash (especially an integer) even easier to crack than a
> symmetrically encrypted strong password?
> --
> Tony Patriarche
|
| Similar Threads | Posted | | Question regarding Cryptographic Hash ... | July 10, 2006, 4:06 am |
| Hash injection mitigation? | October 6, 2007, 7:45 pm |
| url locations of patches and md5 hash | May 11, 2008, 3:44 pm |
| Q) SHA(Secure Hash Algorithm) for wireless NDIS driver. | August 17, 2006, 4:56 pm |
| Re: passwords | June 27, 2005, 1:08 am |
| passwords | June 27, 2005, 12:23 am |
| Passwords | September 16, 2005, 2:07 pm |
| passwords | October 19, 2007, 11:42 am |
| passwords and usernames | August 8, 2005, 5:27 pm |
| Passwords on folders | October 10, 2005, 6:10 am |
|
XML site map