Система авторизации на сайте

Доброго времени суток. Возник такой вопрос. Раньше, когда делал система авторизации на сайте, то в куках хранил логин и md5 шифрованный пароль. А когда надо было проверить авторизирован ли пользователь то просто брал из кук логин и зашифрованный пароль и проверял, есть ли в БД такая пара (в БД естественно тоже пароль в зашифрованном виде). Запрос получался простой, типа SELECT COUNT(*) FROM users WHERE login = '$login' AND password = 'password'.

Но в последнем проекте встал вопрос безопастности. Хранить в таком виде небезопастно. Первое, что приходит в голову, это в куках хранить md5 ($login + $password). Но встаёт вопрос - какой тогда запрос к БД писать?

Или, может кто посоветует другой способ (в плане того, что в куках хранить)?

Зараннее спасибо за помощь=)

froosty, каждый раз когда кто-то из участников форума задает глупый вопрос при этом так невзначай вставляет пару слов о серьезном проекте, безопасности итд меня этот проект почему-то сразу пугает )))
Если ты собираешь хранить md5(login + password) то почему вообще запрос должен измениться? Если ты думаешь, что ты так сильно обезопасишь своим md5 от человека который сможет дернуть чужую куку ради дела, то что-то мне подсказывает, что его алгоритм расшифровки твоего md5 на выходе сделает сразу 2 дела :
1) - Выдаст ему логин
2) - Выдаст ему пароль.
Это очень оригинальное решение по-скольку ему не надо будет дергать одну лишнюю куку с логином. ))

поля таблицы LOGIN, PASSWORD, SALT

LOGIN = Логин пользователя
PASSWORD = md5( $password . $salt )
SALT = $salt

Соль рандомно генерится при регистрации.

в куках храним md5( $password . $salt )
Запрос к базе остается таким же простым.
SELECT COUNT(*) FROM users WHERE login='$login' AND password='$password'

При авторизации посложнее. На входе имеем Логин и чистый пароль.
Первым запросом выдергиваем соль для указанного логина.
$salt = SELECT salt FROM users WHERE login = '$login'
Потом проверяем наличие пользователя
SELECT COUNT(*) FROM users WHERE login='$login' AND password='md5($password.$salt)'

Получается в куках храним хеш от случайного набора символов, вместо пароля. А соль известна только нам.
(Добавление)
Алгоритм хеширования пароля можно усложнять до бесконечности, но самым слабым звеном в этой цепочке безопасности всегда будет пользователь. Поэтому если конфеденциальность крайне важна - НИЧЕГО не храните в куках у пользователя. ;)

-----
Чем больше узнаю, тем больше я не знаю.

Всю эту соль я бы заменил на этот метод

sKaa вы имеете ввиду генерацию соли или что?

-----
Чем больше узнаю, тем больше я не знаю.

DelphinPRO, соль можно сунуть и в константу PHP. Смысл хранить её в базе? Чтобы она просто была уникальная?

Тут на форуме был один тип "Белый тигр", он работает в какой-то конторе которая как-раз и устраняет уязвимости, так вот он писал статьи на тему обеспечения безопасности приложений, вебинар даже какой-то был. Много всего писал, как лучше апач настроить, как пхп, вообще много чего интересного. Так вот там мельком проскакивал вопрос хэширования паролей. Он объяснял, что даже если хакер дернет куку которая N раз была хэширована md5/sha1, то ему потребуются серьезные финансовые вложения, чтобы вычислить алгоритм и узнать пароль.

насчет трудности взлома даже двойного хеша согласен. А соль хранится в базе, потому что генерится уникальная для каждого пользователя, что еще более повышает взломоустойчивость хеша . Аналогичный подход используется в CMS Joomla
(Добавление)
а если код открыт? алгоритм известен.

-----
Чем больше узнаю, тем больше я не знаю.

DelphinPRO, а если код открыт константу задавать в конфиге

sKaa
регистрируем аккаунт, имеем соленый хеш.
алгоритм шифрования знаем, пароль знаем (сами регили).
быстренько брутим и вычисляем соль.

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

-----
Чем больше узнаю, тем больше я не знаю.

Да мне пофигу на самом деле на эту соль. Всё, что я хотел высказать -

DelphinPRO, спасибо, большое.