Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Algorithm Secrecy is not Security Expand / Collapse
Author
Message
Posted Saturday, March 16, 2013 11:07 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 11:24 AM
Points: 32,781, Visits: 14,942
Comments posted to this topic are about the item Algorithm Secrecy is not Security






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1431917
Posted Saturday, March 16, 2013 11:35 PM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Tuesday, February 04, 2014 1:58 PM
Points: 368, Visits: 215
"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).
Post #1431958
Posted Sunday, March 17, 2013 1:28 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 11:24 AM
Points: 32,781, Visits: 14,942
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







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1432018
Posted Sunday, March 17, 2013 6:53 PM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Wednesday, April 16, 2014 8:46 AM
Points: 845, Visits: 2,331
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
Post #1432056
Posted Sunday, March 17, 2013 7:52 PM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Wednesday, April 16, 2014 8:46 AM
Points: 845, Visits: 2,331
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.

Post #1432067
Posted Monday, March 18, 2013 2:31 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Tuesday, February 04, 2014 1:58 PM
Points: 368, Visits: 215
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.
Post #1432102
Posted Monday, March 18, 2013 8:42 AM
SSCrazy Eights

SSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy EightsSSCrazy Eights

Group: Moderators
Last Login: Thursday, April 17, 2014 3:54 PM
Points: 8,369, Visits: 733
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.


Post #1432211
Posted Monday, March 18, 2013 9:24 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Wednesday, April 16, 2014 8:46 AM
Points: 845, Visits: 2,331
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.
Post #1432227
Posted Monday, March 18, 2013 9:27 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Wednesday, April 16, 2014 8:46 AM
Points: 845, Visits: 2,331
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.
Post #1432229
Posted Tuesday, March 19, 2013 7:30 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Tuesday, February 04, 2014 1:58 PM
Points: 368, Visits: 215
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?
Post #1432641
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse