Top Bottom Left Right

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Top Bottom Left Right

Richard Gaskin via use-livecode
Hi ,

If I use property inspector and tick "Resize Rect when setting property" and change top,bottom,left or right property the rect changes shape in its fixed location as expected.

In runtime the rect does not resize but moves location by setting property top,bottom,left or right ?

Have I missed something ?? or this a bug ??

Regards
Camm
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Top Bottom Left Right

Richard Gaskin via use-livecode
Hi Cam,

> Am 24.06.2018 um 21:49 schrieb General 2018 via use-livecode <[hidden email]>:
>
> Hi ,
>
> If I use property inspector and tick "Resize Rect when setting property" and change top,bottom,left or right property the rect changes shape in its fixed location as expected.
>
> In runtime the rect does not resize but moves location by setting property top,bottom,left or right ?
>
> Have I missed something ?? or this a bug ??

nope, this is only a feature of the IDE! 8-)

If you need this functionality in your runtime you need to roll your own.
But it's just:
...
lock screen
put the loc of btn "xyz" int tOldLoc
## do your thing with width and height of this button
## which will affect also the LOC unfortunately!
set the loc of btn "xyz" to tOldLoc
unlock screen
...

> Regards
> Camm

Best

Klaus

--
Klaus Major
http://www.major-k.de
[hidden email]


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

RE: Top Bottom Left Right

Richard Gaskin via use-livecode
Klaus ,

At least I was not going mad ! , thanks.

Regards
Camm

-----Original Message-----
From: use-livecode [mailto:[hidden email]] On Behalf Of Klaus major-k via use-livecode
Sent: 24 June 2018 20:58
To: How to use LiveCode
Cc: Klaus major-k
Subject: Re: Top Bottom Left Right

Hi Cam,

> Am 24.06.2018 um 21:49 schrieb General 2018 via use-livecode <[hidden email]>:
>
> Hi ,
>
> If I use property inspector and tick "Resize Rect when setting property" and change top,bottom,left or right property the rect changes shape in its fixed location as expected.
>
> In runtime the rect does not resize but moves location by setting property top,bottom,left or right ?
>
> Have I missed something ?? or this a bug ??

nope, this is only a feature of the IDE! 8-)

If you need this functionality in your runtime you need to roll your own.
But it's just:
...
lock screen
put the loc of btn "xyz" int tOldLoc
## do your thing with width and height of this button
## which will affect also the LOC unfortunately!
set the loc of btn "xyz" to tOldLoc
unlock screen
...

> Regards
> Camm

Best

Klaus

--
Klaus Major
http://www.major-k.de
[hidden email]


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Examples of encryption for database access

Richard Gaskin via use-livecode
Folks:
In case you are interested, or if you have any feedback, here is the code I use to test AES encryption for sending posts to interact with a mysql database.

This work is inspired by the excellent dbLib product of Andre Garza, that got me to look into encryption a lot deeper than I had to date.

Perhaps Andre would like to chime in here, as I am a complete novice in this area. What got me started was purchasing his dbLib software and getting warning messages that there was no “iv” vector specified. From internet searching I got that the encryption is vulnerable to a “Dictionary” attack. An “iv” vector is analogous to a “salt”, which make the encryption much more difficult to crack. I’m using php version 5.6.36

This should make transfers to a from a remote database pretty secure. It is different from password security, where only the encrypted password needs to be compared with the encrypted db value. Here (I think) both the server and the client need to have the key and iv values.

Here is the code that I used to test the encryption. If I am wrong about any of this, please let me know. An example like this would have saved me a bunch of time, so I hope it will be useful to somebody else on the list.

————Testing iv for encryption
--To test this on your own server, upload the php script where you put cgi's
-- and modify the myURL setting
on testEncryption
   put "http://earthexplorer.earthlearningsolutions.org/scgi-bin/wpEncryptionTest.php" into myURL
   put "AES-256-CTR" into tCipher
   put "AFBDDFCFBDBBDDCCFFACGHDFFFFEEDCC" into tEncryptionKey
   put "ABCDEEABCDEEAA%A" into tIV
   put "The php should return this text." into tPostA["theQuery"]
   put "query" into tPostA["type"]
   put ArrayToJSON(tPostA,"string",pPretty) into tJson
   encrypt tJson using tCipher with key tEncryptionKey and iV tIV
   put base64encode(it) into tMyEncryptedData
   post tMyEncryptedData to url myURL
   put it into tRet
   put tRet into fld "status"
   put cr&"num chars: "&(the number of chars in tRet) after fld "status"
   put cr&base64decode(tRet) after fld "status"
end testEncryption
   
----------php script, on server ---------------------------
--Note:  you can run the above script on my server,
--to test the LC script.  
<?php
//file: wpEncryptionTest.php
//external function
 function debug($msg) {
     $debug = false;
     if ($debug) {
         error_log("[DB LIB] $msg");
         echo "$msg.\n";
      }
  }
