MySQL Encryption

In terms of encryption functions AES_DECRYPT and AES_ENCRYPT, can anyone
point to any good links or offer any suggestions in terms of best
practices on storage of the associated symmetric key? I've found very
little information on this when searching.

Does MySQL offer any asymmetric encryption capabilities?

What are people using in terms of a good solution for encrypting
specific columns of table data while providing protection of the key?

Thanks,
Jim

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org

Re: MySQL Encryption

--0016e6db24d10c8f30048224f7f5
Content-Type: text/plain; charset=ISO-8859-1

Jim,

I tend to derive a key based on a separate character string and the contents
of the data in the same or a related table. This means each row has a unique
encryption key and you never have to have the whole key stored somewhere
(you don't even know it :p ). Biggest advantage to this is should someone
get hold of your data they have to work out your character string and the
logic for deriving the key or attempt to hack each and every individual row
of the table because no two rows will ever have the same key.

For example, in a table with the columns `username`, `email_address`,
`password`, `jointime` (where password is encrypted with AES_ENCRYPT) I may
Use a charcter string of "awfully_complex_char_string-" and derive the key
like so

CONCAT("awfully_complex_char_string-",SUBSTRING(`email_addre ss`,1,LOCATE("@",`email_address`)-1),CAST(`jointime`
AS CHAR))

I then store the logic in a database stored procedure and use database
security to prevent unauthorised access. At no point do I have this logic
outside the database in any external application or script! That would be
silly :)

Regards

John Daisley

On Thu, Mar 18, 2010 at 7:26 PM, Jim wrote:

> In terms of encryption functions AES_DECRYPT and AES_ENCRYPT, can anyone
> point to any good links or offer any suggestions in terms of best practices
> on storage of the associated symmetric key? I've found very little
> information on this when searching.
>
> Does MySQL offer any asymmetric encryption capabilities?
>
> What are people using in terms of a good solution for encrypting specific
> columns of table data while providing protection of the key?
>
> Thanks,
> Jim
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe:
> http://lists.mysql.com/mysql?unsub=john.daisley@butterflysys tems.co.uk
>
>

--0016e6db24d10c8f30048224f7f5--

Re: MySQL Encryption

Thanks for the reply, John.

What you are describing seems to be the approach I've seen on the few
places I've seen this topic discussed.

I've been considering something along those lines, essentially a two
part key.

Part one of the key is made from some data that is in the record I want
to protect and it is different for each record, very much like you suggest.

Part two of the key is some constant key value I store somewhere.

The full key is created based on some defined manipulation of the two
parts, much like you suggest I believe.

But, then the issue comes of where to store part two of the key.

In your case, you are storing it in a stored procedure and I assume that
stored procedure resides on the same mysql server that holds the data
you want to protect.

That's where I start questioning the security of that approach. The
assumption being if someone got full control of that mysql box then
essentially all your eggs are in one basket.

I was thinking in terms of a most secure solution, you could have a
separate server (perhaps a mysql server) that for the purpose of this
example only serves part two of the key. That server is well protected
and non-public as is the mysql server that stores the data.

This way, two servers have to be compromised in order to gain all the
parts of the key and data. But, of course, that's kind of a waste of a
server and can you afford that and the extra resources that go along
with maintaining another server.

So, I was thinking, is it really so bad to store only one part of the
key in source code. That source code resides on a separate server from
the mysql server. Yes, the server that stores the source code is a
public server, but at least it's two servers that have to be compromised
to give up all the components needed to gain access to the encrypted data.

I suppose maybe if I ask you to expand on what you mean by the following
that would be helpful to further understand your approach:
"I then store the logic in a database stored procedure and use database
security to prevent unauthorised access".

Thanks,
Jim


On 3/19/2010 6:39 AM, John Daisley wrote:
> Jim,
>
> I tend to derive a key based on a separate character string and the
> contents of the data in the same or a related table. This means each row
> has a unique encryption key and you never have to have the whole key
> stored somewhere (you don't even know it :p ). Biggest advantage to this
> is should someone get hold of your data they have to work out your
> character string and the logic for deriving the key or attempt to hack
> each and every individual row of the table because no two rows will ever
> have the same key.
>
> For example, in a table with the columns `username`, `email_address`,
> `password`, `jointime` (where password is encrypted with AES_ENCRYPT) I
> may Use a charcter string of "awfully_complex_char_string-" and derive
> the key like so
>
> CONCAT("awfully_complex_char_string-",SUBSTRING(`email_addre ss`,1,LOCATE("@",`email_address`)-1),CAST(`jointime`
> AS CHAR))
>
> I then store the logic in a database stored procedure and use database
> security to prevent unauthorised access. At no point do I have this
> logic outside the database in any external application or script! That
> would be silly :)
>
> Regards
>
> John Daisley
>
> On Thu, Mar 18, 2010 at 7:26 PM, Jim > > wrote:
>
> In terms of encryption functions AES_DECRYPT and AES_ENCRYPT, can
> anyone point to any good links or offer any suggestions in terms of
> best practices on storage of the associated symmetric key? I've
> found very little information on this when searching.
>
> Does MySQL offer any asymmetric encryption capabilities?
>
> What are people using in terms of a good solution for encrypting
> specific columns of table data while providing protection of the key?
>
> Thanks,
> Jim
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe:
> http://lists.mysql.com/mysql?unsub=john.daisley@butterflysys tems.co.uk
>
>


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org

