worth it's salt in security

[J. Landman Gay]

I'm learning this along with you. But this is what I think I know so 
far. If you do a test in the message box:

   encrypt "mysecret" using "aes256" with password "mypass";put it

You get this:

   Salted__«!óÈ<cr>/rm55ı
it @ˇrȨßQ -- (there's a return in there)

The salt is prepended to the encrypted value (the "hash") so the 
receiver knows what it is. The dictionary says that the salt and the 
password are combined and scrambled before the encryption is actually 
done, thus making the password longer, more random, and more secure. 
Without the password, an observer can't decrypt the string. They need to 
know both.

Except...hackers have provided lists of all possible combinations of 
salted passwords up to 14 characters long ("rainbow tables".) So you 
don't want to use short combinations or common passwords or it might 
show up in one of those lists. (I assume if you have a very long and/or 
random password then it would be okay to have a short salt, or vice 
versa, since the two are combined.)

Brian says that the default random salt is short (8 chars) and Kee says 
it is safest to provide 32 chars or more. So instead of letting LC 
auto-generate a salt, you could provide your own. Bob said he does that. 
If you decide to strip out the salt value from the front of the 
encrypted string, then your receiver would need to know what it is.

Kee says it is common for online services to store a unique salt value 
for each user, along with the encrypted string that was generated with 
that salt when the password was first created. The password itself is 
not stored. When a user logs in, the service looks up their salt value, 
uses that salt to encrypt the password the user just sent, and compares 
the computed one to the one stored in the database. (Since no actual 
passwords are ever kept, breaches or employees can't know what they are 
either.)

In any case, the salt alone is not enough to do decryption. Kee says a 
long enough salt makes decryption virtually impossible because the 
number of scrambled combinations becomes astronomical, too many to 
pre-compute.

That's what I've pieced together, I welcome any corrections. This has 
been a useful thread because I had a vague idea of how it worked but not 
many particulars.


On 6/6/18 10:37 PM, prothero--- via use-livecode wrote:
> Hmmm....
> If the salt is included in the encrypted text, doesn’t that enable anyone who intercepts it to decrypt it more easily, invalidating the purpose of using the salt in the first place.
> 
> Or, if the server decrypting the text uses a standard, but secret, salt that is known by both parties, it seems more reasonable to me.

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com