Re: Examples of encryption for database access

[prothero--- via use-livecode]

Thanks, Brian,
Actually, I think I know how to do it now, with iv sent along with the data. 
I’ll post what I come up with.

Thanks so much for your input.
Bill

William Prothero
http://earthlearningsolutions.org

> On Jun 28, 2018, at 7:38 PM, Brian Milby  wrote:
> 
> I can write an LC example, but not sure how quickly I could do the equivalent 
> in PHP. Some of the Mark Smith code can be used for inspiration. I’ll put 
> something on GitHub and post a link here.
> 
> If the server doesn’t need access to the contents, then storing the data 
> encrypted does reduce the location of the key by one. Depending on how 
> paranoid you want to get, you can add all kinds of layers.
> 
> Here is another good answer on secrecy of the IV:
> https://crypto.stackexchange.com/questions/8592/iv-security-clarification
> 
> Not sure how much would be gained using a different key for each direction - 
> both keys would be needed in both places anyway. The random IV ensures each 
> cipher text is unique even if the plain text is the same.
> 
> Transmitting the IV is not a security risk assuming that they are random 
> (which they should be).
>> On Jun 28, 2018, 7:40 PM -0400, proth...@earthlearningsolutions.org , wrote:
>> Brianand Mark
>> Tnx so much for your patience.
>> 
>> What I get so far, where I am sending data to a php script that stores the 
>> data in a mysql db, is that the key and iv vector cannot be sent along with 
>> the encrypted data, because those values make it easier to hack the 
>> encrypted text. As Mark suggests, I can store the iv and key in the 
>> .htaccess file.
>> 
>> Reading stackoverflow and other various googled links, I get even more 
>> confused by the postings, then the corrective comments, then corrections of 
>> the corrections. So, is there a “best practices” source that I can trust 
>> fully? If not, I’m going to go with the above.
>> 
>> Another suggestion was to use a different key and iv for the return message. 
>> Also one source said the db should store the encrypted data, not the 
>> decrypted data. It never ends. For my use I’m ok with what I already know, 
>> but it would really be nice to have the best known useage.
>> 
>> In general, i’m paranoid about security. It oughta be easier.
>> 
>> Best,
>> Bill
>> 
>> William Prothero
>> http://ed.earthednet.org
>> 
>>> On Jun 28, 2018, at 4:02 PM, Brian Milby  wrote:
>>> 
>>> See the second example on the Wikipedia page in the properties section. It 
>>> talks about how a predictable IV can be an issue.
 On Jun 28, 2018, 6:43 PM -0400, proth...@earthlearningsolutions.org 
 , wrote:
 Brian,
 If the iv is appended to the encrypted data, the the hacker will have it.
 
 Your message says “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. “
 
 Now I’m a bit confused. Plse clarify??
 
 Best,
 Bill
 
 William Prothero
 http://earthlearningsolutions.org
 
> On Jun 28, 2018, at 1:49 PM, Brian Milby  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.
> 
> 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 

Re: Examples of encryption for database access

[prothero--- 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 
>  wrote:
> 
> Return-Path: 
> Delivered-To: proth...@earthlearningsolutions.org
> Received: from ssd.earthlearningsolutions.org
>by ssd.earthlearningsolutions.org with LMTP id iK5OBz9nNVvKBQgAqWmBzQ
>for ; Thu, 28 Jun 2018 22:54:55 +
> Return-path: 
> Envelope-to: proth...@earthlearningsolutions.org
> Delivery-date: Thu, 28 Jun 2018 22:54:55 +
> 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 )
>id 1fYfoU-002Cli-VR
>for proth...@earthlearningsolutions.org; Thu, 28 Jun 2018 22:54:55 +
> 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 )
>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 )
>id 1fYfne-0002Tc-Fv
>for use-livecode@lists.runrev.com; 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 ; Thu, 28 Jun 2018 15:53:57 -0700
> Subject: Re: Examples of encryption for database access
> To: Brian Milby via use-livecode 
> References: 
> 
><9f0c3b88-0189-4e92-8d43-c1b344d0f...@major-k.de>
>
> 
><677a939f-b639-4097-a466-70ba02221...@gmail.com>
><9fd89e75-5162-1468-e67e-3e0a28302...@sonic.net>
><9c9c7f4b-b2c7-42da-90ab-0926db177...@gmail.com>
>
>
>
>
><4efe880c-d188-400b-31d9-564a0540a...@sonic.net>
>
><1bcf1dcd-f1ab-7bfd-8404-7df1c1b9c...@sonic.net>
><05ec683c-5dd8-44ef-8352-6e052f1d3...@earthlearningsolutions.org>
>
> Message-ID: <281c22d4-20f8-88a3-c2bd-4a7aa85f3...@sonic.net>
> 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: 
> 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: use-livecode@lists.runrev.com
> X-Mailman-Version: 2.1.20
> Precedence: list
> List-Id: How to use LiveCode 
> List-Unsubscribe: ,
>
> List-Archive: 
> List-Post: 
> List-Help: 
> List-Subscribe: ,
>
> From: Mark Wieder via use-livecode 
> Reply-To: How to use LiveCode 
> Cc: Mark Wieder 
> Content-Transfer-Encoding: 7bit
> Content-Type: text/plain; charset="us-ascii"; Format="flowed"
> Errors-To: use-livecode-boun...@lists.runrev.com
> Sender: "use-livecode" 
> 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, 
> 

