Вот у меня такой нубовский вопрос: сохранять хеш а не сам пароль это на тот случай если кто-то получит доступ к базе данных? Или есть еще какие-то заковырки? (это первый вопрос) И еще, вот есть такая схема регистрации, когда пользователь имеет логин для входа и ник на сайте, то как я понимаю логин для входа тоже можна как хеш хранить? Но потом подумал по сути в базе прийдется все равно хранить маил, и тогда этот логин будет как "продолжение" пароля. Может просто вместо логина маил использовать? Хотя с другой стороны такая "мутная" система может несколько запудрить мозги злоумышлиникам. Т.е. имеем логин и пароль для входа и их хеши в БД (это как бы получается один пароль, тока мудренный ) ник и маил в БД открыты, но они не посылаются каждый раз, значит уже как бы более скрыты от перехвата (насчет ника - вообще побарабану) но даже если кто и получит доступ к БД, то маил вообщем-то еще не так смертельно расскрыть. Что думаете?
да. для этого. только хэш лучше ещё какой-нить строкой дополнять, так как чистый md5 поломан ну, можно ещё от книжек Маркиза де Сада тащиться )) а если тебе нужно будет выдать где-то логин? в общем логин вроде не секьюрная инфа )) можно что ты извращенец и параноик (без обид ) но можешь конечно реализовать и так, если спокойствие нервной системы требует
На мой взгляд, отдавать пароль в куку или куда-то нужно хешированным, а в базе хранить можно чистым. Если кто-то доберётся до базы, то он и так может сменить пароль. Узнают пароль методом подбора? Это не из-за вида в котором пароль сохранён, а из-за плохого пароля. Тогда зачем его хэшировать? Не знаю как все, но я как простой пользователь ненавижу забывать пароль потому что вместо моего "алгоритма" генерации, приходит какая-то чушь, которую не запомню во век. Зато когда приходит чистый, мой пароль, можно ударить себя по лбу и сказать "точно, почему я его забыл?" и уже не забывать, ибо в память откладывается.
lexa Иногда бывает, что доступ к базе есть только на чтение, но не на запись. Например, нашлась SQL-инъекция, которая показывает поля нужных таблиц на странице, но изменить таким образом данные в базе не удается. Твой вариант в таком случае будет означать полный крах. Есть вариант - хранить пароли в базе не в чистом виде, но и не в виде хеша, а в шифрованном виде, чтобы можно было расшифровать при необходимости. Такой вариант все-таки побезопаснее будет, особенно если шифрование идет по ключу, а ключ у каждого проекта уникальный.
1) и смысл? от сниффинга беречь? один хрен при первичной авторизации чистый пароль будет отправляться. и вообще давно придуманы сессии, зачем хранить самому куку? 2) хэшировать в базе как раз нужно, на всякий случай. если уязвимость позволяет читать - не факт, что позволяет писать, догоняешь? генерённая чушь действительно не вставляет, но можно отсылать уникальный линк, по которому можно будет выбрать любой новый пароль
S.t.A.M. хм, тоже верно! если бы еще чтобы и хостер не мог их видет но если md5 "поломан", и хостер может увидет в исходном коде дополнительный "ключ", то как я понимаю от хостера не спрячешь?
Ruzzz MD5 не поломан. Восстанавливать исходную строку по хешу умеют лишь полным перебором. Просто за прошедшее время накопились rainbow-таблицы и базы, облегчающие подбор коротких паролей.
Это элементарно лечится добавлением "мусора" к строке пароля, например пароль "cobaka" добавляешь слово "privet" - ихешеируешь "privetcobaka", а еще лучше "pcroibvaekta"! и фиг кто его перебором откопает! )))
Конечно не в тему скажу) Но у меня знакомый делал авторизацию с базами, и вот как он шифровал пароль: PHP: <?php $salt = "sseftd_vzlomshik_lamer_sjhole73"; $pass_in_db = md5(md5($_POST['password']).md5($salt)).$salt; ?> Конечно не точно так, но система та же. Когда я это увидел первый раз, чуть со стула не упал
lexa Ну это не параноя. Просто нужно быть увереным, если у пользователя пароль "qwerty", "12345" и злоумышленник добрался до БАЗЫ (пользователей) и путем прямого перебора подобрать пароль. Кто виноват? Виноват админ. 1) Не смог осуществить безопасность базы (хотя, если сильно захотеть, поломать можно что угодно) 2) Не смог осуществить безопасность данных в базе (а это уже минус. Лучше лишний раз добавить соль, захэшировать по 2-3 раза - но что бы было безопасно).
Вы кой чего не понимаете. Для обхода md5 ВООБЩЕ не надо знать пароль! Достаточно знать ЛЮБУЮ последовательность, которая имеет тот же хеш! Поэтому: 1. Опасность подбора "короткого" пароля только при прямом переборе или атаки со словарем. В любом случае, для этого не нужно знать хеш пароля. Избежать этого можно поставив ограничение на число попыток логина. 2. Злоумышленник добрался до сайта изнутри - тут глупо говорить о каких либо защитах, поздно предохранятся, если вас уже поимели во все дыры. 3. Хеширование с солью нужно ЛИШЬ для того, если у вас вдруг есть не дай бог на сайте место со SQL иньекцией, и вашу таблицу пользователей смогли посмотреть, или даже изменить - каждая проверка будет выполнена для последовательности пароль+соль, тогда знание хеша не дает возможности найти подходящую последовательность для генерации этого хеша, ибо к ней будет всегда добавлятся соль, т.е. доступ все равно не будет получен, либо, даже в случае изменения таблицы, утерян вообще для всех.