Давайте представим, что злоумышленник таки украл базу. Получается, что он знает $hash вообще всех пользователей, а так как проверяется именно он, то его нужно просто подставить в cookie, а пароль даже и не нужен. Выход:
* в базу сохранять MD5(случайная строка), а пользователю в куки отдаём эту случайную строку. Потом сверяем. Если кто-то украдёт базу, то получит только MD5 от случайных строк, которые ни перебором, ни словарём, ни rainbow tables (при условии достаточной длины) не расколоть.
* в базу сохранять время действия логина, не надеяться на то, что куки будут затёрты автоматически
Это не коллизии. Это восстановление зашифрованной строки при помощи таблиц, которые генерируются заранее. Таблицы генерируются для определённого набора символа и длины исходного текста, отсюда и название time-space tradeoff, то есть мы время полного брутфорса размениваем на генерацию таблиц (rainbow tables).
> смешно. если есть доступ к базе, то в неё можно и пароль новый записать, а потом и войти и сделать что угодно.
SQL injection бывают разные.
> Также двойной ли хеш он, тройной ли - неважно. От этого сложность и скорость расшифровки хеша не будет зависеть.
"Time-space tradeoff" гуглите. MD5(абсолютно_любая_строка_меньше_некоторой_длины) я расшифрую _вмиг_ с его помощью без полного перебора, а вот MD5(MD5(...)) уже нет.
> указатель на соединение и экранирует в зависимости от кодировки.
В пренебрежении управления кодировками большая проблема. Вы никогда не переносили базы из MySQL 4.0 в MySQL 4.1 и старше? Знаете, что бывает, если не задавать кодировку, в которой данные записываете в базу и в которой ожидаете обратно? Правильно, CP1251/koi8-r или любая другая кодировка интерпретируется как latin1 и все русские символы преобразовываются в "?".
Хорошая статья, надеюсь вокруг станет меньше "неправильных" login-форм.
1. mysql_select_db("testtable"); // нелогичное название базы, testdb лучше
2. Нужно использовать mysql_real_escape_string()
3. Убирать лишние пробелы нет смысла, так как их не пропустит вот эта строка:
if(!preg_match("/^[a-zA-Z0-9]+$/",$_POST['login']))
Да, но при таком трафике вполне может лечь датацентер. В такой ситуации лучшей мерой со стороны работников датацентра было бы просто прекратить маршрутизировать подсеть, выделенную атакуемому серверу.
Нет, не шутка. Потому что нужно сделать так, чтобы при отключённом JavaScript элемент управления был всё равно доступен и работал, пусть и в виде обычного input или select.
Нет, всё верно. Если брать только веб-программирование то на данном этапе развития встроенных возможностей JavaScript, JSON без вопросов удобнее. Но как только сюда подмешать какую-то необычную базу данных на сервере, или другое внешнее условие то XML может выйти удобнее. Хотя сходу, наверное, примеров не придумаю.
Давайте представим, что злоумышленник таки украл базу. Получается, что он знает $hash вообще всех пользователей, а так как проверяется именно он, то его нужно просто подставить в cookie, а пароль даже и не нужен. Выход:
* в базу сохранять MD5(случайная строка), а пользователю в куки отдаём эту случайную строку. Потом сверяем. Если кто-то украдёт базу, то получит только MD5 от случайных строк, которые ни перебором, ни словарём, ни rainbow tables (при условии достаточной длины) не расколоть.
* в базу сохранять время действия логина, не надеяться на то, что куки будут затёрты автоматически
SQL injection бывают разные.
> Также двойной ли хеш он, тройной ли - неважно. От этого сложность и скорость расшифровки хеша не будет зависеть.
"Time-space tradeoff" гуглите. MD5(абсолютно_любая_строка_меньше_некоторой_длины) я расшифрую _вмиг_ с его помощью без полного перебора, а вот MD5(MD5(...)) уже нет.
$password = md5(md5(trim($_POST['password'])));
Опасно как-то пароль изменять, пользователь пусть лучше два раза пароль вводит при регистрации.
В пренебрежении управления кодировками большая проблема. Вы никогда не переносили базы из MySQL 4.0 в MySQL 4.1 и старше? Знаете, что бывает, если не задавать кодировку, в которой данные записываете в базу и в которой ожидаете обратно? Правильно, CP1251/koi8-r или любая другая кодировка интерпретируется как latin1 и все русские символы преобразовываются в "?".
1. mysql_select_db("testtable"); // нелогичное название базы, testdb лучше
2. Нужно использовать mysql_real_escape_string()
3. Убирать лишние пробелы нет смысла, так как их не пропустит вот эта строка:
if(!preg_match("/^[a-zA-Z0-9]+$/",$_POST['login']))
Mac сейчас x86, а значит PC. Вы имели ввиду "Windows".
А вообще с отключенным JavaScript работает? А screen readers как к ним относятся?