View Full Version : Encrypt/decrypt MqSQL password?

04-13-2006, 02:49 AM

It's my first post here; please be gentle.

I inherited some *atrocious*, undocumented software. It entails a database of user info (account name, password, email address, etc). I found someone going in and retrieving his own password when I'd changed it on him to keep him out. Unless I'm totally off my mark here, he got in because the SQL database password is saved in a file in clear text. I'd like to encrypt that password, and then change all the routines which use it to decrypt it when they need it.

I run some forum software which does this and I thought I'd filch the code from there, but that turns out to be huge and unwieldy. I'm pretty sure that what I need to do isn't a big deal (please correct me if I'm wrong!).

I'd be super-grateful if someone'd point me toward some PHP code which does this which I can use to accomplish this.


04-13-2006, 07:03 AM
sha1() is probably the best function to do what you want.

mcrypt() can also do it but you need a decent salt value to make it harder to decrypt.

04-13-2006, 08:06 AM

sha1() is probably the best function to do what you want

Good heavens; I've never even *heard* of that one before! I was looking at encrypt. Okay; I'm off to investigate sha. Thanks very much!

04-26-2006, 10:49 PM
I'm using "crypt" to good success. It is one-way encryption, so there's no way to decode it.

04-26-2006, 10:59 PM
You can't use SHA1. Hashing algorithms are made so that they can't be decrypted (SHA1 is a hashing algorithm in case you didn't get that). You need the password in plaintext anyway. Just store it in a .php file and unset the variable as soon as it's not needed anymore.

04-26-2006, 11:31 PM
Passwords should never be stored in plain text or in an encrypted format that can be decrypted. You should always use a one way encryption (hashing) formula and feed the entered password through that before comparing it with the stored one. That way no one except the password owner can ever know what their password is even if the security on the database is breached.

04-26-2006, 11:45 PM
dunno if you figured this one out yet but I use md5. It's old and basic, and I'm sure folks here will have poopoo to fling at it but it is one way (can't decrypt it) and very easy to use.

To store the password, let's assume it's sent as a $_POST var and I've validated all the post vars into an array called $postval:

$sql = '
INSERT into users (
"' . trim( $postval['username'] ) . '",
"' . md5( trim( $postval['password'] )) . '",
"' . trim( $postval['fname'] ) . '",
"' . trim( $postval['lname'] ) . '",
' . $postval['clearance'] . ',
' . $postval['active'] . ',
' . $postval['customer_id'] . '

Now to check if a user has entered his password correctly, in your authentication script, I just do:

$sql = "SELECT user_id,
FROM users
WHERE username = '$login'
AND password = '".md5($passwd)."'
AND active = 1";

You can of course ignore all the extra fields - just pay attention to how md5() is used.

*** edit:
I just re-read the OP and realized I was a bad attention-payer. md5() will not work in your situation, but I must echo what Felgall says. If at all possible, figure out a new way of using the password, so that it cannot be stolen regardless.

04-27-2006, 02:58 AM

Well, I never *did* figger out my problem. See, there's never a "live" user to enter a password. These are scripts I'm talking about, running on the net. Someone clicks a button to start a process, and the database is opened and data gathered and spat out. Only I, the administrator, oughtta know the database password. The end users can't know it (there're a few thousand). So the situation remains that the password is stored in cleartext in a file, and one of those thousands of users found it and entered the database. (Luckily, he wasn't up to no good!) (I'd like to remind folks that I inherited this horrible piece of software, and hafta live with it.)

Since I've been busy with something else, I've backburnered this, while every day waking up and wondering whether someone with evil intentions has breached the database.

04-27-2006, 03:12 AM
The password file that the application is using needs to either be stored above the web root directory and have your application access it from there or check the permissions on the file where it currently is and make sure they are not set to be wide open. For starters what application are we talking about? Is this a common application available to the public or some custom app?

ralph l mayo
04-27-2006, 03:13 AM
Database connection passwords are stored in plaintext php files. That's just how it's done because two-way encryption isn't any more secure if someone has access to your php source. The thing is, with proper configuration, your source should be inaccessable. If just changing the password doesn't help,
(a) another protocol has been breached, like FTP, so the offender can just download the file and look at the source without it being interpreted. Tighten up access to FTP, Telnet, SSH, anything else you've got going on and set permissions on the directory in question to only be viewable by the web server's user and group (probably nobody:nobody if Apache linux)
(b) there's a web based security hole that's allowing people to see the contents of files and/or variables. This is harder to diagnose but look for anything coming from $_GET or $_POST or cookies or sessions or anything to do with the user and make sure nothing stupid is being done with it.
(c) the password is being cracked and not discovered. Brute force, etc. Unless you have a reason for MySQL to listen to the world set it to only accept connections from localhost. Disable any remote consoles or administration tools that allow access to PHP or MySQL to anything but localhsot.

04-27-2006, 04:37 AM
Hi, Spook:

For starters what application are we talking about?

It hasn't got a name. So far as I know, there are four copies being run on the net. It's traffic exchange software, badly-written, and my guess is it was a free script.

The file conmtaining the password has permissions of 644, which now that I think about it, I'm thinking that doesn't make sense. Don't I want everyone to be able to *execute* it, but not read it? Or ... wait. Maybe I only want me (the owner) executing it? (I'm totally unsure of permissions when there's no human intervention.)

The file is in a subdirectory whose permissions are 755. Again, maybe that's not right, either?


Database connection passwords are stored in plaintext php files

Okay; now my head's gonna explode. I run some forum software written in Perl (Ikonboard), and *that* password is encrypted. It, too, accesses a database in which all the member profiles, messages, and so on are stored!

WRT your a, b, and c, b would seem the most likely of the three. My passwords are always made up words with with numbers and non-alphanumeric characters, so that seems unlikely, and I have a *terrific* host and no one has access to telnet, ssh, or ftp but me. So as unappealing as it sounds, I guess I'll try tackling b (though the Spookster has me wondering about my permissions now).

04-27-2006, 05:05 AM
Check your log files and see if anyone has been conducting brute force attacks. There are really only 4 ways someone is getting the password if it is in a php source file:

1. Access to the server
2. Brute Force Attack
3. Password is sniffed from a variable/session
4. Permissions on file allows anyone access to to the source from the web