Secure MySQL connection authentication?

Gordon Burditt ¼g¹D¡G

> >> > currently we store user/pass in a plain php file, but we want to have a
> >> > better method to protect the MySQL login authentication by hiding the
> >> > real user name & password
> >>
> >> Hiding it from whom? By putting it in a plain php file, you are hiding
> >> it from all except those who can access the php file. So who else do
> >> you wish to hide it from. The solution depends on this.
> >
> >okay, let consider it is a Perl script, running on the server, any
> >advice?
> >
> >i.e. sometimes, you even don't want the root to know the password to
> >the remote Database...
>
> If your script can know the password, so can root. If you encrypt
> the password, your script also has to have the key to decrypt it.
> If it isn't necessary to decrypt it, then it *IS* the password.
> Some people have attempted this anyway (see Pay TV vendors with
> their descrambler boxes) but they get hacked in spite of supposedly
> "tamperproof" hardware.


consider some applications like e-banking system, how they protect your
data from being modified by the `root` account?

howa wrote:
> Gordon Burditt ¼g¹D¡G
>
>
>>>>>currently we store user/pass in a plain php file, but we want to have a
>>>>>better method to protect the MySQL login authentication by hiding the
>>>>>real user name & password
>>>>
>>>>Hiding it from whom? By putting it in a plain php file, you are hiding
>>>>it from all except those who can access the php file. So who else do
>>>>you wish to hide it from. The solution depends on this.
>>>
>>>okay, let consider it is a Perl script, running on the server, any
>>>advice?
>>>
>>>i.e. sometimes, you even don't want the root to know the password to
>>>the remote Database...
>>
>>If your script can know the password, so can root. If you encrypt
>>the password, your script also has to have the key to decrypt it.
>>If it isn't necessary to decrypt it, then it *IS* the password.
>>Some people have attempted this anyway (see Pay TV vendors with
>>their descrambler boxes) but they get hacked in spite of supposedly
>>"tamperproof" hardware.
>
>
>
> consider some applications like e-banking system, how they protect your
> data from being modified by the `root` account?
>

They can't. Root can do anything.

What they do have are people they can trust, tracking and auditing. So
if something does change they can track it back.

If something can be done, there is always someone who can do it.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex-at-attglobal.net
==================

howa wrote:
> Gordon Burditt ¼g¹D¡G
>
>
>>>>>currently we store user/pass in a plain php file, but we want to have a
>>>>>better method to protect the MySQL login authentication by hiding the
>>>>>real user name & password
>>>>
>>>>Hiding it from whom? By putting it in a plain php file, you are hiding
>>>>it from all except those who can access the php file. So who else do
>>>>you wish to hide it from. The solution depends on this.
>>>
>>>okay, let consider it is a Perl script, running on the server, any
>>>advice?
>>>
>>>i.e. sometimes, you even don't want the root to know the password to
>>>the remote Database...
>>
>>If your script can know the password, so can root. If you encrypt
>>the password, your script also has to have the key to decrypt it.
>>If it isn't necessary to decrypt it, then it *IS* the password.
>>Some people have attempted this anyway (see Pay TV vendors with
>>their descrambler boxes) but they get hacked in spite of supposedly
>>"tamperproof" hardware.
>
>
>
> consider some applications like e-banking system, how they protect your
> data from being modified by the `root` account?
>

They can't. Root can do anything.

What they do have are people they can trust, tracking and auditing. So
if something does change they can track it back.

If something can be done, there is always someone who can do it.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex-at-attglobal.net
==================

howa wrote:

> Gordon Burditt ¼g¹D¡G
>
>
>>>>>currently we store user/pass in a plain php file, but we want to have a
>>>>>better method to protect the MySQL login authentication by hiding the
>>>>>real user name & password
>>>>
>>>>Hiding it from whom? By putting it in a plain php file, you are hiding
>>>>it from all except those who can access the php file. So who else do
>>>>you wish to hide it from. The solution depends on this.
>>>
>>>okay, let consider it is a Perl script, running on the server, any
>>>advice?
>>>
>>>i.e. sometimes, you even don't want the root to know the password to
>>>the remote Database...
>>
>>If your script can know the password, so can root. If you encrypt
>>the password, your script also has to have the key to decrypt it.
>>If it isn't necessary to decrypt it, then it *IS* the password.
>>Some people have attempted this anyway (see Pay TV vendors with
>>their descrambler boxes) but they get hacked in spite of supposedly
>>"tamperproof" hardware.
>
>
>
> consider some applications like e-banking system, how they protect your
> data from being modified by the `root` account?
>

As Jerry stated, as root - you can do anything, however - root in a database and
root at the OS level *can be* two seperate ids where the OS SysAdmin does not
know the root password for the database. However, that does not completely
protect the database - as he can copy that database to his own system, modify
the password and have access to your information. Again, as Jerry stated, there
is a trust-factor.

There are 4 Admins in all shops that must have your companies implicit trust.
The Sys Admin, the DBA, the Network Admin and the SAN Admin. In smaller shops,
there may be 1 or two people that fill those functions. If you cannot trust
them, they should be terminated as soon as possible.

