PHP: Защита хранилища базы данных - Manual

downloads | documentation | faq | getting help | mailing lists | reporting bugs | php.net sites | links | conferences | my php.net

search for in the

SQL-инъекции Соединение с базой данных

Last updated: Sat, 27 Jan 2007

view this page in

# Защита хранилища базы данных

SSL/SSH защищает данные, которыми обмениваются клиент и сервер, но не защищают сами данные, хранимые в базе данных. SSL - протокол шифрования на уровне сеанса передачи данных.

В случае, если взломщик получил непосредственный доступ к БД (в обход веб-сервера), он может извлечь интересующие данные или нарушить их целостность, поскольку информация не защищена на уровне самой БД. Шифрование данных - хороший способ предотвратить такую ситуацию, но лишь незначительное количество БД предоставляют такую возможность.

Наиболее простое решение этой проблемы - установить вначале обыкновенный программный пакет для шифрования данных, а затем использовать его в ваших скриптах. PHP, в таком случае, может помочь вам в работе с такими расширениями как Mcrypt и Mhash, реализующими различные алгоритмы криптования. При таком подходе скрипт вначале шифрует сохраняемые данные, а затем дешифрует их при запросе. Ниже приведены примеры того, как работает шифрование данных в PHP-скриптах.

В случае работы со скрытыми служебными данными их нешифрованное представление не требуется (т.е. не отображается), и, как следствие, можно использовать хеширование. Хорошо известный пример хэширования - хранение MD5-хеша от пароля в БД, вместо хранения оригинального значения. Более детальная информация доступна в описании функций crypt() and md5().

Пример 27-1. Использование хешированных паролей

`<?php
// сохранение хешированного пароля
$query = sprintf("INSERT INTO users(name,pwd) VALUES('%s','%s');",
addslashes($username), md5($password));
$result = pg_exec($connection, $query);
// проверка введенного пользователем логина и пароля на корректность
$query = sprintf("SELECT 1 FROM users WHERE name='%s' AND pwd='%s';",
addslashes($username), md5($password));
$result = pg_exec($connection, $query);
if (pg_numrows($result) > 0) {
echo "Welcome, $username!";
}
else {
echo "Authentication failed for $username.";
}
?>`

