A public service announcement

[ShadowOfHarbringer]

Here ya go:

Code:

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;
	}

}

3 layered hashing, different salt on each layer. Level 3 salting is optional.

There are 3 smaller rounds in a single big round, so a total of 20 rounds (default) gives you 60 salted hashing rounds in total for a single password. Benchmark your scripts and change the number of rounds depending of the power of your servers. Too many rounds can clog up the server as users logging in massively will use a lot of CPU.

20 big rounds should be enough for everyone for starters.

Usage:

Code:

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

If you want some serious security, put (for example) user's registration date (or anything else generated randomly on registration) into the $additionalLevel3Salt parameter. It will make rainbow tables attack unfeasible.

This is a production - grade code. It should work without any modifications.


License:
WTFPL License, http://en.wikipedia.org/wiki/WTFPL



---------------------
EDIT:
Also, there is a useful list of different hashing algorithms' speed on php.net

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

Plus the lengths of hashes produced by each of the algos:

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

Have fun.

[gene]

This is what hashes were designed to do.

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

[ShadowOfHarbringer]

This is what hashes were designed to do.

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

[image]

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.

[gene]

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.

Try harder. Maybe read primary references.

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.

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.

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 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.

[Alex Zee]

[SYSTEM MESSAGE]: Arrogance indicator overflowing!

[ShadowOfHarbringer]

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.

Try harder. Maybe read primary references.

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.

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.

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 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.

OK.... so here you go.
You have no arguments whatsoever and you are simply saying "hey, I am right because the guy in the article said so". You also have completely no idea how the bcrypt() itself works, as you cannot explain the differences between it and my algorithm in detail.

I am sorry, but you are no cryptography specialist or even an experienced programmer. I find it a waste of time to continue discussing with trolls.

EOT.

[FalconFour]

[SYSTEM MESSAGE]: Arrogance indicator overflowing!

This.

Children, can we stop fighting?

I just did a quick search for bcrypt and saw how pointlessly irrelevant it is:
http://duckduckgo.com/?q=bcrypt
It's a file hashing algorithm FFS. First demonstrated on a Pentium-II, I'm sure, to much fanfare after it took a full second to crunch out. In 1999.

(and to think, prior to scrolling up and reading Shadow's full-blown WTFPL-licensed smack-code, followed by gene's totally worthless off-topic reply, I was almost siding with gene here - then I searched it.)

Here's what we need: an algorithm that's designed for passwords, not files. Run an MD5 through a SHA-1 and a Blowfish and a fuck-why-not-throw-the-rest-in-there-too set of hashes, then store THAT fucking hash in the database. Someone types in a password, run it through the same gauntlet of hashes, compare the result. Match? Good, sexy, let 'em in. Mash two together in a run or something. Obscurity? You bet your fucking ass, but without reading the source code, you'd have no idea how to break the values apart to reverse them, it'd be impossible.

Or just find an API to KeePass or some shit, store everything in there. I dunno, it's probably been done.
(and I can guarantee nobody will have a gripey bitch about how secure KeePass is.)

Or here's a better idea: don't let your fucking forum SQL database get compromised in the first place.

[Pieter Wuille]

Bcrypt means two things: a hashing algorithm and a file encryption utility, both of which are based on the blowfish algorithm.

To encrypt passwords and want to prevent a stolen database from being hacked easily, you need a slowdown. If checking one password for correctness takes N times longer, it takes N times longer to crack as well. The intent is to make a single check as slow as you can bear.

Schemes like iterated sha512 or pbkdf2 achieve this slowdown by hashing multiple times, bcrypt achieves it through a slow key scheduling step.

