Bitcoin Forum

Use BCrypt, Fool! (http://yorickpeterse.com/articles/use-bcrypt-fool/)

This forum stores passwords as weak hashes derived from weak salts using fast hash functions. It is amateur hour at bitcointalk.org.

Stop using MD5 or SHA. They were never designed to store passwords and protect them from offline attacks.

For example, MTGOX foolishly stores passwords as SHA512 hashes. (http://news.ycombinator.com/item?id=2676781) It should use bcrypt(). It is amateur hour at MTGOX and probably most other exchanges. The notable exception is bitcoin-central (https://bitcoin-central.net), which does use bcrypt.

Salts should be generated using proper random number generators (http://en.wikipedia.org/wiki//dev/random).

Again, Use BCrypt, Fool! (http://yorickpeterse.com/articles/use-bcrypt-fool/)

<whole lotta' bullshit>

Some real programmers, please chime in.

Totally wrong. Basically, all of your "advice" is garbage.

Some real programmers, please chime in.

That must mean you are not a real programmer also and are nothing more than a parrot that can only repeat stuff without even understand what he's saying, right?

To cut a long story short, hashing a hash N times doesn't make your passwords more secure and can actually make it less secure as a hacker can quite easily reverse the process by generating hash collisions.

[...]

It has already been mentioned before but the solution is to use an algorithm called "BCrypt". BCrypt is a hashing algorithm based on Blowfish with a small twist: it keeps up with Moore's law. The idea of BCrypt is quite simple, don't just use regular characters (and thus increasing the entropy) and make sure password X always takes the same amount of time regardless of how powerful the hardware is that's used to generate X. I'm not going to cover all the technical details but basically BCrypt requires you to specify a cost/workfactor in order to generate a password. This workfactor not only makes the entire process slower but is also used to generate the end hash. This means that if somebody were to change the workfactor the hash would also be different. In other words, hackers, you're fucked. In order for a hacker to gain the original password he must use the same workfactor and thus has to wait N times longer than when not using a workfactor.

heres an idea that might sound crazy, but what if we all used secure passwords? sure hashing as some weaknesses, but it allows for you to log in fast, and if you use a good password and a salt you should be good, as i dont think any huge company handling huge volumes of traffic would use that algorithm, simply because they do not have the required amount of processing power to keep the passwords secure and a reasonable login time.

Wrong threat model. Read this link:
http://codahale.com/how-to-safely-store-a-password/

Totally wrong. Basically, all of your "advice" is garbage.

Some real programmers, please chime in.

You should be using bcrypt().
Not whatever many rounds of hashing.

Hashing is meant for huge amounts of data (such as files) and is meant to run fast - which means it can be bruteforced fast.

By using bcrypt with a high work factor, logins take one second to process - and bruteforcing takes one second per hash as opposed to 10 billion hashes per second.

I am a programmer from 14 years, and FYI, i have written some stron cryptography myself from scratch.
So stop talking bullshit.


Wait, just let me get something straight before i continue this discussion.

If i generate a password hash using bcrypt with X rounds, and then i increase it to Y rounds, will both functions generate the same hash ?

I mean is bcrypt(pwd, rounds = 10, salt) equal to bcrypt(pwd, rounds = 20, salt) ?

Am I understanding this correctly ?

I am a programmer from 14 years, and FYI, i have written from scratch strong cryptography algorithms myself.
So please stop talking bullshit and let's have a real discussion other than "BCRYPT FTW, IF YOU DON'T THINK SO, STFU".

Wait, just let me get something straight before i continue this discussion.

If i generate a password hash using bcrypt with X rounds, and then i increase it to Y rounds, will both functions generate the same hash ?

I mean is bcrypt(pwd, rounds = 10, salt) equal to bcrypt(pwd, rounds = 20, salt) ?

Am I understanding this correctly ?

id assume no, or else it would be pointless to increase round time.

hash_algo1(salt1 + hash_algo2(salt2 + hash_algo3(salt3 + data))) 

If no is the answer, then there is completely no advantage of using bcrypt versus multi hashes with multi salt as I have already written a recurrent function which does exactly the same as bcrypt().

You simply use the_hash_function($data, salt1, salt2, salt3, rounds) and basically what it does is it recurrently repeats


for X number of rounds, each time salting everything again.

Once the hardware becomes more powerful, i can simply increase the number of rounds to Y.

If no is the answer, then there is completely no advantage of using bcrypt versus multi hashes with multi salt as I have already written a recurrent function which does exactly the same as bcrypt().

You simply use the_hash_function($data, salt1, salt2, salt3, rounds) and basically what it does is it recurrently repeats


for X number of rounds, each time salting everything again.

Once the hardware becomes more powerful, i can simply increase the number of rounds to Y.

Glorious.

Description
string crypt ( string $str [, string $salt ] )

crypt() will return a hashed string using the standard Unix DES-based algorithm or alternative algorithms that may be available on the system.

Some operating systems support more than one type of hash. In fact, sometimes the standard DES-based algorithm is replaced by an MD5-based algorithm. The hash type is triggered by the salt argument. Prior to 5.3, PHP would determine the available algorithms at install-time based on the system's crypt(). If no salt is provided, PHP will auto-generate either a standard two character (DES) salt, or a twelve character (MD5), depending on the availability of MD5 crypt(). PHP sets a constant named CRYPT_SALT_LENGTH which indicates the longest valid salt allowed by the available hashes.

The standard DES-based crypt() returns the salt as the first two characters of the output. It also only uses the first eight characters of str, so longer strings that start with the same eight characters will generate the same result (when the same salt is used).

On systems where the crypt() function supports multiple hash types, the following constants are set to 0 or 1 depending on whether the given type is available:

    CRYPT_STD_DES - Standard DES-based hash with a two character salt from the alphabet "./0-9A-Za-z". Using invalid characters in the salt will cause crypt() to fail.
    CRYPT_EXT_DES - Extended DES-based hash. The "salt" is a 9-character string consisting of an underscore followed by 4 bytes of iteration count and 4 bytes of salt. These are encoded as printable characters, 6 bits per character, least significant character first. The values 0 to 63 are encoded as "./0-9A-Za-z". Using invalid characters in the salt will cause crypt() to fail.
    CRYPT_MD5 - MD5 hashing with a twelve character salt starting with $1$
    CRYPT_BLOWFISH - Blowfish hashing with a salt as follows: "$2a$", a two digit cost parameter, "$", and 22 digits from the alphabet "./0-9A-Za-z". Using characters outside of this range in the salt will cause crypt() to return a zero-length string. The two digit cost parameter is the base-2 logarithm of the iteration count for the underlying Blowfish-based hashing algorithmeter and must be in range 04-31, values outside this range will cause crypt() to fail.
    CRYPT_SHA256 - SHA-256 hash with a sixteen character salt prefixed with $5$. If the salt string starts with 'rounds=<N>$', the numeric value of N is used to indicate how many times the hashing loop should be executed, much like the cost parameter on Blowfish. The default number of rounds is 5000, there is a minimum of 1000 and a maximum of 999,999,999. Any selection of N outside this range will be truncated to the nearest limit.
    CRYPT_SHA512 - SHA-512 hash with a sixteen character salt prefixed with $6$. If the salt string starts with 'rounds=<N>$', the numeric value of N is used to indicate how many times the hashing loop should be executed, much like the cost parameter on Blowfish. The default number of rounds is 5000, there is a minimum of 1000 and a maximum of 999,999,999. Any selection of N outside this range will be truncated to the nearest limit.

hash_algo1(salt1 + hash_algo2(salt2 + hash_algo3(salt3 + data))) * N recursive rounds

If you create a modification for SMF that uses advanced password hashing and gracefully upgrades from old hash types, I will use it.

Bcrypt is probably fine, though I tend to prefer many iterations of traditional hash algorithms. This is what hashes were designed to do. PGP does it, and it's used in many crypto standards.

define('CNF_PASSWORD_SALT1', 'fvuiyt8635t394nng'); //Change this to some random stuff
define('CNF_PASSWORD_SALT2', 'sdfkofuhnA%^%^23J'); //Change this to some random stuff

define('CNF_PASSWORD_HASH0', 'sha512');
define('CNF_PASSWORD_HASH1', 'whirlpool');
define('CNF_PASSWORD_HASH2', 'sha512');

//20 rounds by default. Change to more if more security is required
define('CNF_PASSWORD_EXTRA_ROUNDS', 20);


class HashPassword {

	protected static $level0PassHash = null;
	protected static $level1PassHash = null;
	protected static $level2PassHash = null;

	protected static $defaultHashRounds = null;

	protected static function _init(){
		self::$level0PassHash = CNF_PASSWORD_HASH0;
		self::$level1PassHash = CNF_PASSWORD_HASH1;
		self::$level2PassHash = CNF_PASSWORD_HASH2;

		self::$defaultHashRounds = CNF_PASSWORD_EXTRA_ROUNDS;
	}
	
	public static function Make($inputData, $extraSalt = false, $extraRounds = false) {
		if (!isset(self::$level0PassHash)){
			self::_init();
		}

		if ($extraRounds === false) {
			$extraRounds = self::$defaultHashRounds;
		}

		if ($extraRounds > 0) {//More rounds through recursion
			$halfStringPos = floor(strlen($inputData) / 2);
			$inputData = substr($inputData, $halfStringPos) . substr($inputData, 0, $halfStringPos); //This shifts the string on each round -  '123456' into '456123' etc.
			$inputData = self::Make($inputData, $extraSalt, $extraRounds - 1); // Recursion
		}

		$hashLevel0 = $extraSalt ? 
			hash(self::$level0PassHash, $extraSalt.$inputData.$extraSalt) : 
				hash(self::$level0PassHash, $inputData);
		
		$hashLevel1 = hash(self::$level1PassHash, CNF_PASSWORD_SALT1.$inputData.CNF_PASSWORD_SALT1);

		$output = hash(self::$level2PassHash, CNF_PASSWORD_SALT2.$hashLevel0.CNF_PASSWORD_SALT2);
		
		return $output;
	}

}

HashPassword::Make($data, [optional] $additionalLevel3Salt = null, [optional] $changeNumberOfRounds = 20);

Performance test results on my laptop:
Results are here shorten to fit php web notes ...
This was tested with 1024000 bytes (1000 KB) of random data, md4 always gets the first place, and md2 always get the last place :)

Results: (in microseconds)
   1.  md4                           5307.912
   2.  md5                           6890.058
   3.  crc32b                        7298.946
   4.  crc32                         7561.922
   5.  sha1                          8886.098
   6.  tiger128,3                    11054.992
   7.  haval192,3                    11132.955
   8.  haval224,3                    11160.135
   9.  tiger160,3                    11162.996
  10.  haval160,3                    11242.151
  11.  haval256,3                    11327.981
  12.  tiger192,3                    11630.058
  13.  haval128,3                    11880.874
  14.  tiger192,4                    14776.945
  15.  tiger128,4                    14871.12
  16.  tiger160,4                    14946.937
  17.  haval160,4                    15661.954
  18.  haval192,4                    15717.029
  19.  haval256,4                    15759.944
  20.  adler32                       15796.184
  21.  haval128,4                    15887.022
  22.  haval224,4                    16047.954
  23.  ripemd256                     16245.126
  24.  haval160,5                    17818.927
  25.  haval128,5                    17887.115
  26.  haval224,5                    18085.002
  27.  haval192,5                    18135.07
  28.  haval256,5                    18678.903
  29.  sha256                        19020.08
  30.  ripemd128                     20671.844
  31.  ripemd160                     21853.923
  32.  ripemd320                     22425.889
  33.  sha384                        45102.119
  34.  sha512                        45655.965
  35.  gost                          57237.148
  36.  whirlpool                     64682.96
  37.  snefru                        80352.783
  38.  md2                           705397.844

md2           32
md4           32
md5           32
sha1          40
sha256        64
sha384        96
sha512       128
ripemd128     32
ripemd160     40
ripemd256     64
ripemd320     80
whirlpool    128
tiger128,3    32
tiger160,3    40
tiger192,3    48
tiger128,4    32
tiger160,4    40
tiger192,4    48
snefru        64
gost          64
adler32        8
crc32          8
crc32b         8
haval128,3    32
haval160,3    40
haval192,3    48
haval224,3    56
haval256,3    64
haval128,4    32
haval160,4    40
haval192,4    48
haval224,4    56
haval256,4    64
haval128,5    32
haval160,5    40
haval192,5    48
haval224,5    56
haval256,5    64

This is what hashes were designed to do.

No. They are designed to quickly compute a mostly unique digest for a preimage.

Can you please stop talking "I'm smarter than you and I know better" bullshit and show me the difference between bcrypt() and my algo ?
Because sorry - there isn't any according to PHP manual.

EDIT2:
Investingating the matter further, actually it seems that my function far better than crypt(), as it uses different salt for each layer of hashing, where crypt() only uses single salt for all layers.

EDIT:
OK, i have had enough of this.
Only a fool uses the argument of power instead of power of arguments.

So you either show me the logical evidence that you are correct, or I will officially view you as a fool. I dare you.

Try harder. Maybe read primary references.


Cool. Now go write a paper and submit it, because you have just discovered something that dozens of security specialists over several decades couldn't. Or... maybe you missed something rather important and are letting your ego get the better of you. Sorry, but you're no Niels Provos.


Try reading and understanding what bcrypt actually does instead of assuming that you have trivially solved one of the most well-studied problems in computer security.

[SYSTEM MESSAGE]: Arrogance indicator overflowing!

is this by chance what keepass uses to make breaking your password DB more difficult?

KeePass uses SHA-256.

what is this number for exactly? it makes saving the DB slower so i assumed it did a similar thing.

The funniest thing about this discussion (besides ShadowOfHarbringer, or course, who makes me cringe with each post) is that in a forum dedicated to software which depends on hashing the shit out of SHA256 -- where people buy cheap video cards which are capable of generating literally hundreds of millions of SHA256 hashes per second on a single video card -- people still think that sha256 is a great way to slow down offline password cracking.

Pathetic. And the hits will keep on coming. More stolen password databases from poorly secured websites. More stolen emails and more stolen passwords. An endless comedy of errors and bad PR.

Also, nice ponzi scheme signature, theymos... inspires a lot of confidence in those who are first learning about bitcoin to see that a "Global Moderator" peddles a fucking ponzi scheme. I'm sure that won't reinforce the suspicions that people already have...

BTW. Keypass uses SHA256 to truncate or expand a user's password to 256 bits. It has nothing to do with adding computational cost to cracking.


Who knows? The authors apparently don't go out of their way to make it clear, but then again, I don't use keepass... smells a bit too much like snakeoil (http://www.schneier.com/crypto-gram-9902.html#snakeoil).

yet you trust the very keys that have claim over your coins

and what else would you recommend to store passwords in? lastpass?

The funniest thing about this discussion (besides ShadowOfHarbringer, or course, who makes me cringe with each post (https://bitcointalk.org/index.php?topic=16457.msg222943#msg222943))

Who knows? The authors apparently don't go out of their way to make it clear, but then again, I don't use keepass... smells a bit too much like snakeoil (http://www.schneier.com/crypto-gram-9902.html#snakeoil).

The funniest thing about this discussion (besides ShadowOfHarbringer, or course, who makes me cringe with each post (https://bitcointalk.org/index.php?topic=16457.msg222943#msg222943))

Look at how easy this is:

$hashedPassword = HashPassword::Make($password, 'LEVEL3 SALT', 2048); //Total of 6144 rounds

Oh god, I seriously wanted to reply a big fat "WTF?!" to that post. Biggest crock of bullshit I'd ever read. Why the fuck install an entire virtualized operating system inside a multi-encrypted disk image... that shit doesn't even make any sense; just use the same outer encryption library to create another disk image inside the first layer, which itself is, despite the encryption layer residing on the outside, still encrypting data within a subsequent layer in the same way. Shit just makes me cringe thinking the guy wanted to install multiple OS copies inside multiple layers to produce an illusion of security... it's still protected by a f***ing password. /headdesk

This has nothing to do with the current topic.

I am not listening to you, until you explain what is the difference between bcrypt() and my func. Because i keep stating you have no fuckin idea what you are talking about.

I dare you. Explain that to me. Still waiting.

Also, about earlier post:

Look how easy this is:

This will provide stronger hashing than bcrypt() with 12 rounds , as each round in bcrypt() is actually a power of 2 rounds (bcrypt(data, 12) gives you actually total 4096 small rounds if I am not mistaken) .

The Skein Hash Function Family
Fast, Secure, Simple, Flexible, Efficient. And it rhymes with "rain."

[...]

Skein is fast. Skein-512—our primary proposal—hashes data at 6.1 clock cycles per byte on a 64-bit CPU. This means that on a 3.1 GHz x64 Core 2 Duo CPU, Skein hashes data at 500 MBytes/second per core—almost twice as fast as SHA-512 and three times faster than SHA-256. An optional hash-tree mode speeds up parallelizable implementations even more. Skein is fast for short messages, too; Skein-512 hashes short messages in about 1000 clock cycles.

The "strength" of the hashing is irrelevant (even an 80-bit hash function - used properly - cannot be bruteforced by the current bitcoin network in any reasonable time). The only thing that matters is how long it takes to try one key for an attacker. bcrypt and whatever iterated hashing you're using achieve this in a very different way, and it is hard to compare.

It is true by the way that iterated hashing increases the chances for collisions, but only slightly. As explained in an earlier linked post, NIST recommends PBKDF2 for storing passwords, which is in fact based on salted iterated hashing.

So please stop throwing insults to eachother. Yes, bcrypt() is a very good way for storing passwords, but so it a (well implemented) iterated hashing scheme. Iterated hashing schemes are better researched and used, but bcrypt() is somewhat slower to implement in hardware. If you really want maximal resistance to hardware-assisted attacks, scrypt() may be an even better choice, yet even more recent.

The reasons why eksblowfish is several orders of magnitude harder (http://news.ycombinator.org/item?id=1091445) to bruteforce that other algos (like SHA, or N interations of hash-x) have little to do with iterations.

Provos and Mazières took advantage of this, and actually took it further. They developed a new key setup algorithm for Blowfish, dubbing the resulting cipher "Eksblowfish" ("expensive key schedule Blowfish"). The key setup begins with a modified form of the standard Blowfish key setup, in which both the salt and password are used to set all subkeys. Then there are a number of rounds in which the standard Blowfish keying algorithm is applied, using alternately the salt and the password as the key, each round starting with the subkey state from the previous round. This is not cryptographically significantly stronger than the standard Blowfish key schedule, but the number of rekeying rounds is configurable; the hashing process can therefore be made arbitrarily slow, which helps deter brute-force attacks upon the hash or salt.

The references explain why eksblowfish is so good at being slow. But go ahead... keep "daring" me to explain (the references that I posted in this thread do an ample job, for those who are interested). I will admit that your taunts amuse me, however.

The post of yours that I linked is salient because it demonstrates your level of understanding of security issues (https://bitcointalk.org/index.php?topic=16457.msg222943#msg222943). You seem to think that just by nesting questionable mechanisms N times, that you have achieved some sort of a secure cascade effect

It's not my job to hand-feed you.

Bcrypt is the best tool to protect password databases against offline attacks.