A public service announcement

[gene]

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. It should use bcrypt(). It is amateur hour at MTGOX and probably most other exchanges. The notable exception is bitcoin-central, which does use bcrypt.

Salts should be generated using proper random number generators.

Again, Use BCrypt, Fool!

[ShadowOfHarbringer]

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. It should use bcrypt(). It is amateur hour at MTGOX and probably most other exchanges. The notable exception is bitcoin-central, which does use bcrypt.

Salts should be generated using proper random number generators.

Again, Use BCrypt, Fool!

Actually, you don't need to use bcrypt.
You can have exactly the same effect using multiple layered hashing algorithms with specified number of rounds.
You only need to increase the number of rounds once hardware gets more powerful - it will have exactly the same effect as bcrypt.

Also, i trust multiple salted hashing algorithms more than a single algorithm (blowfish), which is used in bcrypt.

[gene]

<whole lotta' bullshit>

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

Some real programmers, please chime in.

[Raoul Duke]

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?

[captainteemo]

<whole lotta' bullshit>

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.

[gene]

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?

I won't presume to call myself and expert in web programming, but I have experience in certain fields going back more than 10 years. At the very least, I do know how to protect a local password database.

For those who refuse to read linked texts (lazy TL;DR crowd), let me quote a portion of it:

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.

It might be useful to avoid problems which have long ago been solved. Simple things like using proper functions and understanding programming interfaces makes life much easier and keeps us from embarassing situations like MTGOX and others repeatedly keep finding themselves in.

[ctoon6]

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.

[gene]

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/

[ctoon6]

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/

the link contains no information i didnt already know, again, a 64cha hexadecimal password will take a really long time according to https://www.grc.com/haystack.htm . assuming the hashing algorithm isnt found to be insecure or something. hell, acording to grc, "thecowsaysmoo" would take months to crack, id consider that relatively safe, sure over time it becomes more insecure, but it does not have all the drawbacks of bcrypt. its probably fine for personal use, but once you get thousands of people logging on at the same time, that's a thousand seconds worth of computing time you need.

[ShadowOfHarbringer]

<whole lotta' bullshit>

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

Some real programmers, please chime in.

I have been a programmer for 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".

<whole lotta' bullshit>

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.

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 ?

[ctoon6]

<whole lotta' bullshit>

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

Some real programmers, please chime in.

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

<whole lotta' bullshit>

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.

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.

[gene]

<whole lotta' bullshit>

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

Some real programmers, please chime in.

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

Scary... but doubtful.

<whole lotta' bullshit>

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.

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 ?

No. Try reading the links. Also, bcrypt doesn't use "rounds" as a means to be slow. It has a slow key schedule.

[ShadowOfHarbringer]

<whole lotta' bullshit>

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

Some real programmers, please chime in.

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

<whole lotta' bullshit>

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.

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.

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

Code:

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

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.

[ctoon6]

<whole lotta' bullshit>

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

Some real programmers, please chime in.

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

<whole lotta' bullshit>

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.

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.

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

Code:

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

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.

he said it uses a slow key schedule, so i dont think this is the same thing if you are using traditional hashing.

[gene]

<whole lotta' bullshit>

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

Some real programmers, please chime in.

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

<whole lotta' bullshit>

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.

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.

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

Code:

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

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. Way to miss the point of this fundamental concept.

[ctoon6]

i still think bcrypt is stupid because i refuse to change my ways, you will never change me, you communist.


yes its a joke.

[ShadowOfHarbringer]

Glorious.

I am not finished.
I can also increase the entropy by using extra secret field from the database PLUS the user's registration date which is also needed to generate the final hash.

So the entropy is not low (like in the examples shown here) anywhere within the hashing process.

[ShadowOfHarbringer]

I studied the topic a little more:

Here is the description of the crypt() function from PHP manual, which was specified in the article "Use Bcrypt Fool":

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.

Then basically, what crypt() function does, is multiple salted rounds of hashing.

So can somebody explain to me what is the difference between bcrypt and my algorithm ?

Code:

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

Because, seriously - I cannot find one.

[theymos]

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.

[ShadowOfHarbringer]

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.

I can supply the hashing algorithm, as I have already written it.
Give me half an hour, i need to start up the laptop and find it.