Re: MySQL Encryption

--001517475c8ae89280048241e032
Content-Type: text/plain; charset=ISO-8859-1

Hi

What sort of information are you looking to encrypt ? If it is for user
passwords I'd recommend SHA256 which is one way encryption. Or are you
looking to encrypt more sensitive information like card holder data ?

Regards
Neil

On Fri, Mar 19, 2010 at 4:22 PM, Jim wrote:

> Thanks for the reply, John.
>
> What you are describing seems to be the approach I've seen on the few
> places I've seen this topic discussed.
>
> I've been considering something along those lines, essentially a two part
> key.
>
> Part one of the key is made from some data that is in the record I want to
> protect and it is different for each record, very much like you suggest.
>
> Part two of the key is some constant key value I store somewhere.
>
> The full key is created based on some defined manipulation of the two
> parts, much like you suggest I believe.
>
> But, then the issue comes of where to store part two of the key.
>
> In your case, you are storing it in a stored procedure and I assume that
> stored procedure resides on the same mysql server that holds the data you
> want to protect.
>
> That's where I start questioning the security of that approach. The
> assumption being if someone got full control of that mysql box then
> essentially all your eggs are in one basket.
>
> I was thinking in terms of a most secure solution, you could have a
> separate server (perhaps a mysql server) that for the purpose of this
> example only serves part two of the key. That server is well protected and
> non-public as is the mysql server that stores the data.
>
> This way, two servers have to be compromised in order to gain all the parts
> of the key and data. But, of course, that's kind of a waste of a server and
> can you afford that and the extra resources that go along with maintaining
> another server.
>
> So, I was thinking, is it really so bad to store only one part of the key
> in source code. That source code resides on a separate server from the mysql
> server. Yes, the server that stores the source code is a public server, but
> at least it's two servers that have to be compromised to give up all the
> components needed to gain access to the encrypted data.
>
> I suppose maybe if I ask you to expand on what you mean by the following
> that would be helpful to further understand your approach:
>
> "I then store the logic in a database stored procedure and use database
> security to prevent unauthorised access".
>
> Thanks,
> Jim
>
>
>
> On 3/19/2010 6:39 AM, John Daisley wrote:
>
>> Jim,
>>
>> I tend to derive a key based on a separate character string and the
>> contents of the data in the same or a related table. This means each row
>> has a unique encryption key and you never have to have the whole key
>> stored somewhere (you don't even know it :p ). Biggest advantage to this
>> is should someone get hold of your data they have to work out your
>> character string and the logic for deriving the key or attempt to hack
>> each and every individual row of the table because no two rows will ever
>> have the same key.
>>
>> For example, in a table with the columns `username`, `email_address`,
>> `password`, `jointime` (where password is encrypted with AES_ENCRYPT) I
>> may Use a charcter string of "awfully_complex_char_string-" and derive
>> the key like so
>>
>>
>> CONCAT("awfully_complex_char_string-",SUBSTRING(`email_addre ss`,1,LOCATE("@",`email_address`)-1),CAST(`jointime`
>> AS CHAR))
>>
>> I then store the logic in a database stored procedure and use database
>> security to prevent unauthorised access. At no point do I have this
>> logic outside the database in any external application or script! That
>> would be silly :)
>>
>> Regards
>>
>> John Daisley
>>
>> On Thu, Mar 18, 2010 at 7:26 PM, Jim >> > wrote:
>>
>> In terms of encryption functions AES_DECRYPT and AES_ENCRYPT, can
>> anyone point to any good links or offer any suggestions in terms of
>> best practices on storage of the associated symmetric key? I've
>> found very little information on this when searching.
>>
>> Does MySQL offer any asymmetric encryption capabilities?
>>
>> What are people using in terms of a good solution for encrypting
>> specific columns of table data while providing protection of the key?
>>
>> Thanks,
>> Jim
>>
>> --
>> MySQL General Mailing List
>> For list archives: http://lists.mysql.com/mysql
>> To unsubscribe:
>> http://lists.mysql.com/mysql?unsub=john.daisley@butterflysys tems.co.uk
>>
>>
>>
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe:
> http://lists.mysql.com/mysql?unsub=neil.tompkins@googlemail. com
>
>

