Re: worth it's salt in security
Thanks, Brian.
Bill
William Prothero
http://ed.earthednet.org
> On Jun 7, 2018, at 8:29 PM, Brian Milby 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
>> 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
>> > 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
>> >> , 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__«!óÈ/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
>> >> subscript
Re: worth it's salt in security
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__«!óÈ/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
> > Pleas
Re: Area of regular polygon triangles
Cool! On Thu, Jun 7, 2018 at 5:08 PM, David Epstein via use-livecode < use-livecode@lists.runrev.com> wrote: > While trying Mike Bonner's suggestion of "manual" measuring, I learned the > answer: a regular polygon whose official length is L and width is W is > inscribed in the oval whose length is L and width is W. So for an > equilateral triangle the area will be 3/4 * 3^.5 * R^2 (where R = L = W). > > David Epstein > ___ > 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
Re: Area of regular polygon triangles
While trying Mike Bonner's suggestion of "manual" measuring, I learned the answer: a regular polygon whose official length is L and width is W is inscribed in the oval whose length is L and width is W. So for an equilateral triangle the area will be 3/4 * 3^.5 * R^2 (where R = L = W). David Epstein ___ 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
Re: Levure - flicker prior to displaying UI stack on iOS
On Tue, Jun 5, 2018 at 12:36 PM, Ralf Bitter via use-livecode < use-livecode@lists.runrev.com> wrote: > > Unfortunately I am observing an annoying screen flicker > during the startup sequence while the UI stack is opened > and the Levure standalone is closed. > The iOS splash screen, as defined in settings, is shown, > then for a fraction of a second the screen is black just before > the UI stack becomes visible. This happens not only in the > simulator but on a real device (iPad Pro) too. > > Did tests using a very simple UI stack, no code included, just > one card showing an image which is the same as the splash > screen so that the transition from the splash screen to the > UI stack should not be noticeable. I've tracked down what is causing the flicker. 1) When the `startup` message is received the `levureInitializeAndRunApplication` is called. This handler loads your configuration files. 2) Next, the `levureRunApplication` handler is called in time (`0 milliseconds`). 3) `levureRunApplication` processes command line arguments and dispatches the `InitializeApplication` message to your app. It then calls `levureFinishLoadingApplication` in time (`10 milliseconds`). 4) `levureFinishLoadingApplication ` dispatches `OpenApplication` to your application. This is where you display the "testUI" stack of your app. The flicker occurs due to the `send in time` that occurs in step 3, `levureRunApplication`. I just did a test where I called `levureFinishLoadingApplication` inline and the flicker goes away. So now the only issue is to find a fix and I think there is an easy one. In the comments I made for myself in the source code it says that the reason `levureFinishLoadingApplication` is called in time is so that appleEvents can be sent before the application is loaded. This allows URLs that launched application to be tucked away in "process url" levure property and used in `OpenApplication`. Since appleEvents only exist on macOS `in time` only needs to be used on macOS. Try changing line 507 (or thereabouts) in `levure.livecodescript` to the following: ``` if the platform is "macos" then send "levureFinishLoadingApplication" to me in 10 milliseconds else levureFinishLoadingApplication end if ``` In my tests this removes the flicker without breaking the macOS behavior. If it works for you then I will submit a fix to the master branch of Levure. -- Trevor DeVore ScreenSteps www.screensteps.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
Re: Obscure Object Referencing
yeah it is Bob.its one of the reasons why livecode is so flexible and such a joy to work with. On Thu, Jun 7, 2018 at 12:00 PM, Bob Sneidar via use-livecode < use-livecode@lists.runrev.com> wrote: > Yes indeed, it references the datagrid on the currentCard! If there is no > such object on the current card, then even if there is one on another card > that is not the currentCard, it throws an error, as you would expect! > > That is actually quite cool. > > Bob S > > > > On Jun 7, 2018, at 08:54 , Bob Sneidar via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > > Hi all. > > > > I just noticed by accident I can use something like this and it works: > > > > dispatch populateRecord to group cDGName of stack cSubStack > > > > cDGName is "dgDevices" and cSubstack is "Devices". Notice the absence of > a card reference! Apparently, even though the owner of the datagrid group > is the card it's on, this doesn't matter to the parser! I wonder what would > happen if I had another card with a datagrid with the same name on it, if > it would reference that datagrid if it was the currentCard of that stack, > or if it would reference the first datagrid in the stack with that name? I > think I'll give it a try! > > > > Bob S > > > ___ > 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
RE: Android won't quit
It could be solved if we had suspend and resume messages but I heard this is difficult to implement on Android. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On June 7, 2018 12:49:10 PM Ralph DiMola via use-livecode wrote: This is not an easy thing to fix and can be broken easily. The app in memory is not corrupt but the restart of the app is probably exposing an LC engine bug. Details for geeks... To handle the Android unique app restart protocol: After you "Quit" or the app gets hibernated so to speak by the OS, the state of Activities, Fragments and Views will be saved. When returning back to the application , the system will start the process again, recreate the top activity. and you will get a Bundle with the stored state. This is where thing can go sideways, the whole process was killed. So any Singletons (or any “application scope” objects), any temporary data, any data stored in “retained Fragments” ... Everything will be in a state as if the app was just launched , with one big difference , the state is restored and the app is at the point where you left the app. If the Activity you are depending on has some shared Object, or some injected dependency where you keep recent data then most likely the application will just crash on a NullPointerException because it didn’t expect the data to be null. The Android OS is designed not to allow apps to be "stopped/killed" like desktop apps. That is why in the Application Manager it's call "Force stop". To work around the OS design (limitation?) LC could initiate the various activities with startActivityForResult(), and have the LC "quit" send back a result which tells the parent activity to finish(). That activity could then send the same result as part of its onDestroy(), which would cascade back to the main activity and result in no running activities, which should cause the app to close. But this is fighting the basic design of the Android OS and might break with a future OS upgrade. Ralph DiMola IT Director Evergreen Information Services rdim...@evergreeninfo.net -Original Message- From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of Sannyasin Brahmanathaswami via use-livecode Sent: Thursday, June 07, 2018 12:26 PM To: How to use LiveCode Cc: Sannyasin Brahmanathaswami Subject: Re: Android won't quit Argh. I thought I solved in this in my app. But LO... it appears to quit... but is actually not quitting... it leaves a "corrupt" stack on the phone (android) and when you try to restart it, it opens to splash screen stack, but no messages are firing. It is "stuck" ; does not appear to user as "crashed" ; but on is dead-on-arrival - just the card 1 of the launcher stack app, with logo. Good think you caught this. I will have to let users on android force stop, as the only choice. BR J. Landman Gay I want to wipe the app completely so that on next launch I can reinitialize everything. ___ 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
Re: Android won't quit
When I first reported it, the problem was that the quit command unloaded all the libraries but left the app in memory. Sounds like what you see now. In my app it just crashes, but probably for the same reason. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On June 7, 2018 11:28:18 AM Sannyasin Brahmanathaswami via use-livecode wrote: Argh. I thought I solved in this in my app. But LO... it appears to quit... but is actually not quitting... it leaves a "corrupt" stack on the phone (android) and when you try to restart it, it opens to splash screen stack, but no messages are firing. It is "stuck" ; does not appear to user as "crashed" ; but on is dead-on-arrival - just the card 1 of the launcher stack app, with logo. Good think you caught this. I will have to let users on android force stop, as the only choice. BR J. Landman Gay I want to wipe the app completely so that on next launch I can reinitialize everything. ___ 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
RE: Android won't quit
This is not an easy thing to fix and can be broken easily. The app in memory is not corrupt but the restart of the app is probably exposing an LC engine bug. Details for geeks... To handle the Android unique app restart protocol: After you "Quit" or the app gets hibernated so to speak by the OS, the state of Activities, Fragments and Views will be saved. When returning back to the application , the system will start the process again, recreate the top activity. and you will get a Bundle with the stored state. This is where thing can go sideways, the whole process was killed. So any Singletons (or any “application scope” objects), any temporary data, any data stored in “retained Fragments” ... Everything will be in a state as if the app was just launched , with one big difference , the state is restored and the app is at the point where you left the app. If the Activity you are depending on has some shared Object, or some injected dependency where you keep recent data then most likely the application will just crash on a NullPointerException because it didn’t expect the data to be null. The Android OS is designed not to allow apps to be "stopped/killed" like desktop apps. That is why in the Application Manager it's call "Force stop". To work around the OS design (limitation?) LC could initiate the various activities with startActivityForResult(), and have the LC "quit" send back a result which tells the parent activity to finish(). That activity could then send the same result as part of its onDestroy(), which would cascade back to the main activity and result in no running activities, which should cause the app to close. But this is fighting the basic design of the Android OS and might break with a future OS upgrade. Ralph DiMola IT Director Evergreen Information Services rdim...@evergreeninfo.net -Original Message- From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of Sannyasin Brahmanathaswami via use-livecode Sent: Thursday, June 07, 2018 12:26 PM To: How to use LiveCode Cc: Sannyasin Brahmanathaswami Subject: Re: Android won't quit Argh. I thought I solved in this in my app. But LO... it appears to quit... but is actually not quitting... it leaves a "corrupt" stack on the phone (android) and when you try to restart it, it opens to splash screen stack, but no messages are firing. It is "stuck" ; does not appear to user as "crashed" ; but on is dead-on-arrival - just the card 1 of the launcher stack app, with logo. Good think you caught this. I will have to let users on android force stop, as the only choice. BR J. Landman Gay I want to wipe the app completely so that on next launch I can reinitialize everything. ___ 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
Re: Android won't quit
Argh. I thought I solved in this in my app. But LO... it appears to quit... but is actually not quitting... it leaves a "corrupt" stack on the phone (android) and when you try to restart it, it opens to splash screen stack, but no messages are firing. It is "stuck" ; does not appear to user as "crashed" ; but on is dead-on-arrival - just the card 1 of the launcher stack app, with logo. Good think you caught this. I will have to let users on android force stop, as the only choice. BR J. Landman Gay I want to wipe the app completely so that on next launch I can reinitialize everything. ___ 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
Re: Obscure Object Referencing
Yes indeed, it references the datagrid on the currentCard! If there is no such object on the current card, then even if there is one on another card that is not the currentCard, it throws an error, as you would expect! That is actually quite cool. Bob S > On Jun 7, 2018, at 08:54 , Bob Sneidar via use-livecode > wrote: > > Hi all. > > I just noticed by accident I can use something like this and it works: > > dispatch populateRecord to group cDGName of stack cSubStack > > cDGName is "dgDevices" and cSubstack is "Devices". Notice the absence of a > card reference! Apparently, even though the owner of the datagrid group is > the card it's on, this doesn't matter to the parser! I wonder what would > happen if I had another card with a datagrid with the same name on it, if it > would reference that datagrid if it was the currentCard of that stack, or if > it would reference the first datagrid in the stack with that name? I think > I'll give it a try! > > Bob S ___ 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
Obscure Object Referencing
Hi all. I just noticed by accident I can use something like this and it works: dispatch populateRecord to group cDGName of stack cSubStack cDGName is "dgDevices" and cSubstack is "Devices". Notice the absence of a card reference! Apparently, even though the owner of the datagrid group is the card it's on, this doesn't matter to the parser! I wonder what would happen if I had another card with a datagrid with the same name on it, if it would reference that datagrid if it was the currentCard of that stack, or if it would reference the first datagrid in the stack with that name? I think I'll give it a try! Bob S ___ 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
Re: worth it's salt in security
Correct On Jun 7, 2018, 10:01 AM -0500, proth...@earthlearningsolutions.org , wrote: > Folks, > What I get out of this is, for password protection, you use hashed encryption > where you don’t need to return the original password. Only the hashed > password is used to validate the login. > > However, if you need to recover the original encrypted text, like for an sql > query that you sent to your remote server, you need to use a different > encryption method, that can be reversed. > > Right? > Bill > > William Prothero > http://earthlearningsolutions.org ___ 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
Re: worth it's salt in security
Folks, What I get out of this is, for password protection, you use hashed encryption where you don’t need to return the original password. Only the hashed password is used to validate the login. However, if you need to recover the original encrypted text, like for an sql query that you sent to your remote server, you need to use a different encryption method, that can be reversed. Right? Bill William Prothero http://earthlearningsolutions.org > On Jun 7, 2018, at 7:51 AM, Brian Milby via use-livecode > wrote: > > If you strip the first 16 bytes then you must provide the salt to decrypt. If > you leave the salt, then you just need the password to decrypt. >> On Jun 7, 2018, 9:45 AM -0500, Bob Sneidar via use-livecode >> , wrote: >> Okay I think I get it. I noticed the beginning of the hash contained >> "Salted__" but I didn't know why! Are you saying I can strip that along with >> the next 8 bytes, and the hash will be intact, and I can decrypt it without >> the salt?? >> >> Bob S >> >> >>> On Jun 6, 2018, at 21:06 , Brian Milby via use-livecode >>> wrote: >>> >>> If you are using a known salt, then I would say it makes sense to strip it. >>> It would make it easier to decrypt if included, but still not easy to break >>> a cipher that isn’t already cracked. >>> >>> Since only 8 bytes of the salt are unique/used, it may be better to >>> generate your own key instead of using the built in password and salt, but >>> I’m not a security expert. >>> >>> If you are just using a password, then a random salt is added. That means >>> that each encrypted message (even if the message and password is the same) >>> will be unique. On Jun 6, 2018, 10:38 PM -0500, 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. Sorry if I’m being dense. Bill William Prothero http://earthlearningsolutions.org > On Jun 6, 2018, at 7:56 PM, Brian Milby via use-livecode > wrote: > > I’m not sure what the original thread was using the salt for but the > initial post in this one was more about hashing. The question about > encryption was introduced so I answered that. > > For encryption, it looks like there is only an effective 8 byte salt (the > first 8 are static - “Salted__”). Specifying more than 8 bytes does not > change the resulting encrypted text. > > Since LC does include the salt, it does not need to be separately > provided to decrypt. If you strip the salt (first 16 bytes), then you > must supply the salt to decrypt. Providing the salt without stripping it > from the encrypted text did not pose a problem in my test. >>> On Jun 6, 2018, 9:32 PM -0500, Richard Gaskin via use-livecode >>> , wrote: >>> Brian Milby wrote: >>> From the dictionary: >>> >>> The password and salt value are combined and scrambled to form the key >>> and IV which are used as described above. The key derivation process >>> is the same as that used in the openSSL utility. A 16-byte salt prefix >>> is prepended to the encrypted data, based on the salt value. This is >>> used in decryption. >> >> "decryption"? >> >> Are we talking about hashing or encrypting? >> >> -- >> Richard Gaskin >> Fourth World Systems >> Software Design and Development for the Desktop, Mobile, and the Web >> >> ambassa...@fourthworld.com http://www.FourthWorld.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: >>> ht
Re: worth it's salt in security
If you strip the first 16 bytes then you must provide the salt to decrypt. If you leave the salt, then you just need the password to decrypt. On Jun 7, 2018, 9:45 AM -0500, Bob Sneidar via use-livecode , wrote: > Okay I think I get it. I noticed the beginning of the hash contained > "Salted__" but I didn't know why! Are you saying I can strip that along with > the next 8 bytes, and the hash will be intact, and I can decrypt it without > the salt?? > > Bob S > > > > On Jun 6, 2018, at 21:06 , Brian Milby via use-livecode > > wrote: > > > > If you are using a known salt, then I would say it makes sense to strip it. > > It would make it easier to decrypt if included, but still not easy to break > > a cipher that isn’t already cracked. > > > > Since only 8 bytes of the salt are unique/used, it may be better to > > generate your own key instead of using the built in password and salt, but > > I’m not a security expert. > > > > If you are just using a password, then a random salt is added. That means > > that each encrypted message (even if the message and password is the same) > > will be unique. > > On Jun 6, 2018, 10:38 PM -0500, 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. > > > > > > Sorry if I’m being dense. > > > Bill > > > > > > William Prothero > > > http://earthlearningsolutions.org > > > > > > > On Jun 6, 2018, at 7:56 PM, Brian Milby via use-livecode > > > > wrote: > > > > > > > > I’m not sure what the original thread was using the salt for but the > > > > initial post in this one was more about hashing. The question about > > > > encryption was introduced so I answered that. > > > > > > > > For encryption, it looks like there is only an effective 8 byte salt > > > > (the first 8 are static - “Salted__”). Specifying more than 8 bytes > > > > does not change the resulting encrypted text. > > > > > > > > Since LC does include the salt, it does not need to be separately > > > > provided to decrypt. If you strip the salt (first 16 bytes), then you > > > > must supply the salt to decrypt. Providing the salt without stripping > > > > it from the encrypted text did not pose a problem in my test. > > > > > On Jun 6, 2018, 9:32 PM -0500, Richard Gaskin via use-livecode > > > > > , wrote: > > > > > Brian Milby wrote: > > > > > > From the dictionary: > > > > > > > > > > > > The password and salt value are combined and scrambled to form the > > > > > > key > > > > > > and IV which are used as described above. The key derivation process > > > > > > is the same as that used in the openSSL utility. A 16-byte salt > > > > > > prefix > > > > > > is prepended to the encrypted data, based on the salt value. This is > > > > > > used in decryption. > > > > > > > > > > "decryption"? > > > > > > > > > > Are we talking about hashing or encrypting? > > > > > > > > > > -- > > > > > Richard Gaskin > > > > > Fourth World Systems > > > > > Software Design and Development for the Desktop, Mobile, and the Web > > > > > > > > > > ambassa...@fourthworld.com http://www.FourthWorld.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 > > ___ > 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 u
Re: worth it's salt in security
THAT I didn't know! I'm using reversible encryption for my stored passwords! DOH! I'll fix that right away. Bob S > On Jun 6, 2018, at 22:10 , Brian Milby via use-livecode > 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. ___ 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
Re: worth it's salt in security
Okay I think I get it. I noticed the beginning of the hash contained "Salted__" but I didn't know why! Are you saying I can strip that along with the next 8 bytes, and the hash will be intact, and I can decrypt it without the salt?? Bob S > On Jun 6, 2018, at 21:06 , Brian Milby via use-livecode > wrote: > > If you are using a known salt, then I would say it makes sense to strip it. > It would make it easier to decrypt if included, but still not easy to break a > cipher that isn’t already cracked. > > Since only 8 bytes of the salt are unique/used, it may be better to generate > your own key instead of using the built in password and salt, but I’m not a > security expert. > > If you are just using a password, then a random salt is added. That means > that each encrypted message (even if the message and password is the same) > will be unique. > On Jun 6, 2018, 10:38 PM -0500, 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. >> >> Sorry if I’m being dense. >> Bill >> >> William Prothero >> http://earthlearningsolutions.org >> >>> On Jun 6, 2018, at 7:56 PM, Brian Milby via use-livecode >>> wrote: >>> >>> I’m not sure what the original thread was using the salt for but the >>> initial post in this one was more about hashing. The question about >>> encryption was introduced so I answered that. >>> >>> For encryption, it looks like there is only an effective 8 byte salt (the >>> first 8 are static - “Salted__”). Specifying more than 8 bytes does not >>> change the resulting encrypted text. >>> >>> Since LC does include the salt, it does not need to be separately provided >>> to decrypt. If you strip the salt (first 16 bytes), then you must supply >>> the salt to decrypt. Providing the salt without stripping it from the >>> encrypted text did not pose a problem in my test. On Jun 6, 2018, 9:32 PM -0500, Richard Gaskin via use-livecode , wrote: Brian Milby wrote: > From the dictionary: > > The password and salt value are combined and scrambled to form the key > and IV which are used as described above. The key derivation process > is the same as that used in the openSSL utility. A 16-byte salt prefix > is prepended to the encrypted data, based on the salt value. This is > used in decryption. "decryption"? Are we talking about hashing or encrypting? -- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ambassa...@fourthworld.com http://www.FourthWorld.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 ___ 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
Re: Differences between Commercial and Community versions of LiveCode
A salt is simply a string you use to "seed" the hash to make it more difficult to decrypt using rainbow tables or brute force. The decrypting end must also know your salt string to decrypt it. Bob S > On Jun 6, 2018, at 14:16 , prothero--- via use-livecode > wrote: > > I’ve been having questions about aes 256 encryption lately. I encrypt MySQL > queries and data ,(in livecode) before sending it to a php script on my > remote server. The php version returns a warning message that I am not using > a salt, which reduces security. Ok, but I can’t find info about how to create > and use salts. What are the parameters needed to make a salt, and do I have > to do anything to my decode script in php to make it recognize the salt? > > It would be wonderful if there was a sample code for this. > > Best, > Bill > > William Prothero > http://earthlearningsolutions.org ___ 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
Re: worth it's salt in security
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
> 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
>> , 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__«!óÈ/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
Re: Differences between Commercial and Community versions of LiveCode
On 2018-06-06 22:29, Bob Sneidar via use-livecode wrote: I do the same thing, but if they can get to your code, they can discern how you get your salt. Yes - essentially - although I did miss out making one important point... If you are using community (i.e. GPL) then there is nothing you can do here to protect anything embedded in the code: Your app is open-source, so you must provide ALL the source-code - admittedly that doesn't mean you must provide any 'secret keys' but where there are will be obvious as the source has to be for the build you distributed. LiveCode community is open-source (GPL) - this means all code for it is publicly available. If LiveCode Community included code which did obfuscate code in built apps (which it could) then it doesn't do you any good - because the code which deobfuscates at runtime so the code of your app can run also has to be open-source and thus visible. i.e. A suitably motivated individual would just need to invert the code run when building the app, so that it can take a built app and spit out what it was built from. Upshot: In a GPL app code can never be secret as it violates the terms of the license - so using code to protect 'secrets' which are included in a GPL app doesn't work. Of course, I'm not sure I'm entirely clear on what Tom is needing 'secret' salts for, so can't really comment on that specific case. Warmest Regards, Mark. P.S. I'd suggest any use of the word 'hacking' in association with GPL software you put on a local machine is somewhat silly - one of the reasons the GPL came about in the first place was to guarantee the right of hacking around with the source-code for the software you receive! -- Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ LiveCode: Everyone can create apps ___ 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
