hallo, where does the "salt value" come from in the crypt() function? i guess i am looking for an answer for how it is "chosen from the set [a-zA-Z0-9./]". i noticed that the salt value is always the first two chars in the encrypted passwd string, but where does it come from? thanks, -alexm
hallo,
where does the "salt value" come from in the crypt() function? i guess i am looking for an answer for how it is "chosen from the set [a-zA-Z0-9./]". i noticed that the salt value is always the first two chars in the encrypted passwd string, but where does it come from?
thanks,
-alexm
Hi Alex, The salt as used with crypt(3) does not come from the crypt(3) function itself. An application using crypt(3) must provide these two characters (the string). passwd(1) uses values taken from gettimeofday(2), getpid(2) and clock(3), and transforms them to the set of characters expected by crypt(3). Basically, the randomness of these characters is fairly bad, but being a good random number isn't really the purpose of the salt string. In the rare case of two users using the same password, the different salt used with crypt(3) makes the encrypted passwords look different. Regards, Roman. -- - - | Roman Drahtmüller <draht@suse.de> // "Caution: Cape does | SuSE GmbH - Security Phone: // not enable user to fly." | Nürnberg, Germany +49-911-740530 // (Batman Costume warning label) | - -
* alex medvedev wrote on Tue, Aug 15, 2000 at 12:09 -0500:
hallo,
where does the "salt value" come from in the crypt() function?
crypt makes a encrypted string from another string. If you hadn't a salt value, you could crypt() a whole dictionary, and then you could just compare your crypted strings with the strings from the passwd/shadow file, and you would get passwords that are in the dictionary very fast, and you would see whenever passwords are equal or empty. So a random salt value is choosen and stored with the encrypted string. IIRC there are 4096 possibilities for the salt, so it's more difficult to make a dictionary attack, since you cannot crypt() the whole dictionary (or if you do, you get 4096 strings for each word to compare!). Second, the crypted string is a different one if you change you password to the same cleartext value (since both would use a different salt). oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Actually it's less then 4096 values: a-z, A-Z, some other chars, more like 2-3000. This is why you use MD5 passwords (RedHat, etc support it) or Blowfish (OpenBSD). Also using something like MD5 significantly increases the amount of time an attacker needs to brute force the passwords (MD5 is slooooooooow). -Kurt
Kurt Seifried wrote:
Actually it's less then 4096 values:
a-z, A-Z, some other chars, more like 2-3000. This is why you use MD5 passwords (RedHat, etc support it) or Blowfish (OpenBSD). Also using something like MD5 significantly increases the amount of time an attacker needs to brute force the passwords (MD5 is slooooooooow).
-Kurt
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
A snippet from my manual entry indicates there are 4096 possible salts: : : salt is a two-character string chosen from the set [a-zA-Z0-9./]. This string is used to perturb the algo- rithm in one of 4096 different ways. : Cheers - Les Catterall
On Wed, 16 Aug 2000, Steffen Dettmer wrote:
So a random salt value is choosen and stored with the encrypted string. IIRC there are 4096 possibilities for the salt, so it's more difficult to make a dictionary attack, since you cannot crypt() the whole dictionary (or if you do, you get 4096 strings for each word to compare!). Second, the crypted string is a different one if you change you password to the same cleartext value (since both would use a different salt).
This is still not very safe. With the computers we have nowadays one can run about 240,000 entries per second through crypt(). This means that _all_ possible passwords (i.e. all allowed characters plus the NULL in all combinations of 8) can be calculated with all possible salts in just over a month on an average alpha or high-end intel processor. The results could then be stored on a harddisk in a database. The whole database containing all possible passwords in cleartext as well as crypt()ed with every possible salt would take up less than 9 Gb. Using this database any password can be "cracked" in a matter of seconds (i.e. the time needed to pick the correct list out of 4096 total, and then find an entry in this sorted list of about 2Mb). I guess it's time to replace crypt() with a more modern algorithm. OpenBSD uses eks-Blowfish, which seems to do the job wonderfully. Would it be possible to implement this in SuSE Linux? I guess with PAM this should not be too much work. Also I'd think that when implementing it in PAM as an option there should not be any serious compatibility problems. Did anybody try this yet? If not I'm willing to invest some time in it in the near future... Cheers! Yuri. -------------------------------------------------------------------------- drs. Yuri Robbers phone : +31-71-527-4966 Leiden University fax : +31-71-527-4900 Institute for Theoretical Biology email : robbers@rulsfb.leidenuniv.nl Kaiserstraat 63 2311 GP Leiden PGP 5.0 public key available: the Netherlands Check your favourite hkp server. --------------------------------------------------------------------------
This is still not very safe. With the computers we have nowadays one can run about 240,000 entries per second through crypt(). This means that _all_ possible passwords (i.e. all allowed characters plus the NULL in all combinations of 8) can be calculated with all possible salts in just over a month on an average alpha or high-end intel processor. The results could then be stored on a harddisk in a database. The whole database containing all possible passwords in cleartext as well as crypt()ed with every possible salt would take up less than 9 Gb. Using this database any password can be "cracked" in a matter of seconds (i.e. the time needed to pick the correct list out of 4096 total, and then find an entry in this sorted list of about 2Mb).
Yeah, and I just bought a 60gig HD for $219 US, it's insane (that and I have a half dozen PIII coppermine systems to crunch the data, I figure <1 week to generate the database). Hmm, something to do on the weekend maybe =) (with a web interface too, heeeee).
I guess it's time to replace crypt() with a more modern algorithm. OpenBSD uses eks-Blowfish, which seems to do the job wonderfully. Would it be possible to implement this in SuSE Linux? I guess with PAM this should not be too much work. Also I'd think that when implementing it in PAM as an option there should not be any serious compatibility problems. Did anybody try this yet? If not I'm willing to invest some time in it in the near future...
RedHat moved to MD5 quite some time ago. I'm rather shocked SuSE hasn't.
Cheers! Yuri.
-Kurt
Hi! On Wed, 16 Aug 2000, Kurt Seifried wrote:
Yeah, and I just bought a 60gig HD for $219 US, it's insane (that and I have a half dozen PIII coppermine systems to crunch the data, I figure <1 week to generate the database). Hmm, something to do on the weekend maybe =) (with a web interface too, heeeee).
Yes... would be nice... maybe you could even sell your services over the web... the credit card software is in the SuSE 6.4 pay-directory :o)
I guess it's time to replace crypt() with a more modern algorithm. OpenBSD uses eks-Blowfish, which seems to do the job wonderfully. Would it be possible to implement this in SuSE Linux? I guess with PAM this should not be too much work. Also I'd think that when implementing it in PAM as an option there should not be any serious compatibility problems. Did anybody try this yet? If not I'm willing to invest some time in it in the near future...
RedHat moved to MD5 quite some time ago. I'm rather shocked SuSE hasn't.
Indeed. Although MD5 is not the best solution either. Of course any password algorithm is only sufficiently strong for a couple of years, although some algorithms may be expected to "live" longer than others. See for example crypt() which was uncrackable by even supercomputers in 1976, but is a piece of cake nowadays. Of the algorithms I know Bruce Schneier's (1994) Blowfish would have my preference because it can be expected to be too expensive to crack (computationally speaking) for a much longer time than - for example - MD5. Even better would be Niels Provos and David Mazieres' (unpubl. ms.) adaptation eks-Blowfish (expensive key schedule Blowfish) because the computational cost can be set by the user or administrator to easily and transparently adapt to increasing processor power. Also several people (most notably B. den Boer & A. Bosselaers (1994)) have demonstrated several weaknesses in MD5. It has been shown, among other things, that MD5 fails in one of its most important design issues: creation of a collision-resistant compression function. The compression function in MD5 is far from collision-resistant, and although I do not know of an easy way to abuse these weaknesses in MD5, other people might. And if not it's probably only a matter of time until someone creates an exploit. Because of these issues I would prefer using another algorithm if at all possible. Cheers! Yuri. PS. For those among you that are interested in cryptanalysis: full references to cited papers are available upon request. -------------------------------------------------------------------------- drs. Yuri Robbers phone : +31-71-527-4966 Leiden University fax : +31-71-527-4900 Institute for Theoretical Biology email : robbers@rulsfb.leidenuniv.nl Kaiserstraat 63 2311 GP Leiden PGP 5.0 public key available: the Netherlands Check your favourite hkp server. --------------------------------------------------------------------------
On Wed, 16 Aug 2000, Kurt Seifried wrote:
I guess it's time to replace crypt() with a more modern algorithm. OpenBSD uses eks-Blowfish, which seems to do the job wonderfully. Would it be possible to implement this in SuSE Linux? I guess with PAM this should not be too much work. Also I'd think that when implementing it in PAM as an option there should not be any serious compatibility problems. Did anybody try this yet? If not I'm willing to invest some time in it in the near future...
RedHat moved to MD5 quite some time ago. I'm rather shocked SuSE hasn't.
I'd prefer md5 too. What about the upcoming 7.0 version though? Does that still use crypt or md5? Maybe someone from SuSE can inform us. Or should those of us that want more protection do it via PAM?
Cheers! Yuri.
-Kurt
Stefan
RedHat moved to MD5 quite some time ago. I'm rather shocked SuSE hasn't.
I'd prefer md5 too. What about the upcoming 7.0 version though? Does that still use crypt or md5? Maybe someone from SuSE can inform us. Or should those of us that want more protection do it via PAM?
-Kurt Stefan
It's not that I want to justify that we don't use md5. I *think* (it's holiday time...) that md5 is in preparation, but don't pin me down on that now, please... Nevertheless: If an attacker has access to your encrypted passwords, you're in trouble anyway. There is a difference btw a 10th of a second and several days for cracking the passwords, but the result is basically the same, isn't it? Thanks, Roman. -- - - | Roman Drahtmüller <draht@suse.de> // "Caution: Cape does | SuSE GmbH - Security Phone: // not enable user to fly." | Nürnberg, Germany +49-911-740530 // (Batman Costume warning label) | - -
Hi, On Wed, 16 Aug 2000, Roman Drahtmueller wrote:
Nevertheless: If an attacker has access to your encrypted passwords, you're in trouble anyway. There is a difference btw a 10th of a second and several days for cracking the passwords, but the result is basically the same, isn't it?
It's not a matter of a 10th of a second versus several days. If you use MD5, or an even better algorithm, it's the difference between a 10th of a second or a couple of years at the very least (or even centuries, if we ignore technological advances). A 10th of a second is a big problem, and a couple of days is not significantly better of course. But after a couple of years any sensible person would have changed their password, and after a couple of centuries most people would be dead anyway. It all depends on your needs of course, mainly on the time you need your data to be safe, and of course on how often you change your password. For me changing to bcrypt would be well worth the trouble. Cheers! Yuri. -------------------------------------------------------------------------- drs. Yuri Robbers phone : +31-71-527-4966 Leiden University fax : +31-71-527-4900 Institute for Theoretical Biology email : robbers@rulsfb.leidenuniv.nl Kaiserstraat 63 2311 GP Leiden PGP 5.0 public key available: the Netherlands Check your favourite hkp server. --------------------------------------------------------------------------
ignore technological advances). A 10th of a second is a big problem, and a couple of days is not significantly better of course. But after a couple of years any sensible person would have changed their password, and after a couple of centuries most people would be dead anyway.
Convincing. Agreed. :-) [...]
Yuri.
Roman. -- - - | Roman Drahtmüller <draht@suse.de> "Caution: Cape does not | SuSE GmbH - Security enable user to fly." | Nürnberg, Germany (Batman Costume warning label) | - -
On Wed, 16 Aug 2000, Yuri Robbers wrote:
It's not a matter of a 10th of a second versus several days. If you use MD5, or an even better algorithm, it's the difference between a 10th of a second or a couple of years at the very least (or even centuries, if we ignore technological advances). A 10th of a second is a big problem, and a couple of days is not significantly better of course. But after a couple of years any sensible person would have changed their password, and after a couple of centuries most people would be dead anyway.
I don't understand that. If someone has your password file he can start a dictionary attack. Is there any difference encrypting words in crypt or MD5 and comparing the result to passwd? Wouldn't the centuries apply only to cracking the scrambled value but not to a "guessing" approach? Maybe I'm just ignorant. Security would of course be enhanced by allowing more than 8 character passwords. Last I heard there were still issues with NIS. (Not that there's much security left when you use NIS ;-) Cheers Robert -- Robert Casties --------------------- http://philoscience.unibe.ch/~casties History & Philosophy of Science Tel: +41/31/631-8505 Room: 216 Institute for Exact Sciences Sidlerstrasse 5, CH-3012 Bern Uni Bern (PGP key on homepage: D7 2B DE 64 2D 65 16 A0)
Hi! On Wed, 16 Aug 2000, Robert Casties wrote:
I don't understand that. If someone has your password file he can start a dictionary attack. Is there any difference encrypting words in crypt or MD5 and comparing the result to passwd?
Wouldn't the centuries apply only to cracking the scrambled value but not to a "guessing" approach? Maybe I'm just ignorant.
The numbers I mentioned apply to guessing attacks. Algorithms like crypt(), are designed to be one-way. It is not (or should not be) possible to reconsruct the original password from the encrypted password. The differences between crypt(), MD5, etc. with regard to guessing attacks are the amount of time needed for one guess, the maximum number of characters in a password, and the number of possible encrypted passwords. More time per guess slows down the cracker, but also the login-process for the bona fide user. A larger number of possible encrypted passwords increases the search space the cracker needs to cover, and makes it less feasible to create a database of all possible encrypted passwords, which would make it possible to crack a password by doing a simple database lookup. The 10th of a second refers to a lookup in a database of all possible encrypted crypt() passwords (i.e. not only those in a dictionary, but _all_ possible passwords). In this case the brute force attack needed to create this database (which would be just under 9 Gb) has been done beforehand. The couple of days refers to a brute force guessing attack on one encrypted password. As a matter of fact it would take about 1 month on a regular Pentium III system to try all possible passwords in crypt(). Using MD5 the time needed per guess increases dramatically, making it less feasible to launch a brute force guessing attack. Also the total number of possible encrypted passwords increases many orders of magnitude, making it (for the time being) impossible to create a database of all possible encrypted passwords. The same applies in varying degrees to any other algorithm. The years, centuries, and many times the estimated lifetime of the universe apply to guessing attacks on - for example - the eks-Blowfish algorithm. The solution to this dilemma is choosing a good password algorithm that can - hopefully - be used for quite some time into the future. As an aside, the reasons for not choosing a dictionary (or otherwise easily guessable string) as a password is the fact that it is immensily quicker to check all dictionary words in a guesisng attack than to check all possible strings. That's why I tend to have passwords like Ki&G7!0p on all my accounts, and never the same password on any two accounts. It's a pain on the memory, but it keeps my data safer.
Security would of course be enhanced by allowing more than 8 character passwords. Last I heard there were still issues with NIS. (Not that there's much security left when you use NIS ;-)
Yes. Using longer passwords is an easy way of increasing security. But there is a limit to the password length user are prepared (or able) to memorize. And you don't want them to go around writing down their password on a post-it not that they stick to their screen. The same goes for the incomprehensible passwords like Ki&G7!0p. The best method I'm aware of is, using acronyms for passwords. For example "SwAT7D!" which is short for "Snowwhite and the seven dwarves!". And well... about all those unsafe protocols that send plaintext passwords over teh network... they should be outlawed :o) Use ssh (http://www.openssh.com) instead of telnet, rlogin, etc. Or implement IPSec... I hope this helps (and doesn;t bore you to death, being as long-winded as it is)... :o) Cheers! Yuri. -------------------------------------------------------------------------- drs. Yuri Robbers phone : +31-71-527-4966 Leiden University fax : +31-71-527-4900 Institute for Theoretical Biology email : robbers@rulsfb.leidenuniv.nl Kaiserstraat 63 2311 GP Leiden PGP 5.0 public key available: the Netherlands Check your favourite hkp server. --------------------------------------------------------------------------
Hallo all, Am Wed, Aug 16, 2000 at 04:22:31PM +0200 schrieb Yuri Robbers:
Hi! ...
thank you, Yuri, for pointing out all this. It shows two important things: First, all the arguments brought forward here have been discussed before. Second, the real problem is the password approach itself. Its weaknesses are known for over TWO DECADES now (recommended reading: Robert Morris and Ken Thompson: Password Security: A Case History. In: Communications of the ACM 22(11), 1979, pp. 594-597). Still, nothing has changed. So please, if you want to improve things, do not discuss password encryption algorithms, discuss alternatives to the password scheme as a whole! (And remember what Karl Valentin, a german actor, once said (translation): "Everything has been said already, but not by everyone yet." ;-) ) Regards Johannes Geiger ----------------------------------------------------------------- Dipl.-Inform. Johannes Geiger geiger@informatik.tu-muenchen.de Technische Universität München http://wwwspies.in.tum.de/~geiger Fakultät für Informatik Tel.: 089/289-25723 Fax: -22037 D-80290 München Raum 3544, Eingang XI (Ecke Luisen-/Theresienstraße), 3. Stock -----------------------------------------------------------------
On Wed, 16 Aug 2000, Johannes Geiger wrote:
thank you, Yuri, for pointing out all this. It shows two important things:
First, all the arguments brought forward here have been discussed before.
Could be. I never saw them, since I have not bene on this list for long. My apologies for any redundancy. But judging by the amount of reactions there seems to be an interest for the issue.
Second, the real problem is the password approach itself. Its weaknesses are known for over TWO DECADES now (recommended reading: Robert Morris and Ken Thompson: Password Security: A Case History. In: Communications of the ACM 22(11), 1979, pp. 594-597). Still, nothing has changed.
I'm aware of this. I've read the paper. What worries me most is that, like you say, the majority of people didn't act on it.
So please, if you want to improve things, do not discuss password encryption algorithms, discuss alternatives to the password scheme as a whole!
You may be right. But the alternatives I can think of (mainly various methods of biometry like retina scan, voice recognition, etc.) are not generally available yet, are not foolproof either, and suffer from some (though not all) of the problems that passwords also suffer from (like network sniffers). I am open to any and all suggestions. But seeing that no solution is going to last forever, I'd opt for a temporary solution that is not perfect, over staying with the even worse method we use now. It is true that we will never get things 100% secure, but it seems a fallacy to me to not try and increase our percentage from - say - 40% to 65% if this can be done without to much trouble.
(And remember what Karl Valentin, a german actor, once said (translation): "Everything has been said already, but not by everyone yet." ;-) )
Very wise words! But if we would all draw our conclusions and noone would say anything at all anymore the world would get a just a bit too boring for me :o) Kind regards, Yuri. -------------------------------------------------------------------------- drs. Yuri Robbers phone : +31-71-527-4966 Leiden University fax : +31-71-527-4900 Institute for Theoretical Biology email : robbers@rulsfb.leidenuniv.nl Kaiserstraat 63 2311 GP Leiden PGP 5.0 public key available: the Netherlands Check your favourite hkp server. --------------------------------------------------------------------------
Hello Yuri, hello list! Am Wed, Aug 16, 2000 at 05:16:42PM +0200 schrieb Yuri Robbers:
First, all the arguments brought forward here have been discussed before.
Could be. I never saw them, since I have not bene on this list for long. My apologies for any redundancy. But judging by the amount of reactions there seems to be an interest for the issue.
Sorry, Yuri, for me not beeing clear: I absolutely do not blame you for any redundancy. On the contrary: I think your previous mail is a good summary of the state of the global discussion. I only wanted to supplement your statement with the hint to the others that the discussion started in this list had already taken place elsewhere and that there is no point in repeating it here in this list.
Second, the real problem is the password approach itself. Its weaknesses are known for over TWO DECADES now (recommended reading: Robert Morris and Ken Thompson: Password Security: A Case History. In: Communications of the ACM 22(11), 1979, pp. 594-597). Still, nothing has changed.
I'm aware of this. I've read the paper. What worries me most is that, like you say, the majority of people didn't act on it.
As above, I have not meant this as hint to you, Yuri, but to those who apparently have not been aware of it.
But seeing that no solution is going to last forever, I'd opt for a temporary solution that is not perfect, over staying with the even worse method we use now. It is true that we will never get things 100% secure, but it seems a fallacy to me to not try and increase our percentage from - say - 40% to 65% if this can be done without to much trouble.
Of course I agree with you in this point as well. But we all should be aware of the fact that the measures one should take to reach those 65% are all well known since 20 years now, but we are still at 40%. So all, get informed! There is a lot of information out there about longer, hard-to-guess passwords, one-time-password-schemes, better encryption algorithms and all those things. But most important: Take a look at the alternatives to the password-scheme: smartcards, cryptographic protocols, biometry, and so on. So again, Yuri, sorry for beeing unclear, I did not mean to criticize you. Best regards Johannes Geiger ----------------------------------------------------------------- Dipl.-Inform. Johannes Geiger geiger@informatik.tu-muenchen.de Technische Universität München http://wwwspies.in.tum.de/~geiger Fakultät für Informatik Tel.: 089/289-25723 Fax: -22037 D-80290 München Raum 3544, Eingang XI (Ecke Luisen-/Theresienstraße), 3. Stock -----------------------------------------------------------------
Sorry, Yuri, for me not beeing clear: I absolutely do not blame you for any redundancy. On the contrary: I think your previous mail is a good summary of the state of the global discussion. I only wanted to supplement your statement with the hint to the others that the discussion started in this list had already taken place elsewhere and that there is no point in repeating it here in this list.
As above, I have not meant this as hint to you, Yuri, but to those who apparently have not been aware of it.
No offence taken at all... :o)
Of course I agree with you in this point as well. But we all should be aware of the fact that the measures one should take to reach those 65% are all well known since 20 years now, but we are still at 40%.
Yes you are right... strange really: 20 years and still people ignore this issue... any psychologist in need of a subject for a PhD thesis?
So all, get informed! There is a lot of information out there about longer, hard-to-guess passwords, one-time-password-schemes, better encryption algorithms and all those things. But most important: Take a look at the alternatives to the password-scheme: smartcards, cryptographic protocols, biometry, and so on.
Yes! I agree completely. Install that IPSec, ssh and Kerberos. Get those smartcards, retina scanners and fingerprint readers!
So again, Yuri, sorry for beeing unclear, I did not mean to criticize you.
No problem at all. Kind regards, Yuri. -------------------------------------------------------------------------- drs. Yuri Robbers phone : +31-71-527-4966 Leiden University fax : +31-71-527-4900 Institute for Theoretical Biology email : robbers@rulsfb.leidenuniv.nl Kaiserstraat 63 2311 GP Leiden PGP 5.0 public key available: the Netherlands Check your favourite hkp server. --------------------------------------------------------------------------
-----BEGIN PGP SIGNED MESSAGE----- Much ado about nothin', i think. Roman is right. If an attacker has access to your encrypted password there's nothing to worry about, you've been hacked. I one sets up a good security policy (tcp wrappers, firewall, user acces) there's nothing to worry about cracked passwords. Using something like shadow works just fine. You could even set up a plain text password file instead of crypt, md5, blowfish and others. Please, do add an "IMHO" at the begining of each sentence. - --- Bogdan Zapca System Administrator SC EcoSoft SA Internet Service Provider 1-7 Deva st, Cluj-Napoca, Romania Tel: +40 64 199696 PGP: http://www.itotal.ro/lupe@admin2.ecosoft.ro.pgp http://www.ecosoft.ro -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBOZrKadPv6ylvTc6pAQFtFgP/RTamR0d/+lUzEetBWc70lVY/DLlEB5Cz r1R6ii0gWuaN/tfTz86rTzpfohj8+vZvn6zqbOqWU2N6UVgDc1048nHpRJX5kEhy pDMrIEuJOPpLIYrPLYy6wXPbuJHHpdXjeOSnrhfjEAfSmhkaWgQCcN3/MVFhqm2U OnfYADpnYZY= =SwIT -----END PGP SIGNATURE-----
On Wed, 16 Aug 2000, Bogdan Zapca wrote:
Much ado about nothin', i think. Roman is right. If an attacker has access to your encrypted password there's nothing to worry about, you've been hacked. I one sets up a good security policy (tcp wrappers, firewall, user acces) there's nothing to worry about cracked passwords. Using something like shadow works just fine. You could even set up a plain text password file instead of crypt, md5, blowfish and others.
Yes, but it's the difference between one host being hacked and an entire network. I don't know about your network of course, but on ours there are A LOT of hosts, some of which are even maintained by users (much to my horror and disgust ;-)). What about a user who decides he want to use Linux and installs a default installation of say RedHat 4.2 (because he had that lying around anyway) and makes his (registered Windows host) multi boot, so suddenly you have a linux machine on your net that is so full of holes you could drive a truck through it. Of course the user uses the same password on it that he uses on all other university systems. No need for inconvenience eh? ;-). Then I would very much prefer that the passwords would be encrypted by an algorithm that takes the hacker (who gained root on the new machine in about 5 minutes) some weeks to crack, because by that time the user's password will have changed again. And believe me, these users do exist (although not for long after we discover what they did ;-)).
Please, do add an "IMHO" at the begining of each sentence.
Stefan
-----BEGIN PGP SIGNED MESSAGE----- True, but there's something more. If one hacks a machine on the network(that is so unsecure) a sniffer will do, as an unsecure network sure uses telnet instead of ssh and so on. - --- Bogdan Zapca System Administrator SC EcoSoft SA Internet Service Provider 1-7 Deva st, Cluj-Napoca, Romania Tel: +40 64 199696 PGP: http://www.itotal.ro/lupe@admin2.ecosoft.ro.pgp http://www.ecosoft.ro On Wed, 16 Aug 2000, Stefan Suurmeijer wrote:
On Wed, 16 Aug 2000, Bogdan Zapca wrote:
Much ado about nothin', i think. Roman is right. If an attacker has access to your encrypted password there's nothing to worry about, you've been hacked. I one sets up a good security policy (tcp wrappers, firewall, user acces) there's nothing to worry about cracked passwords. Using something like shadow works just fine. You could even set up a plain text password file instead of crypt, md5, blowfish and others.
Yes, but it's the difference between one host being hacked and an entire network. I don't know about your network of course, but on ours there are A LOT of hosts, some of which are even maintained by users (much to my horror and disgust ;-)). What about a user who decides he want to use Linux and installs a default installation of say RedHat 4.2 (because he had that lying around anyway) and makes his (registered Windows host) multi boot, so suddenly you have a linux machine on your net that is so full of holes you could drive a truck through it. Of course the user uses the same password on it that he uses on all other university systems. No need for inconvenience eh? ;-). Then I would very much prefer that the passwords would be encrypted by an algorithm that takes the hacker (who gained root on the new machine in about 5 minutes) some weeks to crack, because by that time the user's password will have changed again. And believe me, these users do exist (although not for long after we discover what they did ;-)).
Please, do add an "IMHO" at the begining of each sentence.
Stefan
-----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBOZrRpdPv6ylvTc6pAQFS3wQAj0xZV3RCIg7nW/PzIq1glaoap0qxV3oL GpDvod1XbiLcKn6z09EaBErZYpzAhWu/2JHZ6Wb+Zf8gw5eUUUZFzZOMHiihsPfG 6H8ShO3iDN2RySTQSMUg68iXhh1YKVyUA0Mbygw7ipehv6MLC5EYv2WoHbepr7Wh muOml1p8Nug= =f9xX -----END PGP SIGNATURE-----
Hi! On Wed, 16 Aug 2000, Bogdan Zapca wrote:
Much ado about nothin', i think. Roman is right. If an attacker has access to your encrypted password there's nothing to worry about, you've been hacked. I one sets up a good security policy (tcp wrappers, firewall, user acces) there's nothing to worry about cracked passwords. Using something like shadow works just fine. You could even set up a plain text password file instead of crypt, md5, blowfish and others.
Please, do add an "IMHO" at the begining of each sentence.
True, to a certain extent. Although personally I prefer the added safety of passwords that take more than a few days to crack. Sometimes a bug in some otehr program enables remote users to obtain the /etc/shadow file. Read some old CERT or Bugtraq mails for inspiration :o) Cheers! Yuri. -------------------------------------------------------------------------- drs. Yuri Robbers phone : +31-71-527-4966 Leiden University fax : +31-71-527-4900 Institute for Theoretical Biology email : robbers@rulsfb.leidenuniv.nl Kaiserstraat 63 2311 GP Leiden PGP 5.0 public key available: the Netherlands Check your favourite hkp server. --------------------------------------------------------------------------
you're in trouble anyway. There is a difference btw a 10th of a second and several days for cracking the passwords, but the result is basically the same, isn't it?
Thanks, Roman. The result is not the same believe me with password expiry in a few days the passwords would have expired. Big difference in my opinion. Noah ksemat@eahd.or.ug
On Wed, Aug 16, Roman Drahtmueller wrote:
RedHat moved to MD5 quite some time ago. I'm rather shocked SuSE hasn't.
I'd prefer md5 too. What about the upcoming 7.0 version though? Does that still use crypt or md5? Maybe someone from SuSE can inform us. Or should those of us that want more protection do it via PAM?
-Kurt Stefan
It's not that I want to justify that we don't use md5. I *think* (it's holiday time...) that md5 is in preparation, but don't pin me down on that now, please...
We have support for it since a long time. Read /usr/doc/packages/pam/README.md5 on SuSE Linux 6.4 or /usr/share/doc/packages/pam/README.md5 on SuSE Linux 7.0. Or look in your handbook. md5 is problematic, because a lot of Unix and services/protocols don't understand it. Only look at distributions which have md5 as default, how long take it until programs like yppasswd/rpc.yppasswdd for example where fixed and doesn't crash with a buffer overun ? (I know when I have fixed it ;) Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background.
We have support for it since a long time. Read /usr/doc/packages/pam/README.md5 on SuSE Linux 6.4 or /usr/share/doc/packages/pam/README.md5 on SuSE Linux 7.0. Or look in your handbook.
md5 is problematic, because a lot of Unix and services/protocols don't understand it. Only look at distributions which have md5 as default, how long take it until programs like yppasswd/rpc.yppasswdd for example where fixed and doesn't crash with a buffer overun ? (I know when I have fixed it ;)
PAM. THis is why we have PAM. A program ralks to PAM, PAM does the grunt work. It could be a crypt based password scheme, MD5 or a smart card, the applicaiton doesn't know or care. http://www.sysadminmag.com/current/feature.shtml
Thorsten
-Kurt
On Wed, Aug 16, Kurt Seifried wrote:
We have support for it since a long time. Read /usr/doc/packages/pam/README.md5 on SuSE Linux 6.4 or /usr/share/doc/packages/pam/README.md5 on SuSE Linux 7.0. Or look in your handbook.
md5 is problematic, because a lot of Unix and services/protocols don't understand it. Only look at distributions which have md5 as default, how long take it until programs like yppasswd/rpc.yppasswdd for example where fixed and doesn't crash with a buffer overun ? (I know when I have fixed it ;)
PAM. THis is why we have PAM. A program ralks to PAM, PAM does the grunt work. It could be a crypt based password scheme, MD5 or a smart card, the applicaiton doesn't know or care.
No, you don't understand the problem and it seems you have not understand what PAM is for and what not. PAM must use the defined protocol to get the password or to change it. If the protocol does not allow md5, PAM cannot ignore this and use md5. PAM can only use what is allowed. If the server on the other side is buggy and don't work with md5, PAM cannot fix this. PAM is for making applications simpler and configuration easier, not for replacing existing authentication schemes or protocols. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background.
No, you don't understand the problem and it seems you have not understand what PAM is for and what not. PAM must use the defined protocol to get the password or to change it. If the protocol does not allow md5, PAM cannot ignore this and use md5. PAM can only use what is allowed. If the server on the other side is buggy and don't work with md5, PAM cannot fix this. PAM is for making applications simpler and configuration easier, not for replacing existing authentication schemes or protocols.
This is probably why I shouldn't answer technical email for breakfast. I'll claim low blood sugar led to the brainfart I had. Anyways, Most vendors have moved from crypt to something more secure quite a long time ago, and as Roman pointed out it looks likely that SuSE will to. I see absoulutely no argument for keeping crypt, as for backwards compatibility you can recompile your software if you absoulutely need to, but if it's that old you probably need to upgrade anyways.
Thorsten
-Kurt
still use crypt or md5? Maybe someone from SuSE can inform us. Or should those of us that want more protection do it via PAM? I think that all of su definitely want more protection. I was recently cracked by someone who spent about 5 days running a cracker on my machine and voila he acquired quite a number of passwords and they were not weak passwords. Lucky for me he wasn't hostile since he was doing it just to show me that I shouldn't sit back and relax.
Cheers! Yuri.
-Kurt
Stefan
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
Noah ksemat@eahd.or.ug
On Wed, 16 Aug 2000, Yuri Robbers wrote:
I guess it's time to replace crypt() with a more modern algorithm. OpenBSD uses eks-Blowfish, which seems to do the job wonderfully. Would it be possible to implement this in SuSE Linux? I guess with PAM this should not be too much work. Also I'd think that when implementing it in PAM as an option there should not be any serious compatibility problems. Did anybody try this yet? If not I'm willing to invest some time in it in the near future...
A patch for pam to support OpenBSD's bcrypt can be found at Nikos Mavroyanopoulos' page at http://members.hellug.gr/nmav/ _ _ _|_ o._ o _ _)(_) |_ || |_>
Hi! On Wed, 16 Aug 2000, Sotiris Tsimbonis wrote:
A patch for pam to support OpenBSD's bcrypt can be found at Nikos Mavroyanopoulos' page at http://members.hellug.gr/nmav/
Thanks a lot! I'll check it out immediately! Cheers! Yuri. -------------------------------------------------------------------------- drs. Yuri Robbers phone : +31-71-527-4966 Leiden University fax : +31-71-527-4900 Institute for Theoretical Biology email : robbers@rulsfb.leidenuniv.nl Kaiserstraat 63 2311 GP Leiden PGP 5.0 public key available: the Netherlands Check your favourite hkp server. --------------------------------------------------------------------------
participants (13)
-
alex medvedev -
Bogdan Zapca -
Johannes Geiger -
Kurt Seifried -
Les Catterall -
Robert Casties -
Roman Drahtmueller -
Sematimba Noah -
Sotiris Tsimbonis -
Stefan Suurmeijer -
Steffen Dettmer -
Thorsten Kukuk -
Yuri Robbers