worth it's salt in security

Fri Jun 8 13:15:01 EDT 2018

Roger. I used MD5 to have it work in LC8 but will add a card that uses SHA3. I also want to implement the RFC HMAC as a demo (unless I find that someone else has already done it).
On Jun 8, 2018, 11:56 AM -0500, Tom Glod via use-livecode <use-livecode at lists.runrev.com>, wrote:
> 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
> >
> _______________________________________________
> 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