add a note User Contributed Notes
Защита хранилища базы данных
somebody
26-Dec-2006 10:07
`A better way to hash would be to use a separate salt for each user. Changing the salt upon each password update will ensure the hashes do not become stale.`
Ketos
02-Nov-2006 04:05
`You should always hash the password with the username, so store md5($password . $username) instead of md5($password) This way the cracker cannot use a precomputed set of hashes of common keys, but has to recompute the hashes for each user.
Double hashing also can help in some situations as it solves length extension problems with all hash functions. Also you should use SHA-256, as it has a longer hash length and thus it takes 2^128 steps to find a collision`
roysimkes at hotmail dot com
17-Aug-2006 05:10
`But the thing in double hashing is to increase the time that they can crack your password! A passwod that takes a year to break is quite secure(!)
And even if they learn somehow that you are double hashing your passwords, how will they learn which one you are using first! Instead of using md5() twice try using sha1(md5()) or vice versa. An the breaker should check more things. For only one password he has to check at least 4 different types (md5 only, sha1 only, md5(sha1) and sha1(md5) ) it will take quite a time to break it! (Yeah if he can see your source files it doesn't mean anything. But if they can see that files, you are already dead in the water)
And also put a salt variable in it! If that's random salt, it will take a very long time to crack the password. The best security is to use a hybrid solution. If you add salt to your passwords they have to use your app to crack the code. And if you add some more features like after 3 times password failure add a secret question and a secret answer, a visual confirmation code! Things are getting complicated for the automated script!
Well yes if you want to protect something, do not publish them in the internet. With enough dedication, time and resources every password can be cracked. But if the time is more then years, who will waste time on it? Or the password to be cracked worth that time?`
dan[ddot) crowley [att]gmail {dott]com
13-Jul-2006 01:31
`A note to the people who think that hashing a password multiple times makes it uncrackable:
It doesn't.
If you're using a standard hash cracker or rainbow tables, sure. But if you've got the smarts to design your own hash cracker, you can just double-hash every string where it would normally be hashed once, and then at best your hashes take twice as long to crack.`
Fairydave at the location of dodo.com.au
11-Feb-2006 06:58
`I think the best way to have a salt is not to randomly generate one or store a fixed one. Often more than just a password is saved, so use the extra data. Use things like the username, signup date, user ID, anything which is saved in the same table. That way you save on space used by not storing the salt for each user.
Although your method can always be broken if the hacker gets access to your database AND your file, you can make it more difficult. Use different user data depending on random things, the code doesn't need to make sense, just produce the same result each time. For example:
if ((asc(username character 5) > asc(username character 2))
{
if (month the account created > 6)
salt = ddmmyyyy of account created date
else
salt = yyyyddmm of account created date
}
else
{
if (day of account created > 15)
salt = user id * asc(username character 3)
else
salt = user id + asc(username character 1) + asc(username character 4)
}
This wont prevent them from reading passwords when they have both database and file access, but it will confuse them and slow them up without much more processing power required to create a random salt`
3M
05-Oct-2005 08:46
`Be smart and simple!
1. Hash a password once on twice! It's sufficient to use SHA-1 twice! (read no.3)
2. Limit the number of log-in trys per ip! This will be a hard hit for online brute force crackers!
3. The comments below that suggest using a SALT whit MD5 ar good as long as the length of the resulting string (password + SALT) is bigger then the output of the hashing algorithm. For example: SHA-1 has an output of 160 bits or 20 ASCII chars. If the password set has 8 chars then the salt would have to be of 12 chars or longer... the longer the better!
The idea here is that by trying to brute force a hash (second) that was computed from another hash (first) from a large string would result in many collisions that will make it impossible to distinguish between them and the first hash of the password!
4. If possible use HMAC for added security! This will prevent sending the same generated hash from a paswrod in the tcp/udp packets... each time the pasword field in tha data packets will contain a different hash (HMAC'ed) but on server side will be decoded to the real hash. For this you will need to design a solution for sending the password needed for HMAC!`
blodo at poczta dot fm
07-Jul-2005 02:05
`You could always double hash the password, which might just be the easiest way to prevent a hash table crack which typically can only crack hashes that store about 8 characters in length (from what i know). For an additional amount of security you can always append a random salt, although you will need to store the salt to succesfully recover the password for checking. The code could look like this:
<?php
function createSalt ($charno = 5) {
for ($i = 0; $i < $charno; $i++;) {
$num = rand(48, 122); //This is roughly the ascii readable character range
$salt .= chr($num); //Convert the number to a real character
}
return $salt;
}
$randomsalt = createSalt();
$hash = md5(md5($string_to_hash.$randomsalt));
/* Now append this to your database, but remember to store the salt somewhere too, or else you wont be able to check the password later on */
?>
Easy as pie. Hope this helps.`
Chris Ladd
05-Jun-2005 11:41
`Using a hard coded salt will only prevent a dictionary attack on the raw database and only if the attacker hasn't gained access to the file the salt is stored in. The attacker could still use the php login site to run a dictionary attack, since the php would be adding the hard coded salt to the password, md5ing it, and checking if it matches. The only real way to prevent a dictionary attack is to not allow weak passwords. There is no shortcuts in real security.`
oguh at gmx dot net
11-May-2005 11:06
`Better use a random value for the salt and store it seperate in the database for every user.
So it is not possible to see if some users have the same password.`
Jim Plush - jiminoc at gmail dot com
17-Mar-2005 01:45
`Another handy trick is to use MD5 with a "salt". Which basically means appending another static string to your $password variable to help prevent against dictionary attacks.
Example:
config.php - KEEP THIS OUTSIDE THE WEBROOT
define("PHP_SALT", "iLov3pHp5");
----------------------------------------------
and when you add your database query you would do:
// storing password hash
$query = sprintf("INSERT INTO users(name,pwd) VALUES('%s','%s');",
addslashes($username), md5($password.PHP_SALT));
This way if a user's password is "DOG" it can't be guessed easily because their password gets saved to the DB as the MD5 version of "DOGiLov3pHp5". Last time I checked, that wasn't in the dictionary :)`
add a note
SQL-инъекции Соединение с базой данных

Last updated: Sat, 27 Jan 2007
show source | credits | stats | sitemap | contact | advertising | mirror sites
Copyright © 2001-2007 The PHP Group
All rights reserved.
This mirror generously provided by: Yahoo! Inc.
Last updated: Sat Mar 10 09:32:46 2007 PST