March 16, 2013 at 11:07 am
Comments posted to this topic are about the item Algorithm Secrecy is not Security
March 16, 2013 at 11:35 pm
"SHA2 is recommended. Unfortunately you would have to upgrade to SQL Server 2012 in order to use this algorithm. "
You should never use hashing algorithms to store password. If sql is indeed using sha1 and sha2 then it is using weak algorithms for password storage. Hashing algorithms are designed to be quick for digesting large blocks of text. To encrypt passwords we need a SLOW algorithm so that it is difficult to try it that many times. Something like twofish or blowfish encrypting the password with itself (for one way).
March 17, 2013 at 1:28 pm
umailedit (3/16/2013)
"SHA2 is recommended. Unfortunately you would have to upgrade to SQL Server 2012 in order to use this algorithm. "You should never use hashing algorithms to store password. If sql is indeed using sha1 and sha2 then it is using weak algorithms for password storage. Hashing algorithms are designed to be quick for digesting large blocks of text. To encrypt passwords we need a SLOW algorithm so that it is difficult to try it that many times. Something like twofish or blowfish encrypting the password with itself (for one way).
Not sure I agree. Plenty of people recommend using one-way hashes for passwords: http://stackoverflow.com/questions/2549988/whats-the-recommended-hashing-algorithm-to-use-for-stored-passwords
March 17, 2013 at 6:53 pm
umailedit (3/16/2013)
"SHA2 is recommended. Unfortunately you would have to upgrade to SQL Server 2012 in order to use this algorithm. "You should never use hashing algorithms to store password. If sql is indeed using sha1 and sha2 then it is using weak algorithms for password storage. Hashing algorithms are designed to be quick for digesting large blocks of text. To encrypt passwords we need a SLOW algorithm so that it is difficult to try it that many times. Something like twofish or blowfish encrypting the password with itself (for one way).
Beware of conflating the core one-way algorithm with the overall algorithm. Choosing a good, solid core one-way (hash) algorithm for authentication is necessary but not sufficient. Fast vs Slow is relevant only as seen through the attacker's eyes with allowances for expected future capability increases.
SHA-1 by itself is no longer really appropriate for use, agreed, and that's essentially what SQL Server 2000 uses, and in a slight reduction in idiocy, what 2005, 2008, and 2008 R2 use. More technically, those use SHA-1(UCS-2(password with salt)), where UCS-2 is the ex-standard SQL Server still uses when it says 'Unicode' (despite it being removed from the actual Unicode standard in the late 90's). SQL Server 2012 uses SHA-512(UCS-2(password with salt)), which removes the attacks that are targetting SHA-1, but does little else of value - as umailedit correctly noted, one SHA-512 round is very fast... just like one bcrypt round, or one scrypt round, or one PBKDF2 round.
What we all should be doing is much like the graphic - pick a standard, well-known variable round algorithm like PBKDF2 (also known as RFC2898 and PKCS #5), scrypt, or bcrypt, and ideally for each password stored, also store how many rounds you used along with the salt, where the number varies. A minimum number of rounds should be selected based on possible adversary, and if your hardware can't keep up with that, buy new hardware. For PBKDF2 in particular, the recommendation long ago was to double the number of rounds every 2 years to keep up with anticipated increases in computing power, starting at 1000 rounds in 2000. Ideally, in 2013, we should be using 90,510 PBKDF2 iterations.
If it helps, WPA and WPA2 Wifi encryption uses a key generated by PBKDF2(HMAC-SHA1, passphrase, ssid, 4096, 256) (note the use of a non-random, potentially short salt, which is a serious flaw). They're using 4,096 rounds of PBKDF2 in low-end consumer devices, starting back in 2004 - almost a decade ago, now!
Note that all of this is 100% worthless in the face of users who select passwords like "password", which "complexity rules" correctly show to be a pathetically weak 8 character password, or "P@$$w0rd123", which "complexity rules" incorrectly show to be a strong 11 character password - it is, in fact, nothing of the sort when facing rules-based dictionary attacks, being simply "password" with the following rules: Proper case, 1337 speak, append 123. Alternately, users will choose, say, "Robert2010" - again, it'll pass "complexity" rules, but it's a very common password for anyone whose son Bob is turning 3 this year, or whose husband Rob is going to forget their three year anniversary this year. That's a simple proper case, append recent year rule for a dictionary attack based on common first names.
Note that in my post in http://www.sqlservercentral.com/Forums/Topic1243249-263-1.aspx#bm1243781, I've provided a stored procedure to help find passwords that some of the most common starting rules based dictionary attacks will find.
Reference: https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
March 17, 2013 at 7:52 pm
On a separate note, there is a significant desire amount the non-security development community to either write their own algorithm, or to "tweak" an existing algorithm. Both of these are very scary prospects.
The best I think we can do to educate developers is to show them what has happened in the various encryption and hashing competitions worldwide. In the U.S., at least, we can see from the AES competition,
http://csrc.nist.gov/archive/aes/round1/r1report.htm even in Round 1, of the algorithms submitted for consideration, there were at least 5 reported major attacks, of which NIST confirmed 3 (and eliminated all 5) - of interest is that these were also 5 of the slowest algorithms. There were also 5 "lesser" attacks, and all five of those algorithms were eliminated for a combination of that and other reasons. Presumably professional cryptographers submitted these... and none were good enough for consideration in Round 2. This shows that writing your own algorithm is unwise.
Note also that there are very subtle tweaks to some of the ciphers even in the Round 1 analysis, and that's common in these competitions, from changing subkey generate mode to tweaking S-box values. This shows, first and foremost, that even the slightest changes can adversely affect the security of any standard algorithm, and thus, tweaking encryption or hash algorithms is unwise.
March 18, 2013 at 2:31 am
Not sure I agree. Plenty of people recommend using one-way hashes for passwords: http://stackoverflow.com/questions/2549988/whats-the-recommended-hashing-algorithm-to-use-for-stored-passwords
One way hashing can be done using encryption algorithms instead of hashing algorithms. You can try more than a million different passwords per second with sha1 and sha2. Not so many with one way two fish encryption with a 100 rounds.
March 18, 2013 at 8:42 am
Actually I am big on this idea. But I think companies should be required to disclose not just password encryption but sensitive data as well such as SSN, Credit Cards, security questions (most people use the same questions everywhere), etc. Anything someone can use to use your accounts or gain further access to your accounts should be fully protected and public disclosure should be required so companies aren't storing plain text or they will get caught. Too many companies rely on passwords to protect user data when the database itself get's hacked and all users data is compromised becuase it is all in plain text. That is my view and I am sticking to it.
March 18, 2013 at 9:24 am
umailedit (3/18/2013)
Not sure I agree. Plenty of people recommend using one-way hashes for passwords: http://stackoverflow.com/questions/2549988/whats-the-recommended-hashing-algorithm-to-use-for-stored-passwords
One way hashing can be done using encryption algorithms instead of hashing algorithms. You can try more than a million different passwords per second with sha1 and sha2. Not so many with one way two fish encryption with a 100 rounds.
Not so many with SHA-1 or one of the SHA-2 family with 100 rounds, either. You're not arguing for encryption vs. hashing, you're arguing for enough rounds to take more time vs. not enough rounds (say, 1).
As far as recommendations for hashing,
http://csrc.nist.gov/publications/drafts/800-118/draft-sp800-118.pdf, Guide to Enterprise Password
Management (Draft) states
"Passwords should not be stored without additional security controls to protect them. Examples of such security controls include:
...
Storing one-way cryptographic hashes for passwords instead of storing the passwords themselves.
...
Federal agencies must protect passwords using FIPS-approved cryptographic algorithm implementations.
...
Many
authentication systems support the protection of passwords only with cryptographic algorithms and implementations that are either no longer FIPS-approved (e.g., DES) or were never FIPS-approved (e.g., MD4, MD5, RC2, RC4). In such situations, agencies must use compensating controls to protect the passwords using FIPS-approved cryptographic means.
"
Which indicates that for some U.S. based uses, Twofish is right out. Using SHA-1 or SHA-2 with a sufficient number of rounds (using the PBKDF2 algorithm) would thus be a reasonable choice. Other countries and industries have other standards.
March 18, 2013 at 9:27 am
Antares686 (3/18/2013)
Actually I am big on this idea. But I think companies should be required to disclose not just password encryption but sensitive data as well such as SSN, Credit Cards, security questions (most people use the same questions everywhere), etc. Anything someone can use to use your accounts or gain further access to your accounts should be fully protected and public disclosure should be required so companies aren't storing plain text or they will get caught. Too many companies rely on passwords to protect user data when the database itself get's hacked and all users data is compromised becuase it is all in plain text. That is my view and I am sticking to it.
You'd better require them to disclose the method and/or passphrase they use to generate the encryption key as well, because the strongest encryption is worthless when the key and/or passphrase is worthless.
March 19, 2013 at 7:30 am
Not so many with SHA-1 or one of the SHA-2 family with 100 rounds, either. You're not arguing for encryption vs. hashing, you're arguing for enough rounds to take more time vs. not enough rounds (say, 1).
I am arguing for one way encryption rather than hashing. Hashing functions are ridiculously fast. even with a hundred rounds you can try 10000 passwords per second as shown by the following sample php I wrote for you.
<?php
function gcrypt($ename,$emode,$text,$key,$ivtext,$crypt)
{
$encrypted_data="";
$td = mcrypt_module_open($ename, '', $emode, '');
if( $td==false ){echo "could not open crypt module ".$ename;return "";}
$ivlen = mcrypt_enc_get_iv_size($td);
$keylen = mcrypt_enc_get_key_size($td);
$iv = substr( $ivtext, 0, $ivlen );
$key = substr($key, 0, $keylen);
// echo "key=$key.$keylen.$ivlen.$iv.";
$s = mcrypt_generic_init($td, $key, $iv);
if( ($s < 0) || ($s === false))dieres( "hasher mcrypt_generic_init failed" );
if($crypt){
$edata = mcrypt_generic($td, $text);
}else {
$edata = mdecrypt_generic($td, $text);
}
mcrypt_generic_deinit($td);
mcrypt_module_close($td);
return $edata;
}
function hasher($ename,$emode,$text,$ivtext)
{
$key = strrev($text)."kjlsdflsdakjflsdkafjjsldkjflkj";
return gcrypt($ename,$emode,$text,$key,$ivtext,1);
}
function pass2key( $algo, $text, $ivtext )
{
$ivtext = mb_strtolower( $ivtext, 'UTF-8' );
$ivtext .= "lksadfkjsadfsadfhsdaklfsadlkfj";
$text = substr( $text."lsdkfjsdalkfjsdalkfjsldakfjlsdakjfjlksdafjsdkaj", 0, 64 );
for( $i=0;$i<1000;$i++ ){
$text = hasher( $algo, 'cbc', $text, $ivtext );
}
return $text;
}
function timealgo( $algo )
{
$start = microtime( true );
pass2key( $algo, "This is a test password", "username" );
echo "algo- $algo:".(microtime(true)-$start)."";
}
function pass2key2( $hash, $text )
{
$text = substr( $text."lsdkfjsdalkfjsdalkfjsldakfjlsdakjfjlksdafjsdkaj", 0, 64 );
for( $i=0;$i<1000;$i++ ){
$text = hash( $hash, $text, true );
}
return $text;
}
function timehash( $algo )
{
$start = microtime( true );
pass2key2( $algo, "This is a test password" );
echo "hash- $algo:".(microtime(true)-$start)."";
}
timealgo( 'blowfish' );
timealgo( 'twofish' );
timehash( 'sha512' );
timehash( 'sha256' );
?>
Sample times on one of my dedis:
algo- blowfish:0.75880813598633
algo- twofish:0.43758201599121
hash- sha512:0.0042619705200195
hash- sha256:0.00357985496521
As you can see blowfish or twofish or any other encryption algo is 100 times slower than any hashing algorithms for a matching number of rounds. It is ridiculous to use hashing algorithms to store passwords.
You'd better require them to disclose the method and/or passphrase they use to generate the encryption key as well, because the strongest encryption is worthless when the key and/or passphrase is worthless.
If you encrypt a password with itself with a suitable salt and the user name as iv. Then there is no need to store the encryption key for some one to hack it. The original password cant be recovered from the hash even though it is a symmetric encryption. As you can see the sample program above uses the password to encrypt itself. there is no way to go back to the password from the resulting key is there?
March 19, 2013 at 8:17 am
umailedit (3/19/2013)
Not so many with SHA-1 or one of the SHA-2 family with 100 rounds, either. You're not arguing for encryption vs. hashing, you're arguing for enough rounds to take more time vs. not enough rounds (say, 1).
I am arguing for one way encryption rather than hashing. Hashing functions are ridiculously fast. even with a hundred rounds you can try 10000 passwords per second as shown by the following sample php I wrote for you.
Then run 100,000,000 rounds; the actual number is completely irrelevant. Run as many rounds of whatever you choose as you need to in order to meet your requirements. N rounds is still at least N times slower than 1 round.
If you really want to make it take longer to crack your passwords, do as many rounds as you can on hardware as close to the optimum cracking hardware as is practical - if that's GPU's, then ideally use GPU's (or NVIDIA Tesla cards - not as fast as the fastest consumer GPU's, but warrantied for a production duty cycle, which is important - and major server manufacturers will put them under the same mission critical warranty as the rest of the server). If you need CPU's with AES-NI instructions, then make sure you're using such.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply