Comments 229
Хорошая статья, надеюсь вокруг станет меньше "неправильных" login-форм.
1. mysql_select_db("testtable"); // нелогичное название базы, testdb лучше
2. Нужно использовать mysql_real_escape_string()
3. Убирать лишние пробелы нет смысла, так как их не пропустит вот эта строка:
if(!preg_match("/^[a-zA-Z0-9]+$/",$_POST['login']))
1. mysql_select_db("testtable"); // нелогичное название базы, testdb лучше
2. Нужно использовать mysql_real_escape_string()
3. Убирать лишние пробелы нет смысла, так как их не пропустит вот эта строка:
if(!preg_match("/^[a-zA-Z0-9]+$/",$_POST['login']))
1. ок :)
2. Впринципе, меня всегда полностью устраевала mysql_escape_string. Но на будущее учту.
3. Да, я ещё когда писал код, хотел убрать trim, но потом забыл. Исправлю.
2. Впринципе, меня всегда полностью устраевала mysql_escape_string. Но на будущее учту.
Функция идентична mysql_real_escape_string(), исключая то, что mysql_real_escape_string() принимает параметром ещё и указатель на соединение и экранирует в зависимости от кодировки. mysql_escape_string() не делает этого и результат работы не зависит от кодировки, в который вы работаете с БД.
3. Да, я ещё когда писал код, хотел убрать trim, но потом забыл. Исправлю.
> указатель на соединение и экранирует в зависимости от кодировки.
В пренебрежении управления кодировками большая проблема. Вы никогда не переносили базы из MySQL 4.0 в MySQL 4.1 и старше? Знаете, что бывает, если не задавать кодировку, в которой данные записываете в базу и в которой ожидаете обратно? Правильно, CP1251/koi8-r или любая другая кодировка интерпретируется как latin1 и все русские символы преобразовываются в "?".
В пренебрежении управления кодировками большая проблема. Вы никогда не переносили базы из MySQL 4.0 в MySQL 4.1 и старше? Знаете, что бывает, если не задавать кодировку, в которой данные записываете в базу и в которой ожидаете обратно? Правильно, CP1251/koi8-r или любая другая кодировка интерпретируется как latin1 и все русские символы преобразовываются в "?".
Переносил, использовал для этого http://sypex.net/ и всё было нормально.
Если не сложно, укажите ссылки на решение этой проблемы.
Проблема не только с записью данных в базу, но и с поиском русского текста в ней.
Заранее спасибо.
Проблема не только с записью данных в базу, но и с поиском русского текста в ней.
Заранее спасибо.
В /etc/my.cnf я написал (это не мешает работе баз на других языках, если с ними уже всё в порядке):
[server]
default-character-set = cp1251
[client]
default-character-set = cp1251
А в сами скрипты после каждого mysql_connect() нужно добавить:
mysql_query("set names cp1251;");
Скажу честно, я не специалист MySQL и возможно существуют решения покрасивее, но это единственное решение (из тех что я пробовал), которое работает для всех баз и скриптов.
Да, кстати, никто не расскажет, как всё-таки правильно создавать базу в нужной кодировке и работать с ней в MySQL 4.1+? Например, я хочу отдавать данные в базу в UTF-8 и принимать тоже в UTF-8. Как это сделать наиболее правильно с точки зрения работы с MySQL?
[server]
default-character-set = cp1251
[client]
default-character-set = cp1251
А в сами скрипты после каждого mysql_connect() нужно добавить:
mysql_query("set names cp1251;");
Скажу честно, я не специалист MySQL и возможно существуют решения покрасивее, но это единственное решение (из тех что я пробовал), которое работает для всех баз и скриптов.
Да, кстати, никто не расскажет, как всё-таки правильно создавать базу в нужной кодировке и работать с ней в MySQL 4.1+? Например, я хочу отдавать данные в базу в UTF-8 и принимать тоже в UTF-8. Как это сделать наиболее правильно с точки зрения работы с MySQL?
4. # Убераем лишние пробелы и делаем двойное шифрование
$password = md5(md5(trim($_POST['password'])));
Опасно как-то пароль изменять, пользователь пусть лучше два раза пароль вводит при регистрации.
$password = md5(md5(trim($_POST['password'])));
Опасно как-то пароль изменять, пользователь пусть лучше два раза пароль вводит при регистрации.
Это уже со стороны юзабилити. Но я не когда не слышал, чтобы использовали пробелы в начале или конце пароля. Пробелы могут появиться к примеру, если у человека длинный пароль в виде "jox8fwJamUaX72" и он его сохраняет на ПК в текстовом документе. А при копировании его случайно копирует пробел, который после пароля или до пароля. Разные ситуации бывают.
Я так делаю уже больше двух лет. Выделяю даблкликом :)
далеко не все такие опытные :)
Небезопасно.
Почему бы не использовать какой-нибудь KeePass, он и пароли хранит зашифровано, и копи-пастить правильно сам умеет (:
Почему бы не использовать какой-нибудь KeePass, он и пароли хранит зашифровано, и копи-пастить правильно сам умеет (:
Даблклик имеет свойство захватывать пробел, следующий за словом. Очень от софта зависит.
Я иногда в качестве «хоть какого-то» пароля использую два пробела.
>Хочу отметить, что здесь я рассматривал авторизацию основоную на cookies,
основоную?
>не стоит в комментариях кричать, что сессии лучше/удобнее и т.д. Спасибо.
Вообще-то браузеры без кук почти не используются (насчет lynx я не уверен). Правда, если речь идет о мобильных сайтах (для WAP, PDA), то там куки могут и не работать, поэтому там лучше ИД сессий, тем более, что их индексация роли не играет.
основоную?
>не стоит в комментариях кричать, что сессии лучше/удобнее и т.д. Спасибо.
Вообще-то браузеры без кук почти не используются (насчет lynx я не уверен). Правда, если речь идет о мобильных сайтах (для WAP, PDA), то там куки могут и не работать, поэтому там лучше ИД сессий, тем более, что их индексация роли не играет.
Убирать пробелы по краям, ИМХО, стоит. Юзер может спокойно копировать свой логин/пароль откуда-нибудь и благополучно зацепить в наследство этих самых пробелов. В то же время непробельная часть логина/пароля будет верной. Так зачем же мучить пользователя и тыкать его носом в повисшие пробелы?
И ещё не зыбать про гадость типа magic_quotes, а то начнут плодиться слеши.
Спасибо большое за статью. Я недавно изучаю PHP, но свою форму регистрации уже написал. Благодоря вашей статье буду её перерабатывать. Ещё раз спасибо.
Спасибо. Как раз сейчас пишу форму. Спасибо за напоминание. Плюс в карму однозначно.
Всё, что отдайт MD5 заведомо имеет длину 32 байта ( 16 если точнее, но это частности )
Поэтому поля pass и hash необходимо из varchar(32) перевести в char(32)
Поэтому поля pass и hash необходимо из varchar(32) перевести в char(32)
Зря, вы, господин jiexaspb, взялись за обучение новичков не разобравшись в деле досконально.
Потом с сайтов этих новичков пароли будут тырить только в путь.
Пока что более оптимального варианта с хранинем сессии для каждого аккаунта не придумали.
Потом с сайтов этих новичков пароли будут тырить только в путь.
Пока что более оптимального варианта с хранинем сессии для каждого аккаунта не придумали.
Можно узнать, чем данный метод хуже сессии?
Данный метод лучше =) Но только если он реализован нормально.
А сессии это лузерство.
А сессии это лузерство.
Не могли бы вы мне постучать в ICQ 863898, написав теоритически все основные недостатки, чтобы я переписал статью, описав в ней идеальный метод.
Не мог бы =)
Во-первых, я не очень общительный и новые контакты завожу неохотно.
Во-вторых, логику я описал уже внизу, дальше фантазируйте сами. Perl я не знал, да ещё и забыл.
В-третьих, есть отличная статья.
А лучше данный метод тем, что меньше соблазнов делать абсолютно немасштабируемое приложение.
Во-первых, я не очень общительный и новые контакты завожу неохотно.
Во-вторых, логику я описал уже внизу, дальше фантазируйте сами. Perl я не знал, да ещё и забыл.
В-третьих, есть отличная статья.
А лучше данный метод тем, что меньше соблазнов делать абсолютно немасштабируемое приложение.
отличная статья, спасибо
заплюсовала, карму подняла
но единственная просьба - посвятите, пожалуйста, 15 минут своего времени изучению правил написания "ться" и "тся" в глаголах, оно несложное.
очень глаз режет :-(
заплюсовала, карму подняла
но единственная просьба - посвятите, пожалуйста, 15 минут своего времени изучению правил написания "ться" и "тся" в глаголах, оно несложное.
очень глаз режет :-(
Из-за невнимательности программиста, во всей системе могут быть дырки, воспользовавшийсь этими дырками, злоумышленик может вытащить хеш пароля из БД и подставить его в свои куки, тем самым получить доступ к закрытым данным.
смешно. если есть доступ к базе, то в неё можно и пароль новый записать, а потом и войти и сделать что угодно.
Также двойной ли хеш он, тройной ли - неважно. От этого сложность и скорость расшифровки хеша не будет зависеть.
Также как вы будете вспоминать пользователя? По привязке к случайной строке? Мало..мало информации вы привязали о конкретном пользователе в куку. Туда желательно ещё привязать время последнего входа.
да и незачем создавать две куки. Это лишнее.
Лично я применяю вспоминание пользователя по куке, где логин уже примешан.
Также советую применять сессию для 24-ёх минутного запоминания пользователя (или пока браузер не закроет) - снижает нагрузку на БД.
Лишнее поле в БД - хеш. Можно использовать время последнего доступа.
Всем успехов.
> смешно. если есть доступ к базе, то в неё можно и пароль новый записать, а потом и войти и сделать что угодно.
SQL injection бывают разные.
> Также двойной ли хеш он, тройной ли - неважно. От этого сложность и скорость расшифровки хеша не будет зависеть.
"Time-space tradeoff" гуглите. MD5(абсолютно_любая_строка_меньше_некоторой_длины) я расшифрую _вмиг_ с его помощью без полного перебора, а вот MD5(MD5(...)) уже нет.
SQL injection бывают разные.
> Также двойной ли хеш он, тройной ли - неважно. От этого сложность и скорость расшифровки хеша не будет зависеть.
"Time-space tradeoff" гуглите. MD5(абсолютно_любая_строка_меньше_некоторой_длины) я расшифрую _вмиг_ с его помощью без полного перебора, а вот MD5(MD5(...)) уже нет.
спасибо за поддержку
Интересно как ))) Если для вас это так просто можно небольшой тест? 6a050fe5329c44c53f2c7f1795b3f322
К сожалению, результата нет. Не могли бы вы раскрыть исходную строку? Как вы получили хеш?
Может из-за кириллицы? Строка была "лябози" (без ковычек). Получил простым echo md5('лябози');
Да, таблицы у меня без кириллицы.
Ну давайте без кириллицы попробуем :) 8c930a2f0660e102d9ee7a1eeda504f4
"bionium" без кавычек.
Не ожидал :) круто. Сам писал или готовое решение нашёл? Думаю если бы присутствовали цифры и знаки пунктуации врядли бы нашлась отгадка но всё равно уважуха :)
http://en.wikipedia.org/wiki/Rainbow_table что это такое
http://rainbowtables.shmoo.com/ скачать исходные коды программ
Ответ можно найти всегда (99.9%), нужно только сгенерировать таблицы с нужными параметрами. Только вот таблицы для длинных строк или больших наборов символов будут занимать уж очень много места.
http://rainbowtables.shmoo.com/ скачать исходные коды программ
Ответ можно найти всегда (99.9%), нужно только сгенерировать таблицы с нужными параметрами. Только вот таблицы для длинных строк или больших наборов символов будут занимать уж очень много места.
md5(md5($pass)) - можно расшифровать, но сложно
md5(md5($pass.$addkey)) - еще сложнее (где $addkey = const)
Так просто, на заметку ;)
md5(md5($pass.$addkey)) - еще сложнее (где $addkey = const)
Так просто, на заметку ;)
Чем сложнее расшифровывать md5(md5()) по сравнению с md5(), при услови что код открытый (т.е. известно как вычислялся хеш)? ведь в обоих случаях можно взять словарь паролей, вычислить по нему хеши и посмотреть есть ли совпадения.
С addkey это уже действительно другой разговор, но как обеспечить его секретность, злоумышленник ведь может получить доступ к файлам на сервере?
С addkey это уже действительно другой разговор, но как обеспечить его секретность, злоумышленник ведь может получить доступ к файлам на сервере?
Только тем, что в словаре врядли будут хэши для 32 разрядных паролей
а зачем они там, злоумышленник значет что у нас хеш md5(md5()) и им же генерирует хеши, по обычным паролям
Time-space tradeoff это восстановление зашифрованной строки при помощи таблиц, которые генерируются заранее. Таблицы генерируются для определённого набора символа и длины исходного текста, отсюда и название time-space tradeoff, то есть мы время полного брутфорса размениваем на генерацию таблиц (rainbow tables).
addkey называется соль. Если соль будет включать, например, большие и маленькие буквы и спецсимволы, то таблицы ranbow tables тоже должны быть сгенерированы для этого набора символов, хотя пусть сам пароль состоит из одних только цифр. А таблицы для больших наборов символов занимают очень много места. А для длинных строк ещё больше, на порядки. Увеличиваем длину соли и в какой-то момент получается так, что даже 6-значный пароль из одних цифр уже не реально восстановить из хеша с солью по таблицам.
addkey называется соль. Если соль будет включать, например, большие и маленькие буквы и спецсимволы, то таблицы ranbow tables тоже должны быть сгенерированы для этого набора символов, хотя пусть сам пароль состоит из одних только цифр. А таблицы для больших наборов символов занимают очень много места. А для длинных строк ещё больше, на порядки. Увеличиваем длину соли и в какой-то момент получается так, что даже 6-значный пароль из одних цифр уже не реально восстановить из хеша с солью по таблицам.
Вообще, рекомендую обратить внимание на сайт http://www.openwall.com/phpass/
Автор сайта 10 лет в шифровании =) Реально интересно и полезно
Автор сайта 10 лет в шифровании =) Реально интересно и полезно
md5($pass.$addkey.time()) также сложно.
1. >В нашем же случае, двойной хеш пароля не чем не сможет помочь хакеру
"береженого бог бережет, думала монашка надевая презерватив на свечку".
2. иногда лучше жевать, чем говорить. лучш не давайте советов, если не полностью разбираетесь в вопросе. и тем более не давайте в таких случаях советов новичкам.
"береженого бог бережет, думала монашка надевая презерватив на свечку".
2. иногда лучше жевать, чем говорить. лучш не давайте советов, если не полностью разбираетесь в вопросе. и тем более не давайте в таких случаях советов новичкам.
иногда лучше не просто говорить, а приводить аргументы.
1. выше и ниже моего поста вполне достаточно аргументов.
2. учить надо тому, в чем реально разбираешься. стиль кода и вопросы типа "чем данный способ хуже сессий" - выдают с головой.
3. не надо учить как проще. надо учить как правильно.
4. я вполне могу оценить уровень "статьи" и сказать что она чертовски далека до уровня http://phpfaq.ru/
хватит?
2. учить надо тому, в чем реально разбираешься. стиль кода и вопросы типа "чем данный способ хуже сессий" - выдают с головой.
3. не надо учить как проще. надо учить как правильно.
4. я вполне могу оценить уровень "статьи" и сказать что она чертовски далека до уровня http://phpfaq.ru/
хватит?
long имел в виду, что такие статьи лучше писать в свой блог, а не коллективный =)
Гуглите "time-space tradeoff".
если иметются ввиду коллизии, то это никакого отношения к востановлению зашифрованной записи не имеет. они будут вне зависимости от уровня вложенности. иначе у нас бы получился суперархиватор. реально может спасти только добавление к исходному зашифровываемому тексту некой строки. см. общий алгоритм работы с эцп.
Это не коллизии. Это восстановление зашифрованной строки при помощи таблиц, которые генерируются заранее. Таблицы генерируются для определённого набора символа и длины исходного текста, отсюда и название time-space tradeoff, то есть мы время полного брутфорса размениваем на генерацию таблиц (rainbow tables).
>>они(коллизии) будут вне зависимости от уровня вложенности. иначе у нас бы получился суперархиватор.
Коллизии будут обязательно, но хэш-функция может быть такой, что H(t1)=H(t2), при t1!=t2 и при t1 много меньше t2. То есть, для конкретной задачи, нам не важно, что хэш от пароля в восемь символов совпадёт с хэшем от пароля в 100 символов, ибо длина пароля в любом случае должна быть ограничена разумным числом символов. Значит мы никогда не обнаружим коллизий в конкретной реализации.
Коллизии будут обязательно, но хэш-функция может быть такой, что H(t1)=H(t2), при t1!=t2 и при t1 много меньше t2. То есть, для конкретной задачи, нам не важно, что хэш от пароля в восемь символов совпадёт с хэшем от пароля в 100 символов, ибо длина пароля в любом случае должна быть ограничена разумным числом символов. Значит мы никогда не обнаружим коллизий в конкретной реализации.
В вашем условии (в последнем if) закралась одна ошибка.
Поясню.
Вот это условие:
if(($userdata['user_hash'] !== $_COOKIE['hash']) or ($userdata['user_id'] !== $_COOKIE['id'])
and (($data['user_ip'] == $_SERVER['REMOTE_ADDR']) or ($data['user_ip'] == "0"))) { ....
Порядок его вычисления следующий:
1. проверяем условие слева от оператора AND: "$userdata['user_id'] !== $_COOKIE['id']" - предположим ID совпали, т.е. условие дает FALSE
2. выражение справа от AND даже проверяться не будет, т.к. FALSE AND "что-то" = FALSE
т.е. теряется всякое условие на IP!!!
Вот так наверно правильнее:
if(($userdata['user_hash'] !== $_COOKIE['hash']) or ($userdata['user_id'] !== $_COOKIE['id'])
or ($data['user_ip'] !== $_SERVER['REMOTE_ADDR']) and ($data['user_ip'] !== "0")) { ....
Поясню.
Вот это условие:
if(($userdata['user_hash'] !== $_COOKIE['hash']) or ($userdata['user_id'] !== $_COOKIE['id'])
and (($data['user_ip'] == $_SERVER['REMOTE_ADDR']) or ($data['user_ip'] == "0"))) { ....
Порядок его вычисления следующий:
1. проверяем условие слева от оператора AND: "$userdata['user_id'] !== $_COOKIE['id']" - предположим ID совпали, т.е. условие дает FALSE
2. выражение справа от AND даже проверяться не будет, т.к. FALSE AND "что-то" = FALSE
т.е. теряется всякое условие на IP!!!
Вот так наверно правильнее:
if(($userdata['user_hash'] !== $_COOKIE['hash']) or ($userdata['user_id'] !== $_COOKIE['id'])
or ($data['user_ip'] !== $_SERVER['REMOTE_ADDR']) and ($data['user_ip'] !== "0")) { ....
Жуть.
Автор, это не ты случаем предлагаешь на http://supercreativ.narod.ru/ обучение занедорого? =)
Во-первых, тестил, небось, на двух записях в таблице, да? Где уникальный индекс на поле с логином? Знаешь, во сто крат надёжнее, правильнее и красивее иметь уникальный индекс, а не выделываться с лотереей "а вдруг никто не успеет между select и insert вставить запись с таким же логином". И select в функции регистрации нафиг не нужен сразу становится, а чем меньше запросов к БД, тем дольше живёшь.
Во-вторых, что это за такой мегарулез, каждый раз лазить в базу для аутентификации? Дешевле зашифровать в куку подписанные нужные данные. Масштабировать БД существенно сложнее, чем масштабировать BL. В случае, когда кто-нибудь начнёт присылать вам в куках какой-нибудь мусор, ни один аутентифицированный пользователь не сможет зайти на сайт, потому что забьют мусором коннекшены к БД пользователей. Дешифровать небольшую строку и проверить подпись существенно быстрее, чем сделать запрос к БД.
В-третьих, сколько уже можно писать код для SQL-инъекций? Я не верю, что DBI перестал поддерживать параметры (мегаязык Perl не использую уже лет пять). Это _единственный_ способ обезопасить себя от SQL-инъекции. А смехопанорамные проверки регэкспами и эскейпы ерунда.
В-чётвёртых, строка $login = $_POST['login']; идёт хрен знает какой по всему коду. Я не понимаю, зачем везде использовать "$_POST['login']", это же каждый встреченный раз даёт возможность на опечатку!
В-пятых, в-шестых, в-седьмых, ..., в-стовосемдесятдевятых - всё это есть в куче книг и статей. Ё-маё, уже в переводах есть практически любая западная литература. Почему вы бросаетесь решать какие-то мегапроблемы мегазащит от мегахакеров не умея кодировать?!
Да ещё авторизация. Я плачу. Какая это авторизация? То, что описано выше, это аутентификация. А авторизация начнётся, когда автор сделает аналог ACL. В самом тривиальном случае авторизации Id пользователя надо хоть с чем-нибудь сравнить, чтобы понять, давать ему доступ к функциональности или не давать.
Автор, это не ты случаем предлагаешь на http://supercreativ.narod.ru/ обучение занедорого? =)
Во-первых, тестил, небось, на двух записях в таблице, да? Где уникальный индекс на поле с логином? Знаешь, во сто крат надёжнее, правильнее и красивее иметь уникальный индекс, а не выделываться с лотереей "а вдруг никто не успеет между select и insert вставить запись с таким же логином". И select в функции регистрации нафиг не нужен сразу становится, а чем меньше запросов к БД, тем дольше живёшь.
Во-вторых, что это за такой мегарулез, каждый раз лазить в базу для аутентификации? Дешевле зашифровать в куку подписанные нужные данные. Масштабировать БД существенно сложнее, чем масштабировать BL. В случае, когда кто-нибудь начнёт присылать вам в куках какой-нибудь мусор, ни один аутентифицированный пользователь не сможет зайти на сайт, потому что забьют мусором коннекшены к БД пользователей. Дешифровать небольшую строку и проверить подпись существенно быстрее, чем сделать запрос к БД.
В-третьих, сколько уже можно писать код для SQL-инъекций? Я не верю, что DBI перестал поддерживать параметры (мегаязык Perl не использую уже лет пять). Это _единственный_ способ обезопасить себя от SQL-инъекции. А смехопанорамные проверки регэкспами и эскейпы ерунда.
В-чётвёртых, строка $login = $_POST['login']; идёт хрен знает какой по всему коду. Я не понимаю, зачем везде использовать "$_POST['login']", это же каждый встреченный раз даёт возможность на опечатку!
В-пятых, в-шестых, в-седьмых, ..., в-стовосемдесятдевятых - всё это есть в куче книг и статей. Ё-маё, уже в переводах есть практически любая западная литература. Почему вы бросаетесь решать какие-то мегапроблемы мегазащит от мегахакеров не умея кодировать?!
Да ещё авторизация. Я плачу. Какая это авторизация? То, что описано выше, это аутентификация. А авторизация начнётся, когда автор сделает аналог ACL. В самом тривиальном случае авторизации Id пользователя надо хоть с чем-нибудь сравнить, чтобы понять, давать ему доступ к функциональности или не давать.
> Во-вторых, что это за такой мегарулез, каждый раз лазить в базу для
> аутентификации? Дешевле зашифровать в куку подписанные нужные данные.
> Масштабировать БД существенно сложнее, чем масштабировать BL. В случае,
> когда кто-нибудь начнёт присылать вам в куках какой-нибудь мусор, ни
> один аутентифицированный пользователь не сможет зайти на сайт, потому
> что забьют мусором коннекшены к БД пользователей. Дешифровать небольшую
> строку и проверить подпись существенно быстрее, чем сделать запрос к БД.
А можно подробнее об этом?
> В-третьих, сколько уже можно писать код для SQL-инъекций? Я не верю, что DBI
> перестал поддерживать параметры (мегаязык Perl не использую уже лет пять). Это
> _единственный_ способ обезопасить себя от SQL-инъекции. А смехопанорамные
> проверки регэкспами и эскейпы ерунда.
Параметры,.. это то что называют плейсхолдерами?
> аутентификации? Дешевле зашифровать в куку подписанные нужные данные.
> Масштабировать БД существенно сложнее, чем масштабировать BL. В случае,
> когда кто-нибудь начнёт присылать вам в куках какой-нибудь мусор, ни
> один аутентифицированный пользователь не сможет зайти на сайт, потому
> что забьют мусором коннекшены к БД пользователей. Дешифровать небольшую
> строку и проверить подпись существенно быстрее, чем сделать запрос к БД.
А можно подробнее об этом?
> В-третьих, сколько уже можно писать код для SQL-инъекций? Я не верю, что DBI
> перестал поддерживать параметры (мегаязык Perl не использую уже лет пять). Это
> _единственный_ способ обезопасить себя от SQL-инъекции. А смехопанорамные
> проверки регэкспами и эскейпы ерунда.
Параметры,.. это то что называют плейсхолдерами?
Да вот мне тоже интересно по поводу подписи данных...
Цифровая подпись данных в данном случае - пролетает.
Полюбому нужно сравнивать с БД. Иначе, пользователь один раз залогинится, его удалят из БД, а он все-равно будет как бы свой
Полюбому нужно сравнивать с БД. Иначе, пользователь один раз залогинится, его удалят из БД, а он все-равно будет как бы свой
Ну зачем такой жесткач. Либо всё время доверять кукам, либо всё время лазить в БД.
Совместное использование неприемлемо? Сравнивайте с БД на здоровье. Но не каждый хит, а, скажем, раз в час.
Но Вы, вероятно, не об этом, да? Цифровая подпись может быть в виде CRC32, например. Цифовая подпись и сертификат, выданный в каком-нибудь Verisign, не синонимы.
Задача цифровой подписи - подтвердить валидность данных. В случае с электронным письмом, например, имеет значение не только гарантия валидности данных (неизменности текста письма), но и гарантия валидности отправителя - сертификат решает обе эти задачи.
Совместное использование неприемлемо? Сравнивайте с БД на здоровье. Но не каждый хит, а, скажем, раз в час.
Но Вы, вероятно, не об этом, да? Цифровая подпись может быть в виде CRC32, например. Цифовая подпись и сертификат, выданный в каком-нибудь Verisign, не синонимы.
Задача цифровой подписи - подтвердить валидность данных. В случае с электронным письмом, например, имеет значение не только гарантия валидности данных (неизменности текста письма), но и гарантия валидности отправителя - сертификат решает обе эти задачи.
Подпись нужна, чтобы узнать, что данные не мусор.
Подробнее о чём? И что за подробности нужны?
Про плейсхолдеры - это кто по что горазд. Обычно они вопросами вставляются в запросы. Вероятно, терминология в разных фреймворках различается.
Про плейсхолдеры - это кто по что горазд. Обычно они вопросами вставляются в запросы. Вероятно, терминология в разных фреймворках различается.
О том, как шифровать и подписывать, если лень расказывать, дайте, пожалуйста ссылку, иил ключевые слова, по которым искать.
Как шифровать - по реализации не знаю, я на PHP ни строчки кода не написал.
А алгоритм простой - сначала сериализуете данные в массив байт, добавляете подпись (например, CRC32), шифруете (например, AES), кодируете в base64 и полученную строку пишите в куку.
Обратно, соответственно, декодируете из base64, дешифруете, разворачиваете в массив байт и подпись, проверяете валидность данных (для CRC32 заново считаете его и сравниваете со значением после дешифрования) и дальше продолжаете работу с данными, если они валидные. Или не продолжаете, если они невалидные.
А алгоритм простой - сначала сериализуете данные в массив байт, добавляете подпись (например, CRC32), шифруете (например, AES), кодируете в base64 и полученную строку пишите в куку.
Обратно, соответственно, декодируете из base64, дешифруете, разворачиваете в массив байт и подпись, проверяете валидность данных (для CRC32 заново считаете его и сравниваете со значением после дешифрования) и дальше продолжаете работу с данными, если они валидные. Или не продолжаете, если они невалидные.
+1 base64 ещё к тому же можно искусственно "сломать", но с возможностью обратного восстановления. Тут однако следует предотвратить возможность кражи куки.
Вообще сей способ можно описать проще "юзеру выдается некий доверительный сертификат, содержащий все необходимые данные о нём, но который должен быть неработоспособен при искусственном перемещений в другой браузер/на другую машину".
Вообще сей способ можно описать проще "юзеру выдается некий доверительный сертификат, содержащий все необходимые данные о нём, но который должен быть неработоспособен при искусственном перемещений в другой браузер/на другую машину".
>Я не верю, что DBI перестал поддерживать параметры (мегаязык Perl не использую уже лет пять).
DBI не перестал. Только это не мегазяык Perl, а супермегаязык пхп :). Его и так недоучки делали, которые не поняли что и для чего было сделано в перле, но что касается работы с БД - тут они сами себя превзошли. Там отродясь для каждой БД свой собственный набор функций. А до того, чтобы передавать параметры запроса параметрами функции эти умники за 10 лет мегабурного развития языка так и не додумались. Поэтому каждый, кому выпало пхп-шное щастье либо прикручивает какое-то самодельное подобие (да, да, с помощью смехопанорамных регэкспов и эскейпов), либо... не прикручивает и все мы в курсе количества сайтов, ломаемых инъекцией :).
DBI не перестал. Только это не мегазяык Perl, а супермегаязык пхп :). Его и так недоучки делали, которые не поняли что и для чего было сделано в перле, но что касается работы с БД - тут они сами себя превзошли. Там отродясь для каждой БД свой собственный набор функций. А до того, чтобы передавать параметры запроса параметрами функции эти умники за 10 лет мегабурного развития языка так и не додумались. Поэтому каждый, кому выпало пхп-шное щастье либо прикручивает какое-то самодельное подобие (да, да, с помощью смехопанорамных регэкспов и эскейпов), либо... не прикручивает и все мы в курсе количества сайтов, ломаемых инъекцией :).
Ага, уже понял. Заголовок сообщества почему-то ушёл из внимания, а код похож на перловый. Чтобы в следующий раз не забывал, куда пишу, в карму уже наминусовали =)
Вообще-то для этого есть PEAR::DB
А еще грамотные пхпшники используют нормальные средства такие как PDO или в крайнем случае mysqli. И то и другое уже года с бородатого php5.0 есть.
Представьте, что я — злоумышленник.
Что помешает мне на моем сайте получить значения id и hash из cookie, когда вы ко мне зайдете, а потом подделать cookie на своей машине и зайти королем на ваш сайт?
Потом, как уже говорилось выше, каждый раз лазить в БД за данными об авторизации — это слишком накладно.
Хотя, я в общем-то рад, что появляются такие статьи. Это значит, что люди учатся. Некоторые на своих ошибках, некоторые на чужих.
Как говорится, если у человека есть желание, он ищет возможности, если нет желания, он ищет причины...
Спасибо за то, что ищете для себя возможности.
Что помешает мне на моем сайте получить значения id и hash из cookie, когда вы ко мне зайдете, а потом подделать cookie на своей машине и зайти королем на ваш сайт?
Потом, как уже говорилось выше, каждый раз лазить в БД за данными об авторизации — это слишком накладно.
Хотя, я в общем-то рад, что появляются такие статьи. Это значит, что люди учатся. Некоторые на своих ошибках, некоторые на чужих.
Как говорится, если у человека есть желание, он ищет возможности, если нет желания, он ищет причины...
Спасибо за то, что ищете для себя возможности.
А как Вы собираетесь на своём сайте получить куки прописанные для другого сайта?
А в предложенном коде они "прописаны" для другого сайта?
вообще то они автоматом прикручиваються к домену. http://ru2.php.net/setcookie
т.е. вы хотите сказать, что так установленные куки будут транслироваться на все сайты, на которые заходит пользователь дальше?
в данном коде кука ставится на текущий домен проекта, где установлены скрипты, потому что путь не указан в функции setcookie().
Я придумал атаку.
Давайте представим, что злоумышленник таки украл базу. Получается, что он знает $hash вообще всех пользователей, а так как проверяется именно он, то его нужно просто подставить в cookie, а пароль даже и не нужен. Выход:
* в базу сохранять MD5(случайная строка), а пользователю в куки отдаём эту случайную строку. Потом сверяем. Если кто-то украдёт базу, то получит только MD5 от случайных строк, которые ни перебором, ни словарём, ни rainbow tables (при условии достаточной длины) не расколоть.
* в базу сохранять время действия логина, не надеяться на то, что куки будут затёрты автоматически
Давайте представим, что злоумышленник таки украл базу. Получается, что он знает $hash вообще всех пользователей, а так как проверяется именно он, то его нужно просто подставить в cookie, а пароль даже и не нужен. Выход:
* в базу сохранять MD5(случайная строка), а пользователю в куки отдаём эту случайную строку. Потом сверяем. Если кто-то украдёт базу, то получит только MD5 от случайных строк, которые ни перебором, ни словарём, ни rainbow tables (при условии достаточной длины) не расколоть.
* в базу сохранять время действия логина, не надеяться на то, что куки будут затёрты автоматически
Хоть сама статья и не дала мне ничего нового, комментарии набросившихся на бедного автора людей иногда было интересно читать, ценные замечания. Расстраивает только, что некоторые всеми способами норовят оскорбить, как будто этим доказывая свое превосходство и ум, как дети, ей-богу. А автору спасибо, что поднял тему.
Непонятно для чего так изголялся. Кто мешает использовать более стойкий хеш sha1? Можно так-же к паролю на входе перед хешированием добавлять некую secret string.
А как этот string сделать secret, я уже где-то на хабре предлагал генерировать нестандартный хеш или стандартный хеш от измененного пароля и меня просветили, что все, что лежит на сервере может в любой момент стать несекретным.
Я, конечно, не спец, но пароли пользователей оригинальность обычно не отличаются и можно по хорошему словарю нагенерировать хешей (хоть sha1, хоть md5) заранее, а когда в руки попадет база, только проверить, нет ли в ней известных хешей, а для md5(md5(pass)) генерить придется слишком дофига, это немного компенсирует невозможность заставить пользователя выбирать пароль по всем правилам.
Я, конечно, не спец, но пароли пользователей оригинальность обычно не отличаются и можно по хорошему словарю нагенерировать хешей (хоть sha1, хоть md5) заранее, а когда в руки попадет база, только проверить, нет ли в ней известных хешей, а для md5(md5(pass)) генерить придется слишком дофига, это немного компенсирует невозможность заставить пользователя выбирать пароль по всем правилам.
что-то я затупил насчет md5(md5()) подобрать его не сложнее остальных
Скажите, как вы подбираете md5? Я, может, что-то пропустил и появился некий универсальный быстрый декодер?=)
Универсального декодера, конечно, нет, но для прикладных задач, подходят вот такие http://passcracking.ru/ru/index.php сервисы с готовыми базами хешей, в том числе md5(md5(pass)), ведь у реальных пользователей простые пароли.
Пока PHP программисты из Виллабаджо изобретают велосипеды, Python программисты из Вилларибо уже давно на них катаются.
А вообще все подобные вопросы давно рассмотрены и хорошо представлены на http://phpclub.ru/ (особенно полезно почитать форум)
Мелочь:
я бы заменил на
Действовать будет быстрее, а эффект почти не изменится.
if(!preg_match("/^[a-zA-Z0-9]+$/",$_POST['login']))я бы заменил на
if(!ctype_alnum($_POST['login']))Действовать будет быстрее, а эффект почти не изменится.
В последнем своем проекте использовал HTTP Аутентификацию.
С точки зрения программиста это удобней, так как надо значительно меньше кода, но зато логин идет в попап окне, и контроля над процессом нет.
Может ктонибудь может сказать а с точки зрения безопасности. Устойчива ли HTTP аутентификация?
С точки зрения программиста это удобней, так как надо значительно меньше кода, но зато логин идет в попап окне, и контроля над процессом нет.
Может ктонибудь может сказать а с точки зрения безопасности. Устойчива ли HTTP аутентификация?
Да, я думаю она устойчивая, только не гибкая и не удобная
Ну, с одной стороны, это встроенный инструмент сервера. Т.е. трудозатраты на реализацию минимальны.
С другой стороны, как вы правильно отметили, нет контроля на процессом.
Что же касается устойчивости, то такая аутентификация в исходном своем виде не защищает от, например, брутфорс атак. И тут уже приходится извращаться (например, вешать обработчик на 401 ошибку).
В общем, если вам нужно закрыть мембер зону на порно сайте, то это подойдет (кому нужно, все равно взломают, что туда не прикрути). А если вы закрываете панель управления от серьезной системы, тот тут лучше не полениться написать действительно хороший алгоритм авторизации.
С другой стороны, как вы правильно отметили, нет контроля на процессом.
Что же касается устойчивости, то такая аутентификация в исходном своем виде не защищает от, например, брутфорс атак. И тут уже приходится извращаться (например, вешать обработчик на 401 ошибку).
В общем, если вам нужно закрыть мембер зону на порно сайте, то это подойдет (кому нужно, все равно взломают, что туда не прикрути). А если вы закрываете панель управления от серьезной системы, тот тут лучше не полениться написать действительно хороший алгоритм авторизации.
смотря какая. если basic, то не очень. пароль передаётся в открытом виде ПРИ КАЖДОМ запросе страниц.
если digest, то чуть надёжнее - пароль шифруется в хеш-функции , да ещё есть дополнительная защита по времени и по домену.
надёжнее всего авторизация через https-соединение, затем установка сессии, куки. и дальнейшая работа.
если digest, то чуть надёжнее - пароль шифруется в хеш-функции , да ещё есть дополнительная защита по времени и по домену.
надёжнее всего авторизация через https-соединение, затем установка сессии, куки. и дальнейшая работа.
Ужасное написание кода. Про ООП когда-нить слышали?
Слышал. Глаза вверх поднимите, и прочитайте что написано первой строкой.
Нужно изначально подготавливать молодое поколение на написание нормального кода, а не, извините, этого говна.
Элементарно - завтра я захочу поменять, например, пароль доступа к базе данных, и что - нужно будет переписывать везде пароль? Это бред. Как минимум чего не хватает в статье - это одного общего файла
Элементарно - завтра я захочу поменять, например, пароль доступа к базе данных, и что - нужно будет переписывать везде пароль? Это бред. Как минимум чего не хватает в статье - это одного общего файла
Тут-же сказано для начинающих! Врятли начинающий на PHP, я подчеркиваю на PHP, будет знать о ООП.
Нормально написание.
Для простого случая ООП будет только увеличивать колличество строк и усложнять логику. Тем более статья показывает как делается авторизация, метод, принцип, логика etc.
Да и какое здесь может быть ООП, в этом пимере? Писать класс, чтобы реализовать в нем один метод? Если вы спец, сами внесете эту логику в структуру классов своего проекта.
Не надо делать из ООП фетишь
Для простого случая ООП будет только увеличивать колличество строк и усложнять логику. Тем более статья показывает как делается авторизация, метод, принцип, логика etc.
Да и какое здесь может быть ООП, в этом пимере? Писать класс, чтобы реализовать в нем один метод? Если вы спец, сами внесете эту логику в структуру классов своего проекта.
Не надо делать из ООП фетишь
ООП здесь к чему? ;) Один файл кода или четыре, к ООП никакого отношения не имеет =)
Я бы $hash = md5(microtime().getmypid());
или md5(uniqid(rand(),true));
Нет (простой) возможности выбрать длину строки.
Поясните, в чем состоит проблема, если речь идет о хэше.
А смысл??? ))) Хэш мы получаем, чтобы сверять с БД.
Можно вообще тогда получать $hash=md5(rand(0,10000))
=)
Можно вообще тогда получать $hash=md5(rand(0,10000))
=)
спасибо за статью:)
Ошибок-то в комментариях — мама дорогая.
спасибо огромное!
как раз мне сейчас это требуется!
как раз мне сейчас это требуется!
Спасибо за статью!
Комментарии наводят на мысли в верном направлении. Без автора не было бы и комментариев.
Комментарии наводят на мысли в верном направлении. Без автора не было бы и комментариев.
после того как попробуете статью переходите изучайте PEAR:Auth
спасибо за статью,
Немного не в тему вопрос, а почему от перебора нужна капча, можно ведь просто ограничить количество попыток (например, 10 достаточно в любом нормальном случае), а потом 5 минут не принимать, пароль с этого IP?
Немного не в тему вопрос, а почему от перебора нужна капча, можно ведь просто ограничить количество попыток (например, 10 достаточно в любом нормальном случае), а потом 5 минут не принимать, пароль с этого IP?
Не однократно, сам забывал пароль, и весьма напрягает когда на 15 минут тебя отрубает, а восстанавливать и ждать на мыло пароля может быть нет желания
ну а если там большой список прокси, который меняться через каждые 5 паролей?
для дезинформарования злоумышленников можно использовать вместо md5() такой код:
function md_5($what){
return substr(sha1($what),0,32);
}
function md_5($what){
return substr(sha1($what),0,32);
}
Раньше я использовал,что-то похожее, но это абсолютно бесполезно, потому что злоумышленник может получить доступ к коду и тогда, никаких проблем с подбором паролей у него не будет, хотя в определенной ситуации это может быть полезно
Хорошая статья. Только я использую session_id(); - куки глючная штука.
Хранение в двойном md5 - тоже неплохая идея. Только нужно понимать.
Если человек имеет доступ к БД (чужой человек). И от туда узнает ваш md5 - пароля. Ему легче поменять на свой пароль. :) Наделать глупостей. А потом вернуть ваш старый. Так-что двойном md5 - не спасёт.
Хранение в двойном md5 - тоже неплохая идея. Только нужно понимать.
Если человек имеет доступ к БД (чужой человек). И от туда узнает ваш md5 - пароля. Ему легче поменять на свой пароль. :) Наделать глупостей. А потом вернуть ваш старый. Так-что двойном md5 - не спасёт.
Хорошая статья. Запомнил себе. Буду применять подобное решение вместе с сессиями.
За http://captcha.ru/ - отдельное спасибо.
За http://captcha.ru/ - отдельное спасибо.
Не плохо, но растянуто =) чет как-то шибко много кода.
setcookie("id", "", time() - 3600*24*30*12, "/");
=) кука убьется обычным setcookie("id", "");
setcookie("id", "", time() - 3600*24*30*12, "/");
=) кука убьется обычным setcookie("id", "");
куки удалится только в том случае, если время создания её будет в прошлом. поэтому нужно писать не только time() - время_жизни_куки, но и time() - (время_жизни_куки+1).
учите матчасть. Достаточно обнулить куку, любой бразуер подобную пустоту тут же прибьет.
не верите мне - поставте себе FF, установите плаг Tamper Data и глянте что в заголовках отдаст web сервер, который получает от php setcookie с пустым значением.
P.S. даже если представить, что вы правы, какого черта мне заставлять машину считать какое-то время, если явно 0 меньше времени создания куки? Т.е. зачем городить time()-3600*24*31 и прочее, когда в вашем случае, если уж вас не устраивает пустое значение, достаточно поставить 0?
бред.
не верите мне - поставте себе FF, установите плаг Tamper Data и глянте что в заголовках отдаст web сервер, который получает от php setcookie с пустым значением.
P.S. даже если представить, что вы правы, какого черта мне заставлять машину считать какое-то время, если явно 0 меньше времени создания куки? Т.е. зачем городить time()-3600*24*31 и прочее, когда в вашем случае, если уж вас не устраивает пустое значение, достаточно поставить 0?
бред.
цитирую учебник
"When deleting a cookie you should assure that the expiration date is in the past, to trigger the removal mechanism in your browser"
и это не голословное утверждение. можно не то что представлять, что я прав, а просто попробовать, перед тем, как утврждать что-то, да ещё и судить.
успехов вам.
"When deleting a cookie you should assure that the expiration date is in the past, to trigger the removal mechanism in your browser"
и это не голословное утверждение. можно не то что представлять, что я прав, а просто попробовать, перед тем, как утврждать что-то, да ещё и судить.
успехов вам.
Во-первых, проверяйте сами. 5 лет делаю веб и всегда именно так тру куки, никогда небыло проблем. Во-вторых, цитата из учебника говорит о одном из способ удаления куки — установки даты expiries в прошедшем (хочу заетить, при этом достаточно поставить дату 0 или time()-1, если вам так нравится функция time(), но никак не то, что вы предлогаете).
Ну и на последок, помните, все что пишут учебники — это теория. На практике часто web сервера и клиентские браузеры ведут себя по разному. И не факт, что то, что написано в чебнике, будет работать у всех поголовно пользователей.
Ну и на последок, помните, все что пишут учебники — это теория. На практике часто web сервера и клиентские браузеры ведут себя по разному. И не факт, что то, что написано в чебнике, будет работать у всех поголовно пользователей.
да при чём тут учебник. на днях у меня кука не удалялась ни в какую путём установки её просто в пустоту. потом попробовал ставить -время. ни в какую. удалилась только пр и установки времени в -(время+1). завтра попробую поэкспериментировать ещё разок.
=))) слушай, ты сам свой учебник процитировал. Есть лишь 3 объяснения вашему неудачному опыту с пустой кукой. Первое — у вас экзотический браузер, который игнорирует заголовки сервера. Второе — у вас был экзотический web сервер, который игнорирует то, что ем шлет php. Третье — все это вы выдумали.
Я в силу своей профессии использовал кучу браузеров и изюзал кучу хостов, в данный момент у меня свой сервак. и никогда с этим небыло проблем. Поэтому я сколняюсь более к третьему объяснению.
Я в силу своей профессии использовал кучу браузеров и изюзал кучу хостов, в данный момент у меня свой сервак. и никогда с этим небыло проблем. Поэтому я сколняюсь более к третьему объяснению.
проверил все варианты.
итог
кука удаляется при условиях, что:
1.пустое значение куки или FALSE.
2.остальные параметры те же самые, что и при установке куки (то есть путь, домен). время может быть любым.
просто вы не ставили у куки путь при установке, поэтому при удалении можно было путь и не указывать - она отлично удаляется, проверил.
итог
кука удаляется при условиях, что:
1.пустое значение куки или FALSE.
2.остальные параметры те же самые, что и при установке куки (то есть путь, домен). время может быть любым.
просто вы не ставили у куки путь при установке, поэтому при удалении можно было путь и не указывать - она отлично удаляется, проверил.
немного не верно. в случае setcookie('id', '') удалится для всех путей на данном домене. Наконец-то вы предпочли практику теории =) ура. Плюс вам.
Вы писали, что "в случае setcookie('id', '') удалится для всех путей на данном домене". Отвечаю - не удалится.
Повторяю более подробно.
Удалятся только те куки, которые были установлены без путей. Если же кука была поставлена с путём, то при удалении её без указания пути она НЕ УДАЛЯЕТСЯ. ох..
Успехов.
Повторяю более подробно.
Удалятся только те куки, которые были установлены без путей. Если же кука была поставлена с путём, то при удалении её без указания пути она НЕ УДАЛЯЕТСЯ. ох..
Успехов.
Да, соврал, если указать путь то мой способ не подходит =)
тем не менее проектов, которые пишут куки в конкретный путь - по пальцам пересчитать.
P.S. "Отвечаю - не удалится" я разве спрашивал вас о чем-то?
P.P.S. "Повторяю более подробно" более подробно расскажите зачем время ставить? именно это вы так упорно доказывали.
тем не менее проектов, которые пишут куки в конкретный путь - по пальцам пересчитать.
P.S. "Отвечаю - не удалится" я разве спрашивал вас о чем-то?
P.P.S. "Повторяю более подробно" более подробно расскажите зачем время ставить? именно это вы так упорно доказывали.
Удалится только если эта кука была поставлена этим же скриптом, или в скриптом, находящимся в той же виртуальной папке что и текущий.
Вот несколько (в принципе лежащих на поверхности) мыслей, обобщенных в общую тему о том, как обезопасить пользователей от использования потерянной куки/сессии, если пользователь выбрал опцию "запомнить": Persistent Login Cookie Best Practice, и комментарии с улучшениями идеи Improved Persistent Login Cookie Best Practice
UFO just landed and posted this here
Осталось описать безопасные методы авторизации средствами Perl, ASP, и QBasic, подключенного через CGI к апачу .)
> Какие есть предложения, имхо, от капчи избавиться необходимо, это удар по юзабилити, лишние телодвижения.
Зачем избавляться? Самый ИМХО лучший вариант... зделать просто хорошо читабельным, я например себе сделал большой шрифт и генерирую не просто набор символов, а слова из словаря:) для человека это будет легко я для компа...
Зачем избавляться? Самый ИМХО лучший вариант... зделать просто хорошо читабельным, я например себе сделал большой шрифт и генерирую не просто набор символов, а слова из словаря:) для человека это будет легко я для компа...
UFO just landed and posted this here
porca madonna putana!
К предыдущим комментаторам насчет безопасности строки -
можно ведь прицепиться, к примеру, к ip+пароль связке
т.е. делать
md5(sha1(SERVER[REMOTE_ADDR].pass))
и проверку на вход - что-то типа
select * from users where hash=^^^^
каждый раз при пользовательском обновлении страницы.
ну или чтоб базу не грузить - в те же куки записать и по кукам проверять. Или в сессии записать.
можно ведь прицепиться, к примеру, к ip+пароль связке
т.е. делать
md5(sha1(SERVER[REMOTE_ADDR].pass))
и проверку на вход - что-то типа
select * from users where hash=^^^^
каждый раз при пользовательском обновлении страницы.
ну или чтоб базу не грузить - в те же куки записать и по кукам проверять. Или в сессии записать.
Никогда не понимал подобных авторизаций...
Надо хеш - есть md5(uniqid(rand()));
Есть задача проверять "не украли ли куку"/действительна ли авторизация -
session_start();
// в куке (при дефолтных настройках пхп) появляется PHPSESSID, уже сгенеренное
// присваиваем готовые значения
$_SESSION['USER_PHPSESSID'] = $_COOKIE['PHPSESSID'];
$_SESSION['USER_REMOTE_ADDR'] = $_SERVER['REMOTE_ADDR'];
// айпишник "записываем" как раз на случай украденных кук
// и проверяем так же просто...
если разные айпи - логаут.
если айди сессии != тому айди, что в куках - логаут.
в таком случае не нужно что-то генерить, а тем более хранить в базе или совать и читать оттуда каждый раз(!) при вызове странички, где предполагается авторизация..А если страничек тысяча? Мемкеш можно, но зачем? :) Просто напишите функцию и вызывайте в хедере каждой страницы, где нужна проверка.
Да, проверку на длину строки/заглавные или строчные буквы можно прямо в регулярке делать.
И никогда не стоит делать что-то вроде md5(md5(...)); т.к. это хэш-функция, т.е. перебор будет осуществляться без особых осложнений (единственный минус - с каждым md5 увеличивается процессорное время, необходимое на генерацию хеша), просто выбирайте более продвинутые алгоритмы.
Надо хеш - есть md5(uniqid(rand()));
Есть задача проверять "не украли ли куку"/действительна ли авторизация -
session_start();
// в куке (при дефолтных настройках пхп) появляется PHPSESSID, уже сгенеренное
// присваиваем готовые значения
$_SESSION['USER_PHPSESSID'] = $_COOKIE['PHPSESSID'];
$_SESSION['USER_REMOTE_ADDR'] = $_SERVER['REMOTE_ADDR'];
// айпишник "записываем" как раз на случай украденных кук
// и проверяем так же просто...
если разные айпи - логаут.
если айди сессии != тому айди, что в куках - логаут.
в таком случае не нужно что-то генерить, а тем более хранить в базе или совать и читать оттуда каждый раз(!) при вызове странички, где предполагается авторизация..А если страничек тысяча? Мемкеш можно, но зачем? :) Просто напишите функцию и вызывайте в хедере каждой страницы, где нужна проверка.
Да, проверку на длину строки/заглавные или строчные буквы можно прямо в регулярке делать.
И никогда не стоит делать что-то вроде md5(md5(...)); т.к. это хэш-функция, т.е. перебор будет осуществляться без особых осложнений (единственный минус - с каждым md5 увеличивается процессорное время, необходимое на генерацию хеша), просто выбирайте более продвинутые алгоритмы.
«И никогда не стоит делать что-то вроде md5(md5(...))»
Почему не стоит делать md5(md5()) или лучше sha1(md5())? Ведь, теоретически, это усилит сложность подбора пусть не в два раза, но значительно. Разве нет?
Почему не стоит делать md5(md5()) или лучше sha1(md5())? Ведь, теоретически, это усилит сложность подбора пусть не в два раза, но значительно. Разве нет?
Я же написал, это хэш-функция, а не функция шифрования строки :)
Если вы закодировали строку как md5(), то и брутофорсить я ее буду как md5(), примерно так:
$hash = md5('dwadad');
for($i=a;$i<=zzzzzz;$i++) {
if(md5($i) == $hash) {
echo 'Found: ' . $i . "\n";
}
}
А если md5(md5()), то
...
if(md5(md5($i)) == $hash) { }
...
вы думали, что сначала будет раскрываться первый md5, а потом второй? :)
еще раз, это хеш-функция, как и sha1...единственная польза от увеличения (разумного) числа хеш-функций при получении хеша строки состоит в том, что будет тратиться процессорное время на генерацию хеша строки, т.е. раскодировать md5 будет быстрее по времени, чем sha1(md5())...
Если вы закодировали строку как md5(), то и брутофорсить я ее буду как md5(), примерно так:
$hash = md5('dwadad');
for($i=a;$i<=zzzzzz;$i++) {
if(md5($i) == $hash) {
echo 'Found: ' . $i . "\n";
}
}
А если md5(md5()), то
...
if(md5(md5($i)) == $hash) { }
...
вы думали, что сначала будет раскрываться первый md5, а потом второй? :)
еще раз, это хеш-функция, как и sha1...единственная польза от увеличения (разумного) числа хеш-функций при получении хеша строки состоит в том, что будет тратиться процессорное время на генерацию хеша строки, т.е. раскодировать md5 будет быстрее по времени, чем sha1(md5())...
Ну так откуда злоумышленник знает, каким образом я получил хэш? :-) Если он влез в мои исходники, значит, он может и пароль к БД подсмотреть, а там уже и поменять хэш пароля на нужный проблем не составит.
я могу влезть в ваши исходники, если это публичный opensource и подсмотреть метод получения хешей :)
очень часто на хостингах веб-сервер запускается под nobody и имеет права чтения на всей файлы, с которыми он работает, а вот на изменение - нет, разве что найти пароль от базы и там уже подсмотреть хеш, но менять же глупо с точки зрения "чтобы не засекли" :), поэтому придется брутофорсить.
очень часто на хостингах веб-сервер запускается под nobody и имеет права чтения на всей файлы, с которыми он работает, а вот на изменение - нет, разве что найти пароль от базы и там уже подсмотреть хеш, но менять же глупо с точки зрения "чтобы не засекли" :), поэтому придется брутофорсить.
Ну и, кстати, даже если знать, сколько (N), каких и в какой последовательности хэшей взято, процессорной мощносто потребуется в N раз больше, стало быть, и времени уйдёт в два раза больше. Если не принимать в расчёт коллизии, конечно…
если разные айпи - логаут.
если айди сессии != тому айди, что в куках - логаут.
таким методом вы создаёте возможность "кикнуть" пользователя для стороннего.
пояснить можно что имелось в виду?
Если вы делаете logout когда сторонний подбирает пароль или ключ сессии, то вы выключаете самого пользователя, который всё сделал правильно. Таким образом вы даёте любому симулировать атаку для того, чтобы просто выбить (kick) пользователя из форума/магазина и пр.
Имелось ввиду что если злоумышленник заходит с чужими cookies — происходит логаут (удаление сессии).
Но когда добропорядочный юзер зайдёт со своими cookies после злоумышленника — то ему опять придётся авторизовываться, ведь его сессия удалена.
Но когда добропорядочный юзер зайдёт со своими cookies после злоумышленника — то ему опять придётся авторизовываться, ведь его сессия удалена.
Вопрос к автору не совсем по теме: почему вы не используете mysql_free_result()? Я всегда считал, что сами собой ресурсы БД, полученные через mysql_query(), не очищаются. Может, я просто заблуждался?
mysql_free_result() нуждается в вызове только в том случае, если вы всерьёз обеспокоены тем, сколько памяти используют ваши запросы к БД, возвращающие большое количество данных. Вся память, используемая для хранения этих данных автоматически очистится в конце работы скрипта.
При попытке авторизироватся, у меня вылазит ошибка:
Warning: Cannot modify header information - headers already sent by (output started at /home/sleshforev/domains/genya.net.ua/public_html/aut/login.php:1) in /home/sleshforev/domains/genya.net.ua/public_html/aut/login.php on line 43
Warning: Cannot modify header information - headers already sent by (output started at /home/sleshforev/domains/genya.net.ua/public_html/aut/login.php:1) in /home/sleshforev/domains/genya.net.ua/public_html/aut/login.php on line 44
Warning: Cannot modify header information - headers already sent by (output started at /home/sleshforev/domains/genya.net.ua/public_html/aut/login.php:1) in /home/sleshforev/domains/genya.net.ua/public_html/aut/login.php on line 47
Чего так...(( ?
Warning: Cannot modify header information - headers already sent by (output started at /home/sleshforev/domains/genya.net.ua/public_html/aut/login.php:1) in /home/sleshforev/domains/genya.net.ua/public_html/aut/login.php on line 43
Warning: Cannot modify header information - headers already sent by (output started at /home/sleshforev/domains/genya.net.ua/public_html/aut/login.php:1) in /home/sleshforev/domains/genya.net.ua/public_html/aut/login.php on line 44
Warning: Cannot modify header information - headers already sent by (output started at /home/sleshforev/domains/genya.net.ua/public_html/aut/login.php:1) in /home/sleshforev/domains/genya.net.ua/public_html/aut/login.php on line 47
Чего так...(( ?
Как вариант, кстати, можно не получать хэш из случайной строки, а генерировать хэш сразу :-)
Интересно, на что уйдёт больше ресурсов на 32 рандома, или на один md5 + 10 рандомов… :-)
Интересно, на что уйдёт больше ресурсов на 32 рандома, или на один md5 + 10 рандомов… :-)
Не понимаю, раз уж используется двойной md5, неужели его нельзя подсолить? Хотя, тогда в таблице появится дополнительный атрибут с солью, но оно того стоит - подбор пароля станет заметно сложнее.
По проверке формы:
1.Проверять логин в базе нужно только в том случае, если он прошел проверку на символы и длину. Иначе это бессмысленно. Если он не прошел по используемым символам, то его и не будет в базе.
2. Лучше не удалять пробелы в пароле. Использование пробелов - хороший способ улучшить свой пароль.
См. книгу "Как создать идеальный пароль" - http://www.yugzone.ru/Books/perfect_passwords.zip
1.Проверять логин в базе нужно только в том случае, если он прошел проверку на символы и длину. Иначе это бессмысленно. Если он не прошел по используемым символам, то его и не будет в базе.
2. Лучше не удалять пробелы в пароле. Использование пробелов - хороший способ улучшить свой пароль.
См. книгу "Как создать идеальный пароль" - http://www.yugzone.ru/Books/perfect_passwords.zip
Кстати, IE7 не удаляет куки в прошедшем времени.
Ну и если генерить хеш для пароля, то в функции не должно участвовать никакого random, иначе как сформировать такой же хеш из пароля, который ввел пользователь для сравнения с хешем в БД.
Идея создавать токен лично для меня тоже сомнительна. Чем не устраивает хеш пароля с именем пользователя, солью и перцем? Если сайт требует серьезной аунтификации, то достаточно выдать клиенту таблицу переменных кодов (один код на одну операцию), как это принято в платежных системах банков.
Ну и если генерить хеш для пароля, то в функции не должно участвовать никакого random, иначе как сформировать такой же хеш из пароля, который ввел пользователь для сравнения с хешем в БД.
Идея создавать токен лично для меня тоже сомнительна. Чем не устраивает хеш пароля с именем пользователя, солью и перцем? Если сайт требует серьезной аунтификации, то достаточно выдать клиенту таблицу переменных кодов (один код на одну операцию), как это принято в платежных системах банков.
А как таблицу переменных кодов разумнее использовать? Можно ли осуществить такую схему.
-используется http-авторизация.
-В таблице юзеров поля login, password и id. Добавляем колонку salt.
-создаём дополнительно таблицу, например тоже salt, содержащую набор переменных кодов.(3 символа?)(100 строк?)(периодически обновлять?)
-при авторизации забираем md5 от пароля, рандомом забираем какой-либо код из таблицы salt, добавляем к хэшу и пишем в переменную PHP_AUTH_PASSWORD.
-инсертим соль в колонку salt и работаем с какой-либо таблицей по id юзера, cверяя хэш+соль из переменной PHP_AUTH_PASSWORD c записями из таблицы паролей password+salt.
-при следующей авторизации апдэйтим код соли в колонке salt, забираяя его рандомом из таблицы кодов.
Такая схема имеет право на существование? Минусы, плюсы? Пользователей порядка 100, максимум до 1000 вырастет. В данный момент всё работает без соли, стоит ли усложнять?
-используется http-авторизация.
-В таблице юзеров поля login, password и id. Добавляем колонку salt.
-создаём дополнительно таблицу, например тоже salt, содержащую набор переменных кодов.(3 символа?)(100 строк?)(периодически обновлять?)
-при авторизации забираем md5 от пароля, рандомом забираем какой-либо код из таблицы salt, добавляем к хэшу и пишем в переменную PHP_AUTH_PASSWORD.
-инсертим соль в колонку salt и работаем с какой-либо таблицей по id юзера, cверяя хэш+соль из переменной PHP_AUTH_PASSWORD c записями из таблицы паролей password+salt.
-при следующей авторизации апдэйтим код соли в колонке salt, забираяя его рандомом из таблицы кодов.
Такая схема имеет право на существование? Минусы, плюсы? Пользователей порядка 100, максимум до 1000 вырастет. В данный момент всё работает без соли, стоит ли усложнять?
Сперва надо задать вопрос. На сколько требуется серьезная и подлинная авторизация. Если у вас простой форум, то достаточно просто сравнивать логин и хеш пароля. Если платежная система или крайне ценная информация, доступ к которой должен быть ограничен, то лучше замудрить. На примере одного крупного банка. Они выдают карточку с токенами, там 100 5-7 значных чисел. Перед каждой операцией надо вводить очередное число.
md5 легко ломается, лучше брать что-то типа sha(md5(user_email+login + salt)). Я не силен в http-авторизации, но обычную сделал бы так:
- users_table: uid, login, hash(password), token
- users_token_table: uid, token (int)
вторая таблица содержит переменные коды, выданные пользователю. При регистрации пользователя заносим его первый токен в таблицу users из таблицы token.
При авторизации удаляем токен из token и кидаем следующий в users. Если с токенами связываться лень (а это для большинства интернет-авторизаций и не надо), можно сделать проще: в users хранить token (какой-нибудь 128битовый казябрик), каждый раз после логина его менять, а в сессию и куки писать не пароль и логин (как это принято), а этот токен, который будет действовать до следующего удачного входа.
md5 легко ломается, лучше брать что-то типа sha(md5(user_email+login + salt)). Я не силен в http-авторизации, но обычную сделал бы так:
- users_table: uid, login, hash(password), token
- users_token_table: uid, token (int)
вторая таблица содержит переменные коды, выданные пользователю. При регистрации пользователя заносим его первый токен в таблицу users из таблицы token.
При авторизации удаляем токен из token и кидаем следующий в users. Если с токенами связываться лень (а это для большинства интернет-авторизаций и не надо), можно сделать проще: в users хранить token (какой-нибудь 128битовый казябрик), каждый раз после логина его менять, а в сессию и куки писать не пароль и логин (как это принято), а этот токен, который будет действовать до следующего удачного входа.
Ошибочка вышла)
Этот запрос
$query = mysql_query("SELECT *,INET_NTOA(user_ip) FROM users WHERE user_id = '".intval($_COOKIE['id'])."' LIMIT 1");
при сравнении
if(($userdata['user_hash'] !== $_COOKIE['hash']) or ($userdata['user_id'] !== $_COOKIE['id'])
or (($userdata['user_ip'] !== $_SERVER['REMOTE_ADDR']) and ($userdata['user_ip'] !== "0")))
($userdata['user_ip'] !== $_SERVER['REMOTE_ADDR'])
$userdata['user_ip'] будет в двоичной форме, а $_SERVER['REMOTE_ADDR'] нет
можно использовать так
$query = mysql_query("SELECT *,INET_NTOA(user_ip) as user_ip FROM users WHERE user_id = '".intval($_COOKIE['id'])."' LIMIT 1");
или просто выбрать все колонки которые нужны с присваиванием INET_NTOA(user_ip) as user_ip
Этот запрос
$query = mysql_query("SELECT *,INET_NTOA(user_ip) FROM users WHERE user_id = '".intval($_COOKIE['id'])."' LIMIT 1");
при сравнении
if(($userdata['user_hash'] !== $_COOKIE['hash']) or ($userdata['user_id'] !== $_COOKIE['id'])
or (($userdata['user_ip'] !== $_SERVER['REMOTE_ADDR']) and ($userdata['user_ip'] !== "0")))
($userdata['user_ip'] !== $_SERVER['REMOTE_ADDR'])
$userdata['user_ip'] будет в двоичной форме, а $_SERVER['REMOTE_ADDR'] нет
можно использовать так
$query = mysql_query("SELECT *,INET_NTOA(user_ip) as user_ip FROM users WHERE user_id = '".intval($_COOKIE['id'])."' LIMIT 1");
или просто выбрать все колонки которые нужны с присваиванием INET_NTOA(user_ip) as user_ip
А вот аргумент "Хм, что-то не получилось" не прокомментировали... все сделал как здесь написано, но вылезает надпись. Я так полагаю одно из условий не выполнилось. Ни фига не пойму ПОЧЕМУ? У кого нибудь была такая проблема?
Так проверь их все вручную - выведи на экран. Выяснишь, какое не выполнилось. тогда можно будет дальше думать, в чем дело.
если условие не выполняется, то выводят все участвующие в нем операнды.
лучше - с помощью var_dump()
если условие не выполняется, то выводят все участвующие в нем операнды.
лучше - с помощью var_dump()
Не стал заморачиваться. Сделал на сессиях, теперь все работает без проблем. Спасибо за отклик.
Неплохой метод авторизации. Вот только нашел одно неудобство: авторизуемся например в ФФ, потом открываем ИЕ и авторизуемся в нем, после этого меняется хеш авторизации в базе пользователя и соответственно слетает авторизация в ФФ.
Странно, что за столько времени никто не обратил внимане на то, что при проверке существования логина он искейпится, а при вставке - нет.
Хороший код. С заложенной инъекцией.
Хороший код. С заложенной инъекцией.
А какая разница между $a===$b и $a==$b?
Почему все не перешли еще на crypt()?
$insip = ", user_ip=INET_ATON('".$_SERVER['REMOTE_ADDR']."')";
Если кто-то будет авторизоваться, используя ipv6, а не ipv4, вас ждёт неприятный сюрприз в этом месте, ибо в $_SERVER['REMOTE_ADDR'] будет ip шестой версии, а функция INET_ATON не сработает и возвратит не число.
Sign up to leave a comment.
Безопасный метод авторизации на PHP