worth it's salt in security
prothero at earthlearningsolutions.org
prothero at earthlearningsolutions.org
Wed Jun 6 19:50:20 EDT 2018
So does the decrypt need the salt somehow? Or does it get it from the stuff that is encrypted with the salt? That is, when I encrypt “with salt my salt” does the decode function somehow get the salt from the encoded data, because it has the “key”?
Btw, thanks for responding,
> On Jun 6, 2018, at 3:48 PM, kee nethery via use-livecode <use-livecode at lists.runrev.com> wrote:
> There is a bunch of basic info on the use of a salt on the web. The wikipedia article is a good start. It depends upon where and how you are using it. Mostly they discuss using a salt with a hash function. They recommend a long salt. They recommend storing the salt with the hashed password.
> User enters their name and password. You look up the salt for their name. You hash the password they provided using the salt you have stored for them. You compare the hash with the hash you had stored. If they match, bingo.
> The salt eliminates the ability for a hacker to use a rainbow table. It is trivial to buy a CD of all hashes for all possible password that are 1 to 14 characters in length. Take a hash, look it up on the CD, and it displays the original password that created that hash.
> Now … if you use a salt, your hash for that password will not match the hash for that password in the rainbow table on the CD. If you have a 32 character salt that is different for each password, assuming lower and upper case ascii and numbers (26 + 26 + 10 = 62) the number of possible salts for a 32 char salt is 62^32. To pre-compute rainbow table for each 14 char possible password would mean 2.27 * 10^57 rainbow tables. Just isn’t practical. So they would have to snag your password table, see the salts for each password, create a rainbow table for that salt, then do a lookup to see if the hash you stored is in the rainbow table. if yes, they know the users password. For the next password, new rainbow table.
> So for a password hash, use a 32 char salt, and store the salt along with the password hash, and toss the password, don’t store it.
>> On Jun 6, 2018, at 2:52 PM, prothero--- via use-livecode <use-livecode at lists.runrev.com> wrote:
>> I’m in LC 9.0.0 and Encryption is discussed, and the code is shown to set a salt. However, the docs say it’s beyond the scope of the docs to explain how to choose a salt. For example, how many characters need to be in a salt. Are any characters permissible? Are all character formats permissible? There is no guidance on what makes an acceptable salt.
>> William Prothero
>>> On Jun 6, 2018, at 2:40 PM, Bob Sneidar via use-livecode <use-livecode at lists.runrev.com> wrote:
>>> The encrypt command in the dictionary has that info.
>>> Bob S
>>>> On Jun 6, 2018, at 14:16 , prothero--- via use-livecode <use-livecode at lists.runrev.com> wrote:
>>>> I’ve been having questions about aes 256 encryption lately. I encrypt MySQL queries and data ,(in livecode) before sending it to a php script on my remote server. The php version returns a warning message that I am not using a salt, which reduces security. Ok, but I can’t find info about how to create and use salts. What are the parameters needed to make a salt, and do I have to do anything to my decode script in php to make it recognize the salt?
>>>> It would be wonderful if there was a sample code for this.
>>>> William Prothero
>>> use-livecode mailing list
>>> use-livecode at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
More information about the Use-livecode