Password protecting a data file... how to cope with forgotten password?
guglielmo at braguglia.ch
Thu Jun 14 04:45:07 CDT 2012
about the "length" of password, this can help :
http://tech.dropbox.com/?p=165 , together with this "test" page :
On 14.06.2012 11:32, Dave Cragg wrote:
> On 14 Jun 2012, at 09:52, Igor de Oliveira Couto wrote:
>> Hi, Dave!
>> On 14/06/2012, at 5:29 PM, Dave Cragg wrote:
>>> My first thought was that applying MD5 twice or more times would perhaps increase its security, but nowhere do I see this suggested as a solution. If anyone can add any information or point out my probable misunderstanding, I'd be very grateful.
>> I'm not a security expert, but I can tell you that a very common mistake most programmers make is thinking that running the same cipher twice - or three times, or n times - would increase the security of your information. Almost always, the mathematics involved in the cipher mean that the load is no more secure than if you had just run the cipher once.
>> Think, for instance, of a common 'Caesar Cipher': you simply "shift" the characters in a text message, so that, let's say, "a" becomes "b", "b" becomes "c", and so on. You could run this cipher twice, and think that your message was twice as secure. However, for a cracker, this would simply mean that they would shift "a" directly to "c", "b" directly to "d", etc., not even knowing that you had to go through 2 steps to get there - and their cracking code might be even faster and more efficient than yours.
> Thanks, Igor. I understand your point. (The old joke about rot26 being twice as secure as rot13). But I don't think creating a one-way hash is the same as creating a cipher. 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 found a link to the source of the "no longer considered safe” story.
> 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. He also suggests obscurity in the sense that each site should implement its own algorithm. This is interesting (to me) as it seems to go against recent common wisdom. (And has got me wondering whether applying SHA1 then SHA2 then BLOWFISH is more or less obscure than applying MD5 27 times.)
> Elsewhere, I've read that the length of a password is much more significant in terms of strength than using obscure characters.
> So from now on, it should PasswordPasswordPassword. :-)
More information about the use-livecode