//php code
        $encryption_key = "AFBDDFCFBDBBDDCCFFACGHDFFFFEEDCC";
  $cipher = "AES-256-CTR"; // do not change cipher unless you know what you're doing
        $post = file_get_contents('php://input');
        $iv = 'ABCDEEABCDEEAA%A';
        $ivlen = 16;
        /* set for debugging. To encrypt, set to TRUE */
        $post = openssl_decrypt($post, $cipher, $encryption_key, $options=0, $iv);
        $req = json_decode($post,true);
        if (!$req) {
      debug("error on decrypt");
      debug(openssl_error_string());
  }
  $theOut = $req["theQuery"];
  $tRet = base64_encode("Decrypted query: $theOut.\n");
  echo $tRet;
?>


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Examples of encryption for database access

Richard Gaskin via use-livecode
Folks:
Woke up this morning and realized I need to clarify a couple of points on my post.
1. For a test, you can use the LC script I included, exactly as given, which will access the included php test script on my server.
2. The php script just returns the decrypted text that you put in the tPostA[“theQuery”] array element. For real world use, you would want to, in the php, encrypt the return text.
3. As far as I can tell, I need to have the encryption key and iV stored on both the LC app (to encrypt the text that is being sent) and the php script, to decrypt it.
4. I left out the part where the php encrypts the return value and the LC decrypts it. I’ll add it in if anybody wants it.

Best,
Bill

> On Jun 24, 2018, at 5:17 PM, William Prothero via use-livecode <[hidden email]> wrote:
>
> Folks:
> In case you are interested, or if you have any feedback, here is the code I use to test AES encryption for sending posts to interact with a mysql database.
>
> This work is inspired by the excellent dbLib product of Andre Garza, that got me to look into encryption a lot deeper than I had to date.
>
> Perhaps Andre would like to chime in here, as I am a complete novice in this area. What got me started was purchasing his dbLib software and getting warning messages that there was no “iv” vector specified. From internet searching I got that the encryption is vulnerable to a “Dictionary” attack. An “iv” vector is analogous to a “salt”, which make the encryption much more difficult to crack. I’m using php version 5.6.36
>
> This should make transfers to a from a remote database pretty secure. It is different from password security, where only the encrypted password needs to be compared with the encrypted db value. Here (I think) both the server and the client need to have the key and iv values.
>
> Here is the code that I used to test the encryption. If I am wrong about any of this, please let me know. An example like this would have saved me a bunch of time, so I hope it will be useful to somebody else on the list.
>
> ————Testing iv for encryption
> --To test this on your own server, upload the php script where you put cgi's
> -- and modify the myURL setting
> on testEncryption
>   put "http://earthexplorer.earthlearningsolutions.org/scgi-bin/wpEncryptionTest.php" into myURL
>   put "AES-256-CTR" into tCipher
>   put "AFBDDFCFBDBBDDCCFFACGHDFFFFEEDCC" into tEncryptionKey
>   put "ABCDEEABCDEEAA%A" into tIV
>   put "The php should return this text." into tPostA["theQuery"]
>   put "query" into tPostA["type"]
>   put ArrayToJSON(tPostA,"string",pPretty) into tJson
>   encrypt tJson using tCipher with key tEncryptionKey and iV tIV
>   put base64encode(it) into tMyEncryptedData
>   post tMyEncryptedData to url myURL
>   put it into tRet
>   put tRet into fld "status"
>   put cr&"num chars: "&(the number of chars in tRet) after fld "status"
>   put cr&base64decode(tRet) after fld "status"
> end testEncryption
>
> ----------php script, on server ---------------------------
> --Note:  you can run the above script on my server,
> --to test the LC script.  
> <?php
> //file: wpEncryptionTest.php
> //external function
> function debug($msg) {
>     $debug = false;
>     if ($debug) {
>         error_log("[DB LIB] $msg");
>         echo "$msg.\n";
>     }
> }
> //php code
> $encryption_key = "AFBDDFCFBDBBDDCCFFACGHDFFFFEEDCC";
> $cipher = "AES-256-CTR"; // do not change cipher unless you know what you're doing
> $post = file_get_contents('php://input');
> $iv = 'ABCDEEABCDEEAA%A';
> $ivlen = 16;
> /* set for debugging. To encrypt, set to TRUE */
> $post = openssl_decrypt($post, $cipher, $encryption_key, $options=0, $iv);
> $req = json_decode($post,true);
> if (!$req) {
>     debug("error on decrypt");
>     debug(openssl_error_string());
> }
> $theOut = $req["theQuery"];
> $tRet = base64_encode("Decrypted query: $theOut.\n");
> echo $tRet;
> ?>
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Examples of encryption for database access