--001517475c8ae89280048241e032--

Re: MySQL Encryption

Hi Neil.

Information (in most cases a string < 100 chars, but that's probably not
important) that actually needs to be decrypted, so a hash won't do.

Jim

On 3/20/2010 5:09 PM, Tompkins Neil wrote:
> Hi
>
> What sort of information are you looking to encrypt ? If it is for user
> passwords I'd recommend SHA256 which is one way encryption. Or are you
> looking to encrypt more sensitive information like card holder data ?
>
> Regards
> Neil
>
> On Fri, Mar 19, 2010 at 4:22 PM, Jim > > wrote:
>
> Thanks for the reply, John.
>
> What you are describing seems to be the approach I've seen on the
> few places I've seen this topic discussed.
>
> I've been considering something along those lines, essentially a two
> part key.
>
> Part one of the key is made from some data that is in the record I
> want to protect and it is different for each record, very much like
> you suggest.
>
> Part two of the key is some constant key value I store somewhere.
>
> The full key is created based on some defined manipulation of the
> two parts, much like you suggest I believe.
>
> But, then the issue comes of where to store part two of the key.
>
> In your case, you are storing it in a stored procedure and I assume
> that stored procedure resides on the same mysql server that holds
> the data you want to protect.
>
> That's where I start questioning the security of that approach. The
> assumption being if someone got full control of that mysql box then
> essentially all your eggs are in one basket.
>
> I was thinking in terms of a most secure solution, you could have a
> separate server (perhaps a mysql server) that for the purpose of
> this example only serves part two of the key. That server is well
> protected and non-public as is the mysql server that stores the data.
>
> This way, two servers have to be compromised in order to gain all
> the parts of the key and data. But, of course, that's kind of a
> waste of a server and can you afford that and the extra resources
> that go along with maintaining another server.
>
> So, I was thinking, is it really so bad to store only one part of
> the key in source code. That source code resides on a separate
> server from the mysql server. Yes, the server that stores the source
> code is a public server, but at least it's two servers that have to
> be compromised to give up all the components needed to gain access
> to the encrypted data.
>
> I suppose maybe if I ask you to expand on what you mean by the
> following that would be helpful to further understand your approach:
>
> "I then store the logic in a database stored procedure and use
> database security to prevent unauthorised access".
>
> Thanks,
> Jim
>
>
>
> On 3/19/2010 6:39 AM, John Daisley wrote:
>
> Jim,
>
> I tend to derive a key based on a separate character string and the
> contents of the data in the same or a related table. This means
> each row
> has a unique encryption key and you never have to have the whole key
> stored somewhere (you don't even know it :p ). Biggest advantage
> to this
> is should someone get hold of your data they have to work out your
> character string and the logic for deriving the key or attempt
> to hack
> each and every individual row of the table because no two rows
> will ever
> have the same key.
>
> For example, in a table with the columns `username`,
> `email_address`,
> `password`, `jointime` (where password is encrypted with
> AES_ENCRYPT) I
> may Use a charcter string of "awfully_complex_char_string-" and
> derive
> the key like so
>
> CONCAT("awfully_complex_char_string-",SUBSTRING(`email_addre ss`,1,LOCATE("@",`email_address`)-1),CAST(`jointime`
> AS CHAR))
>
> I then store the logic in a database stored procedure and use
> database
> security to prevent unauthorised access. At no point do I have this
> logic outside the database in any external application or
> script! That
> would be silly :)
>
> Regards
>
> John Daisley
>
> On Thu, Mar 18, 2010 at 7:26 PM, Jim >
> >>
> wrote:
>
> In terms of encryption functions AES_DECRYPT and
> AES_ENCRYPT, can
> anyone point to any good links or offer any suggestions in
> terms of
> best practices on storage of the associated symmetric key? I've
> found very little information on this when searching.
>
> Does MySQL offer any asymmetric encryption capabilities?
>
> What are people using in terms of a good solution for encrypting
> specific columns of table data while providing protection of
> the key?
>
> Thanks,
> Jim
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe:
> http://lists.mysql.com/mysql?unsub=john.daisley@butterflysys tems.co.uk
>
>
>
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe:
> http://lists.mysql.com/mysql?unsub=neil.tompkins@googlemail. com
>
>


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org

RE: MySQL Encryption

Jim

In the case of our encrypted data no user, application or script is given a=
ccess to the tables in question. Access is only granted via a couple of sto=
red procedures and to be honest if you didn't know which ones you would hav=
e a hard job finding them as we have hundreds.