Re: tsNet issues

[Charles Warwick via use-livecode]

Hi Richard,

What version of LC are you using?

If I run the following code in LC 9.0.0, I get an answer dialog indicating a 
404 error was returned:

on mouseUp
   get URL “https://downloads.techstrategies.com.au/blah”
   if the result is not empty then
  answer the result
   end if
end mouseUp

Cheers,

Charles

> On 29 Jun 2018, at 5:29 am, Richard Gaskin via use-livecode 
>  wrote:
> 
> 1. When attempting to get a URL that should return 404, "the result" is 
> empty.  Is this a known issue, or should I file a new report?
> 
> 2. I don't need tsNet for what I'm working on at the moment - how do I turn 
> it off?
> 
> This older recommendation no longer seems to do the trick:
> 
>   dispatch "revUnloadLibrary" to stack "tsNetLibURL"
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://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

Re: Examples of encryption for database access

[Mark Wieder 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
 ahsoftw...@gmail.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: What exactly does the status pending in Livecode Quality Control Center mean

[panagiotis merakos via use-livecode]

Hi all,

This problem happened because some on-rev servers (Jasmine, Sage and
Diesel) had only the 64 bit version of this library, while others (e.g.
Tio) had both the 32 and 64 bit version.

Robin has identified and fixed the problem, so the 32bit version of LC
Server 9 now does work on all on-rev servers.

Best,
Panos
--

On Wed, Jun 27, 2018 at 12:15 PM, panagiotis merakos 
wrote:

> @Ralf,
>
> I see the same error when trying to install LC 9 32 bit on Sage.
>
> However the exact same setup is successful on Tio.
>
> So I guess some of the on-rev servers do have this library, while others
> don't. I will ask Robin about this.
>
> Best,
> Panos
> --
>
> On Wed, Jun 27, 2018 at 12:08 PM, Ralf Bitter via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> Hi Matthias,
>>
>> > On 26. Jun 2018, at 23:57, Matthias Rebbe via use-livecode <
>> use-livecode@lists.runrev.com> wrote:
>> >
>> > Hm, On-Rev support told me that  GLIBC 2.1.4 is needed to run Livecode
>> Server 9 64bit on On-Rev. The 32bit version is working on On-Rev with the
>> older one.
>> > They did not mention that this library is also needed to get the 32bit
>> tsNET external  running with Livecode server 32 bit on On-Rev.
>>
>>
>>
>> even my 32 bit LC 9 version installation fails on Diesel, at least
>> the business flavour fails with error:
>> “error while loading shared libraries: libfontconfig.so.1: cannot open
>> shared object file: No such file or directory”
>>
>>
>> Ralf
>> ___
>> 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

Array Column Subset Revisited

[Bob Sneidar via use-livecode]

Hi all. 

We know we can set the customKeys of an object, which will delete any elements 
of the custom properties not in the list we set it to. Wouldn't it be great if 
you do the same with the keys of an array? Currently, the keys of an array are 
read only. If they were settable, you could effectively get just the column(s) 
of an array (like the dgData of a datagrid) without having to iterate through 
every array element. 

It may be nitpicking though, if the time savings are negligible. 

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: tsNet issues

[panagiotis merakos via use-livecode]

Hi Richard,

RE 2, this is a bug that will be fixed in 9.0.1 rc1. You can apply locally
the changes described here until we release 9.0.1 rc1:
https://github.com/livecode/livecode/pull/6567

Best,
Panos


On Thu, Jun 28, 2018, 21:08 Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> 1. When attempting to get a URL that should return 404, "the result" is
> empty.  Is this a known issue, or should I file a new report?
>
> 2. I don't need tsNet for what I'm working on at the moment - how do I
> turn it off?
>
> This older recommendation no longer seems to do the trick:
>
> dispatch "revUnloadLibrary" to stack "tsNetLibURL"
>
> --
>   Richard Gaskin
>   Fourth World Systems
>   Software Design and Development for the Desktop, Mobile, and the Web
>   
>   ambassa...@fourthworld.comhttp://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

Re: Examples of encryption for database access

[Brian Milby 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 
> >  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
> > ahsoftw...@gmail.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: Examples of encryption for database access

[prothero--- 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 
>  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
> ahsoftw...@gmail.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

tsNet issues

[Richard Gaskin via use-livecode]

1. When attempting to get a URL that should return 404, "the result" is 
empty.  Is this a known issue, or should I file a new report?


2. I don't need tsNet for what I'm working on at the moment - how do I 
turn it off?


This older recommendation no longer seems to do the trick:

   dispatch "revUnloadLibrary" to stack "tsNetLibURL"

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://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

Re: Examples of encryption for database access

[Kee Nethery via use-livecode]

On Jun 28, 2018, at 9:17 AM, William Prothero via use-livecode 
 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
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: Examples of encryption for database access

[Mark Wieder 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
 ahsoftw...@gmail.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: Examples of encryption for database access

[William Prothero 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 
>  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
> ahsoftw...@gmail.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