Examples of encryption for database access

William Prothero waprothero at gmail.com
Thu Jun 28 12:17:01 EDT 2018

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.


> On Jun 26, 2018, at 2:37 PM, Mark Wieder via use-livecode <use-livecode at lists.runrev.com> 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
> ahsoftware at gmail.com
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

More information about the Use-livecode mailing list