Where to store sensitive client details (MYSQL DB credentials)

[Neji]

I have a security related question about storing some client information - specifically their database login credentials.

My app works based on the client and so the database details need to be set at the start. My initial thought was to hold it all in a MYSQL database table but if that gets compromised, then all my clients are at risk.

I've also thought about creating a PHP array with all these details in, then when a new client is added through the GUI, write the details into that array using fopen etc.

Are there any better alternatives out there that I'm missing?

More details:

I have a MYSQL database on my host server (where the app runs from) then the app needs to connect to one of an number of external databases (my client's) but obviously the app needs to know all of their details.

I'm not sure that encryption is really possible, I can hash it and save it to a table but I can't reverse that so it'd have to be plain text, hence my worry about security - I'd never want to store plain text passwords in a database.

[ginerjm]

This is not the answer you seek, since security is not one of my strong points.  Simply - you do not store the password in plain text.  You store it in your chosen hash/encryption/etc. scheme.  Then when a user presents a password your hash that entry and use it to find a matching (already-hashed) password in the database.

 

$q = select * from mysignons where username=$user and password = PASSWORD($pass)

 

where PASSWORD is the standard MySQL hashing function.  If you choose to use some other hash method, you simply apply that to the $pass var and use the result in your where clause.    The thought you have is probably triggered by the desire to be able to recover the password should the user forget it, but that is not what one does.  Once forgotten, the user is given an entirely new password, never the old one.

[trq]

If an attacker gets as far as your database your pretty well screwed anyway.

[ginerjm]

Well, that's true, but at least a good security method for 'other' sensitive data can prevent the damage from progressing beyond.

[kicken]

I'm not sure that encryption is really possible, I can hash it and save it to a table but I can't reverse that so it'd have to be plain text, hence my worry about security - I'd never want to store plain text passwords in a database.

You can encrypt it, you just need to use something that is reversible and keep the decryption key somewhere. Depending on how complex you want to get there are various ways you can go about this.

 

On the basic level, just define the decryption key inside a PHP file somewhere that you include into your app. When you need to access the details you'd pull the encrypted values from the DB, include the key and decrypt them.

Pros: Easy to setup and use. If your DB is leaked, the key is not leaked as well since it is stored separate.

Cons: If the server itself is compromised, the attacker will get both the key and the database, enabling them to decrypt the details

 

On a more advanced level, you'd set something up to store the key in memory, and have your app access the key that way. You'd have to input the key manually whenever you restart your server.

Pros: The key is not physically stored anywhere, thus simple filesystem hacks or DB dumps will not reveal it.

Cons: Takes a bit more effort to setup properly, and requires someone to manually enter the key after a reboot.

 

Regardless of which way you end up going, you also need to ensure that you use a strong algorithm and key size. If your DB gets leaked and you use a weak algorithm or key the attacker could just brute-force decrypt the data given a bit of time.

[ginerjm]

I dont' understand why you need a plain text password, nor why encryption is not possible.  Your app reads the data (password) and uses it to validate the user's input value - it never goes anywhere else.  So why can you not encrypt it for your usage?  Nobody/no one will ever access this value - if they are then you have a serious design problem, since by simply letting another application access your secured data is a security breach itself.

[Barand]

This is not the answer you seek, since security is not one of my strong points.  Simply - you do not store the password in plain text.  You store it in your chosen hash/encryption/etc. scheme.  Then when a user presents a password your hash that entry and use it to find a matching (already-hashed) password in the database.

 

$q = select * from mysignons where username=$user and password = PASSWORD($pass)

 

where PASSWORD is the standard MySQL hashing function.  If you choose to use some other hash method, you simply apply that to the $pass var and use the result in your where clause.    The thought you have is probably triggered by the desire to be able to recover the password should the user forget it, but that is not what one does.  Once forgotten, the user is given an entirely new password, never the old one.

 

According to the MySQL manual:

 

Note

The PASSWORD() function is used by the authentication system in MySQL Server; you should not use it in your own applications. For that purpose, consider MD5() or SHA1() instead. Also see RFC 2195, section 2 (Challenge-Response Authentication Mechanism (CRAM)), for more information about handling passwords and authentication securely in your applications.

[ginerjm]

I've learned something new.  So - the user should use one of the suggested functions instead of the MySQL one - everything else is I've described stays the same.

 

ps - what the heck is the "authentication system in MySQL"?  I've seen so many examples of its usage, I never knew it was not a preferred method.

[kicken]

ps - what the heck is the "authentication system in MySQL"?

It refers the the way mysql handles user accounts/access, ie the Username/Password you use to access mysql. Pretty much the only thing that the PASSWORD function is intended to be used for is changing your mysql login password using a query like:

SET PASSWORD=PASSWORD('YourNewPassword');