These 4 Admin-types have tools and methods that allow them to have complete
control over the system AND the data on those systems. Most companies such as
the one for which I work have many people in this capacity.

--
Michael Austin.
Database Consultant

howa wrote:

> Gordon Burditt ¼g¹D¡G
>
>
>>>>>currently we store user/pass in a plain php file, but we want to have a
>>>>>better method to protect the MySQL login authentication by hiding the
>>>>>real user name & password
>>>>
>>>>Hiding it from whom? By putting it in a plain php file, you are hiding
>>>>it from all except those who can access the php file. So who else do
>>>>you wish to hide it from. The solution depends on this.
>>>
>>>okay, let consider it is a Perl script, running on the server, any
>>>advice?
>>>
>>>i.e. sometimes, you even don't want the root to know the password to
>>>the remote Database...
>>
>>If your script can know the password, so can root. If you encrypt
>>the password, your script also has to have the key to decrypt it.
>>If it isn't necessary to decrypt it, then it *IS* the password.
>>Some people have attempted this anyway (see Pay TV vendors with
>>their descrambler boxes) but they get hacked in spite of supposedly
>>"tamperproof" hardware.
>
>
>
> consider some applications like e-banking system, how they protect your
> data from being modified by the `root` account?
>

As Jerry stated, as root - you can do anything, however - root in a database and
root at the OS level *can be* two seperate ids where the OS SysAdmin does not
know the root password for the database. However, that does not completely
protect the database - as he can copy that database to his own system, modify
the password and have access to your information. Again, as Jerry stated, there
is a trust-factor.

There are 4 Admins in all shops that must have your companies implicit trust.
The Sys Admin, the DBA, the Network Admin and the SAN Admin. In smaller shops,
there may be 1 or two people that fill those functions. If you cannot trust
them, they should be terminated as soon as possible.

These 4 Admin-types have tools and methods that allow them to have complete
control over the system AND the data on those systems. Most companies such as
the one for which I work have many people in this capacity.

--
Michael Austin.
Database Consultant

"howa" wrote:
> Gordon Burditt =BCg=B9D=A1G
>
>> >i.e. sometimes, you even don't want the root to know the password to
>> >the remote Database...
>>
>> If your script can know the password, so can root. If you encrypt
>> the password, your script also has to have the key to decrypt it.
>> If it isn't necessary to decrypt it, then it *IS* the password.
>> Some people have attempted this anyway (see Pay TV vendors with
>> their descrambler boxes) but they get hacked in spite of supposedly
>> "tamperproof" hardware.
>
> consider some applications like e-banking system, how they protect your
> data from being modified by the `root` account?

By encrypting the data and *NOT* storing the key on the computer. Then
all root can get is encrypted data. But all depends on how "secure"
things need to be. Perfect security is an illusion. The best you can
get is sufficient security. This is when the costs for a successful
attack are higher than the value of the protected good.

The traditional use-more-than-once password is already a compromise,
sacrificing security for simplicity. A password entered on the keyboard
should be considered exposed (keyloggers exist, even in pure software)
and must never be re-used. If this is a viable attack vector you need
external hardware like key tokens or smartcard terminals.


XL
--
Axel Schwenke, Senior Software Developer, MySQL AB

Online User Manual: http://dev.mysql.com/doc/refman/5.0/en/
MySQL User Forums: http://forums.mysql.com/

"howa" wrote:
> Gordon Burditt =BCg=B9D=A1G
>
>> >i.e. sometimes, you even don't want the root to know the password to
>> >the remote Database...
>>
>> If your script can know the password, so can root. If you encrypt
>> the password, your script also has to have the key to decrypt it.
>> If it isn't necessary to decrypt it, then it *IS* the password.
>> Some people have attempted this anyway (see Pay TV vendors with
>> their descrambler boxes) but they get hacked in spite of supposedly
>> "tamperproof" hardware.
>
> consider some applications like e-banking system, how they protect your
> data from being modified by the `root` account?

By encrypting the data and *NOT* storing the key on the computer. Then
all root can get is encrypted data. But all depends on how "secure"
things need to be. Perfect security is an illusion. The best you can
get is sufficient security. This is when the costs for a successful
attack are higher than the value of the protected good.

The traditional use-more-than-once password is already a compromise,
sacrificing security for simplicity. A password entered on the keyboard
should be considered exposed (keyloggers exist, even in pure software)
and must never be re-used. If this is a viable attack vector you need
external hardware like key tokens or smartcard terminals.


XL
--
Axel Schwenke, Senior Software Developer, MySQL AB

Online User Manual: http://dev.mysql.com/doc/refman/5.0/en/
MySQL User Forums: http://forums.mysql.com/

