Thanks, Brian. Bill William Prothero http://ed.earthednet.org
> On Jun 7, 2018, at 8:29 PM, Brian Milby <br...@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@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@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@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 >> >> >> _______________________________________________ >> 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