Problem with keeping any part of the key in a place other than the mysql se=
rver is you add complexity and give yourself a whole bunch of new security =
concerns as you then have to transmit the 'key part' to the mysql server ov=
er a network.

For someone to take complete control of our mysql server and compromise our=
data they would need to guess a username and password for the box in under=
3 attempts, then guess the root password and then guess a valid mysql user=
name and password.

The biggest headache for us, and one which is often overlooked is 'How do w=
e keep our backups secure'



-----Original Message-----
From: Jim
Sent: Friday, March 19, 2010 4:22 PM
To: John Daisley ; mysql@lists.mysql.com
Subject: Re: MySQL Encryption

Thanks for the reply, John.

What you are describing seems to be the approach I've seen on the few=20
places I've seen this topic discussed.

I've been considering something along those lines, essentially a two=20
part key.

Part one of the key is made from some data that is in the record I want=20
to protect and it is different for each record, very much like you suggest.

Part two of the key is some constant key value I store somewhere.

The full key is created based on some defined manipulation of the two=20
parts, much like you suggest I believe.

But, then the issue comes of where to store part two of the key.

In your case, you are storing it in a stored procedure and I assume that=20
stored procedure resides on the same mysql server that holds the data=20
you want to protect.

That's where I start questioning the security of that approach. The=20
assumption being if someone got full control of that mysql box then=20
essentially all your eggs are in one basket.

I was thinking in terms of a most secure solution, you could have a=20
separate server (perhaps a mysql server) that for the purpose of this=20
example only serves part two of the key. That server is well protected=20
and non-public as is the mysql server that stores the data.

This way, two servers have to be compromised in order to gain all the=20
parts of the key and data. But, of course, that's kind of a waste of a=20
server and can you afford that and the extra resources that go along=20
with maintaining another server.

So, I was thinking, is it really so bad to store only one part of the=20
key in source code. That source code resides on a separate server from=20
the mysql server. Yes, the server that stores the source code is a=20
public server, but at least it's two servers that have to be compromised=20
to give up all the components needed to gain access to the encrypted data.

I suppose maybe if I ask you to expand on what you mean by the following=20
that would be helpful to further understand your approach:
"I then store the logic in a database stored procedure and use database=20
security to prevent unauthorised access".

Thanks,
Jim


On 3/19/2010 6:39 AM, John Daisley wrote:
> Jim,
>
> I tend to derive a key based on a separate character string and the
> contents of the data in the same or a related table. This means each row
> has a unique encryption key and you never have to have the whole key
> stored somewhere (you don't even know it :p ). Biggest advantage to this
> is should someone get hold of your data they have to work out your
> character string and the logic for deriving the key or attempt to hack
> each and every individual row of the table because no two rows will ever
> have the same key.
>
> For example, in a table with the columns `username`, `email_address`,
> `password`, `jointime` (where password is encrypted with AES_ENCRYPT) I
> may Use a charcter string of "awfully_complex_char_string-" and derive
> the key like so
>
> CONCAT("awfully_complex_char_string-",SUBSTRING(`email_addre ss`,1,LOCATE(=
"@",`email_address`)-1),CAST(`jointime`
> AS CHAR))
>
> I then store the logic in a database stored procedure and use database
> security to prevent unauthorised access. At no point do I have this
> logic outside the database in any external application or script! That
> would be silly :)
>
> Regards
>
> John Daisley
>
> On Thu, Mar 18, 2010 at 7:26 PM, Jim > > wrote:
>
> In terms of encryption functions AES_DECRYPT and AES_ENCRYPT, can
> anyone point to any good links or offer any suggestions in terms of
> best practices on storage of the associated symmetric key? I've
> found very little information on this when searching.
>
> Does MySQL offer any asymmetric encryption capabilities?
>
> What are people using in terms of a good solution for encrypting
> specific columns of table data while providing protection of the key?
>
> Thanks,
> Jim
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe:
> http://lists.mysql.com/mysql?unsub=3Djohn.daisley@butterflys ystems.co=
..uk
>
>



--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=3Dgcdmg-mysql-2@m.gmane.o rg

RE: MySQL Encryption

At 05:54 PM 3/20/2010, John Daisley wrote:
>Jim
>
>In the case of our encrypted data no user, application or script is given
>access to the tables in question. Access is only granted via a couple of
>stored procedures and to be honest if you didn't know which ones you would
>have a hard job finding them as we have hundreds.
>
>Problem with keeping any part of the key in a place other than the mysql
>server is you add complexity and give yourself a whole bunch of new
>security concerns as you then have to transmit the 'key part' to the mysql
>server over a network.
>
>For someone to take complete control of our mysql server and compromise
>our data they would need to guess a username and password for the box in
>under 3 attempts, then guess the root password and then guess a valid
>mysql username and password.
>
>The biggest headache for us, and one which is often overlooked is 'How do
>we keep our backups secure'