Axel Schwenke wrote:
> "howa" wrote:
>
>>Gordon Burditt =BCg=B9D=A1G
>>
>>
>>>>i.e. sometimes, you even don't want the root to know the password to
>>>>the remote Database...
>>>
>>>If your script can know the password, so can root. If you encrypt
>>>the password, your script also has to have the key to decrypt it.
>>>If it isn't necessary to decrypt it, then it *IS* the password.
>>>Some people have attempted this anyway (see Pay TV vendors with
>>>their descrambler boxes) but they get hacked in spite of supposedly
>>>"tamperproof" hardware.
>>
>>consider some applications like e-banking system, how they protect your
>>data from being modified by the `root` account?
>
>
> By encrypting the data and *NOT* storing the key on the computer. Then
> all root can get is encrypted data. But all depends on how "secure"
> things need to be. Perfect security is an illusion. The best you can
> get is sufficient security. This is when the costs for a successful
> attack are higher than the value of the protected good.
>
> The traditional use-more-than-once password is already a compromise,
> sacrificing security for simplicity. A password entered on the keyboard
> should be considered exposed (keyloggers exist, even in pure software)
> and must never be re-used. If this is a viable attack vector you need
> external hardware like key tokens or smartcard terminals.
>
>
> XL
> --
> Axel Schwenke, Senior Software Developer, MySQL AB
>
> Online User Manual: http://dev.mysql.com/doc/refman/5.0/en/
> MySQL User Forums: http://forums.mysql.com/

Even encrypting the data isn't foolproof. The code (and key) to decrypt
the data must be on the server, and that can be copied. Or, the key
must be entered from a terminal. And someone with root access can
easily intercept the incoming key.

If you want absolute security, put it on your own machine that only you
can access, lock that machine in a vault and don't give anyone else the
combination.

Of course, someone could also break into the vault...

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex-at-attglobal.net
==================

Axel Schwenke wrote:
> "howa" wrote:
>
>>Gordon Burditt =BCg=B9D=A1G
>>
>>
>>>>i.e. sometimes, you even don't want the root to know the password to
>>>>the remote Database...
>>>
>>>If your script can know the password, so can root. If you encrypt
>>>the password, your script also has to have the key to decrypt it.
>>>If it isn't necessary to decrypt it, then it *IS* the password.
>>>Some people have attempted this anyway (see Pay TV vendors with
>>>their descrambler boxes) but they get hacked in spite of supposedly
>>>"tamperproof" hardware.
>>
>>consider some applications like e-banking system, how they protect your
>>data from being modified by the `root` account?
>
>
> By encrypting the data and *NOT* storing the key on the computer. Then
> all root can get is encrypted data. But all depends on how "secure"
> things need to be. Perfect security is an illusion. The best you can
> get is sufficient security. This is when the costs for a successful
> attack are higher than the value of the protected good.
>
> The traditional use-more-than-once password is already a compromise,
> sacrificing security for simplicity. A password entered on the keyboard
> should be considered exposed (keyloggers exist, even in pure software)
> and must never be re-used. If this is a viable attack vector you need
> external hardware like key tokens or smartcard terminals.
>
>
> XL
> --
> Axel Schwenke, Senior Software Developer, MySQL AB
>
> Online User Manual: http://dev.mysql.com/doc/refman/5.0/en/
> MySQL User Forums: http://forums.mysql.com/

Even encrypting the data isn't foolproof. The code (and key) to decrypt
the data must be on the server, and that can be copied. Or, the key
must be entered from a terminal. And someone with root access can
easily intercept the incoming key.

If you want absolute security, put it on your own machine that only you
can access, lock that machine in a vault and don't give anyone else the
combination.

Of course, someone could also break into the vault...

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex-at-attglobal.net
==================

>> >> > currently we store user/pass in a plain php file, but we want to have a
>> >> > better method to protect the MySQL login authentication by hiding the
>> >> > real user name & password
>> >>
>> >> Hiding it from whom? By putting it in a plain php file, you are hiding
>> >> it from all except those who can access the php file. So who else do
>> >> you wish to hide it from. The solution depends on this.
>> >
>> >okay, let consider it is a Perl script, running on the server, any
>> >advice?
>> >
>> >i.e. sometimes, you even don't want the root to know the password to
>> >the remote Database...
>>
>> If your script can know the password, so can root. If you encrypt
>> the password, your script also has to have the key to decrypt it.
>> If it isn't necessary to decrypt it, then it *IS* the password.
>> Some people have attempted this anyway (see Pay TV vendors with
>> their descrambler boxes) but they get hacked in spite of supposedly
>> "tamperproof" hardware.
>
>
>consider some applications like e-banking system, how they protect your
>data from being modified by the `root` account?

You can't. In practice, you can hire trustworthy people, do
background checks, pay them well, have multiple people checking up
on each other, and provide separation of duties (for example, 'root'
on the webserver might not also have 'root' on the database server).
You can't prevent 'root' from modifying database data, but you don't
have to make it easy by also giving him an administrative database
login as well. And if he creates one for himself, the DBA in charge
of the database might notice.

Separation of duties is a big deal even in non-computerized accounting
systems. For example, you have two people open deposit envelopes
and count the cash in deposits. The same person who credits deposits
isn't allowed to be the person who prepares customer statements (or
he could conveniently "lose" the deposit, but send the customer a
phony statement indicating it's there).