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 _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