Or they can find your drive in the local swap shop after the ISP retires
your drive for a new one. Or if you are doing your own hosting, the local
bne artist will do a smash and grab if they find out you have computers in
your office. It happens all the time over here, even government offices
aren't immune. Of course if your competitors want your information bad
enough, they'll bribe one of the support staff to make an extra backup, or
your competitor will hire people to recover your drive. Corporate and
intra-country espionage is growing rapidly and is largely unreported by the
ISP and the companies that were hit.

There are many ways your drive can grow legs and walk out of there. So
storing all of the passwords on the drive isn't secure enough, unless the
drive itself is encrypted with a password known only to a few people in
your company. Never trust the internet service provider to be your only
means to protect your data or your drives.

Mike




>-----Original Message-----
>From: Jim
>Sent: Friday, March 19, 2010 4:22 PM
>To: John Daisley ; mysql@lists.mysql.com
>Subject: Re: MySQL Encryption
>
>Thanks for the reply, John.
>
>What you are describing seems to be the approach I've seen on the few
>places I've seen this topic discussed.
>
>I've been considering something along those lines, essentially a two
>part key.
>
>Part one of the key is made from some data that is in the record I want
>to protect and it is different for each record, very much like you suggest.
>
>Part two of the key is some constant key value I store somewhere.
>
>The full key is created based on some defined manipulation of the two
>parts, much like you suggest I believe.
>
>But, then the issue comes of where to store part two of the key.
>
>In your case, you are storing it in a stored procedure and I assume that
>stored procedure resides on the same mysql server that holds the data
>you want to protect.
>
>That's where I start questioning the security of that approach. The
>assumption being if someone got full control of that mysql box then
>essentially all your eggs are in one basket.
>
>I was thinking in terms of a most secure solution, you could have a
>separate server (perhaps a mysql server) that for the purpose of this
>example only serves part two of the key. That server is well protected
>and non-public as is the mysql server that stores the data.
>
>This way, two servers have to be compromised in order to gain all the
>parts of the key and data. But, of course, that's kind of a waste of a
>server and can you afford that and the extra resources that go along
>with maintaining another server.
>
>So, I was thinking, is it really so bad to store only one part of the
>key in source code. That source code resides on a separate server from
>the mysql server. Yes, the server that stores the source code is a
>public server, but at least it's two servers that have to be compromised
>to give up all the components needed to gain access to the encrypted data.
>
>I suppose maybe if I ask you to expand on what you mean by the following
>that would be helpful to further understand your approach:
>"I then store the logic in a database stored procedure and use database
>security to prevent unauthorised access".
>
>Thanks,
>Jim
>
>
>On 3/19/2010 6:39 AM, John Daisley wrote:
> > Jim,
> >
> > I tend to derive a key based on a separate character string and the
> > contents of the data in the same or a related table. This means each row
> > has a unique encryption key and you never have to have the whole key
> > stored somewhere (you don't even know it :p ). Biggest advantage to this
> > is should someone get hold of your data they have to work out your
> > character string and the logic for deriving the key or attempt to hack
> > each and every individual row of the table because no two rows will ever
> > have the same key.
> >
> > For example, in a table with the columns `username`, `email_address`,
> > `password`, `jointime` (where password is encrypted with AES_ENCRYPT) I
> > may Use a charcter string of "awfully_complex_char_string-" and derive
> > the key like so
> >
> >
> CONCAT("awfully_complex_char_string-",SUBSTRING(`email_addre ss`,1,LOCATE("@",`email_address`)-1),CAST(`jointime`
> > AS CHAR))
> >
> > I then store the logic in a database stored procedure and use database
> > security to prevent unauthorised access. At no point do I have this
> > logic outside the database in any external application or script! That
> > would be silly :)
> >
> > Regards
> >
> > John Daisley
> >
> > On Thu, Mar 18, 2010 at 7:26 PM, Jim > > > wrote:
> >
> > In terms of encryption functions AES_DECRYPT and AES_ENCRYPT, can
> > anyone point to any good links or offer any suggestions in terms of
> > best practices on storage of the associated symmetric key? I've
> > found very little information on this when searching.
> >
> > Does MySQL offer any asymmetric encryption capabilities?
> >
> > What are people using in terms of a good solution for encrypting
> > specific columns of table data while providing protection of the key?
> >
> > Thanks,
> > Jim
> >
> > --
> > MySQL General Mailing List
> > For list archives: http://lists.mysql.com/mysql
> > To unsubscribe:
> > http://lists.mysql.com/mysql?unsub=john.daisley@butterflysys tems.co.uk
> >
> >
>
>
>
>--
>MySQL General Mailing List
>For list archives: http://lists.mysql.com/mysql
>To unsubscribe: http://lists.mysql.com/mysql?unsub=mos99@fastmail.fm


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org

