Форум PHP

>Чем лучше?
Функция агрегатная, чтобы провернуть SQL-инъекцию придется сильно покумекать над GROUP BY (я вот например сходу что-то даже не соображу возможна ли тут инъекция или нет - т.е. ситуация сильно нестандартной становится), что в условиях, когда таблица не видна может быть затруднительно... может какой-нибудь неуч погрызет погрызет уязвимость, да бросит (понятно, что лучше уязвимостей не допускать, но всякое бывает, особенно со временем, при переписывании кода).

Это интересно для общего развития, но я начал тему с того, что мне не нужна сверхзащита. Об этом тут уже писалось и писалось и писалось. Если исходить из утверждения, что пользователь - чудак на букву М, то нужно HTTPS, сменяемую сессию, одноразовые пароли и смс-подтверждения. Все остальное - это игрушки. Тупой юзер сам при первой возможности отдаст свои данные кому угодно и не узнает об этом.

> Да, только лучше count(id_user) вместо просто id_user.
Чем лучше?

> Переменные $_COOKIE["login"] и $_COOKIE["hash"] обязательно обработать на предмет SQL-инъекции.
Само собой. Я алгаритм показал, а не готовый код.

> В конце концов можно не вводить поле, можно просто класть md5-хэш, а при аутентификации расшифровывать пароль и получать его md5-хэш.
Я сначала так и подумал.... А потом подумал другое - ведь обратимый пароль есть ток в базе, значит чтоб найти у кого он совпадает придется перелопатить (раскодировать пароль и получать хеш) всю базу! И вот ток щас сообразил, что логины не дублируются и проверку нужно ток одну произвести. Утро вечера мудренее ))

> Вы этот ключ где-нибудь еще используете, кроме как для шифрования пароля, есть у пользователей шанс поиметь с его выгоду, даже если они его узнают?
нет, не использую.

посмотрел доступные на данный момент для скачивания таблицы http://www.freerainbowtables.com/ru/tables2/.
Согласно этим данным можно рекомендовать пароли:
Чисто цифровые: > 14 знаков
Только маленькие (большие) буквы и цифры: > 9 знаков
Смешанные: > 8.

Но опять же простые пользователи игнорят или не знают этих правил, так что лучше подсолить

PS http://crackfor.me Сервис по восстановлению паролей к md5-хешам

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

> Причем пароль хэшировать md5()

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

Т.е. если исключить возможность кражи базы, то в БД можно и открытый пароль хранить. Главное в куку в открытом виде не писАть =)

Да, только лучше count(id_user) вместо просто id_user. Переменные $_COOKIE["login"] и $_COOKIE["hash"] обязательно обработать на предмет SQL-инъекции. Если будут ломать, начнут именно от сюда - не будет защиты, считайте сайт уже взломан. Лучше не поленитесь, составьте SQL-инъекцию сами на незащищенном скрипте, потом защите и проверяйте защиту, можно даже cron-заданием (вот это уже паранойя, но полезная паранойя - потом сами не заметите как чего-нибудь где-нибудь поправите, забудете и готово дело дыра).

>> При аутентификации хэшировать введенный пароль и сравнивать его с хэшем в базе данных.
>У меня пароль в БД зашифрован через mcrypt_ecb(). Значит нужно еще поле с хешем в БД добавить?
Ну нет, не стоит, уже слишком избыточно будет, можно оставить mcrypt_ecb(), предполагается, что даже хэши не будут покидать машины пользователей... плохо, конечно, что шифрование обратимое, у пользователей повышается шанс получить ключ... даже не знаю, может идея с дополнительным полем не так плоха. В конце концов можно не вводить поле, можно просто класть md5-хэш, а при аутентификации расшифровывать пароль и получать его md5-хэш. Вы этот ключ где-нибудь еще используете, кроме как для шифрования пароля, есть у пользователей шанс поиметь с его выгоду, даже если они его узнают?

>> придется ложить хэш пароля в cookie wrdp - это он и есть
>То есть не нужно всей этой ерунды, типа md5($login."::".$pass."::".$super_secret_key)? Это паранойя?
Да, нет от чего паранойя - хуже не будет.

И при авторизации тогда проверка типа

<? if (!isset($_SESSION["id_user"])){   if (isset($_COOKIE["login"]) && isset($_COOKIE["hash"])){     if (mysql_num_rows($id_user = mysql_query("SELECT `id_user` FROM `users` WHERE `login`='{$_COOKIE["login"]}' && `hash`='{$_COOKIE["hash"]}'"))){       $id_user = mysql_fetch_array($id_user);       $_SESSION["id_user"] = $id_user[0];     }   } }

Я прально понимаю?