Richard Gaskin via use-livecode
Corrections to the posted code:
I changed the code to encrypt the returned text. I also note that using openSSL in php returns base64 data.
Bill

--------temp, testing iv for encryption
--To test this on your own server, upload the php script where you put cgi's
-- and modify the myURL setting.
//Be sure to change the encryption key and tiv value
on testEncryption
   put "http://earthexplorer.earthlearningsolutions.org/scgi-bin/wpEncryptionTest.php" into myURL
   put "AES-256-CTR" into tCipher
   put "AFBDDFCFBDBBDDCCFFACGHDFFFFEEDCC" into tEncryptionKey //must be 43 chars
   put "ABCDEEABCDEEAA%A" into tIV //must be 16 chars
   put "The php should return this text." into tPostA["theQuery"]
   put "query" into tPostA["type"]
   put ArrayToJSON(tPostA,"string",pPretty) into tJson
   encrypt tJson using tCipher with key tEncryptionKey and iV tIV
   put base64encode(it) into tMyEncryptedData
   post tMyEncryptedData to url myURL
   put it into tRet
   put tRet into fld "status"
   —Note that openSSL in php returns base64 encoded data.
   put base64decode(tRet) into tRetVal
   decrypt tRetVal using tCipher with key tEncryptionKey and iV tIV
   put it into theResult
   put theResult after fld "status"
end testEncryption
   
----------php script, on server ---------------------------
--Note:  you can run the above script on my server,
--to test the LC script.  
<?php
//file: wpEncryptionTest.php
//external function
 function debug($msg) {
     $debug = false;
     if ($debug) {
         error_log("[DB LIB] $msg");
         echo "$msg.\n";
      }
  }
//php code
        $encryption_key = "AFBDDFCFBDBBDDCCFFACGHDFFFFEEDCC";
  $cipher = "AES-256-CTR"; // do not change cipher unless you know what you're doing
        $post = file_get_contents('php://input');
        $iv = 'ABCDEEABCDEEAA%A';
        $ivlen = 16;
        /* set for debugging. To encrypt, set to TRUE */
        $post = openssl_decrypt($post, $cipher, $encryption_key, $options=0, $iv);
        $req = json_decode($post,true);
        if (!$req) {
      debug("error on decrypt");
      debug(openssl_error_string());
  }
  $theOut = $req["theQuery"];  //This is just the text of the query
  //$req is the array value of the tPostA array sent with the post comand.
        //Access the elements of tPostA using $req[“name of element”]
        //example: $req[“theQuery”] is tPoasA[“theQuery”]
  $retVal = "Decrypted query: $theOut.\n";
  $doEncryptOutput = TRUE;
  if ($doEncryptOutput) {
    $retVal = openssl_encrypt($retVal, $cipher, $encryption_key,0,$iv);
                //openSSL in php returns base64 encoded data.`
    }
        echo $retVal;
?>



William A. Prothero
http://earthlearningsolutions.org

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Examples of encryption for database access

Richard Gaskin via use-livecode
In reply to this post by Richard Gaskin via use-livecode
Bill-

Nicely done. For security though, I wouldn't store the encryption keys
in either the LC stack or (especially) the php script.

In the php script you can set the environment variable on the server and
then access it as

$encryption_key = .$_ENV["ENCRYPTION_KEY"]

Same thing, obviously, for the initialization vector.

On the LC end of things, it depends on whether you're distributing the
stack as a standalone application or whether you have control over the
environment the stack is running in. If you're in control of the
environment then you can do something similar: set environment variables
and then pick them up in the LC script. If you're distributing the stack
to others, then I'd probably obfuscate the keys as much as possible: put
them into an array with numeric keys, encrypt the array, store it in a
custom property of some non-related object... if you need to distribute
a stack without password protection I don't think there's any way to be
completely secure, but there are ways to at least pretend to hide the keys.


[semi-related isue]

be careful with lines like
$post = file_get_contents('php://input');

Your test code should be fine, but if you're interacting with a database
you'll want to scrub the input before acting on it.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Examples of encryption for database access

Richard Gaskin via use-livecode
Mark:
Thanks so much! This is just the advice I needed. I was wondering about the security of the keys.

I’m setting up a general db library stack. One of the apps will be distributed for free to teachers and students. The other apps are mobile and will be used either by me alone, or distributed to others, possibly through the app store.

So, it’s good to get the techniques for securing the db in a variety of environments.

Best,
Bill