Given that no preimage attack against the used hash function (sha1 on this forum and in pbkdf2, sha512 on mtgox) exist, I'd say they are equally safe if their verification step takes the same time. There exist attacks against sha1, but only collision attacks (which won't help you here) and theoretical preimage attacks (which don't really help much)

The main advantage of bcrypt is that is slower to implement on hardware, but not so much anymore on modern hardware. A more recent password hashing system called scrypt was designed to overcome this, but is not very much used. Given that the bitcoin community has massive amounts of computation hardware, that may be the best choice.

Sources:

• http://stackoverflow.com/questions/2772014/is-sha-1-secure-for-password-storage
• http://security.stackexchange.com/questions/4781/do-any-security-experts-recommend-bcrypt-for-password-storage/6415#6415

[gene]

I'm not the one claiming to have written a superior technique here. The burden of proof rests with the person making claims about his superior his method is compared to established methods. Also, the functions are already written in basically every language that matters.


Look at how easy this is:

Code:

$hash = bcrypt_hash({
                        key_nul => 1,
                        cost => 8,
                        salt => $salt,
                }, $password);

Done. That particular problem is now solved, and you can go on to other issues.

No need for algorithms of dubious efficacy written by anonymous authors.

Also, don't take my word for it:
https://bitcointalk.org/index.php?topic=17004.msg228724#msg228724

Bcrypt effectively eliminates offline attacks. Iterative hashing does not. Again, I'm not the one who proved that. This has been well understood for many years. Time to use the right tools.

Also worth noting explicitly, as this has come up: the question of obtaining the database is of course important, but it is a separate issue.

[ShadowOfHarbringer]

@gene

When you are done trolling and making a fool of yourself and you actually **understand** what bcrypt() does, then we can talk.
For now, I find discussion with you a complete waste of time.

[ctoon6]

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

[theymos]

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

KeePass uses SHA-256.

[ctoon6]

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.

[gene]

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 "Administrator/Hero Member" peddles a fucking ponzi scheme. I'm sure that won't reinforce the suspicions that people already have... What happened to your previous ponzi scheme website? Wasn't there some security problem there too?

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.

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

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.

[ctoon6]

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.

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

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.

yet you trust the very keys that have claim over your coins, and what else would you recommend to store passwords in? lastpass?, don't get me started.

[gene]

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

Wrong. I trust that I can keep my private key secure. You're conflating separate issues.

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

GnuPG.

[FalconFour]

The funniest thing about this discussion (besides ShadowOfHarbringer, or course, who makes me cringe with each post)

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

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

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.

KeePass user here. Works damn fucking well IMO. Here's how the key transformation thing works, to my understanding:
your master composite key (whatever method you use to authenticate - a password, a file, etc) -> key to encrypt data stored in each data row of login data <-><-> buttfuck using some encryption algorithm -> repeat 100,000+ times to generate completely incomprehensible data.
That happens whenever the DB is changed and saved. And when it's opened, it goes through the reverse mechanism: take a row, un-buttfuck it 100,000 times, and see if it's valid data. If not, bad composite key, try again. If so, buzzah, there's your key. Except that there's no way to break down any one of those 99,999 intermediate steps to see if you got it right without going through each one of the 100,000 iterations for every attempt. So let's amplify your brute-force method by 100,000 times and see how long it takes to crack the fuckin' database, shall we?

I'd say it's pretty effective.
(that's also why it takes about 20 seconds for my phone to load the database (a 55KB database from SD) that takes only about 1 second for my computer to load. 600MHz processor sucks ass.)

[trentzb]

I've been watching http://en.wikipedia.org/wiki/NIST_hash_function_competition and particularly Skein. Seems interesting.

[ShadowOfHarbringer]

The funniest thing about this discussion (besides ShadowOfHarbringer, or course, who makes me cringe with each post)

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. You are deliberately making offtopic to mask your total lack of knowledge, but this trick does not work with me.

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

Also, about earlier post:

Look at how easy this is:

Code:

$hash = bcrypt_hash({
                        key_nul => 1,
                        cost => 8,
                        salt => $salt,
                }, $password);

Look how easy this is:

Code:

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

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) .

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 is just one bad idea, **which I admitted is not the best sollution** in the same topic. But still gives you higher level of security than no virtual machine at all (the attacker has to crack all the layers, which will take time. Also, he has to figure out that there is VM within VM, which he may accidentally not do).

But what is important, this has completely nothing to do with the current discussion.

[Pieter Wuille]

The funniest thing about this discussion (besides ShadowOfHarbringer, or course, who makes me cringe with each post)

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 at how easy this is:

Code:

$hash = bcrypt_hash({
                        key_nul => 1,
                        cost => 8,
                        salt => $salt,
                }, $password);

Look how easy this is:

Code:

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

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 "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.