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 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