> On Jun 25, 2018, at 9:54 AM, Mark Wieder via use-livecode <[hidden email]> wrote:
>
> Bill-
>
> Nicely done. For security though, I wouldn't store the encryption keys in either the LC stack or (especially) the php script.
>
> In the php script you can set the environment variable on the server and then access it as
>
> $encryption_key = .$_ENV["ENCRYPTION_KEY"]
>
> Same thing, obviously, for the initialization vector.
>
> On the LC end of things, it depends on whether you're distributing the stack as a standalone application or whether you have control over the environment the stack is running in. If you're in control of the environment then you can do something similar: set environment variables and then pick them up in the LC script. If you're distributing the stack to others, then I'd probably obfuscate the keys as much as possible: put them into an array with numeric keys, encrypt the array, store it in a custom property of some non-related object... if you need to distribute a stack without password protection I don't think there's any way to be completely secure, but there are ways to at least pretend to hide the keys.
>
>
> [semi-related isue]
>
> be careful with lines like
> $post = file_get_contents('php://input');
>
> Your test code should be fine, but if you're interacting with a database you'll want to scrub the input before acting on it.
>
> --
> Mark Wieder
> [hidden email]
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Examples of encryption for database access

Richard Gaskin via use-livecode
Mark:
I’ve been exploring, Googling, and my Web Host Manager to figure out where to set the environmental variables for the security keys. It might be nice if I could set different values for different subdomains on my server, but my Web Host Manager program states that it will put a copy of the keys in the .htaccess file. Is the .htaccess file for a domain a secure place to put the keys?

I’ve put in a support ticket to my web host manager, but I’m not confident they know anything about security, so any bit of wisdom from you would be great.

Best,
Bill

> On Jun 25, 2018, at 10:16 AM, William Prothero via use-livecode <[hidden email]> wrote:
>
>> On Jun 25, 2018, at 9:54 AM, Mark Wieder via use-livecode <[hidden email]> wrote:
>>
>> Bill-
>>
>> Nicely done. For security though, I wouldn't store the encryption keys in either the LC stack or (especially) the php script.
>>
>> In the php script you can set the environment variable on the server and then access it as
>>
>> $encryption_key = .$_ENV["ENCRYPTION_KEY"]
>>
>> Same thing, obviously, for the initialization vector.
>>
>> On the LC end of things, it depends on whether you're distributing the stack as a standalone application or whether you have control over the environment the stack is running in. If you're in control of the environment then you can do something similar: set environment variables and then pick them up in the LC script. If you're distributing the stack to others, then I'd probably obfuscate the keys as much as possible: put them into an array with numeric keys, encrypt the array, store it in a custom property of some non-related object... if you need to distribute a stack without password protection I don't think there's any way to be completely secure, but there are ways to at least pretend to hide the keys.
>>
>>
>> [semi-related isue]
>>
>> be careful with lines like
>> $post = file_get_contents('php://input');
>>
>> Your test code should be fine, but if you're interacting with a database you'll want to scrub the input before acting on it.
>>
>> --
>> Mark Wieder
>> [hidden email]
>>


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Examples of encryption for database access

Richard Gaskin via use-livecode
On 06/25/2018 02:17 PM, William Prothero via use-livecode wrote:
> Mark:
> I’ve been exploring, Googling, and my Web Host Manager to figure out where to set the environmental variables for the security keys. It might be nice if I could set different values for different subdomains on my server, but my Web Host Manager program states that it will put a copy of the keys in the .htaccess file. Is the .htaccess file for a domain a secure place to put the keys?

Yes, that's a proper place to initialize server variables, and
especially if you want different values for different subdomains, as
you'll have a separate .htaccess file for each subdomain. In *theory*
nobody has access to the . files except you.

The .htaccess line will look something like

SetEnv name value

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Examples of encryption for database access

Richard Gaskin via use-livecode
Mark:
Thanks, that makes it a lot easier. I have been tearing my limited hair out over trying to set Apache environmental variables and deleted a load of files on my server, accidentally.

This I can do.
Best,
Bill


> On Jun 25, 2018, at 4:04 PM, Mark Wieder via use-livecode <[hidden email]> wrote:
>
> On 06/25/2018 02:17 PM, William Prothero via use-livecode wrote:
>> Mark:
>> I’ve been exploring, Googling, and my Web Host Manager to figure out where to set the environmental variables for the security keys. It might be nice if I could set different values for different subdomains on my server, but my Web Host Manager program states that it will put a copy of the keys in the .htaccess file. Is the .htaccess file for a domain a secure place to put the keys?
>
> Yes, that's a proper place to initialize server variables, and especially if you want different values for different subdomains, as you'll have a separate .htaccess file for each subdomain. In *theory* nobody has access to the . files except you.
>
> The .htaccess line will look something like
>
> SetEnv name value
>
> --
> Mark Wieder
> [hidden email]
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Examples of encryption for database access

Richard Gaskin via use-livecode
One thing this misses is that the IV is not another private key/password. It should be random/different for every use of the key.

https://en.m.wikipedia.org/wiki/Initialization_vector

https://crypto.stackexchange.com/questions/3965/what-is-the-main-difference-between-a-key-an-iv-and-a-nonce

