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@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 | jac...@hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.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
_______________________________________________
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
