Форум PHP

Начитался тут вариантов авторизации..... Куча md5-хешей у всех, вложенные хеши, ключи секретные и т.п...... Навеяло сомнения: "А безопасна ли моя авторизация"??? Наверно я чего-то не понимаю!

Дело обстоит так:
В куках хранится только идентификатор сессии.
В БД пасс хранится закодированный через base64_encode(mcrypt_ecb($pass)) на случай если юзеру понадобится восстановить пароль.
Юзер вводит логин/пасс....
скрипт делает запрос
"SELECT `id` FROM `users` WHERE `login`='$login' && `pass`='".base64_encode(mcrypt_ecb($pass))."'";
Если результат не пустой, в $_SESSION записывается "user_id".
В дальнейшем на всем сайте если в $_SESSION "user_id" установлен, значит пользователь авторизован. Если не установлен - нет.

Где слабое место?

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

Кстати да! Я вроде как устанавливаю
ini_set("session.gc_maxlifetime","2592000"); // месяц
а сессия все-равно умирает. Почему?

Может сервер не принимает (запрещено) изменений, которые устанавливаются при помощи ini_set().

в phpinfo() "Local Value" у session.gc_maxlifetime меняется.

Не буду начинать новую тему, т.к. тут тем про авторизацию уже тышша.... И именно поэтому не возможно разобраться, как будет делать правильно и достаточно безопасно.

Т.к. безопасность это вопрос, на мой взгляд параноидально-пофигистический и зависит это только от наклонностей автора, меня бы вполне устроила схема устройства авторизации этого форума.

Поэтому, cheops, опишите, плиз, как у вас тут что устроено, что значит кука wrdp, какие доп таблицы и поля используются для "безопасного" "запоминания" пользователя, какие запросы, какие проверки?

У нас тут не по делу организовано было и мы от этой схемы уходим (ну насколько это возможно для базы 7-летней давности), сейчас как раз форум в стадии тестирования очередного шага. Самый лучший способ - это:
1) Хранить логин и пароль на сервере
2) Причем пароль хэшировать md5(). У нас тут по историческим причинам барахло, а не хэш.
3) При аутентификации хэшировать введенный пароль и сравнивать его с хэшем в базе данных.
4) Если нужно, чтобы приложение запоминало пользователя и не приходилось вводить пароль каждый раз, то придется ложить хэш пароля в cookie wrdp - это он и есть. Для вас будет лучше, если там будет лежать md5-хэш. Если можно обойтись без хранения пароля или хэша в куки (пользователь каждый раз вводит логин и пароль перед работой), то вообще отлично - это самый безопасный путь. Мы почти всегда его и используем, кроме пожалуй этого форума (по историческим причинам), но тут пароли нигде больше не используются на сайте (посетителям тоже не рекомендуем тут использовать сверхважные пароли, совпадающие с платежными паролями электронных кошельков :).

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

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

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

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

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

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

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

<? 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];     }   } }

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

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

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

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

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

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

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

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

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

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

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

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

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

Возможно вас также заинтересует следующее приложение http://softtime.ru/info/authorization.php - вот оно нами часто используется, в отличие от схемы, используемой на форуме. Но это базовая авторизация - вещь специфичная и не везде подойдет.