RE: MySQL Encryption

Mike,

Encrypted filesystems can seriously impact performance of MySQL.=20

Its an entirely different issue to MySQL encryption but one would hope that=
, if you are going to go to all the trouble of using two part keys and the =
strongest encryption available in your database, you would also take as muc=
h care of your hardware by ensuring that it is kept secure and not left in =
the hands of an untrustworthy isp, disposed of in an insecure manner or kep=
t in an insecure office.=20


John Daisley
Certified MySQL 5 DBA / Developer
Cognos BI Developer

Tel: +44 (0)1283 537111
Mobile: +44 (0)7918 621621

===================3D




-----Original Message-----
From: mos
Sent: Sunday, March 21, 2010 3:40 AM
To: mysql@lists.mysql.com
Subject: RE: MySQL Encryption

At 05:54 PM 3/20/2010, John Daisley wrote:
>Jim
>
>In the case of our encrypted data no user, application or script is given=
=20
>access to the tables in question. Access is only granted via a couple of=20
>stored procedures and to be honest if you didn't know which ones you would=
=20
>have a hard job finding them as we have hundreds.
>
>Problem with keeping any part of the key in a place other than the mysql=20
>server is you add complexity and give yourself a whole bunch of new=20
>security concerns as you then have to transmit the 'key part' to the mysql=
=20
>server over a network.
>
>For someone to take complete control of our mysql server and compromise=20
>our data they would need to guess a username and password for the box in=20
>under 3 attempts, then guess the root password and then guess a valid=20
>mysql username and password.
>
>The biggest headache for us, and one which is often overlooked is 'How do=
=20
>we keep our backups secure'

Or they can find your drive in the local swap shop after the ISP retires=20
your drive for a new one. Or if you are doing your own hosting, the local=20
bne artist will do a smash and grab if they find out you have computers in=
=20
your office. It happens all the time over here, even government offices=20
aren't immune. Of course if your competitors want your information bad=20
enough, they'll bribe one of the support staff to make an extra backup, or=
=20
your competitor will hire people to recover your drive. Corporate and=20
intra-country espionage is growing rapidly and is largely unreported by the=
=20
ISP and the companies that were hit.

There are many ways your drive can grow legs and walk out of there. So=20
storing all of the passwords on the drive isn't secure enough, unless the=20
drive itself is encrypted with a password known only to a few people in=20
your company. Never trust the internet service provider to be your only=20
means to protect your data or your drives.

Mike




>-----Original Message-----
>From: Jim
>Sent: Friday, March 19, 2010 4:22 PM
>To: John Daisley ; mysql@lists.mysql.com
>Subject: Re: MySQL Encryption
>
>Thanks for the reply, John.
>
>What you are describing seems to be the approach I've seen on the few
>places I've seen this topic discussed.
>
>I've been considering something along those lines, essentially a two
>part key.
>
>Part one of the key is made from some data that is in the record I want
>to protect and it is different for each record, very much like you suggest=

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=3Dgcdmg-mysql-2@m.gmane.o rg

RE: MySQL Encryption

At 03:21 PM 3/21/2010, John Daisley wrote:
>Mike,
>
>Encrypted filesystems can seriously impact performance of MySQL.
>
>Its an entirely different issue to MySQL encryption but one would hope
>that, if you are going to go to all the trouble of using two part keys and
>the strongest encryption available in your database, you would also take
>as much care of your hardware by ensuring that it is kept secure and not
>left in the hands of an untrustworthy isp, disposed of in an insecure
>manner or kept in an insecure office.

John,

>ensuring that it is kept secure and not left in the hands of an
>untrustworthy isp, disposed of in an insecure manner or kept in an
>insecure office

In theory that makes sense. But how you would know your ISP is trustworthy
and vigilant?

As many of you already know, the Homeland Security act revoked all
expectation of privacy for data that is stored on a 3rd party server like
an ISP. The ISP is obligated to turn over any and all data at the request
of a federal employee without need for a warrant. Refusal to comply or if
your ISP tells you or anyone else the information was released, they are
subject to a long federal prison sentence. Not too many ISP's will go up
against the fed gov't. E-Bay for instance consistently turns over their
customer data every month, not only on what items people are buying and
selling, but also what they are looking at.on E-Bay. Sprint was discovered
giving GPS data on all of their phone customers to the gov't without
telling their customers. Ouch! As a result the gov't knows exactly where
you've been every minute of the day and who you've been meeting with
(provided they also had a GPS capable cell phone) because you'll have the
same gps coordinates at the same time of day. They also know how long the
meeting took place. All this without any of the parties making a cell call
from the location. Clever.

