Re: How to secure passwords?
Following on with the MD5 + salt advice, the Jasypt project (http://www.jasypt.org/) looks to be the way I'd go if I needed to do this. See http://www.jasypt.org/howtoencryptuserpasswords.html for a recap of what's been discussed here. /Gwyn On 04/12/2007, John Krasnay [EMAIL PROTECTED] wrote: On Tue, Dec 04, 2007 at 03:41:03PM +0100, Sebastiaan van Erk wrote: My original point was that MD5 hash plus salt is adequate in most use cases; and I still stand by that. If you're developing a high profile site, then I STRONGLY suggest you hire a security expert to audit your entire site: security policy, operating procedures, and systems. Agreed on both points. jk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Download Wicket 1.3.0-rc1 now! - http://wicketframework.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to secure passwords?
John Krasnay wrote: I see from your later posts that your requirements are not that strict, but if anyone else on the list needs to do password hashing, here's one of the best articles I've seen on it: http://www.matasano.com/log/958/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes/ jk This article is a total rant with lots of stupid inaccurate information. For example: 1. take a “dictionary” —- say, of all combinations of alphanumerics less than 15 characters 2. hash all of them 3. burn the results onto a DVD. The keyspace is size is 62^15-1 = 76890970494878552634367. That means if you can save a hash in 1 byte you still need about 143220593211942663 DVD's. Next he goes on to state: Speed is exactly what you don’t want in a password hash function. You don’t care if password tests take twice as long, or even ten times as long, because password hashes aren’t in the 80/20 hot spot. Now the attacker. This is easy. The attacker cares a lot if password tests take twice as long. If one password test takes twice as long, the total password cracking time takes twice as long. But if you add 2 characters to your salt you increase your search space by a factor 3844. And that's just 2 characters; this technique is scalable. Add 10 characters to your salt and you increase the time it takes to crack (brute force) by a factor of 839299365868340224. Obviously you can't make a hash function 839299365868340224 times slower because it won't be able to check your password when you log in. Finally he goes on to assume stupid stuff like this: So when you inevitably lose your SQL password table, you haven’t exposed all the passwords; just the crappy ones. Again you've got more to worry about when you lose your SQL database. It's all about risk management. You can change your password hashing from salt + MD5 to a high grade industrial strength solution. But it's wasted effort: because MD5 + a long salt is not even close to the weakest link in your system, and your total security is only as good as your weakest link. And with passwords, the weakest link is always the user; you'll have 1/2 of your password database cracked anyway by a simple dictionary attack if you lose the database. And the users will blame YOU for losing it, so don't. Regards, Sebastiaan smime.p7s Description: S/MIME Cryptographic Signature
Re: How to secure passwords?
Sebastiaan van Erk wrote: Next he goes on to state: Speed is exactly what you don’t want in a password hash function. You don’t care if password tests take twice as long, or even ten times as long, because password hashes aren’t in the 80/20 hot spot. Now the attacker. This is easy. The attacker cares a lot if password tests take twice as long. If one password test takes twice as long, the total password cracking time takes twice as long. But if you add 2 characters to your salt you increase your search space by a factor 3844. And that's just 2 characters; this technique is scalable. Add 10 characters to your salt and you increase the time it takes to crack (brute force) by a factor of 839299365868340224. Obviously you can't make a hash function 839299365868340224 times slower because it won't be able to check your password when you log in. Oops, bit trigger happy on that one. ;-) Of course slowing down your hash function DOES help against dictionary attacks and brute force on the password itself (instead of on the hash). However, even if you slow it down to 1 second per hash a cracker will easily be able to do dictionary attacks with his botnet, so it does not adequately protect weak passwords anyway. And 1 second per hash is quite expensive for a high volume site. So I still think you're better of make sure you don't lose your password database instead of making the login slow. Regards, Sebastiaan smime.p7s Description: S/MIME Cryptographic Signature
Re: How to secure passwords?
On Tue, Dec 04, 2007 at 09:36:21AM +0100, Sebastiaan van Erk wrote: John Krasnay wrote: I see from your later posts that your requirements are not that strict, but if anyone else on the list needs to do password hashing, here's one of the best articles I've seen on it: http://www.matasano.com/log/958/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes/ jk This article is a total rant with lots of stupid inaccurate information. I disagree. The author's tone is a little condescending, but IMHO his advice is bang on. For example: 1. take a “dictionary” —- say, of all combinations of alphanumerics less than 15 characters 2. hash all of them 3. burn the results onto a DVD. The keyspace is size is 62^15-1 = 76890970494878552634367. That means if you can save a hash in 1 byte you still need about 143220593211942663 DVD's. Yeah, but that really doesn't really take away from his argument. Again you've got more to worry about when you lose your SQL database. It's all about risk management. You can change your password hashing from salt + MD5 to a high grade industrial strength solution. But it's wasted effort: because MD5 + a long salt is not even close to the weakest link in your system, and your total security is only as good as your weakest link. First, no one in this thread has even mentioned salts, yet a password hashing scheme without them would be completely inadequate. Further, the author correctly points out that a randomly-generated salt, stored with the password hash, is far more secure than a secret constant salt. Second, the high grade industrial strength solution the author suggests is salt+BCrypt instead of salt+MD5. Sure, it's a little more effort to download jBCrypt (http://www.mindrot.org/projects/jBCrypt/) than to use MD5, but not that much. And with passwords, the weakest link is always the user; you'll have 1/2 of your password database cracked anyway by a simple dictionary attack if you lose the database. The whole point of using random salts + slow hashing is to make even simple passwords hard to crack when your DB is stolen. And the users will blame YOU for losing it, so don't. Hey, there's some good security advice. Don't worry about your password hashing scheme, just don't let anyone steal your database. Ask the guys at Reddit how that worked out (http://blog.moertel.com/articles/2006/12/15/never-store-passwords-in-a-database). jk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to secure passwords?
John Krasnay wrote: For example: 1. take a “dictionary” —- say, of all combinations of alphanumerics less than 15 characters 2. hash all of them 3. burn the results onto a DVD. The keyspace is size is 62^15-1 = 76890970494878552634367. That means if you can save a hash in 1 byte you still need about 143220593211942663 DVD's. Yeah, but that really doesn't really take away from his argument. I think it does. Makes me wonder if he knows what he's talking about for one. He suggests you do something which is impossible, and with a condescending tone at that. First, no one in this thread has even mentioned salts, yet a password hashing scheme without them would be completely inadequate. Further, the author correctly points out that a randomly-generated salt, stored with the password hash, is far more secure than a secret constant salt. I certainly mentioned salts. :-) And a secret salt is not a salt, a salt by definition has to be random. Second, the high grade industrial strength solution the author suggests is salt+BCrypt instead of salt+MD5. Sure, it's a little more effort to download jBCrypt (http://www.mindrot.org/projects/jBCrypt/) than to use MD5, but not that much. The whole point of using random salts + slow hashing is to make even simple passwords hard to crack when your DB is stolen. I certainly don't disagree with you (or the author) that using BCrypt is better that MD5. But it won't protect your weak passwords. Sure, it'll take a little more effort; but the protection will not be enough. I've seen dictionary attacks on actual password databases with a relatively small dictionary succeed on 50% of the passwords. With botnets or other distribution methods, testing an entire dictionary (plus simple variations) will always be feasible. And the users will blame YOU for losing it, so don't. Hey, there's some good security advice. Don't worry about your password hashing scheme, just don't let anyone steal your database. Ask the guys at Reddit how that worked out (http://blog.moertel.com/articles/2006/12/15/never-store-passwords-in-a-database). I'm not saying NOT to use a password hashing scheme. But I think in the reddit case blaming it on the absence of password hashing is just finding a scapegoat; they had some MUCH MORE SERIOUS security failures when they let their database get stolen. Security failures you are NOT going to fix by introducing password hashing. For example, some elementary questions: 1) what was their security policy that allowed somebody who is unauthorized to access the backup database? 2) if the backup contained confidential information, why was it not encrypted? My original point was that MD5 hash plus salt is adequate in most use cases; and I still stand by that. If you're developing a high profile site, then I STRONGLY suggest you hire a security expert to audit your entire site: security policy, operating procedures, and systems. Regards, Sebastiaan smime.p7s Description: S/MIME Cryptographic Signature
How to secure passwords?
Hello, I've a little question with wicket: I would like to hash my users' passwords (with md5) to make them unreadable for a human. And I also would like to hash them before sending them through the network (to avoid the biggest part of security issues). Is there a way to achieve this? Thank you ;) -- View this message in context: http://www.nabble.com/How-to-secure-passwords--tf4936916.html#a14131090 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to secure passwords?
This is nothing about wicket - its about base security. MD5 is a hash-algorithm (see: http://en.wikipedia.org/wiki/Md5) which is no more secure (flaw found 1996) as there are tables to reverse given md5 (from 2003 on) to a valid input if you need security youre best with SHA at the moment, that has a greater length than the 128 Bit of MD5 and therefore more non-collision space - have a look here: http://en.wikipedia.org/wiki/SHA_hash_functions the implementation is available in java itself have a look at these examples here: http://mindprod.com/jgloss/sha1.html http://o9y.net/archives/2005/11/30/java-string-to-md5-hash/ Best, Korbinian Pills schrieb: Hello, I've a little question with wicket: I would like to hash my users' passwords (with md5) to make them unreadable for a human. And I also would like to hash them before sending them through the network (to avoid the biggest part of security issues). Is there a way to achieve this? Thank you ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to secure passwords?
Pills, I don't really thing this has anything to do w/ Wicket... Do a Google search for java password hash. A quick search found this: http://www.devarticles.com/c/a/Java/Password-Encryption-Rationale-and-Java-Example/ J On Dec 3, 2007 9:40 AM, Pills [EMAIL PROTECTED] wrote: Hello, I've a little question with wicket: I would like to hash my users' passwords (with md5) to make them unreadable for a human. And I also would like to hash them before sending them through the network (to avoid the biggest part of security issues). Is there a way to achieve this? Thank you ;) -- View this message in context: http://www.nabble.com/How-to-secure-passwords--tf4936916.html#a14131090 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to secure passwords?
Korbinian Bachl wrote: This is nothing about wicket - its about base security. MD5 is a hash-algorithm (see: http://en.wikipedia.org/wiki/Md5) which is no more secure (flaw found 1996) as there are tables to reverse given md5 (from 2003 on) to a valid input thank you for your answers. I know that MD5 isn't much secure, but it doesn't matter (I just want to obfuscate them, to prevent an admin to get a clear password from his admin console). But I agree, SHA may be better... I guessed there was a wicket way to 1) crypt some data before sending them out of the client's browser (so it doesn't travel in clear) 2) compare it on the server side with the required hashed password. I know how to write the crypto algorithm... I just don't know the best way to integrate it into wicket. However, I saw some interface on Wicket (like ICrypt) and guessed there is a way to use it well... Thank you for your interest ;) -- View this message in context: http://www.nabble.com/How-to-secure-passwords--tf4936916.html#a14132134 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to secure passwords?
Pills schrieb: Korbinian Bachl wrote: This is nothing about wicket - its about base security. MD5 is a hash-algorithm (see: http://en.wikipedia.org/wiki/Md5) which is no more secure (flaw found 1996) as there are tables to reverse given md5 (from 2003 on) to a valid input thank you for your answers. I know that MD5 isn't much secure, but it doesn't matter (I just want to obfuscate them, to prevent an admin to get a clear password from his admin console). But I agree, SHA may be better... to get a wanted md5 collision requires a person that uses a rainbow table under 1h time by a successrate at about 99,9% - http://www.antsight.com/zsl/rainbowcrack/ I guessed there was a wicket way to 1) crypt some data before sending them out of the client's browser (so it doesn't travel in clear) 2) compare it on the server side with the required hashed password. you want to use SSL (TLS now called) for this! - go to a banklogin and you see changing the http://www.mybank.com to https://www.mybank.com see http://en.wikipedia.org/wiki/Transport_Layer_Security for a overview I know how to write the crypto algorithm... I just don't know the best way to integrate it into wicket. However, I saw some interface on Wicket (like ICrypt) and guessed there is a way to use it well... 1. there are under 100 people on this planet that know how to write a secure crapto algorithm - and believe me that we two arent anywhere near them :) 2. AFAIK the ICrypt is good for obscuring the URL itself - not for the content (but im not sure on this) Thank you for your interest ;) youre welcome, Korbinian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to secure passwords?
Korbinian Bachl wrote: However, they *CAN NOT* generate a collision for an arbitrary hash. Furthermore, doing this in a limited size string (like a password) adds another complication. they can and did ! - if you have a hashvalue e.g: 79054025255fb1a26e4bc422aef54eb4 you can use various reverse tables to get the needed inputString into any md5(inputString) function to get the desired hash - example look here: http://www.antsight.com/zsl/rainbowcrack/ They're using precomputed tables to speed up finding a hash from a *known* plaintext space. For example, the 36GB md5 table allows you to find which string of 1-8 characters from the lowercase alphanum charset was used to generate a specific has. To be specific, if I provided the hash: 4a251a2ef9bbf4ccc35f97aba2c9cbda rainbow crack would find the key: test123. However, if I provided the hash: 36a03a8a4c00e81f03d62d8b04bbbf4d rainbow crack would *NOT* find the key: Test123, since it contains a character not in their character set. Furthermore, it would find no key at all if it so happens (which is overwhelmingly probably the case) that there exists no 1-8 string lowercase alphanum string which has this hash. with classic rainbow tables or hybrid rainbow tables you get a 99,9% chance to score a hit for under 1h time... sounds not very secure to me Only for specific plaintexts, after precomputing the tables. Nope, MD5 password hashes are still perfectly fine. sure? Yes, secure enough. In practical use, passwords are rather weak, and there are many easy attack points (social engineering, reading passwords from an unprotected password vault of the browser, dictionary attacks, etc.). Hashing the password is (in general) used to hide the plaintext from view (in a DB for example). Furthermore, anybody can gain access to an account if they have write access to the DB by simply putting in their own hash. Hashing the password client side is actually UNSAFE. This means the hash goes over the network, and somebody else can just send the same hash to the server to log in without ever knowing the user's password. and its more save if the md5 sits in the RDBMS that may be breached? Yes again. If your RDBMS is breached you've got far more serious issues. Futhermore, somebody sniffing a hash going of the network (especially LAN) is *EASY*. If you have a secure setup with your RDBS, it's on a safe network, behind a DMZ, and not accessible from the internet directly. Apart from other confidential data that will be leaked (e.g. credit card numbers, or whatever), I think hashed MD5 passwords are the least of your problems. But I agree with one thing: since it's free in Java to use SHA instead of MD5 (all you have to do is change 1 little string), you may as well use SHA. Regards, Sebastiaan smime.p7s Description: S/MIME Cryptographic Signature
Re: How to secure passwords?
You are correct, I'm assuming his admin has knowledge of the salt, if there even was one... On Dec 3, 2007 1:33 PM, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Jeremy Levy wrote: Don't use MD5: http://md5.rednoize.com/ 328b78157026ea76f87d3f2d7111dfb1 j I REALLY don't get your point. So you can do a dictionary attack on MD5 hashes or brute force on short plaintexts if you don't use a salt. Weeha. So what else is new? This has ABSOLUTELY NOTHING to do with MD5. This works with SHA1, and ANY other hash. That's why you use salts. When you store a hashed password in the database you generally do something like this. Take a random generated alphanumeric string of 10 chars: GXSYvmzz0y Then take the plaintext password, i.e., test123 and append it to the salt: GXSYvmzz0y$test123 Now make an MD5 hash: ca62c4bd0a5094d9198112a6ce6ab4f4 Now prepend the salt to the hash, and store this in the database. In other words, store this: GXSYvmzz0y$ca62c4bd0a5094d9198112a6ce6ab4f4 in the database. To verify the password for a user, split the stored value, use the salt to compute the required hash, and compare. Good luck cracking that. Your site is not going to help, and neither will rainbow crack. Regards, Sebastiaan On Dec 3, 2007 12:17 PM, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Korbinian Bachl wrote: However, they *CAN NOT* generate a collision for an arbitrary hash. Furthermore, doing this in a limited size string (like a password) adds another complication. they can and did ! - if you have a hashvalue e.g: 79054025255fb1a26e4bc422aef54eb4 you can use various reverse tables to get the needed inputString into any md5(inputString) function to get the desired hash - example look here: http://www.antsight.com/zsl/rainbowcrack/ They're using precomputed tables to speed up finding a hash from a *known* plaintext space. For example, the 36GB md5 table allows you to find which string of 1-8 characters from the lowercase alphanum charset was used to generate a specific has. To be specific, if I provided the hash: 4a251a2ef9bbf4ccc35f97aba2c9cbda rainbow crack would find the key: test123. However, if I provided the hash: 36a03a8a4c00e81f03d62d8b04bbbf4d rainbow crack would *NOT* find the key: Test123, since it contains a character not in their character set. Furthermore, it would find no key at all if it so happens (which is overwhelmingly probably the case) that there exists no 1-8 string lowercase alphanum string which has this hash. with classic rainbow tables or hybrid rainbow tables you get a 99,9% chance to score a hit for under 1h time... sounds not very secure to me Only for specific plaintexts, after precomputing the tables. Nope, MD5 password hashes are still perfectly fine. sure? Yes, secure enough. In practical use, passwords are rather weak, and there are many easy attack points (social engineering, reading passwords from an unprotected password vault of the browser, dictionary attacks, etc.). Hashing the password is (in general) used to hide the plaintext from view (in a DB for example). Furthermore, anybody can gain access to an account if they have write access to the DB by simply putting in their own hash. Hashing the password client side is actually UNSAFE. This means the hash goes over the network, and somebody else can just send the same hash to the server to log in without ever knowing the user's password. and its more save if the md5 sits in the RDBMS that may be breached? Yes again. If your RDBMS is breached you've got far more serious issues. Futhermore, somebody sniffing a hash going of the network (especially LAN) is *EASY*. If you have a secure setup with your RDBS, it's on a safe network, behind a DMZ, and not accessible from the internet directly. Apart from other confidential data that will be leaked (e.g. credit card numbers, or whatever), I think hashed MD5 passwords are the least of your problems. But I agree with one thing: since it's free in Java to use SHA instead of MD5 (all you have to do is change 1 little string), you may as well use SHA. Regards, Sebastiaan
Re: How to secure passwords?
Jeremy Levy wrote: You are correct, I'm assuming his admin has knowledge of the salt, if there even was one... Of course the admin will know the salt, but that does not help him reverse the MD5 hash, nor will the hash be found on the md5.rednoize.com site. So the only options left are brute force and dictionary attacks. And these are always possible and have nothing to with MD5. So what you actually meant instead of Don't use MD5 is Don't use weak passwords. Of course it's up to the users to use strong passwords. And unfortunately most of them don't... or they do and then stick them on their monitor. ;-) And since all of this has nothing to do with Wicket (other than the fact that many Wicket apps probably have user accounts with passwords in a database), I'm going to leave it at this. :-) Regards, Sebastiaan On Dec 3, 2007 1:33 PM, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Jeremy Levy wrote: Don't use MD5: http://md5.rednoize.com/ 328b78157026ea76f87d3f2d7111dfb1 j I REALLY don't get your point. So you can do a dictionary attack on MD5 hashes or brute force on short plaintexts if you don't use a salt. Weeha. So what else is new? This has ABSOLUTELY NOTHING to do with MD5. This works with SHA1, and ANY other hash. That's why you use salts. When you store a hashed password in the database you generally do something like this. Take a random generated alphanumeric string of 10 chars: GXSYvmzz0y Then take the plaintext password, i.e., test123 and append it to the salt: GXSYvmzz0y$test123 Now make an MD5 hash: ca62c4bd0a5094d9198112a6ce6ab4f4 Now prepend the salt to the hash, and store this in the database. In other words, store this: GXSYvmzz0y$ca62c4bd0a5094d9198112a6ce6ab4f4 in the database. To verify the password for a user, split the stored value, use the salt to compute the required hash, and compare. Good luck cracking that. Your site is not going to help, and neither will rainbow crack. Regards, Sebastiaan On Dec 3, 2007 12:17 PM, Sebastiaan van Erk [EMAIL PROTECTED] wrote: Korbinian Bachl wrote: However, they *CAN NOT* generate a collision for an arbitrary hash. Furthermore, doing this in a limited size string (like a password) adds another complication. they can and did ! - if you have a hashvalue e.g: 79054025255fb1a26e4bc422aef54eb4 you can use various reverse tables to get the needed inputString into any md5(inputString) function to get the desired hash - example look here: http://www.antsight.com/zsl/rainbowcrack/ They're using precomputed tables to speed up finding a hash from a *known* plaintext space. For example, the 36GB md5 table allows you to find which string of 1-8 characters from the lowercase alphanum charset was used to generate a specific has. To be specific, if I provided the hash: 4a251a2ef9bbf4ccc35f97aba2c9cbda rainbow crack would find the key: test123. However, if I provided the hash: 36a03a8a4c00e81f03d62d8b04bbbf4d rainbow crack would *NOT* find the key: Test123, since it contains a character not in their character set. Furthermore, it would find no key at all if it so happens (which is overwhelmingly probably the case) that there exists no 1-8 string lowercase alphanum string which has this hash. with classic rainbow tables or hybrid rainbow tables you get a 99,9% chance to score a hit for under 1h time... sounds not very secure to me Only for specific plaintexts, after precomputing the tables. Nope, MD5 password hashes are still perfectly fine. sure? Yes, secure enough. In practical use, passwords are rather weak, and there are many easy attack points (social engineering, reading passwords from an unprotected password vault of the browser, dictionary attacks, etc.). Hashing the password is (in general) used to hide the plaintext from view (in a DB for example). Furthermore, anybody can gain access to an account if they have write access to the DB by simply putting in their own hash. Hashing the password client side is actually UNSAFE. This means the hash goes over the network, and somebody else can just send the same hash to the server to log in without ever knowing the user's password. and its more save if the md5 sits in the RDBMS that may be breached? Yes again. If your RDBMS is breached you've got far more serious issues. Futhermore, somebody sniffing a hash going of the network (especially LAN) is *EASY*. If you have a secure setup with your RDBS, it's on a safe network, behind a DMZ, and not accessible from the internet directly. Apart from other confidential data that will be leaked (e.g. credit card numbers, or whatever), I think hashed MD5 passwords are the least of your problems. But I agree with one thing: since it's free in Java to use SHA instead of MD5 (all you have to do is change 1 little string), you may as well use SHA. Regards, Sebastiaan smime.p7s Description: S/MIME Cryptographic Signature
