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
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
I’m in LC 9.0.0 and Encryption is discussed, and the code is shown to set a
salt. However, the docs say it’s beyond the scope of the docs to explain how to
choose a salt. For example, how many characters need to be in a salt. Are any
characters permissible? Are all character formats
The encrypt command in the dictionary has that info.
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
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
yupgood point Richard
On Wed, Jun 6, 2018 at 4:51 PM, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:
> Tom Glod wrote:
>
> > what if for example you want to hard code a hash salt into your
> > code?.
>
> Most auth DBs store a salt in plain text, but unique for
Tom Glod wrote:
> what if for example you want to hard code a hash salt into your
> code?.
Most auth DBs store a salt in plain text, but unique for each user.
A single RAM dump doesn't slow attacks; eating up clock cycles does.
--
Richard Gaskin
Fourth World Systems
Software Design and
I do the same thing, but if they can get to your code, they can discern how you
get your salt. I guess that is the upshot of what Mark was saying. If they
cannot get to your code however and read it, then it seems safe enough for me.
My salts are dynamically generated using a method only I
thanks for that reply marktotally hear you on that my
application works fully on 1 local machine..I will have a central
registration server, but it will be optional. So everything is on a local
drive or on a server on a lan. my task is to follow standards and add to
the
On 2018-06-06 18:09, Tom Glod via use-livecode wrote:
what if for example you want to hard code a hash salt into your
code?.
if the code is readable, then so is the salt. I would vote for
unreadable
code 100% of the time.
Technically even if the code isn't readable, then the salt will
Never tried it for Livecode because as in my previous message - Just encode
their name - you dont even have to tell them its encoded
but check on boot up - which I do and wait 6 Months and then tell them -
that will F**Ck them up when they thought they got away with it.
Revenge is a dish best
Oh
and for those who do want to make totally sure ..
https://www.cybrary.it/0p3n/advanced-exe-multi-protection-reverse-engineering-free-tools/
shows you how to modify the UPX compressor so that someone with the source
code (it's open source) will have difficulty.
I don't use it - my copy
after trying UPX on my win32 standalone executable i got a upx: UMP.exe:
NotCompressibleException :)
On Wed, Jun 6, 2018 at 1:00 PM, Tom Glod wrote:
> great suggestion Lagi... thats a great solution for anyone who needs an
> extra layer of obfuscation on the binaries.
>
> Yes indeed...the
great suggestion Lagi... thats a great solution for anyone who needs an
extra layer of obfuscation on the binaries.
Yes indeed...the .livecode files must be made available.
On Wed, Jun 6, 2018 at 12:51 PM, Lagi Pittas via use-livecode <
use-livecode@lists.runrev.com> wrote:
> The code doesn't
The code doesn't need to be available "in the clear" either in Community or
Business in the executable.
So there is nothing stopping us using something like
https://www.pelock.com/products/pelock/buy
or a free one here
https://upx.github.io/
http://www.pazera-software.com/products/free-upx/
You
Can’t do that with community... code must be available.
On Jun 6, 2018, 11:09 AM -0500, Tom Glod via use-livecode
, wrote:
> what if for example you want to hard code a hash salt into your code?.
> if the code is readable, then so is the salt. I would vote for unreadable
> code 100% of the
what if for example you want to hard code a hash salt into your code?.
if the code is readable, then so is the salt. I would vote for unreadable
code 100% of the time.
On Wed, Jun 6, 2018 at 10:38 AM, Brian Milby via use-livecode <
use-livecode@lists.runrev.com> wrote:
> For commercial I
For commercial I would think so, but don’t see any issue on the community side.
On Jun 6, 2018, 9:34 AM -0500, Bob Sneidar via use-livecode
, wrote:
> Don't we want that NOT to be possible?? Otherwise bring back the runtime
> engine and run the app as a stack file of the runtime.
>
> Bob S
>
>
>
Don't we want that NOT to be possible?? Otherwise bring back the runtime engine
and run the app as a stack file of the runtime.
Bob S
> On Jun 5, 2018, at 19:37 , Brian Milby via use-livecode
> wrote:
>
> Looking at the code, “deflate” is called on the stack as it is being written
> out
On 6/5/18 4:20 PM, Tom Glod via use-livecode wrote:
so i went to check the standalone file from v9 ...and indeed the code
cannot be seen. in previous versions, I could clearly see the script text
of a stack by opening it up in notepad++.
maybe i was hallucinating.. but i'm pretty sure
Looking at the code, “deflate” is called on the stack as it is being written
out (zlib). So while not easy, it should be possible to separate a stack file
from the binary if deployed from the community edition. It would take a bit of
work to figure out where the file started and ended. Well
h. maybe i'm thinking all the way back to v6 or v7 standalones. cuz
v8 is also not visible.
On Tue, Jun 5, 2018 at 5:20 PM, Tom Glod wrote:
> so i went to check the standalone file from v9 ...and indeed the code
> cannot be seen. in previous versions, I could clearly see the script
so i went to check the standalone file from v9 ...and indeed the code
cannot be seen. in previous versions, I could clearly see the script text
of a stack by opening it up in notepad++.
maybe i was hallucinating.. but i'm pretty sure i checked this before
because of my own curiosities
I believe this thread started as a result is someone asking if there was a way
to recover their work if all they could salvage was a built binary (from
community edition). It sounds like there should be a way based on another
response in the thread.
Thanks,
Brian
On Jun 5, 2018, 2:16 PM -0500,
Richmond Mathewson wrote:
> Recently I ran off a very simple standalone with the Indy and the
> Community version of LC 8.1.9
> and cracked both of them open with a text editor.
>
> In neither of the standalones could I access the code.
>
> Presumably this means that a standalone generated with
Thanks: very useful information.
Richmond.
On 5/6/2018 10:08 pm, Tom Glod via use-livecode wrote:
if u open up a lc standalone exe in a hex editor or even notepad++ you can
totally read the code contained. at least it used to be the case before v9
(haven't looked)
maybe your text editor
if u open up a lc standalone exe in a hex editor or even notepad++ you can
totally read the code contained. at least it used to be the case before v9
(haven't looked)
maybe your text editor wasn't able to display the code in some way but
I assure you its there.
Not so the case for non
On LiveCode's webpage there is a chart of differences between the
Commercial veriosn
and the Community version.
I was given to understand one of the most important differences was
that, in the Commercial versions,
code in standalones was "obfuscated" in such a way that an end-user
could not
28 matches
Mail list logo