Have you ever heard of an ISP informing their clients that their site was
hacked into by an outside source (hacker from another country or one of
your competitors) and that your data may have been compromised? Of course
not. Security breaches happens all the time and your information could be
on its way to China for all you know, and your ISP certainly isn't going
to tell you. There is no such thing as a safe machine running at an ISP. I
would definitely store part of the password off the ISP and on a machine
that I controlled.

I'm really surprised MySQL doesn't have table-wide encryption like so many
other databases do. This will prevent at least the low to medium level
hacker from accessing your data. I've used other databases with AES256 with
no noticeable reduction in speed.

In conclusion, I wouldn't store anything at an ISP that I wouldn't write on
the back of a postcard (unless it was encrypted). :-)

Mike



>-----Original Message-----
>From: mos
>Sent: Sunday, March 21, 2010 3:40 AM
>To: mysql@lists.mysql.com
>Subject: RE: MySQL Encryption
>
>At 05:54 PM 3/20/2010, John Daisley wrote:
> >Jim
> >
> >In the case of our encrypted data no user, application or script is given
> >access to the tables in question. Access is only granted via a couple of
> >stored procedures and to be honest if you didn't know which ones you would
> >have a hard job finding them as we have hundreds.
> >
> >Problem with keeping any part of the key in a place other than the mysql
> >server is you add complexity and give yourself a whole bunch of new
> >security concerns as you then have to transmit the 'key part' to the mysql
> >server over a network.
> >
> >For someone to take complete control of our mysql server and compromise
> >our data they would need to guess a username and password for the box in
> >under 3 attempts, then guess the root password and then guess a valid
> >mysql username and password.
> >
> >The biggest headache for us, and one which is often overlooked is 'How do
> >we keep our backups secure'
>
>Or they can find your drive in the local swap shop after the ISP retires
>your drive for a new one. Or if you are doing your own hosting, the local
>bne artist will do a smash and grab if they find out you have computers in
>your office. It happens all the time over here, even government offices
>aren't immune. Of course if your competitors want your information bad
>enough, they'll bribe one of the support staff to make an extra backup, or
>your competitor will hire people to recover your drive. Corporate and
>intra-country espionage is growing rapidly and is largely unreported by the
>ISP and the companies that were hit.
>
>There are many ways your drive can grow legs and walk out of there. So
>storing all of the passwords on the drive isn't secure enough, unless the
>drive itself is encrypted with a password known only to a few people in
>your company. Never trust the internet service provider to be your only
>means to protect your data or your drives.
>
>Mike
>
>
>
>
> >-----Original Message-----
> >From: Jim
> >Sent: Friday, March 19, 2010 4:22 PM
> >To: John Daisley ; mysql@lists.mysql.com
> >Subject: Re: MySQL Encryption
> >
> >Thanks for the reply, John.
> >
> >What you are describing seems to be the approach I've seen on the few
> >places I've seen this topic discussed.
> >
> >I've been considering something along those lines, essentially a two
> >part key.
> >
> >Part one of the key is made from some data that is in the record I want
> >to protect and it is different for each record, very much like you suggest


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org

Re: MySQL Encryption

--0016e6d99a7fecbda8048257f134
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Mar 21, 2010 at 9:49 PM, mos wrote:

> At 03:21 PM 3/21/2010, John Daisley wrote:
>
>> Mike,
>>
>> Encrypted filesystems can seriously impact performance of MySQL.
>>
>> Its an entirely different issue to MySQL encryption but one would hope
>> that, if you are going to go to all the trouble of using two part keys and
>> the strongest encryption available in your database, you would also take as
>> much care of your hardware by ensuring that it is kept secure and not left
>> in the hands of an untrustworthy isp, disposed of in an insecure manner or
>> kept in an insecure office.
>>
>
> John,
>
>
> ensuring that it is kept secure and not left in the hands of an
>> untrustworthy isp, disposed of in an insecure manner or kept in an insecure
>> office
>>
>
>
Jim


> In theory that makes sense. But how you would know your ISP is trustworthy
> and vigilant?
>
> Don't store data which is this sensitive on shared servers or servers where
you do not have complete control. If you must keep data like this you should
invest in the hardware needed to keep it secure.