https://security.stackexchange.com/questions/35210/encrypting-using-aes-256-do-i-need-iv

On Jun 25, 2018, 7:34 PM -0400, William Prothero via use-livecode <[hidden email]>, wrote:

> Mark:
> Thanks, that makes it a lot easier. I have been tearing my limited hair out over trying to set Apache environmental variables and deleted a load of files on my server, accidentally.
>
> This I can do.
> Best,
> Bill
>
>
> > On Jun 25, 2018, at 4:04 PM, Mark Wieder via use-livecode <[hidden email]> wrote:
> >
> > On 06/25/2018 02:17 PM, William Prothero via use-livecode wrote:
> > > Mark:
> > > I’ve been exploring, Googling, and my Web Host Manager to figure out where to set the environmental variables for the security keys. It might be nice if I could set different values for different subdomains on my server, but my Web Host Manager program states that it will put a copy of the keys in the .htaccess file. Is the .htaccess file for a domain a secure place to put the keys?
> >
> > Yes, that's a proper place to initialize server variables, and especially if you want different values for different subdomains, as you'll have a separate .htaccess file for each subdomain. In *theory* nobody has access to the . files except you.
> >
> > The .htaccess line will look something like
> >
> > SetEnv name value
> >
> > --
> > Mark Wieder
> > [hidden email]
> >
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Examples of encryption for database access

Richard Gaskin via use-livecode
On 06/25/2018 08:57 PM, Brian Milby via use-livecode wrote:
> One thing this misses is that the IV is not another private key/password. It should be random/different for every use of the key.

True, but for the purpose of Bill's demo it works fine. For that matter,
a 16-bit iv won't get you very far either. I'd be inclined to generate a
large random iv and post it to the server with the encrypted data. But
I'd also worry about putting a database out in the open like this
without good security constraints. Of course, I have no idea what Bill
has in mind here, so ymmv.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Examples of encryption for database access

Richard Gaskin via use-livecode
Mark and Brian:
Thank you for your input. Security is a big deal these days and I think it is very important that best practices get discussed and examples available. Ideally, we would be able to download example scripts of best practices for both db access, and password verification. For my use, the consequences of a breach are very small, but I don’t want my site to be able to be hijacked for nefarious purposes.

A few questions.

I understand Mark’s comment about putting the key and IV vector in the .htaccess file. I will do this as soon as I figure out if I’ve destroyed my server by deleting all files in the /etc/httpd directory by mistake (I was trying to set an environment variable in that directory and ….. arg…l). However, if IV is a random vector, I don’t understand how the php code that accesses the mySQL db would decode the commands and data. The setup would be different for password verification because it doesn’t need to be decoded to be verified. However, for access to a mySQL server, it needs to be decoded on the server. My understanding was that the function of the IV was to increase the number of possible keys to make a dictionary attack less feasible. Also, my php docs say the IV should be 16 bits. I haven’t tried more, but I do get an error message complaining about IV not being 16 bits.

Another question I have is the best way to process the input text to eliminate injection type attacks.

Best,
Bill

> On Jun 26, 2018, at 2:37 PM, Mark Wieder via use-livecode <[hidden email]> wrote:
>
> On 06/25/2018 08:57 PM, Brian Milby via use-livecode wrote:
>> One thing this misses is that the IV is not another private key/password. It should be random/different for every use of the key.
>
> True, but for the purpose of Bill's demo it works fine. For that matter, a 16-bit iv won't get you very far either. I'd be inclined to generate a large random iv and post it to the server with the encrypted data. But I'd also worry about putting a database out in the open like this without good security constraints. Of course, I have no idea what Bill has in mind here, so ymmv.
>
> --
> Mark Wieder
> [hidden email]
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Examples of encryption for database access

Richard Gaskin via use-livecode
On 06/28/2018 09:17 AM, William Prothero via use-livecode wrote:

> I understand Mark’s comment about putting the key and IV vector in the .htaccess file. I will do this as soon as I figure out if I’ve destroyed my server by deleting all files in the /etc/httpd directory by mistake (I was trying to set an environment variable in that directory and ….. arg…l). However, if IV is a random vector, I don’t understand how the php code that accesses the mySQL db would decode the commands and data. The setup would be different for password verification because it doesn’t need to be decoded to be verified. However, for access to a mySQL server, it needs to be decoded on the server. My understanding was that the function of the IV was to increase the number of possible keys to make a dictionary attack less feasible. Also, my php docs say the IV should be 16 bits. I haven’t tried more, but I do get an error message complaining about IV not being 16 bits.

There's no requirement for the initialization vector to be private, just
that it is unique among all messages using the same encryption key. It
can be posted to the server along with the encrypted data. Thus you can
use a new randomized iv for each post, and the php code on the server
would take the posted iv and use it with the already-known encryption
key to decrypt the data.

