RE: [suse-security] Password Encryption
ok, but if we knows, that there is a way to crack the shadow file, why don't we use a secure algorithm ? (triple DES or AES) Are there no implementation for this algorithms ? (a DES cracker-maschine costs about 100.000 $)
Wait! and read aloud after me: "The password is *not* encrypted." Take a deep breath. Now repeat it, please. The password is in fact hashed. The resulting hash is stored in /etc/shadow. The password is gone after that, there's no trace of it left. What then happens, when you login, is that the password you supply to the system is hashed and the hash is compared to the one stored in /etc/shadow. If they match, you're in, if they don't, you're not. As Olaf has repeatedly said, in the case where DES is used, the salt is encrypted using the password as a key to get the 'hash'. However, if you're using 'MD5 passwords' (which is something of a misnomer, of course), DES isn't involved. Someone correct me if I'm wrong. Cheers Tobias
On Wednesday 10 July 2002 12.23, Reckhard, Tobias wrote:
As Olaf has repeatedly said, in the case where DES is used, the salt is encrypted using the password as a key to get the 'hash'.
I think this is slightly wrong. The salt is used to mix the encryption algorithm, and what is actually encrypted is 128 zero-bits. At least that is how I understand the code in libcrypt and the manpage of crypt() //Anders
To simplify; You run a process which basically takes your password and turn it into a number format, does some addition and subtraction to it and converts it into characters and stores it. Looking at the result does not tell you what you started with. It's like you typed 25 but it stores 4513. You cannot reverse it and get 25. So the password you type is processed and the result of that process is then stored in /etc/shadow. So it's the result, not the original password you typed, that is kept. When you login the same process is run and the result is now compared to the result stored in /etc/shadow. I.e. the two results are compared.
Wait! and read aloud after me: "The password is *not* encrypted." Take a deep breath. Now repeat it, please.
The password is in fact hashed. The resulting hash is stored in /etc/shadow. The password is gone after that, there's no trace of it left.
What then happens, when you login, is that the password you supply to the system is hashed and the hash is compared to the one stored in /etc/shadow. If they match, you're in, if they don't, you're not.
As Olaf has repeatedly said, in the case where DES is used, the salt is encrypted using the password as a key to get the 'hash'.
However, if you're using 'MD5 passwords' (which is something of a misnomer, of course), DES isn't involved.
Someone correct me if I'm wrong.
Cheers Tobias
-- Steve Szmidt V.P. Information Technology Video Group Distributors, Inc.
Hi, I'm following this thread and need a little clarity. I'm thinking that if my password was ABC then hashed, the result is compared in the hashed file correct? Therefore could be possible to have another password that when compared to the hashed value it could give the be the same result of my ABC password? Dre :) Luck is my game ;-) Linux is my aim :) -----Original Message----- From: Reckhard, Tobias [mailto:tobias.reckhard@secunet.com] Sent: Wednesday, July 10, 2002 11:24 AM To: suse-security@suse.com Subject: RE: [suse-security] Password Encryption
ok, but if we knows, that there is a way to crack the shadow file, why don't we use a secure algorithm ? (triple DES or AES) Are there no implementation for this algorithms ? (a DES cracker-maschine costs about 100.000 $)
Wait! and read aloud after me: "The password is *not* encrypted." Take a deep breath. Now repeat it, please. The password is in fact hashed. The resulting hash is stored in /etc/shadow. The password is gone after that, there's no trace of it left. What then happens, when you login, is that the password you supply to the system is hashed and the hash is compared to the one stored in /etc/shadow. If they match, you're in, if they don't, you're not. As Olaf has repeatedly said, in the case where DES is used, the salt is encrypted using the password as a key to get the 'hash'. However, if you're using 'MD5 passwords' (which is something of a misnomer, of course), DES isn't involved. Someone correct me if I'm wrong. Cheers Tobias -- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
Yup. Several different passwords could very well generate the same hashed string. Claus Lund Department of Taxes Information Systems 109 State Street Montpelier, Vermont 05609 (802) 828-3735 ----- Original Message ----- From: "arawak" <arawak@blueyonder.co.uk> To: <suse-security@suse.com> Cc: "'Reckhard, Tobias'" <tobias.reckhard@secunet.com> Sent: Wednesday, July 10, 2002 2:26 PM Subject: RE: [suse-security] Password Encryption
Hi,
I'm following this thread and need a little clarity.
I'm thinking that if my password was ABC then hashed, the result is compared in the hashed file correct?
Therefore could be possible to have another password that when compared to the hashed value it could give the be the same result of my ABC password?
Dre :)
Luck is my game ;-) Linux is my aim :)
-----Original Message----- From: Reckhard, Tobias [mailto:tobias.reckhard@secunet.com] Sent: Wednesday, July 10, 2002 11:24 AM To: suse-security@suse.com Subject: RE: [suse-security] Password Encryption
ok, but if we knows, that there is a way to crack the shadow file, why don't we use a secure algorithm ? (triple DES or AES) Are there no implementation for this algorithms ? (a DES cracker-maschine costs about 100.000 $)
Wait! and read aloud after me: "The password is *not* encrypted." Take a deep breath. Now repeat it, please.
The password is in fact hashed. The resulting hash is stored in /etc/shadow. The password is gone after that, there's no trace of it left.
What then happens, when you login, is that the password you supply to the system is hashed and the hash is compared to the one stored in /etc/shadow. If they match, you're in, if they don't, you're not.
As Olaf has repeatedly said, in the case where DES is used, the salt is encrypted using the password as a key to get the 'hash'.
However, if you're using 'MD5 passwords' (which is something of a misnomer, of course), DES isn't involved.
Someone correct me if I'm wrong.
Cheers Tobias
-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
-- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
On Wednesday 10 July 2002 02:38 pm, Claus Lund wrote:
Yup. Several different passwords could very well generate the same hashed string.
But the point of a hash algorithm is to make this possibility extremely unlikely. This is, in fact, a measure of the quality of the hash algorithm: How likely is it that two different input values can yield the same output? When that does happen, it is a hash collision. I say this for the benefit of the folks who asked the original question; I know that Claus knows this already. :-) Scott -- -----------------------+------------------------------------------------------ Scott Courtney | "I don't mind Microsoft making money. I mind them courtney@4th.com | having a bad operating system." -- Linus Torvalds http://4th.com/ | ("The Rebel Code," NY Times, 21 February 1999) | PGP Public Key at http://4th.com/keys/courtney.pubkey
Enlightened :-) Tnx Luck is my game ;-) Linux is my aim :) Dre -----Original Message----- From: Scott Courtney [mailto:courtney@4th.com] Sent: Wednesday, July 10, 2002 9:04 PM To: suse-security@suse.com Subject: Re: [suse-security] Password Encryption On Wednesday 10 July 2002 02:38 pm, Claus Lund wrote:
Yup. Several different passwords could very well generate the same hashed string.
But the point of a hash algorithm is to make this possibility extremely unlikely. This is, in fact, a measure of the quality of the hash algorithm: How likely is it that two different input values can yield the same output? When that does happen, it is a hash collision. I say this for the benefit of the folks who asked the original question; I know that Claus knows this already. :-) Scott -- -----------------------+------------------------------------------------ -----------------------+------ Scott Courtney | "I don't mind Microsoft making money. I mind them courtney@4th.com | having a bad operating system." -- Linus Torvalds http://4th.com/ | ("The Rebel Code," NY Times, 21 February 1999) | PGP Public Key at http://4th.com/keys/courtney.pubkey -- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
* arawak wrote on Wed, Jul 10, 2002 at 19:26 +0100:
Therefore could be possible to have another password that when compared to the hashed value it could give the be the same result of my ABC password?
Yes, this is called a collision. With the crypt algorithm, which produces 56 bit results, every 72,057,594,037,927,936th (==2^56) password gets the same hash value. With other words, if you calculate a plain text value for each of those possiblities, you have a reverse-translation table. But this table would be very large and expensive to build - even expensive to store... To say a word about the salt. To explain the need, just thing a second about hashing. Imagine, many people would use words as passwords. If you have, let's say a million words, you could crypt a million words and get a million crypt values, this table would have a size of 7,000,000 bytes only. With that table, you could retranslate the crypt value to the plaintext. To avoid that, a password is salted with one of 4096 values (on crypt, typical MD5 "crypts" use much larger ranges). The value is taken by random. So every password has 4096 possible results. To be able to decrypt, the salt itself is stored in plain as the first two bytes of the password "hash". So for a million words you would need 4 billion precalculated hashes. Antoher advantage: when you chose the same password twice, you would ususally get different crypt values. With MD5 all those is similar but with more bits :) IIRC MD5 uses 128 bits and 2^128 evaluates to: 340,282,366,920,938,463,463,374,607,431,768,211,456 which is quite nice large :) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
participants (7)
-
Anders Johansson -
arawak -
Claus Lund -
Reckhard, Tobias -
Scott Courtney -
Steffen Dettmer -
Steve