As many of you already know, the Homeland Security act revoked all
> expectation of privacy for data that is stored on a 3rd party server like an
> ISP. The ISP is obligated to turn over any and all data at the request of a
> federal employee without need for a warrant. Refusal to comply or if your
> ISP tells you or anyone else the information was released, they are subject
> to a long federal prison sentence. Not too many ISP's will go up against
> the fed gov't. E-Bay for instance consistently turns over their customer
> data every month, not only on what items people are buying and selling, but
> also what they are looking at.on E-Bay. Sprint was discovered giving GPS
> data on all of their phone customers to the gov't without telling their
> customers. Ouch! As a result the gov't knows exactly where you've been
> every minute of the day and who you've been meeting with (provided they also
> had a GPS capable cell phone) because you'll have the same gps coordinates
> at the same time of day. They also know how long the meeting took place.
> All this without any of the parties making a cell call from the location.
> Clever.
>

These are really issues for consumers not people looking after data and
databases. This is about companies intentionally giving data out. No amount
of database encryption or hardware security is ever going to stop a company
from deciding to share its data.

>
> Have you ever heard of an ISP informing their clients that their site was
> hacked into by an outside source (hacker from another country or one of your
> competitors) and that your data may have been compromised? Of course not.
> Security breaches happens all the time and your information could be on its
> way to China for all you know, and your ISP certainly isn't going to tell
> you. There is no such thing as a safe machine running at an ISP. I would
> definitely store part of the password off the ISP and on a machine that I
> controlled.
>
> I'm really surprised MySQL doesn't have table-wide encryption like so many
> other databases do. This will prevent at least the low to medium level
> hacker from accessing your data. I've used other databases with AES256 with
> no noticeable reduction in speed.
>

You should choose an RDBMS that fits your needs. MySQL has many very good
features but if you need full database encryption then perhaps you should be
looking at using Oracle which has excellent database encryption.

>
> In conclusion, I wouldn't store anything at an ISP that I wouldn't write on
> the back of a postcard (unless it was encrypted). :-)
>

My point exactly, if you have sensitive data, invest in the technology you
need to look after that data, don't rely on someone else to look after it
for you.


> Mike
>
>
>
>
> -----Original Message-----
>> From: mos
>> Sent: Sunday, March 21, 2010 3:40 AM
>> To: mysql@lists.mysql.com
>> Subject: RE: MySQL Encryption
>>
>> At 05:54 PM 3/20/2010, John Daisley wrote:
>> >Jim
>> >
>> >In the case of our encrypted data no user, application or script is given
>> >access to the tables in question. Access is only granted via a couple of
>> >stored procedures and to be honest if you didn't know which ones you
>> would
>> >have a hard job finding them as we have hundreds.
>> >
>> >Problem with keeping any part of the key in a place other than the mysql
>> >server is you add complexity and give yourself a whole bunch of new
>> >security concerns as you then have to transmit the 'key part' to the
>> mysql
>> >server over a network.
>> >
>> >For someone to take complete control of our mysql server and compromise
>> >our data they would need to guess a username and password for the box in
>> >under 3 attempts, then guess the root password and then guess a valid
>> >mysql username and password.
>> >
>> >The biggest headache for us, and one which is often overlooked is 'How do
>> >we keep our backups secure'
>>
>> Or they can find your drive in the local swap shop after the ISP retires
>> your drive for a new one. Or if you are doing your own hosting, the local
>> bne artist will do a smash and grab if they find out you have computers in
>> your office. It happens all the time over here, even government offices
>> aren't immune. Of course if your competitors want your information bad
>> enough, they'll bribe one of the support staff to make an extra backup, or
>> your competitor will hire people to recover your drive. Corporate and
>> intra-country espionage is growing rapidly and is largely unreported by
>> the
>> ISP and the companies that were hit.
>>
>> There are many ways your drive can grow legs and walk out of there. So
>> storing all of the passwords on the drive isn't secure enough, unless the
>> drive itself is encrypted with a password known only to a few people in
>> your company. Never trust the internet service provider to be your only
>> means to protect your data or your drives.
>>
>> Mike
>>
>>
>>
>>
>> >-----Original Message-----
>> >From: Jim
>> >Sent: Friday, March 19, 2010 4:22 PM
>> >To: John Daisley ; mysql@lists.mysql.com
>> >Subject: Re: MySQL Encryption
>> >
>> >Thanks for the reply, John.
>> >
>> >What you are describing seems to be the approach I've seen on the few
>> >places I've seen this topic discussed.
>> >
>> >I've been considering something along those lines, essentially a two
>> >part key.
>> >
>> >Part one of the key is made from some data that is in the record I want
>> >to protect and it is different for each record, very much like you
>> suggest
>>
>
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe:
> http://lists.mysql.com/mysql?unsub=john.daisley@butterflysys tems.co.uk
>
>

--0016e6d99a7fecbda8048257f134--