Ignore my comment about 16 bits. You're supplying an iv of 16 *bytes*,
which is 128 bytes. That's standard for normal use. If you want to get
serious about it, you could double the length.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Examples of encryption for database access

Richard Gaskin via use-livecode
In reply to this post by Richard Gaskin via use-livecode
On Jun 28, 2018, at 9:17 AM, William Prothero via use-livecode <[hidden email]> wrote:

> Another question I have is the best way to process the input text to eliminate injection type attacks.

I have a series of functions that filter out everything but ...

digitsOnly() <- deletes everything other than 0 through 9

moneyOnly() <- deletes all but 0 through 9, period, minus sign

emailOnly() <- only keeps stuff that has the format of an email

alphaOnly() <- tosses everything outside of a-z and A-Z

noQuoted() <- anything containing a quote is set to empty. For example no username or password should ever contain a quote.

I only use a filtered version of the data provided by a user. I’ll write custom filters if needed. This applies to desktop apps and web apps.




_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Examples of encryption for database access

Richard Gaskin via use-livecode
In reply to this post by Richard Gaskin via use-livecode
Mark,
Pardon me for being dense. But if you send an iv with the data, can’t a hacker obtain and use that iv to support hacking the encrypted data?

What I understand, possibly erroneous, is that a Dictionary attack involves trying all possible combinations of a key. A 32 char key would have 2**(32*8) combinations. The iv vector increases the possible combinations to [2**(32*8)]*[2**(16*8)] and makes dictionary attacks much less practical.. Now I’m wondering whether I’m understanding what the iv does. If the iv for data with an unknown key, is known, can’t that iv be used to reduce the number of possible combinations of keys back to the 2**(16*32) value, making the use of an iv irrelevant?

I am going to google this to see if I can get more info, but please chime in if I am on the wrong track.

Best,
Bill

Bill

William Prothero
http://earthlearningsolutions.org

> On Jun 28, 2018, at 12:30 PM, Mark Wieder via use-livecode <[hidden email]> wrote:
>
>> On 06/28/2018 09:17 AM, William Prothero via use-livecode wrote:
>>
>> I understand Mark’s comment about putting the key and IV vector in the .htaccess file. I will do this as soon as I figure out if I’ve destroyed my server by deleting all files in the /etc/httpd directory by mistake (I was trying to set an environment variable in that directory and ….. arg…l). However, if IV is a random vector, I don’t understand how the php code that accesses the mySQL db would decode the commands and data. The setup would be different for password verification because it doesn’t need to be decoded to be verified. However, for access to a mySQL server, it needs to be decoded on the server. My understanding was that the function of the IV was to increase the number of possible keys to make a dictionary attack less feasible. Also, my php docs say the IV should be 16 bits. I haven’t tried more, but I do get an error message complaining about IV not being 16 bits.
>
> There's no requirement for the initialization vector to be private, just that it is unique among all messages using the same encryption key. It can be posted to the server along with the encrypted data. Thus you can use a new randomized iv for each post, and the php code on the server would take the posted iv and use it with the already-known encryption key to decrypt the data.
>
> Ignore my comment about 16 bits. You're supplying an iv of 16 *bytes*, which is 128 bytes. That's standard for normal use. If you want to get serious about it, you could double the length.
>
> --
> Mark Wieder
> [hidden email]
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Examples of encryption for database access

Richard Gaskin via use-livecode
Random IV means that an attacker can not generate a dictionary in advance. Knowing it at the same time is not an issue since they cypher is not cracked. The other reason is that the IV seeds the AES encryption so that the first block does not give anything away. If the first encrypted block for the same data is always the same, the attacker can use that to test guesses if they can control what is being encrypted. Same issue if they can predict the IV. See the Wikipedia entry I linked to for a better discussion.

IV is fixed at the block size of the cipher. So for AES it is 16 bytes.
On Jun 28, 2018, 4:33 PM -0400, prothero--- via use-livecode , wrote:

