Соединение с базой данных
Using functions to obfuscate the hash generation does not increase security. This is security by obscurity. The algorithm used to hash the data needs to be secure by itself.
I would not suggest to use other data as salt. For example if you use the username, you won't be able to change the values without rehashing the password.
I would use a dedicated salt value stored in the same database table.
Why? Because a lot of users use the same login credentials on different web services. And in case another service also uses the username as salt, the resulting hashed password might be the same!
Also an attacker may prepare a rainbow table with prehashed passwords using the username and other known data as salt. Using random data would easily prevent this with little programming effort.
Шифрование хранилища базы данных
SSL/SSH защищает данные, которыми обмениваются клиент и сервер, но не защищает сами данные, хранимые в базе данных. SSL - протокол шифрования на уровне сеанса передачи данных.
В случае, если взломщик получил непосредственный доступ к БД (в обход веб-сервера), он может извлечь интересующие данные или нарушить их целостность, если информация не защищена на уровне самой БД. Шифрование данных - хороший способ предотвратить такую ситуацию, но лишь незначительное количество БД предоставляют такую возможность.
Наиболее простое решение этой проблемы - установить вначале обыкновенный программный пакет для шифрования данных, а затем использовать его в ваших PHP-скриптах. PHP может вам помочь с этой задачей с помощью таких расширений как Mcrypt и Mhash, реализующих довольно большое число алгоритмов шифрования. При таком подходе скрипт вначале шифрует сохраняемые данные, а затем дешифрует их при запросе. Ниже приведены примеры того, как работает шифрование данных в PHP-скриптах.
В случае работы со скрытыми служебными данными, если не требуется их нешифрованное представление (т.е. его не нужно показывать), то, как следствие, можно использовать хэширование. Хорошо известный пример хэширования - хранение криптографического хэша от пароля в БД, вместо хранения оригинального значения. Смотрите также документацию по функции crypt().
Пример #1 Использование хешированных паролей
<?php
// сохранение хэшированного пароля
$query = sprintf("INSERT INTO users(name,pwd) VALUES('%s','%s');",
pg_escape_string($username), crypt($password, '$2a$07$usesomesillystringforsalt$'));
$result = pg_query($connection, $query);
// проверка введенного пользователем пароля на корректность
$query = sprintf("SELECT 1 FROM users WHERE name='%s' AND pwd='%s';",
pg_escape_string($username), crypt($password, '$2a$07$usesomesillystringforsalt$'));
$result = pg_query($connection, $query);
if (pg_num_rows($result) > 0) {
echo 'Добро пожаловать, $username!';
} else {
echo 'Авторизация не удалась, $username.';
}
?>
add a note
User Contributed Notes
Шифрование хранилища базы данных
Reiner
21-Apr-2011 12:46
zyppora at nosmac yahoo dot com
14-Mar-2007 04:30
In addition to roysimkes at hotmail dot com:
If your passwords are so secret that they're worth a year's hacking/cracking/etc, you might want to consider 'password renewal', much like Windows' option. Tell your users to renew their passwords every x days/weeks/months to make it extra hard on those already-sweating malicious visitors.
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.
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