worth it's salt in security

Tom Glod tom at makeshyft.com
Fri Jun 8 12:55:38 EDT 2018


cool demo stack brian..... i would exchange the md5 to a modern hashing
algo .... but demonstrates the point well. thanks.

On Thu, Jun 7, 2018 at 11:50 PM, prothero--- via use-livecode <
use-livecode at lists.runrev.com> wrote:

> Thanks, Brian.
> Bill
>
> William Prothero
> http://ed.earthednet.org
>
> > On Jun 7, 2018, at 8:29 PM, Brian Milby <brian at milby7.com> wrote:
> >
> > I've made a brief demo stack that shows one way of handling passwords.
> > https://github.com/bwmilby/lc-misc/tree/master/PasswordDemo
> >
> > I used my ScriptTracker to export the actual scripts and make them
> available to view online.  I also included an image of the stack layout.  I
> used MD5 for the hash to make it work with LC8, but for security
> applications it is recommended to use SHA3 (or better) which is available
> in LC9.
> >
> >
> >> On Thu, Jun 7, 2018 at 9:12 AM, prothero--- via use-livecode <
> use-livecode at lists.runrev.com> wrote:
> >> Folks,
> >> A stack that demonstrates the various kinds and best practices for
> encryption would be very useful, as the privacy issue has become so
> important. When I get encrypted communication with a server worked out,
> I’ll post my findings for feedback from those more knowledgeable. Examples
> of password security practices would also be useful too.
> >>
> >> Thanks for all the discussion on this topic.
> >> Best,
> >> Bill
> >>
> >> William Prothero
> >> http://earthlearningsolutions.org
> >>
> >> > On Jun 6, 2018, at 10:10 PM, Brian Milby via use-livecode <
> use-livecode at lists.runrev.com> wrote:
> >> >
> >> > 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
> >> > _______________________________________________
> >> > 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
> >>
> >>
> >> _______________________________________________
> >> 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
> >
> _______________________________________________
> 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