Aarstad

Yuk хочет сделать разграничение прав, для зарегестрированных пользователей.

Это можно реализовать проверяя id пользователя, или если прав много и они произвольным образом смешиваются у разных пользователей, то имеет смысл завести отдельную таблицу в базе.

Кстати говоря, при логауте, наверное, лучше все же не обнулять сессионную переменную, а убивать сессию при помощи session_destroy().

А насчет моей заинтересованности проблемами безопасности, то тут все просто. Я просто не знаю, где может возникнуть уязвимость (разумеется речь идет о конкретном скрипте) и мне хотелось бы узнать об этом. Ну кража кукиса и взлом пароля — это очевидно и не так интересно. Хотелось бы знать, что может быть еще…

+ добавлю "галочку" запоминать или нет

простите, не понял о чем вы…

а насчет механизма — безусловно вы правы, и я вас полностью поддерживаю.

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

Нет нет… девушка лет шестнадцати, должна знать, что лучше не сохраняться в кукисах в клубах. А если она не в курсе, то и кнопку выход она жать не будет. [Можно подпись к чекбоксу сделать такую, чтобы ясно было, как сохраняется пароль — "запомнить меня на этом компьютере"].
Человек же выходит из приватной зоны не обязательно для того, чтобы никто другой не смог войти. Он, к примеру, желает войти под другим именем.

Но вы правы, если просто сделать так, как я писал в предыдущем посте, то кукисы можно будет удалить только руками. Но это легко исправить, надо просто удалять установленные кукисы, если человек входит со снятой галкой "запомнить меня". На мой взгляд, это весьма очевидно, и кроме того довольно распространено в природе. Например на mail.ru. Там правда сделано по-уродски все: по-умолчанию тебя запомнят, если не поставить галку. Надо делать конечно наоборот — по-умолчанию не запоминать.

Не ну я как бы не настаиваю, ваш скрипт — ваш выбор. Но поправьте его, чтобы выйти хотя бы можно было в принципе.

Соль надо добавлять к уже сгенерированному хэшу.

согласен, поправлено

Да и соль и в базе, как уже указывалось, лучше тоже не хранить.

Есть очень одна проблема в вашем скрипте — если сохраняться в кукисах, то из защищенной зоны невозможно будет выйти.))) После логаута нас переправляет на корневой раздел, который тут же логинится через кукисы. Чтобы решить эту проблему, можно ставить еще одну куку "logout" и проверять — если такая кука установлена, то показывать форму логина с уже заполненными полями, чтобы пользователь только нажал клавишу если решит войти; если куки "logout" нет, то логиниться сразу. Можно конечно при логауте просто удалять кукисы, но на мой взгляд менее удобно для конечного пользователя.

Это я читал. Согласен — узнать начальную строку будет очень проблематично. Особенно если ломают какую-то ерунду…

Хакер взломав базу получает md5 хэш и при помощи радужных таблиц находит строку из которой этот хэш получен.

Ты сам то пробовал так сделать или только в инете прочитал?

Это сложно, но возможно в теории…

Найдя эту строку он отнимет от нее соль (которую также найдет во взломанной базе) и получит пароль.

А откуда вообще возникла мысль, что кто-то станет хранить ее в базе?

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

Можно брать двойной хеш (например, md5(sha1('password'))) или использовать так называемую "соль" (salt).
Пример использования соли: md5('password' . 'secret_code');
secret_code — это и есть соль, то есть мы тупо к паролю добавляем какой-то набор символов (желательно ещё и запомнить, какой набор символов мы добавляем ;))

Насколько я понимаю, это бессмысленно. Ведь какую проблему мы пытаемся решить? Хакер взломав базу получает md5 хэш и при помощи радужных таблиц находит строку из которой этот хэш получен. Найдя эту строку он отнимет от нее соль (которую также найдет во взломанной базе) и получит пароль.

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

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

Кроме того, можно добавлять к уже готовому хэшу пароля в качестве соли использовать какое-нить неочевидное поле (например хэш даты регистрации пользователя). Чтобы хакеру было сложнее определить что добавлено и куда.