> Mark,
> Pardon me for being dense. But if you send an iv with the data, can’t a hacker obtain and use that iv to support hacking the encrypted data?
>
> What I understand, possibly erroneous, is that a Dictionary attack involves trying all possible combinations of a key. A 32 char key would have 2**(32*8) combinations. The iv vector increases the possible combinations to [2**(32*8)]*[2**(16*8)] and makes dictionary attacks much less practical.. Now I’m wondering whether I’m understanding what the iv does. If the iv for data with an unknown key, is known, can’t that iv be used to reduce the number of possible combinations of keys back to the 2**(16*32) value, making the use of an iv irrelevant?
>
> I am going to google this to see if I can get more info, but please chime in if I am on the wrong track.
>
> Best,
> Bill
>
> Bill
>
> William Prothero
> http://earthlearningsolutions.org
>
> > On Jun 28, 2018, at 12:30 PM, Mark Wieder via use-livecode <[hidden email]> wrote:
> >
> > > On 06/28/2018 09:17 AM, William Prothero via use-livecode wrote:
> > >
> > > I understand Mark’s comment about putting the key and IV vector in the .htaccess file. I will do this as soon as I figure out if I’ve destroyed my server by deleting all files in the /etc/httpd directory by mistake (I was trying to set an environment variable in that directory and ….. arg…l). However, if IV is a random vector, I don’t understand how the php code that accesses the mySQL db would decode the commands and data. The setup would be different for password verification because it doesn’t need to be decoded to be verified. However, for access to a mySQL server, it needs to be decoded on the server. My understanding was that the function of the IV was to increase the number of possible keys to make a dictionary attack less feasible. Also, my php docs say the IV should be 16 bits. I haven’t tried more, but I do get an error message complaining about IV not being 16 bits.
> >
> > There's no requirement for the initialization vector to be private, just that it is unique among all messages using the same encryption key. It can be posted to the server along with the encrypted data. Thus you can use a new randomized iv for each post, and the php code on the server would take the posted iv and use it with the already-known encryption key to decrypt the data.
> >
> > Ignore my comment about 16 bits. You're supplying an iv of 16 *bytes*, which is 128 bytes. That's standard for normal use. If you want to get serious about it, you could double the length.
> >
> > --
> > Mark Wieder
> > [hidden email]
> >
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Examples of encryption for database access

Richard Gaskin via use-livecode
On 06/28/2018 01:49 PM, Brian Milby via use-livecode wrote:
> Random IV means that an attacker can not generate a dictionary in advance. Knowing it at the same time is not an issue since they cypher is not cracked. The other reason is that the IV seeds the AES encryption so that the first block does not give anything away. If the first encrypted block for the same data is always the same, the attacker can use that to test guesses if they can control what is being encrypted. Same issue if they can predict the IV. See the Wikipedia entry I linked to for a better discussion.

Encryption with an initialization vector isn't a reversible operation.
It's not like XORing a value with another. Being able to *predict* an iv
value, however, as opposed to just knowing the current value, is a
security problem.

>
> IV is fixed at the block size of the cipher. So for AES it is 16 bytes.

Yes, I stand corrected. Silly me assumed that aes-256 would use a larger
block size. AES uses only 128-bit blocks with different key sizes.

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Examples of encryption for database access

Richard Gaskin via use-livecode
Here’s an interesting link re iv vectors. It says iv can be sent in plain view. Hmmm....
http://www.cryptofails.com/post/70059609995/crypto-noobs-1-initialization-vectors

But, I thought having the iv vector in plain view was also a security risk.
Perhaps I’m belaboring this and I apologize if I this discussion is getting tedious.

Bill

William Prothero
http://earthlearningsolutions.org

