Сила MD5: почему MD5 и как применять на практике

Меня иногда спрашиваю, а в чем крутость MD5? На кой черт нужно шифровать пароли этим хешем?

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

Что происходит, если пароли лежат в открытом виде? Понятно: он берет любой логин и пароль и заходит под ними, делает гадости. Что происходит, если пароли зашифрованы двунаправленным шифрованием (это когда можно зашифровать и другим скриптом расшифровать)? Так как обычно тоже применяются стандартные алгоритмы, взломщик помучается, но расшифрует пароль. Что происходит, если пароль зашифрован с помощью md5? Взломщик видит хэш, но ничего сделать не может. Это однонаправленный метод шифрования.

Небольшая справка. Что такое однонаправленное шифрование? Это когда слово шифруется по какому-то алгоритму, а расшифровать его обратно нельзя – слишком моного возможных комбинаций или другая причина.

Как применять md5 на практике? Когда пользователь регистрируется и первый раз вводи пароль, в базу мы записываем его MD5-хеш. Ну скажем так:

$login = $_POST['login'];
$hash = md5($_POST['password']);
mysql_query («INSERT INTO table VALUES (0, ‘$login’, ‘$hash’);»)

Теперь, когда пользователь заходит в свой аккаунт, нужно проверять хеш из базы с хешем введенного пароля, который мы создаем «на лету». Например так:

$login = $_POST['login'];
$pass = $_POST['password'];
$user = mysql_fetch_array (mysql_query («SELET * FROM table WHERE login=’$login’;»));
if ($user['hash'] == md5($pass)){ /* вошли успешно */}

Конечно, я тут не проверял входящие данные и не проверял ошибки. Кстати, MySQL тоже понимает MD5, поэтому код выше можно переписать так, оставив только запрос:

$login = $_POST['login'];
$pass = $_POST['password'];
$user = mysql_fetch_array (mysql_query («SELET * FROM table WHERE login=’$login’ AND hash=MD5(‘$pass’);»));

Комментариев: (12)

Умный сайт: что мы там последнее читали?.. Закладки на сайте.

Пришла в голову оригинальная идея. Даже не одна, две пришли. Нигде такого еще не видел. Не буду тянуть кота за и так уже растянутые постоянным упоминанием <подставить слово>, перейду к сути.

1. Читая чужой блог, мы листаем посты, ходим по страницам, по категориям, жмем на теги. Иногда мы проделываем довольно длинный пусть по сайту. И, например, страшно нам блог понравился. На следующий день мы открываем этот же блог и хотим продолжить чтение, но… не помним где мы остановились. Судорожно ищем место, не находим. Читать уже знакомые заголовки, когда ищешь что-то новенькое раздражает неимоверно. Листать страницы по 5 постов на каждой раздражает еще больше (ну почему нельзя было сделать по 20 постов хотя бы?!).

А почему бы автору блога не сделать следующее?

Например, где-то вверху есть галочка «Запомнить, что я читал последним». При нажатии на нее пользователь может покинуть сайт, а при повторном открытии браузера (хоть через год) он попадет на ту самую страницу, которую читал последней.

Девид Блейн, остановись, демон! Как это?! А очень просто. Когда пользователь жмет галочку, то на сайте врубается простой механизм: при переходе на очередную страницу пользователю записывается Cookie с URL или URI этой страницы. Когда пользователь заходит на сайт с другого сайта или из «чистого» браузера, мы проверяем реферер и если пользователь пришел не с нашего сайта, то делаем редирект на последний записанный URL. Конечно значение галочки «Запомнить, что я читал последним» тоже нужно записать в Cookie.

Или даже так: URL сохраняется в Cookie в любом случае, но если галочка не установлена, то редиректа не происходит (для того, чтобы всегда точно знать, что пользователь прочитал последним).

2. Еще более глобальная система закладок. Причем индивидуальная для каждого пользователя и, понятное дело, доступная без регистрации (я вообще регистрации ненавижу).

Скажем, в боковой колонке есть блок под названием «Вот это я читал», а в постах под заголовком есть ссылка «Запомнить этот пост». Когда пользователь жмет на «запомнить», то в блоке появляется ссылка на этот пост. Ну и, скажем, запомнить можно сколько угодно постов.

Реализация тоже простая. Для этого тоже достаточно одной только Cookie. Правда записывать туда придется уже не URI, а ID поста из базы данных, т.к. мы должны иметь возможность отобразить заголовок поста в блоке. В Cookie же можно просто записывать ID через запятую, а при неободимости разбивать строку через «разделитель «запятая»" функцией explode и считывать все, что нам нужно из БД.

Да, почему я не назвал это «Закладками» и «Добавить в закладки». Потому, что, очевидно, пользователи будут путать это с закладками браузера, а нужно сделать так, чтобы даже никаких ассоциаций в эту сторону не появлялось.

Эпилог. Вторая идея – это продолжение первой. И, к сожалению, на мой взгляд она немного сомнительна. Ее можно использовать, например, в инернет-магазинах в качестве функции а-ля «сравнить товары» или «отобрать понравившиеся». Но… Сами понимаете. А вот первая, я считаю, вполне себе идеища и достойна реализации. Она помогает и пользователю и повышает крутость ресурса в глазах пользователя («- Толян, смотри, какая там прикольная фишка!»). Главное, дать пользователю выбор, сохранять или не сохранять страницу последнего посещения.

