worth it's salt in security

Brian Milby brian at milby7.com
Thu Jun 7 01:10:51 EDT 2018

One big difference is that encrypt is reversible and messagedigest is not. Generally for password “storage” you want to use a hash that is one way. You don’t actually store anything that can be reversed to obtain the actual password. For that, you are probably better off just doing a couple of rounds of the digest as the dictionary example shows.
On Jun 6, 2018, 11:57 PM -0500, J. Landman Gay via use-livecode <use-livecode at lists.runrev.com>, wrote:
> 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
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

More information about the Use-livecode mailing list