SHA1 cracked .... What are the chances this will be addressed in LC?

[Bob Sneidar]

NVM I think I see. I hash the user's password entry and compare the value to what is stored. But if the stored hash is an asymmetric one and cannot be decrypted, what is all the fuss about? Rainbow tables are all that is left, and you cannot create rainbow tables for every possible methodology. 

I'm wondering if this is much ado about nothing? No matter how a password is stored, it can always theoretically be compromised once someone gains access to the storage system. I get that having a different seed for each password makes it more difficult to be able to decrypt a captured hash in transit, but passwords MUST be stored somewhere, and if so, then encrypted, and if so, then never completely safely. 

Bob S


> On Mar 7, 2017, at 07:28 , Bob Sneidar via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
>> Hi Bob,
>> 
>> The "encrypt" command provides symmetric cryptographic functions, i.e.
>> you can decrypt the result again to get the cleartext back.  This is _not_ a desirable property for a password storage system; you should always use one-way (asymmetric) functions, such as a cryptographic hash.
>> 
>>                                     Peter
>> 
>> -- 
>> Dr Peter Brett <peter.brett at livecode.com>