Комментариев: (9)

Drupal :: модуль BOOK, скрываем вывод дочерних категорий прямо в меню

Сейчас делаю еще один сайт на Drupal. Для организации каталога статей я решил в этот раз использовать модуль Book, т.е. он проще для понимания (наполнять буду не я один). И все там классно-расчудесно, кроме того, что в главном меню при клике на один из пунктов подшивки открывается вложенный список прямо в меню. А если статей 200, то и меню на сайте сразу получится из 200 пунктов.

Как это убрать? В админке я ничего не нашел, поэтому полез в код.

Редактируем файл book.module. Строка 196:

$book_menus[$book_id] = menu_tree_output(menu_tree_all_data($node->book['menu_name'], $node->book));
Меняем на:

$book['in_active_trail'] = FALSE;
$pseudo_tree[0]['link'] = $book;
$book_menus[$book_id] = menu_tree_output($pseudo_tree);

Готово.

Комментариев: (8)

Универсальная партнерская ссылка с любой страницы сайта

Откладывая в сторону сиськи и возвращаясь к моему предпоследнему посту, хочется написать еще один, раз уж пошла такая пьянка.

Как работают партнерские программы мы все знаем: ставим свои ссылочки, по ним приходят покупатели, оплачивают товарчеги и мы получаем денежги на свой счетег. Ссылки обычно имеют вид site.ru/?p=10, где 10 – это наш ID.

Как правило можно поставить партнерскую ссылку на любой товар, например site.ru/tovari/rozoviy_slon.htm?p=10 или на другую страницу.

А как программируются такие ссылки? Обычно предполагается, что ссылка будет передаваться через GET-запрос и находить мы ее будем в глобальном $_GET-массиве.

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

В самом мега-главном файле сайта index.php в самом верху (после инициализации движка, точно так же как и в случае с tkd), пишем следующее:

preg_match («/(.*?)?p=([0-9]+)/si», $_SERVER["REQUEST_URI"], $m);
if (!empty ($m[2])) $pid = $m[2];

if (!empty ($pid)){
setcookie («partner», $pid, time()+3600*24*7, «/»);
}
Как видно из кода, мы опять использовали REQUEST_URI. Напомню, что он содержит URL данной страницы (там где сейчас юзер) без http и домена сайта. Например такой: /hello.htm. С помощью регулярных выражений мы вырезаем из URI выражение вида ?p=x, и определяем этот x (переменная $pid). Причем тут автоматически идет и защита от злых дядек – если после ?p= идут не цифры, то ничего мы не получим.

Дальше, понятное дело, на Ваше усмотрение. У меня ставится кука с ID партнера, который привел пользователя на сайт.

И, таким макаром, мы можем добавить ?p= вообще в любую ссылку, движку теперь просто все равно куда мы ее добавляем – вырезается все с помощью регулярок.

Кстати, раскрываю секрет фирмы. $pid не имеет никакого отношения к пидарасам мужчинам нетрадиционной сексуальной ориентации. Расшифровывается в данном случае как partner id. В линуксе, например, pid означает как правило process id и так далее.

Комментариев: (3)

title / description / keywords – универсальная система для сайта

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

Возник вопрос о том, что для каждой страницы надо как-то задавать title, description и keywords (для SEO). Нужно было быстро реализовать это решение.

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

За 0.0141 секунды раздумий я придумал следующую систему, которая позволяет не перерабатывать весь движок.

Понятно, что каждая страница сайта имеет свой URL. URI – это тот же URL, только без домена. Его можно получить из переменной $_SERVER["REQUEST_URI"]. Понятно, что для каждой страницы URI свой собственный (иначе это уже одна и та же страница).

И возникает очень простая система. Создаем таблицу в БД с полями «title, key, descr, uri». В том месте, где должны выводиться title, description и keywords пишем что-то вроде:

<?php
$uri = $_SERVER["REQUEST_URI"];
if ($uri == «/index.php») $uri = «/»;
$q = mysql_query («SELECT * FROM table WHERE uri=’$uri’;»);
if (mysql_num_rows ($q) > 0){
$str = mysql_fetch_array ($q);
$t = $str['title']; $k = $str['key']; $d = $str['descr'];
}
?>
<meta name=»keywords» content=»<?php echo $k; ?>» />
<meta name=»description» content=»<?php echo $d; ?>» />
<title><?php echo $t; ?></title>

Понятно, что в таблицу записывается заголовок, описание и ключевики для того адреса, для которого мы хотим задать их. И работать это будет для всех страниц, которые обрабатывает движок (то есть в данном случае – для всего сайта вообще). А администратор получает возможность задавать заголовки, ключи и описание даже для тех страниц, которые в ТЗ не предусмотрены, плюс в следующих модулях не нужно будет реализовывать «внутреннюю» поддержку title, keywords и description.

Конечно, не забудьте о безопасности! Проверяйте это выражение перед передачей его в базу. Обычно оно проверяется очень просто – нельзя использовать никакие символы, кроме слеша, точки, букв и цифр.

Комментариев: (6)