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@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.br...@livecode.com>

use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription 

Reply via email to