> On Jun 28, 2018, at 3:53 PM, Mark Wieder via use-livecode <[hidden email]> wrote:
>
> Return-Path: <[hidden email]>
> Delivered-To: [hidden email]
> Received: from ssd.earthlearningsolutions.org
>    by ssd.earthlearningsolutions.org with LMTP id iK5OBz9nNVvKBQgAqWmBzQ
>    for <[hidden email]>; Thu, 28 Jun 2018 22:54:55 +0000
> Return-path: <[hidden email]>
> Envelope-to: [hidden email]
> Delivery-date: Thu, 28 Jun 2018 22:54:55 +0000
> Received: from on-rev.com ([37.59.205.90]:45213 helo=var.runrev.com)
>    by ssd.earthlearningsolutions.org with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
>    (Exim 4.91)
>    (envelope-from <[hidden email]>)
>    id 1fYfoU-002Cli-VR
>    for [hidden email]; Thu, 28 Jun 2018 22:54:55 +0000
> Received: from localhost ([127.0.0.1]:40505 helo=meg.on-rev.com)
>    by meg.on-rev.com with esmtp (Exim 4.85)
>    (envelope-from <[hidden email]>)
>    id 1fYfnh-0002Uo-3q; Fri, 29 Jun 2018 00:54:05 +0200
> Received: from c.mail.sonic.net ([64.142.111.80]:34500)
>    by meg.on-rev.com with esmtps (TLSv1.2:DHE-RSA-AES128-GCM-SHA256:128)
>    (Exim 4.85) (envelope-from <[hidden email]>)
>    id 1fYfne-0002Tc-Fv
>    for [hidden email]; Fri, 29 Jun 2018 00:54:02 +0200
> Received: from [192.168.0.1] (50-1-85-235.dsl.dynamic.fusionbroadband.com
>    [50.1.85.235]) (authenticated bits=0)
>    by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id w5SMruW6005477
>    (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT)
>    for <[hidden email]>; Thu, 28 Jun 2018 15:53:57 -0700
> Subject: Re: Examples of encryption for database access
> To: Brian Milby via use-livecode <[hidden email]>
> References: <[hidden email]>
>    <[hidden email]>
>    <[hidden email]>
>    <[hidden email]>
>    <[hidden email]>
>    <[hidden email]>
>    <[hidden email]>
>    <[hidden email]>
>    <[hidden email]>
>    <f9a11613-1c50-48a8-9106-0c779e0aa607@Spark>
>    <[hidden email]>
>    <[hidden email]>
>    <[hidden email]>
>    <[hidden email]>
>    <b1c23eff-7f5d-4028-abfd-bf912ded88fa@Spark>
> Message-ID: <[hidden email]>
> Date: Thu, 28 Jun 2018 15:53:47 -0700
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
>    Thunderbird/52.8.0
> MIME-Version: 1.0
> In-Reply-To: <b1c23eff-7f5d-4028-abfd-bf912ded88fa@Spark>
> Content-Language: en-US
> X-Sonic-CAuth: UmFuZG9tSVYV61H8iJnDK8B78GdZlYqOiytilmPik8b3rpWaN3EnRBEaGwmBl44wO/6mwKUeRD6UgYKrQpGb7glziXUhBLNd
> X-Sonic-ID: C;bmxTIyZ76BGfs641UvMdPQ== M;TH6LIyZ76BGfs641UvMdPQ==
> X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
> X-BeenThere: [hidden email]
> X-Mailman-Version: 2.1.20
> Precedence: list
> List-Id: How to use LiveCode <use-livecode.lists.runrev.com>
> List-Unsubscribe: <http://lists.runrev.com/mailman/options/use-livecode>,
>    <mailto:[hidden email]?subject=unsubscribe>
> List-Archive: <http://lists.runrev.com/pipermail/use-livecode/>
> List-Post: <mailto:[hidden email]>
> List-Help: <mailto:[hidden email]?subject=help>
> List-Subscribe: <http://lists.runrev.com/mailman/listinfo/use-livecode>,
>    <mailto:[hidden email]?subject=subscribe>
> From: Mark Wieder via use-livecode <[hidden email]>
> Reply-To: How to use LiveCode <[hidden email]>
> Cc: Mark Wieder <[hidden email]>
> Content-Transfer-Encoding: 7bit
> Content-Type: text/plain; charset="us-ascii"; Format="flowed"
> Errors-To: [hidden email]
> Sender: "use-livecode" <[hidden email]>
> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
> X-AntiAbuse: Primary Hostname - meg.on-rev.com
> X-AntiAbuse: Original Domain - earthlearningsolutions.org
> X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
> X-AntiAbuse: Sender Address Domain - lists.runrev.com
> X-Get-Message-Sender-Via: meg.on-rev.com: acl_c_authenticated_local_user: mailman/mailman
>
>> On 06/28/2018 01:49 PM, Brian Milby via use-livecode wrote:
>> Random IV means that an attacker can not generate a dictionary in advance. Knowing it at the same time is not an issue since they cypher is not cracked. The other reason is that the IV seeds the AES encryption so that the first block does not give anything away. If the first encrypted block for the same data is always the same, the attacker can use that to test guesses if they can control what is being encrypted. Same issue if they can predict the IV. See the Wikipedia entry I linked to for a better discussion.
>
> Encryption with an initialization vector isn't a reversible operation. It's not like XORing a value with another. Being able to *predict* an iv value, however, as opposed to just knowing the current value, is a security problem.
>
>> IV is fixed at the block size of the cipher. So for AES it is 16 bytes.
>
> Yes, I stand corrected. Silly me assumed that aes-256 would use a larger block size. AES uses only 128-bit blocks with different key sizes.
>
> --
> Mark Wieder
> [hidden email]
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>> On 06/28/2018 01:49 PM, Brian Milby via use-livecode wrote:
>> Random IV means that an attacker can not generate a dictionary in advance. Knowing it at the same time is not an issue since they cypher is not cracked. The other reason is that the IV seeds the AES encryption so that the first block does not give anything away. If the first encrypted block for the same data is always the same, the attacker can use that to test guesses if they can control what is being encrypted. Same issue if they can predict the IV. See the Wikipedia entry I linked to for a better discussion.
>
> Encryption with an initialization vector isn't a reversible operation. It's not like XORing a value with another. Being able to *predict* an iv value, however, as opposed to just knowing the current value, is a security problem.
>
>> IV is fixed at the block size of the cipher. So for AES it is 16 bytes.
>
> Yes, I stand corrected. Silly me assumed that aes-256 would use a larger block size. AES uses only 128-bit blocks with different key sizes.
>
> --
> Mark Wieder
> [hidden email]
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
12