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 < [email protected]> wrote: > Thanks, Brian. > Bill > > William Prothero > http://ed.earthednet.org > > > On Jun 7, 2018, at 8:29 PM, Brian Milby <[email protected]> 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 < > [email protected]> 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 < > [email protected]> 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 < > [email protected]>, 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 | [email protected] > >> >> HyperActive Software | http://www.hyperactivesw.com > >> >> > >> >> > >> >> _______________________________________________ > >> >> use-livecode mailing list > >> >> [email protected] > >> >> Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > >> >> http://lists.runrev.com/mailman/listinfo/use-livecode > >> > _______________________________________________ > >> > use-livecode mailing list > >> > [email protected] > >> > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > >> > http://lists.runrev.com/mailman/listinfo/use-livecode > >> > >> > >> _______________________________________________ > >> use-livecode mailing list > >> [email protected] > >> Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > >> http://lists.runrev.com/mailman/listinfo/use-livecode > > > _______________________________________________ > use-livecode mailing list > [email protected] > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
