Secure MySQL connection authentication?

>> >> > 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).

>>> >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

Then you can't use the data except when the key is provided. This
may be OK for user passwords, but for much other private information,
the only reason to have it on the system at all is that there's a
need for it when the user is NOT logged in. For example, the alert
topics list and the user's email address might be used by the system
to send an email when something of interest (as specified by the
user) is posted. Banks need to know customer account balances (e.g.
when checks clear, to see if the check should bounce). Both the
store and the user need the user's credit card number when he orders
something and the order is processed.

>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.

And never forget that more primitive methods, like yanking an ATM
machine out of the ground with a chain and blowing it open with
explosives, or bribing the employee with the keys, can get around
sophisticated encryption locks.

>>> >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

Then you can't use the data except when the key is provided. This
may be OK for user passwords, but for much other private information,
the only reason to have it on the system at all is that there's a
need for it when the user is NOT logged in. For example, the alert
topics list and the user's email address might be used by the system
to send an email when something of interest (as specified by the
user) is posted. Banks need to know customer account balances (e.g.
when checks clear, to see if the check should bounce). Both the
store and the user need the user's credit card number when he orders
something and the order is processed.

>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.

And never forget that more primitive methods, like yanking an ATM
machine out of the ground with a chain and blowing it open with
explosives, or bribing the employee with the keys, can get around
sophisticated encryption locks.