Password protecting a data file... how to cope with forgotten password?

[Igor de Oliveira Couto]

Hi, Dave,

Hmmm, let me see if I can expand a little on my explanation:

On 14/06/2012, at 7:32 PM, Dave Cragg wrote:

[...]

> You can't go directly from a hash to the original text like you might with a cipher once you understand the key. Hashes are cracked (I think) by using precompiled tables (rainbow tables) or by brute force (feeding text to your program until the target hash pops out). We're not trying to make the hash more secure in the cypher sense, just less likely to be in a rainbow table and more difficult to discover in a brute force attack. 

[...]

> I understood from this that "time" should be a key factor of a hashing algorithm, which is what made me think of just applying MD5 more times.

Consider the following scenario: you have stored MD5 hashes (salted or not) to your user's passwords in a database table, which you use in your login system to authenticate and authorise the user. Now, let's say that a clever hacker has managed to break into the 'users' table, and now has the list of hashes for all your users. The question is: how likely is it, that they will be able to come up with *some* string (password/passphrase) that will generate a selected hash from that table?

It is important to note that the hacker doesn't need to know what the user's original password/passphrase was - he doesn't care. The original text is irrelevant. What he needs is some text that will generate the *same* hash - this is called a 'collision'. In MD5, collisions are now considered *easy*.

If you MD5 the original password once, you end up with a 32-char hash. If you MD5 that again, you are effectively using *that 32-char hash* as your 'password'. Is it less likely that the hacker will find a collision for *that*? Unfortunately, no. You may increase the time they'll need to find the collision, but only marginally - they *will* still find it.

Using different ciphers *does* make the hacker's job more difficult, but again, not necessarily safer. The choice of cipher is the key: ciphers that generate longer hashes, or longer keys, are more secure. Ultimately, a single safer cipher will keep your data more secure than using multiple unsafe ones. Note that SHA1 has also been 'broken' - ie., it is possible to generate collisions willingly - and that is why the SHA2-family of ciphers was created. If you *really* want security that will last a while (ie., a couple of years), you should consider using a cipher that generates much longer hashes, such as SHA-256. These more complex ciphers might add a few milliseconds to the computation cycle of your program, but these will not be felt by your users, and are certainly worth the investment.

I hope this info helps!

--
Igor Couto
Sydney, Australia