Пароль на страницу PHP


Оглавление (нажмите, чтобы открыть):

Легкий способ защиты паролем php-страницы

У меня есть страница, которую я хочу защитить паролем. Я попытался выполнить HTTP-аутентификацию, но по какой-то причине она не работает на моем хостинге. Любой другой быстрый (и простой) способ сделать это? Спасибо!

Не самая надежная защита паролем здесь, поэтому, пожалуйста, не используйте это для защиты номеров кредитных карт или чего-то очень важного.

Просто отбросьте весь следующий код в файл с именем (secure.php), измените пользователя и перейдите от «admin» к тому, что вы хотите. Затем прямо под теми строками, где он говорит include ( «secure.html» ), просто замените это на имя файла, который вы хотите, чтобы он мог видеть.

Они будут получать доступ к этой странице в [YouDomain.com/secure.php], а затем PHP script будет внутренне включать файл, который вы хотите защитить паролем, чтобы они не знали имя этого файла и не могли позже просто войдите в него напрямую, минуя подсказку с паролем.

Если вы хотите добавить дополнительный уровень защиты, я бы рекомендовал вам взять файл (secure.html) за пределами корневой папки вашего сайта [/public_html] и разместить его на том же уровне, что и этот каталог, поэтому что он не находится внутри каталога. Затем в PHP script, где вы включаете файл, просто используйте ( «../secure.html» ). Это (../) означает возврат каталога для поиска файла. Выполняя это так, единственный способ получить доступ к содержимому, которое находится на странице (secure.html) через (secure.php) script.

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

Парольная защита

Автор: Артемьев Сергей Игоревич
ICQ: 438856621
email: _spin_@bk.ru

Одна из основных аксиом защиты информации гласит — «комфортность системы обратно пропорциональна её защищённости». Это значит, что при выборе системы защиты необходимо найти оптимальное соотношение сложности защиты и удобства работы пользователей.

С другой стороны, разработка и внедрение защиты требует определённых затрат сил и средств. Следовательно, надо разумно подходить к проектированию защиты. Проще говоря, не надо делать сложную и дорогостоящую систему защиты, если на сайте не хранится ничего ценного. Ни один злоумышленник не полезет ломать вашу домашнюю страничку, сайт-визитку небольшой компании или сайт детского сада.

В предыдущем уроке мы рассматривали авторизацию средствами Web-сервера (Basic-авторизация). Наверное, это самый лёгкий и самый безопасный способ ограничения доступа к ресурсам. Однако, сопровождение такого механизма достаточно трудоёмко, особенно при большом количестве пользователей с различными правами. Кроме того, не все сервера позволяют использовать HTTP-авторизацию.

Более популярная альтернатива — парольная защита. Смысл её в том, что на сервере хранятся списки пользователей и соответствующие им логины, пароли и права доступа. При первом обращении к сайту пользователь вводит логин/пароль и получает доступ к ресурсам. Сервер «запоминает» пользователя и не спрашивает пароль до следующего открытия сессии (перезапуска браузера).

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

Рассмотри пример реализации простейшей парольной защиты. Создадим файл logon.php

При нажатии на кнопку «вход» данные формы будут отправлены на сервер, там скрипт проверит введённые логин и пароль и если они равны «admin» и «megaPass» соответственно — отобразит сообщение, что вход разрешен. Если логин или пароль не верны — пользователь увидит предупреждающее сообщение.

Первый недостаток этого скрипта: передача данных методом GET. При использовании этого метода данные передаются непосредственно в адресе, а значит видны даже невооруженным глазом. Например, если вы ввели правильные логин и пароль, то в адресной строке увидите

Второй недостаток: имена пользователей и пароли зашиты прямо в код. Это значит, что для добавления новых пользователей вам надо будет постоянно менять код файла. А представьте себе, какого размера будет файл, если у вас на сайте хотя-бы тысяча зарегистрированных пользователей. Списки пользователей лучше всего хранить в отдельном файле, а лучше в базе данных, т.к. злоумышленнику файл украсть намного проще, чем добывать что-то из базы данных.

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

Итак, рассмотрим способы устранения этих недостатков.

Скрыть передаваемые данные проще всего используя метод передачи POST. В этом случае браузер сам (скрытно от пользователя) передаст серверу все необходимые данные и перехватить их можно будет только специальными программами из арсенала IT-специалистов, программистов или хакеров.

Как говорилось выше, списки пользователей надо хранить отдельно. Создадим таблицу в тестовой базе данных:

и добавим в неё несколько записей пользователей:

Обратите внимание, что оператор INSERT допускает одновременное добавление в таблицу сразу нескольких записей, при этом данные перечисляются блоками через запятую.

Теперь изменим logon.php таким образом, чтобы имя пользователя и пароль корректно проверялись непосредственно в базе данных:

Теперь логин и пароль передаются скрытно, а учётные данные очень просто изменить, отредактировав таблицу в базе данных. Остался последний штрих — научить сервер запоминать факт регистрации. Проще всего сделать это при помощи механизма сессий. Внесём необходимые изменения:

Теперь сервер будет запоминать каждого пользователя, успешно вошедшего в систему, а при следующем обновлении страницы будет выводиться приветственное сообщение.

Это скрипт — лишь пример организации парольной защиты, пусть и вполне функциональный. Сделать из него практически ценный образец можно, добавив проверку вводимых данных, функции шифрования, восстановения пароля, завершения сессии и др.

Пароль на страницу

Пароль на страницу. Часть 1. Скорее теоретическая.

Я решил описать способы закрыть паролем часть сайта. Тема, на самом деле, большая, поэтому на первый раз ограничусь авторизацией php+mysql.

Самый первый вопрос, который обычно встаёт — как закрыть директорию со скрпитами администрирования паролем. При этом не нужно никаких изысков — один или несколько администраторов имеют одни и те же права, а персоналии меняются редко. Проще всего в данной ситуации использовать стандартную серверную авторизацию — положить файлы .htaccess и .htpasswd и прописать в них нужные параметры. Про это уже написано много, поэтому я ничего особо нового не скажу, лучше посмотрите сюда.

Добавлю две вещи. Первое — это куда класть файл .htpasswd. Экспериментальным путем я выяснил, что если, например, путь к документу с сообщением об ошибке (ErrorDocument) пишется относительно системной переменной DocumentRoot. Но путь к файлу с паролями (UserFile) пишется относительно ServerRoot. Насколько я понял, выше ServerRoot положить .htpasswd нельзя — «../» не воспринимается. Всё это сделано для того, чтобы можно было поместить файл с паролями, например, одним уровнем выше корневой директории сайта, чтобы из сети доступа к файлу не было вообще.

Второе — это то, что скрипт может узнать, кто его открывает и пароль: переменные $PHP_AUTH_USER и $PHP_AUTH_PW.

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

Ещё один недостаток — необходимость переписывать файлы с паролями при удалении пользователя или введении нового. Но если это происходит нечасто, этого способа вполне достаточно, к тому же не придётся забивать голову написанием механизма авторизации.

Это нужно не только для упрощения работы с большим количеством пользователей и их большой «текучкой». Если нужно держать дополнительную информацию о пользователях, либо необходимо гибкое разграничение прав, лучше перенести авторизацию в базу.

Каждая страница закрытой территории подключает файл с вот таким кодом:

В первой строке из логина удаляются все символы кроме букв, цифр, тире и символа подчеркивания. Затем проверяется количество полученных строк, и только если это одна строка, дается доступ. В остальных случаях пользователь увидит в броузере окно, предлагающее ввести логин и пароль. Если же пользователь вошел успешно, в массиве $user_row мы имеем всю информацию о нем.

Конечно же, пример, который я привёл, имеет ряд существенных недостатков. Не переписывайте его один-в-один, чтобы потом не пасть жертвой попыток подбора пароля, потому что

  • защиты от подбора здесь нет
  • если таблица пользователей большая, при подборе пароля злоумышленник, скорее всего, «завалит» базу

И последний на сегодня способ — хранение зашифрованных данных в куках.

Есть скрипт для входа, остальные подключают код, позволяющий только продолжить действия в закрытой области — если куки истекут, или он выйдет оттуда, придётся возвращаться на страницу для входа.

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

Все остальные программы подключают код, который делает следующее. Делает запрос в базу — выбирает строку с полученным логином. Из этой строки берет поле «log_time» и пароль и делает из них, как и описано выше, хэш. Сравнивает его с тем, что получил, и если они совпадают, выдает новую куку хэша, опять же, от пароля, времени и буквы «Ы» и делает запрос в базу данных «UPDATE user SET log_time=’. ‘ WHERE login=’$cookie_login'».

Опять же, здесь нет никакой защиты от подбора и атаки на сервер (кстати, здесь можно вместо буквы «Ы» писать IP-адрес пользователя — чтобы, например, соседу по офису нельзя было взять файл с кукой и зайти со своего компьютера).

Пароль на страницу. Часть 2. Блокировка подбора

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

Но сначала о блокировке подбора. Банальности, но всё-таки. Пароль длинной десять символов из букв латиницы и цифр — это очень много вариантов. Если подбирать пароль по 1 000 000 вариантов в секунду, понадобится несколько тысяч лет. Но поскольку такую абракадабру запомнить сложно, мы чаще делаем пароль из осмысленных слов. Несколько лет назад оказалось, что большинство паролей можно подобрать при помощи словаря из 10 000 слов. В своё время в сети появился червь (вирус такой), который лазил по юниксовым серверам, используя их дырки в защите, и подбирал пароли привелигированых пользователей при помощи. системного орфографического словаря Юникса. Ничего таскать не надо было!

Каждый пользователь, пока он не ввёл правильный логин и пароль, считается злобным хакером. С чем же мы имеем дело, когда пользователь вводит что-либо неправильно?

  • забывчивость (на это на приличных сайтах есть формочка «забыл пароль», чтобы отправить на введёный в системных настройках email этот самый пароль)
  • баловство («ибо нефиг»)
  • подбор пароля по словарю (вероятность удачного подбора велика, поэтому закрывать надо, тем более, если сайт коммерческого характера)
  • DoS-атака (чтобы не перегрузить сервер, надо минимизировать действия, которые будет выполнять скрипт в таком случае)

Я долго думал, как можно вызвать перегрузку на сервере, если механизм защиты стоит на файлах. Оказалось, несложно (сколько это будет стоить — другой вопрос). Итак, допустим, сервер не выдержит, если скрипт будет пытаться 1000 раз в секунду открывать файлы на запись и писать в них данные. Поскольку после 5 неудачных попыток войти в систему пользователь будет сразу получать отказ в доступе (без какой-либо записи данных в файл), надо найти 200 уникальных IP, с которых по пять раз и обратиться. Это возможно. Вешаем в баннерокрутилке html-баннер с пятью тегами:

Пользователь моментально делает пять обращений сервер пять раз пишет в файл (кстати, в некоторых броузерах, возможно, выскочит окно для ввода логина и пароля). Можно сделать html-страницу с пятью такими картинками, а саму страницу вставить через iframe на посещаемый сайт (через iframe — чтобы по полю referer не нашли. Вряд ли служба поддержки халявного хостинга будет заниматься такими вещами как копание в лог-файлах в поисках рефереров). Те примеры, которые я привёл, разумеется, натянуты, но сам факт того, что можно воспользоваться таким недостатком системы, доказан. Кстати, нечто подобное уже было.

Но всё-таки приведу этот способ — зря писал, что ли? Его, кстати, можно без особого страха применять для ограниченного количества адресов (например, для локальной сети фирмы), положив в директорию файл .htaccess такого содержания:

А вот код программы:

Впрочем, грех работать с файлами, если есть база. Шутка. Для не прошедших авторизации создаём таблицу:


И вместо обращения к файлам работаем с базой.

Хранить ли старые записи для статистики или нет — дело хозяйское. Если что, их можно удалять, выполняя перед авторизацией запрос:

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

Пароль на страницу. Часть 3. Пароль от базы

Была у меня в своё время проблема: надо закрыть администрационную часть сайта, но при этом я не могу положить файл .htpasswd выше корневой директории сайта. Врождённая подозрительность не позволяла положить файл с паролем и отдельную директорию и заблокировать доступ к ней по http. Решил попробовать сделать защиту как в phpMyAdmin: у пользователя спрашиваются логин и пароль, с которыми скрипт соединяется с базой. В своём анализаторе логов я сделал именно так. Удобство метода в том, что файл можно складывать куда угодно — никаких кук, никаких директив сервера для директории. Заодно, если поменяется пароль в базе данных, не надо ничего исправлять в скрипте.

Распишу метод на примере MySQL. Пишем функцию, например, mysql_die:

В начале программы указываются хост сервера БД и, если надо, имя базы:

А для соединения с базой берутся переменные сервера: $PHP_AUTH_USER и $PHP_AUTH_PW.

И всё. Теперь о недостатках. Разумеется, с такой защитой можно пробовать подбирать пароль (в принципе, можно приделать блокировку, но тогда потеряется вся красота метода). Пароль, как и в случае защитой средствами сервера, пересылается в открытом виде. Но для простых задач такое вполне сгодится.

Доступ к сайту по паролю: простой php-скрипт

С помощью данного скрипта мы защитим страницы нашего сайта паролем. Скрипт довольно простой, а что самое главное очень надежный.

Создадим новый файл php — например, lock.php.

Сначала в нём сделаем подключение к базе данных:

Затем вставим следующее:

На 15 строке находится запрос к базе данных, в данном случае к таблице userlist. Вы можете поменять на любое название, в зависимости от того, как вы назовёте таблицу в БД.

А теперь создайте таблицу userlist (или свое название). В ней нам надо будет создать три поля: id, логин и пароль.

После этого создайте нового пользователя (в PHPmyadmin вкладка вставить).

Осталось только подключить наш скрипт, для этого используйте обычную функцию include с адресом до файла lock.php.

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

Как поставить пароль только для главной страницы PHP сайта?

Здравствуйте. Есть самописный движок на php.
Главная страница у него Index.php

Задача, поставить пароль на доступ к Index.php оставив не тронутыми все каталоги и подкаталоги сайта. То есть пароль должен быть только на главной, реально ли? И если да, то как?

update:
Прошу прощения, не знаю уместно ли. но приведу свой код.

Вот исходник Index.php:

Буду очень признателен за любую помощь, в прошлом верстальщик, в php знания очень минимальны 🙁

  • Вопрос задан более года назад
  • 226 просмотров

Просто напишите, в чем проблема?
Если у вас что то не получается, покажите нам код, который вы писали и расскажите что у вас не выходит.
Мы его посмотрим и возможно поможем.

Во всех остальных случаях, обращаться на https://freelansim.ru

тогда этот сервис для чего.
Если не знаете, то зачем вообще пишите что то.

Скрипт самый не на есть обычный скрипт,

Сервис нужен помогать тем, кто ищет помощи.
Как можно помочь тем, кто сам не помогает себе помочь?!

По мне обычный скрипт — самостоятельный скрипт без авторизации. либо это скрипт авторизации без привязки к index.php

Вот как можно помочь людям дать тебе ответ:

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

Защита выполнения php-скрипта паролем

При написании PHP скриптов иногда требуется ввести дополнительный уровень безопасности их исполнения для того, чтобы они могли быть запущены только администратором сайта (или по крайней мере того, кто знает пароль для запуска этого скрипта на исполнение). Задача защиты выполнения php-скрипта паролем достаточно тривиальная: для этого нужно перед исполнением скрипта запросить пароль и сверить его с тем, что был назначен для защиты скрипта от несанкционированного запуска.

Мастер Йода рекомендует:  Разрешение изображений и качество печати

Код защиты паролем выполнения php скрипта

Код защиты паролем выполнения php скрипта в простейшем случае будет выглядеть так:

Пояснения к PHP скрипту с защитой от выполнения паролем

В строке 6 производится проверка соответствия логина и пароля на значения admin / admin (их конечно нужно поменять). И, если логин и пароль совпадают с этими значениями, то выполняется то, что находится в блоке между фигурными скобками этого условия (между строками 7 и 9). В данном случае, выполняется вывод сообщения echo ‘Логин и пароль указаны верно!’;

Если значения введены неправильно или вообще не введены, то срабатывает условие else в строке 10 и выдаётся вывод HTML формы, в которой запрашиваются логин и пароль:

Для работы нужен логин и пароль

Обработчиком формы назначен тот же скрипт, который выдаёт эту форму. Обратите внимание на параметр action=»» в 15-й строке. Его можно изменить, введя тот скрип, который будет обрабатывать логин и пароль, введённый в этой форме.

Резюме

Таким образом можно достаточно просто защитить php скрипт логином и паролем для запуска его только теми пользователями, которые из знают.

Проверку можно усложнять, разнеся её в разные файлы и/или функции, ввести cookie, чтобы правильно введённые пароли не нужно было вводить каждый раз.

Можно упростить данный скрипт, оставив только ввод пароля (логин мне тут кажется лишним).

Код защиты выполнения php-скрипта паролем будет работать на любой версии PHP в том виде, котором он приведён, что и требуется на первом этапе разработки PHP приложения. =)

О том, как передать логин и пароль в php-скрипте в скрытом поле (hidden) формы для того, чтобы его не нужно было каждый раз вводить, можно прочитать в → этой статье.

Использование нескольких паролей для простой защищенной паролем страницы

Я пытаюсь защитить некоторые страницы на моем сайте, используя PHP, но без создания базы данных или имени пользователя.

Я следовал инструкциям, написанным в комментарии к этому сообщению: Каков наилучший способ защитить паролем папку / страницу, используя php без имени пользователя или имени пользователя?
Который работает отлично! Но я хотел бы пойти еще дальше и изменить код, чтобы принимать несколько паролей на одной странице. Это возможно?

Я предполагаю, что это будет что-то вроде: проверьте, существует ли полученное значение в массиве $ password

Решение

Создайте массив паролей, затем используйте функцию in_array, чтобы проверить, есть ли там пароль пользователя.


Строки для изменения:

Другие решения

Вы можете установить свои пароли в виде массива и цикла, чтобы проверить их, как это

Пароль на страницу с помощью php. Установка пароля на страницу

Одна из основных аксиом защиты информации гласит — «комфортность системы обратно пропорциональна её защищённости». Это значит, что при выборе системы защиты необходимо найти оптимальное соотношение сложности защиты и удобства работы пользователей.

С другой стороны, разработка и внедрение защиты требует определённых затрат сил и средств. Следовательно, надо разумно подходить к проектированию защиты. Проще говоря, не надо делать сложную и дорогостоящую систему защиты, если на сайте не хранится ничего ценного. Ни один злоумышленник не полезет ломать вашу домашнюю страничку, сайт-визитку небольшой компании или сайт детского сада.

В предыдущем уроке мы рассматривали авторизацию средствами Web-сервера (Basic-авторизация). Наверное, это самый лёгкий и самый безопасный способ ограничения доступа к ресурсам. Однако, сопровождение такого механизма достаточно трудоёмко, особенно при большом количестве пользователей с различными правами. Кроме того, не все сервера позволяют использовать HTTP-авторизацию.

Более популярная альтернатива — парольная защита. Смысл её в том, что на сервере хранятся списки пользователей и соответствующие им логины, пароли и права доступа. При первом обращении к сайту пользователь вводит логин/пароль и получает доступ к ресурсам. Сервер «запоминает» пользователя и не спрашивает пароль до следующего открытия сессии (перезапуска браузера).

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

Рассмотри пример реализации простейшей парольной защиты. Создадим файл logon.php

При нажатии на кнопку «вход» данные формы будут отправлены на сервер, там скрипт проверит введённые логин и пароль и если они равны «admin» и «megaPass» соответственно — отобразит сообщение, что вход разрешен. Если логин или пароль не верны — пользователь увидит предупреждающее сообщение.

Первый недостаток этого скрипта: передача данных методом GET. При использовании этого метода данные передаются непосредственно в адресе, а значит видны даже невооруженным глазом. Например, если вы ввели правильные логин и пароль, то в адресной строке увидите

Второй недостаток: имена пользователей и пароли зашиты прямо в код. Это значит, что для добавления новых пользователей вам надо будет постоянно менять код файла. А представьте себе, какого размера будет файл, если у вас на сайте хотя-бы тысяча зарегистрированных пользователей. Списки пользователей лучше всего хранить в отдельном файле, а лучше в базе данных, т.к. злоумышленнику файл украсть намного проще, чем добывать что-то из базы данных.

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

Итак, рассмотрим способы устранения этих недостатков.

Скрыть передаваемые данные проще всего используя метод передачи POST. В этом случае браузер сам (скрытно от пользователя) передаст серверу все необходимые данные и перехватить их можно будет только специальными программами из арсенала IT-специалистов, программистов или хакеров.

Как говорилось выше, списки пользователей надо хранить отдельно. Создадим таблицу в тестовой базе данных:

CREATE TABLE `smplusers` (
`user_id` int(11) NOT NULL auto_increment,
`user_name` varchar(50) NOT NULL,
`user_login` varchar(50) NOT NULL,
`user_password` varchar(50) NOT NULL,
`reg_date` datetime NOT NULL,
PRIMARY KEY (`user_id`)
)

и добавим в неё несколько записей пользователей:

INSERT INTO smplUsers
(user_name, user_login, user_password, reg_date)
values
(«Иванов И.И.», «ivanov-i-i», «pass1», NOW()),
(«Петров П.П.», «petrovich», «pass2», NOW()),
(«Сидоров С.С.», «sidorov», «pass3», NOW())

Обратите внимание, что оператор INSERT допускает одновременное добавление в таблицу сразу нескольких записей, при этом данные перечисляются блоками через запятую.

Теперь изменим logon.php таким образом, чтобы имя пользователя и пароль корректно проверялись непосредственно в базе данных:

0)
<
echo «Доступ разрешен
» . «\n»;

echo «Пользователь: » . $row[«user_name»];
>
else
echo «Доступ запрещен!»;
>
>
else
echo «Введите логин и пароль»;
?>

Теперь логин и пароль передаются скрытно, а учётные данные очень просто изменить, отредактировав таблицу в базе данных. Остался последний штрих — научить сервер запоминать факт регистрации. Проще всего сделать это при помощи механизма сессий. Внесём необходимые изменения:

Теперь сервер будет запоминать каждого пользователя, успешно вошедшего в систему, а при следующем обновлении страницы будет выводиться приветственное сообщение.

Это скрипт — лишь пример организации парольной защиты, пусть и вполне функциональный. Сделать из него практически ценный образец можно, добавив проверку вводимых данных, функции шифрования, восстановения пароля, завершения сессии и др.

Я решил описать способы закрыть паролем часть сайта. Тема, на самом деле, большая, поэтому на первый раз ограничусь авторизацией php+mysql.

Самый первый вопрос, который обычно встаёт — как закрыть директорию со скриптами администрирования паролем. При этом не нужно никаких изысков — один или несколько администраторов имеют одни и те же права, а персоналии меняются редко. Проще всего в данной ситуации использовать стандартную серверную авторизацию — положить файлы.htaccess и.htpasswd и прописать в них нужные параметры. Про это уже написано много, поэтому я ничего особо нового не скажу.

Добавлю две вещи. Первое — это куда класть файл.htpasswd. Экспериментальным путем я выяснил, что если, например, путь к документу с сообщением об ошибке (ErrorDocument) пишется относительно системной переменной DocumentRoot. Но путь к файлу с паролями (UserFile) пишется относительно ServerRoot. Насколько я понял, выше ServerRoot положить.htpasswd нельзя — «../» не воспринимается. Всё это сделано для того, чтобы можно было поместить файл с паролями, например, одним уровнем выше корневой директории сайта, чтобы из сети доступа к файлу не было вообще.

Второе — это то, что скрипт может узнать, кто его открывает и пароль: переменные $PHP_AUTH_USER и $PHP_AUTH_PW.

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

Ещё один недостаток — необходимость переписывать файлы с паролями при удалении пользователя или введении нового. Но если это происходит нечасто, этого способа вполне достаточно, к тому же не придётся забивать голову написанием механизма авторизации.

Автоматизация авторизации

Это нужно не только для упрощения работы с большим количеством пользователей и их большой «текучкой». Если нужно держать дополнительную информацию о пользователях, либо необходимо гибкое разграничение прав, лучше перенести авторизацию в базу.

Каждая страница закрытой территории подключает файл с вот таким кодом:

В первой строке из логина удаляются все символы кроме букв, цифр, тире и символа подчеркивания. Затем проверяется количество полученных строк, и только если это одна строка, дается доступ. В остальных случаях пользователь увидит в броузере окно, предлагающее ввести логин и пароль. Если же пользователь вошел успешно, в массиве $user_row мы имеем всю информацию о нем.

Конечно же, пример, который я привёл, имеет ряд существенных недостатков. Не переписывайте его один-в-один, чтобы потом не пасть жертвой попыток подбора пароля, потому что
1. защиты от подбора здесь нет
2. если таблица пользователей большая, при подборе пароля злоумышленник, скорее всего, «завалит» базу

И последний на сегодня способ — хранение зашифрованных данных в куках.

Есть скрипт для входа, остальные подключают код, позволяющий только продолжить действия в закрытой области — если куки истекут, или он выйдет оттуда, придётся возвращаться на страницу для входа.

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

Все остальные программы подключают код, который делает следующее. Делает запрос в базу — выбирает строку с полученным логином. Из этой строки берет поле «log_time» и пароль и делает из них, как и описано выше, хэш. Сравнивает его с тем, что получил, и если они совпадают, выдает новую куку хэша, опять же, от пароля, времени и буквы «Ы» и делает запрос в базу данных «UPDATE user SET log_time=’…’ WHERE login=’$cookie_login’».

Опять же, здесь нет никакой защиты от подбора и атаки на сервер (кстати, здесь можно вместо буквы «Ы» писать IP-адрес пользователя — чтобы, например, соседу по офису нельзя было взять файл с кукой и зайти со своего компьютера).

Пароль на страницу. Часть 2. Блокировка подбора

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

Но сначала о блокировке подбора. Банальности, но всё-таки. Пароль длинной десять символов из букв латиницы и цифр — это очень много вариантов. Если подбирать пароль по 1 000 000 вариантов в секунду, понадобится несколько тысяч лет. Но поскольку такую абракадабру запомнить сложно, мы чаще делаем пароль из осмысленных слов. Несколько лет назад оказалось, что большинство паролей можно подобрать при помощи словаря из 10 000 слов. В своё время в сети появился червь (вирус такой), который лазил по юниксовым серверам, используя их дырки в защите, и подбирал пароли привелигированых пользователей при помощи… системного орфографического словаря Юникса. Ничего таскать не надо было!

Каждый пользователь, пока он не ввёл правильный логин и пароль, считается злобным хакером. С чем же мы имеем дело, когда пользователь вводит что-либо неправильно?
забывчивость (на это на приличных сайтах есть формочка «забыл пароль», чтобы отправить на введёный в системных настройках email этот самый пароль)
баловство («ибо нефиг»)
подбор пароля по словарю (вероятность удачного подбора велика, поэтому закрывать надо, тем более, если сайт коммерческого характера)
DoS-атака (чтобы не перегрузить сервер, надо минимизировать действия, которые будет выполнять скрипт в таком случае)

Я долго думал, как можно вызвать перегрузку на сервере, если механизм защиты стоит на файлах. Оказалось, несложно (сколько это будет стоить — другой вопрос). Итак, допустим, сервер не выдержит, если скрипт будет пытаться 1000 раз в секунду открывать файлы на запись и писать в них данные. Поскольку после 5 неудачных попыток войти в систему пользователь будет сразу получать отказ в доступе (без какой-либо записи данных в файл), надо найти 200 уникальных IP, с которых по пять раз и обратиться. Это возможно. Вешаем в баннерокрутилке html-баннер с пятью тегами:

Пользователь моментально делает пять обращений сервер пять раз пишет в файл (кстати, в некоторых броузерах, возможно, выскочит окно для ввода логина и пароля). Можно сделать html-страницу с пятью такими картинками, а саму страницу вставить через iframe на посещаемый сайт (через iframe — чтобы по полю referer не нашли. Вряд ли служба поддержки халявного хостинга будет заниматься такими вещами как копание в лог-файлах в поисках рефереров). Те примеры, которые я привёл, разумеется, натянуты, но сам факт того, что можно воспользоваться таким недостатком системы, доказан. Кстати, нечто подобное уже было.

Но всё-таки приведу этот способ — зря писал, что ли? Его, кстати, можно без особого страха применять для ограниченного количества адресов (например, для локальной сети фирмы), положив в директорию файл.htaccess такого содержания:

order deny,allow
deny from all
allow from xxx.xxx.xxx

А вот код программы:

$errors = 0; $fn = «ignore/». preg_replace(«[^d.]», «», $REMOTE_ADDR. «.». $HTTP_FORWARDED_FOR); if (is_file($fn)) < if (filectime($fn) 5) < print ("Доступ закрыт. Зайдите через час."); exit(); >; // здесь происходит установка связи с сервером БД. чтобы не трогать зря, если пользователя сразу же «отлупили». $result = mysql_query(«SELECT * FROM user WHERE login=»». preg_replace(«/[^w_-]/», «», $PHP_AUTH_USER). «» AND pass=»». md5($PHP_AUTH_PW). «»»); if (@mysql_num_rows($result)!=1) < header("WWW-Authenticate: Basic realm="secret area""); header("HTTP/1.0 401 Unauthorized"); print ("Authorization required"); fwrite(fopen($fn, "w"), ++$errors); exit(); >; $current_user = mysql_fetch_array($result); mysql_free_result($result); Впрочем, грех работать с файлами, если есть база. Шутка. Для непрошедших авторизаций создаём таблицу: CREATE TABLE unauth (username VARCHAR(64) NOT NULL, pass VARCHAR(64) NOT NULL, ip VARCHAR(255), logintime TIMESTAMP) И вместо обращения к файлам работаем с базой. $errors = @mysql_result(mysql_query(«SELECT count(username) as falses FROM unauth WHERE logintime>DATE_SUB(NOW(),INTERVAL 1 HOUR) AND ip=»$REMOTE_ADDR»»),0); if (mysql_error()) die(mysql_error()); if ($errors>5) < print ("Доступ закрыт. Зайдите через час."); exit(); >; $result = mysql_query(«SELECT * FROM user WHERE login=»». preg_replace(«/[^w_-]/», «», $PHP_AUTH_USER). «» AND pass=»». md5($PHP_AUTH_PW). «»»); if (@mysql_num_rows($result)!=1) < header("WWW-Authenticate: Basic realm="secret area""); header("HTTP/1.0 401 Unauthorized"); print ("Authorization required"); mysql_query("INSERT INTO unauth (username, pass, ip) VALUES ("$PHP_AUTH_USER", "$PHP_AUTH_PW", "$REMOTE_ADDR $HTTP_X_FORWARDED_FOR")"); exit(); >; $current_user = mysql_fetch_array($result); mysql_free_result($result);

Хранить ли старые записи для статистики или нет — дело хозяйское. Если что, их можно удалять, выполняя перед авторизацией запрос:

Опять же, здесь нет никакой защиты от подбора и атаки на сервер (кстати, здесь можно вместо буквы «Ы» писать IP-адрес пользователя — чтобы, например, соседу по офису нельзя было взять файл с кукой и зайти со своего компьютера).

Пароль на страницу. Часть 2. Блокировка подбора

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


Но сначала о блокировке подбора. Банальности, но всё-таки. Пароль длинной десять символов из букв латиницы и цифр — это очень много вариантов. Если подбирать пароль по 1 000 000 вариантов в секунду, понадобится несколько тысяч лет. Но поскольку такую абракадабру запомнить сложно, мы чаще делаем пароль из осмысленных слов. Несколько лет назад оказалось, что большинство паролей можно подобрать при помощи словаря из 10 000 слов. В своё время в сети появился червь (вирус такой), который лазил по юниксовым серверам, используя их дырки в защите, и подбирал пароли привелигированых пользователей при помощи. системного орфографического словаря Юникса. Ничего таскать не надо было!

Каждый пользователь, пока он не ввёл правильный логин и пароль, считается злобным хакером. С чем же мы имеем дело, когда пользователь вводит что-либо неправильно?

  • забывчивость (на это на приличных сайтах есть формочка «забыл пароль», чтобы отправить на введёный в системных настройках email этот самый пароль)
  • баловство («ибо нефиг»)
  • подбор пароля по словарю (вероятность удачного подбора велика, поэтому закрывать надо, тем более, если сайт коммерческого характера)
  • DoS-атака (чтобы не перегрузить сервер, надо минимизировать действия, которые будет выполнять скрипт в таком случае)

Я долго думал, как можно вызвать перегрузку на сервере, если механизм защиты стоит на файлах. Оказалось, несложно (сколько это будет стоить — другой вопрос). Итак, допустим, сервер не выдержит, если скрипт будет пытаться 1000 раз в секунду открывать файлы на запись и писать в них данные. Поскольку после 5 неудачных попыток войти в систему пользователь будет сразу получать отказ в доступе (без какой-либо записи данных в файл), надо найти 200 уникальных IP, с которых по пять раз и обратиться. Это возможно. Вешаем в баннерокрутилке html-баннер с пятью тегами:

Пользователь моментально делает пять обращений сервер пять раз пишет в файл (кстати, в некоторых броузерах, возможно, выскочит окно для ввода логина и пароля). Можно сделать html-страницу с пятью такими картинками, а саму страницу вставить через iframe на посещаемый сайт (через iframe — чтобы по полю referer не нашли. Вряд ли служба поддержки халявного хостинга будет заниматься такими вещами как копание в лог-файлах в поисках рефереров). Те примеры, которые я привёл, разумеется, натянуты, но сам факт того, что можно воспользоваться таким недостатком системы, доказан. Кстати, нечто подобное уже было .

Но всё-таки приведу этот способ — зря писал, что ли? Его, кстати, можно без особого страха применять для ограниченного количества адресов (например, для локальной сети фирмы), положив в директорию файл.htaccess такого содержания:

Order deny,allow deny from all allow from xxx.xxx.xxx

А вот код программы:

// здесь происходит установка связи с сервером БД. чтобы не трогать зря, если пользователя сразу же «отлупили».

Впрочем, грех работать с файлами, если есть база. Шутка. Для непрошедших авторизаций создаём таблицу:

CREATE TABLE unauth (username VARCHAR(64) NOT NULL, pass VARCHAR(64) NOT NULL, ip VARCHAR(255), logintime TIMESTAMP)

И вместо обращения к файлам работаем с базой.

$errors = @mysql_result(mysql_query(«SELECT count(username) as falses FROM unauth WHERE logintime>DATE_SUB(NOW(),INTERVAL 1 HOUR) AND ip=»$REMOTE_ADDR»»),0); if (mysql_error()) die(mysql_error()); if ($errors>5) < print ("Доступ закрыт. Зайдите через час."); exit(); >; $result = mysql_query(«SELECT * FROM user WHERE login=»». preg_replace(«/[^\w_\-]/», «», $PHP_AUTH_USER). «» AND pass=»». md5($PHP_AUTH_PW). «»»); if (@mysql_num_rows($result)!=1) < header("WWW-Authenticate: Basic realm=\"secret area\""); header("HTTP/1.0 401 Unauthorized"); print ("Authorization required"); mysql_query("INSERT INTO unauth (username, pass, ip) VALUES ("$PHP_AUTH_USER", "$PHP_AUTH_PW", "$REMOTE_ADDR $HTTP_X_FORWARDED_FOR")"); exit(); >; $current_user = mysql_fetch_array($result); mysql_free_result($result);

Хранить ли старые записи для статистики или нет — дело хозяйское. Если что, их можно удалять, выполняя перед авторизацией запрос:

Все закрытые страницы вызывают файл, в котором проверяется правильность пароля, полученного из куки:

Имена кук будут использоваться в нескольких местах, поэтому лучше заранее поместить их в одном месте (например, объявив константы), чтобы потом не исправлять по нескольку раз.

Как видите, пароль будет бегать по каналу и лежать в файле с куками в открытом незакодированном виде. Это очень небезопасно. В отсутствие хозяина можно подойти к компьютеру, заглянуть в файл, где броузер держит куки, и записать пароль на бумажку (а если в локальной сети всё общее, то и подходить не надо, и стащить пароль можно прямо при хозяине).

Чтобы этого не произошло, пароль нужно кодировать. Как приемлемый вариант, хэш md5. Тут уже нельзя увидеть пароль и зайти в систему, записав его на бумажку или copy-paste-нув. Кстати, именно так можно залазить под паролем и без ведома друга в web-интерфейсы, строящие авторизацию на сессиях. Поэтому последнее, что можно сделать в этом направлении — это менять куку при каждой загрузке страницы.

Сам когда-то делал такую схему: в таблице пользователей есть колонка с датой последнего обращения. Эту дату последнего обращения и пароль, закодированные через md5, пользователь получает при каждом обращении. Система берёт куку с логином, вытаскивает из базы эту строку, генерирует хэш от полей last_log и passwd и сравнивает его с полученным. Если они совпадают, значит посетителя можно впускать. Для пущей безопасности можно добавить проверку на истечение куки — кука должна истечь после получаса неактивности, и, соответсвенно, в базе дата последнего лога должна быть менее чем полчаса назад.

Разумеется, » Ы — чтоб никто не догадался « лучше тоже выделить в отдельную переменную, а лучше использовать вместо этой строки ip-адрес посетителя (или, для обрывающегося диалапа, первые два/три числа ip-адреса).

Кстати, насчёт IP-адреса. Его лучше проверять, но не весь адрес, а только первые два (для ip, начинающихся на число меньше 127) или три (соответственно, больше 127) числа адреса. Это спасёт пользователей плохого и обрывающегося диалапа от необходимости заново авторизовыватсья после обрыва связи, и в то же время, не даст зайти взломщику, укравшему куку. Конечно же, он не сможет перезвонить и зайти через другого провайдера — адрес пула не тот, но это не наши проблемы («в такую погоду свои дома сидят»). Как не наша проблема и воровство паролей внутри фирмы. Мы защитили от любопытных товарищей и неграмотных взломщиков, а против троянов и снифферов, которые можно поставить жертве, ничего сделать не можем.

На этом «навороты» закончились. Надёжнее защиту уже не сделать. Никто не будет лазить в файл кук за хэшем и подбирать его. Проще будет поместить между пользователем и веб-интерфейсом сниффер и при помощи него найти пароль. Можно поместить трояна, который будет запоминать всё, что пользователь ввёл на клавиатуре, но это уже не наши проблемы. Чтобы защититься от прослушивания канала, надо использовать соединения типа SSL или шифрование данных.

Пароль на страницу. Часть 5. Сессии

Зачем я писал заметку про куки? «Не понимаю, зачем писать про куки, когда в php есть сессии?!» Затем, чтобы у читателей не образовывалась перед глазами плоская картина. Не везде ещё стоит php 4-й версии, а в третьей они не поддерживаются. Более того, не везде сессии так необходимы — за редким исключением алгоритм авторизации проверяет правильность логина/пароля и правильность данных сессии, а затем либо отфутболивает клиента на страницу входа, либо берёт массив (или объект) с данными о пользователе.

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

В общем, я не утверждаю, что сессиями пользоваться не нужно. Нужно, только всему своё место. К вопросу применимости трёх способов авторизации — через 401-й заголовок («realm»), куки или сессии — я вернусь позже. Сейчас поговорю о сессиях.

Сессии в php — это на самом деле не метод авторизации (само понятие неправильное, но в форумах спрашивают именно «как авторизовывать пользователя через сессии?»). Встроенный в php механизм пользовательских сессий лишь идентифицирует этих пользователей, авторизовывать — опять же, работа вашего скрипта.

Много про механизм сессий рассказывать не буду — уже рассказано. В самом простом виде (вернее в самом dafault-ном) механизм этот работает так: система держит на сервере файл сессии, в котором содержатся её переменные. Пользователь при запуске сессии получает уникальный идентификатор (обычно через куку), и при обращении к другим страницам отправляет её. При запуске механизма сессий в вашем скрипте обработчик php проверяет, существует ли файл соответствующий пришедшему идентификатору сессии — если существует, то скрипт сможет прочесть данные из файла, если нет — будет запущена новая сессия и создан файл. Разумеется, имя данной переменной опеределено в установках php.

Теперь о том, какими функциями мы пользуемся.

session_start() . Запускает сам механизм сессий. От пользователя должна быть переменная и соответствующий ей файл. Если нет файла, он создаётся, и сессия запускается с нуля. Если нет ни файла, ни переменной, то генерируется переменная (например, посылается заголовок с кукой) и создаётся файл.

session_register(имя1, имя2, имя3. ) . Указание, какие переменные запомнить в файле по окончании работы скрипта. После того как пользователь перейдёт к другой странице, можно запустить механизм сессий, и после вызова данной функции переменные будут доступны.

session_destroy() . Удаляет файл данных сессии (при использовании кук надо удалять их вручную, выставив пустую куку: «setcookie(session_name())» ).

session_set_cookie_params(жизнь, путь, домен) . Установка параметров куки с идентификатором сессии (по умолчанию кука выставляется на корень сервера и на 0 секунд — до закрытия браузера).

Пока всё. Подробно про сессии будут отдельные выпуски. Пока опишу механизм авторизации и идентификации пользователя при помощи сессий.

Итак, имеем три файла — вход (login), проверка (auth) и выход (logout).

Данный скрипт является и обработчиком и формой для ввода данных. При получении логина и пароля он обрабатывает их и, если они правильные, прекращает работу, отправив пользователя на нужную страницу. Если данные неправильные или вообще отсутствуют, рисует форму.

Пользователь проверен и в массиве $user — все данные о нём, можно, например, поприветствовать его по имени-отчеству:

Пара замечаний: закрываемая паролем часть в данном примере — весь сервер (например, service.firm.ru), для закрытия директории нужно исправить пути. Вместо PHPSESSID используется session_name() , чтобы можно было свободно менять имя идентификатора. Кстати, на одном физическом сервере можно делать разные имена идентификаторов сессий — достаточно в нужную часть положить файл.htaccess со строкой php_value session.name «ABRACADABRA» .

Есть еще вопросы или что-то непонятно — добро пожаловать на наш

Ставим пароль на страницу

Данная статья не претендует на какие-то откровения, все эти вещи достаточно очевидны и широко известны. Но получив за последнее время несколько вопросов об ограничении доступа к web-страницам, я решил свести ответы на них вместе.

Итак, наша задача — установить пароль на доступ к некоторой странице. Начнем с самого примитивного способа, если можно так сказать, защиты — нескольких строчек на JavaScript»е. Код — что-то вроде

Var pass = prompt(«Enter the Password:», «»); if (pass == null) window.location = «bad.html»; else if (pass.toLowerCase() == «password») window.location = «ok.html»; else window.location = «bad..js»> принципиально ничего не меняют.

Уровнем повыше расположена аналогичная система, реализованная на Java.

Ниже приведен упрощенный исходный код.

Import java.applet.*; import java.awt.*; import java.net.*; public ; > try < getAppletContext().showDocument (new URL(s)); >catch(Exception e) < password.setText(e.toString()); >return true; > return false; > >

Включив этот апплет в страницу, можно получить нечто такое:

; $localpath = «/materials/pagepsw/»; $login = «login»; $password = «password»; $l = $query->param(«login»); $p = $query->param(«password»); if(($p eq $password) && ($l eq $login)) < $address = $ok; >print $query->header(); open (FL, $docroot.$localpath.$address); while( ) < # Здесь заодно можно на лету модифицировать html-код # Зачем? Ну мало ли. :) print $_; >close (FL);

Как видно, URL файла уже не светится, правда ценой SSI, если что-то подобное присутствовало (впрочем, это как раз можно отлавливать при выводе и обрабатывать вручную). Но и здесь остается теоретическая возможность угадывания URL, при этом не надо забывать, что медвежью услугу могут сослужить всевозможные картинки, включаемые в страницы — при использовании относительных путей, конечно.

Наконец, наиболее надежный способ установки пароля на доступ — это воспользоваться средствами сервера — не зря ж их люди делали, в конце концов. Остановлюсь на двух — Апаче как самом популярном и IIS как тоже популярном:)

С IIS все совсем просто — защита осуществляется средствами NTFS, что, конечно, несколько ограничивает возможности не-администраторов сервера. Идея следующая: у пользователя IUSR_xxxx, под аккаунтом которого по умолчанию работают все посетители узла, отбирается доступ к желаемому файлу/каталогу. После чего доступ к этим файлам будут иметь только те пользователи, для которых это явно указано в Properties->Security. Понятно, что их гораздо удобнее объединять в группы. Здесь есть пара тонкостей. Во-первых, указанным пользователям должно быть дано право Logon locally (Policies->User Rights в User Manager»е). Во-вторых, если не выбрать в настройках WWW service Basic authentication (Clear Text), внутрь будут пропущены только пользователи Internet Explorer»а.

В Apache все делается несколько иначе. Защита ставится на уровне каталогов. Соответствующие директивы могут быть помещены как в в общий конфигурационный файл (в разделе ), так и в файлы.htaccess. Набор директив в обоих случаях одинаков, а для большинства людей, арендующих место под сайт/страницу на чужом сервере, гораздо актуальнее второй способ. Итак, вы создаете в каталоге, доступ к которому планируется ограничить, файл.htaccess, после чего вставляете в него следующие директивы (привожу основные):

AuthType тип контроля — обычно используется Basic.


AuthName имя — задает имя области, в которой действительны имена и пароли пользователей. Это то самое имя, которое броузер показывает в диалоге ввода пароля. Задав одно такое имя для разных каталогов, можете сэкономить пользователям время по вводу лишнего пароля.

AuthGroupFile имя — задает имя файла, в котором хранятся имена групп и их членов. Его формат:
group1: member1 member2 .
group2: member3 member4 .

AuthUserFile имя — задает имя файла с паролями. По большому счету для его формирования надо воспользоваться утилитой htpasswd из поставки Apache. Но по крайней мере для некоторых версий сервера этот формат такой:
user1:passwordhash1
user2:passwordhash2

Passwordhash вполне можно получить стандартной функцией Perl»а:
$hash=crypt($pass,$salt);
где $pass — пароль, $salt — строка из двух символов, участвующая в формировании хэша.

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

require user user1 user2 и require group user1 user2 позволяют указать, какие пользователи и группы получат доступ к данному каталогу.

require valid-user разрешает доступ всем пользователям, указанным в файле паролей системы.

  • . , где methodi определяет HTTP-метод. Например,
  • ограничивает применение вложенных в нее директив случаями использования методов GET и POST (обычно этого более чем достаточно). Вложенными могут быть директивы require, order, allow и deny.

    Еще пара полезных директив — deny и allow — соответственно запрещения и разрешения доступа. Применяются примерно так:
    deny from all
    allow from 192.168

    По умолчанию сначала выполняются все deny, потом все allow, так что allow from all разрешит доступ всем пользователям, невзирая ни на какие deny. Порядок можно изменить директивой order: order allow, deny.

    deny from all отлично сочетается со вторым способом защиты страниц через CGI, именно этой директивой лучше всего прикрывать всякие пароли к гостевым книгам и т.д.

    Кстати, тут между делом демонстрируется самостоятельная обработка ошибок: в данном случае — код 403, Forbidden. Аналогично обрабатывается и всеми любимая 404, Not Found, и 401, Unauthorized. Для этого достаточно добавить в.htaccess директиву ErrorDocument код url :
    ErrorDocument 404 /cgi-bin/bad.pl
    ErrorDocument 403 /cgi-bin/badaccess.pl
    ErrorDocument 401 /cgi-bin/badaccess.pl

    Все, что делает скрипт — формирует сообщение об ошибке, используя переменную окружения REQUEST_URI, так что всместо него вполне можно просто указать какую-нибудь подходящую страницу.

    Для заключительного примера используем файл.htaccess со следующим содержимым:

    AuthType Basic AuthName Test AuthGroupFile /. /pagepsw/deny/tgroup AuthUserFile /. /pagepsw/deny/tuser
    require group test

    В файле tgroup всего одна строчка — test: login test , в файле tuser — зашифрованные пароли для login (password) и test (test). Обратите внимание, при повторном обращении к этой странице броузер понимает, что только что обращался к этой области, и не утруждает пользователя лишним запросом пароля.

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

    Итак, наша задача — установить пароль на доступ к некоторой странице. Начнем с самого примитивного способа, если можно таксказать, защиты — нескольких строчек на JavaScript:

    Var pass = prompt(«Enter the Password:», «»); if (pass == null) window.location = «wrong.html»; else if (pass.toLowerCase() == «wwvsfc») window.location = «temp.html»; else window.location = «wrong.html»; Ухищрения наподобие скрытия скрипта в отдельном файле с помощью конструкции принципиально ничего не меняют.

    Аналогичная система, реализованная на Java:

    Import java.applet.*; import java.awt.*; import java.net.*; public ; > try < getAppletContext().showDocument(new URL(s)); >catch(Exception e) < password.setText(e.toString()); >return true; > return false; >>

    Включив этот апплет в страницу, можно получить нечто такое (во всех последующих примерах используются ok.html и bad.html):

    Password check

    Его можно сделать поумнее, завести для каждого пользователя отдельную страницу,заставить считывать данные из файла и т.д. Принципиальный недостаток — после того как человек попал на искомую страницу, никто не в силах запретить ему запомнить этот URL, так что средство это одноразовое. Конечно, можно запрятать страницу внутрь фрейма, чтобы URL не светился в строке адреса, но сами понимаете, от кого эта защита. Опять же, апплет полностью уходит к клиенту и в принципе полностью доступен для исследования.

    Последнего недостатка лишено решение, основанное на использовании CGI. Простенький скрипт на Perl»е выглядит примерно так:

    #!/usr/bin/perluse CGI qw(:standard); $query = new CGI;$ok = «ok.html»;$address = «bad.html»; $login = «login»;$password = «password»; $l = $query->param(«login»); $p = $query->param(«password»); if(($p eq $password) && ($l eq $login))< $address = $ok;>print $query->redirect($address);

    Чтобы справиться с первым недостатком, можно динамически сформировать новую страницу на основе спрятанной где-то там внутри, не выдавая при этом URL.

    #!/usr/bin/perluse CGI qw(:standard); $query = new CGI; $ok = «ok.html»; $address = «bad.html»; $docroot = $ENV<"DOCUMENT_ROOT">; $localpath = «/articles/»; $login = «login»;$password = «password»; $l = $query->param(«login»); $p = $query->param(«password»); if(($p eq $password) && ($l eq $login)) < $address = $ok;>print $query->header(); open (FL, $docroot.$localpath.$address); while( ) <# Здесь заодно можно на лету модифицировать html-код# Зачем? Ну мало ли. :) print $_;>close (FL);

    Как видно, URL файла уже не светится, правда ценой SSI (впрочем, их как раз можно отлавливать при выводе и обрабатывать вручную).Но и здесь остается теоретическая возможность угадывания URL, при этом не надо забывать, что медвежьюуслугу могут сослужить всевозможные картинки, включаемые в страницы — при использовании относительных путей,конечно.

    Наконец, наиболее надежный способ установки пароля на доступ — это воспользоваться средствами сервера -не зря ж их люди делали, в конце концов. Остановлюсь на двух — Апаче как самом популярном и IIS кактоже популярном:)

    С IIS все совсем просто — защита осуществляется средствами NTFS, что, конечно, несколько ограничивает возможности не-администраторов сервера. Идея следующая: у пользователя IUSR_xxxx, под аккаунтомкоторого по умолчанию работают все посетители узла, отбирается доступ к желаемому файлу/каталогу. После чего доступ к этим файлам будут иметь только те пользователи, для которых это явно указано в Properties->Security. Понятно, что их гораздо удобнее объединять в группы. Здесь есть пара тонкостей. Во-первых, указанным пользователямдолжно быть дано право Logon locally (Policies->User Rights в User Manager»е). Во-вторых, если не выбратьв настройках WWW service Basic authentication (Clear Text), внутрь будут пропущены только пользователиInternet Explorer»а.

    В Apache все делается несколько иначе. Защита ставится на уровне каталогов. Соответствующие директивы могут быть помещены как в общий конфигурационный файл php.ini, так и в файлы.htaccess . Набор директив в обоих случаях одинаков, а для большинства людей, арендующих место под сайт/страницу на чужом сервере, первый вариант недоступен. Итак, вы создаете в каталоге, доступ к которому планируется ограничить, файл.htaccess , после чего вставляете в него следующие директивы:

    AuthType тип контроля — обычно используется Basic.

    AuthName имя — задает имя области, в которой действительны имена и пароли пользователей. Это то самое имя, которое броузер показывает в диалоге ввода пароля. Задав одно такое имя для разных каталогов, можете сэкономить пользователям время по вводу лишнего пароля.

    AuthGroupFile имя — задает имя файла, в котором хранятся имена групп и их членов. Его формат:
    group1: member1 member2 .
    group2: member3 member4 .

    AuthUserFile имя — задает имя файла с паролями. По большому счету для его формирования надо воспользоваться утилитой htpasswd из поставки Apache. Но по крайней мере для некоторых версий сервера этот формат такой:
    user1:passwordhash1
    user2:passwordhash2

    Passwordhash вполне можно получить стандартной функцией Perl»а:
    $hash=crypt($pass,$salt);
    где $pass — пароль, $salt — строка из двух символов, участвующая в формировании хэша.

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

    require user user1 user2 и require group user1 user2 позволяют указать, какие пользователи и группы получат доступ к данному каталогу.

    require valid-user разрешает доступ всем пользователям, указанным в файле паролей системы.

  • . , где methodi определяет HTTP-метод. Например,
  • ограничивает применение вложенных в неедиректив случаями использования методов GET и POST (обычно этого более чем достаточно).Вложенными могут быть директивы require, order, allow и deny.

    Еще пара полезных директив — deny и allow — соответственно запрещения и разрешения доступа.Применяются примерно так:
    deny from all
    allow from 192.168

    По умолчанию сначала выполняются все deny, потом все allow, так что allow from all разрешит доступ всем пользователям, не взирая ни на какие deny. Порядок можно изменить директивой order: order allow, deny .

    deny from all отлично сочетается со вторым способом защиты страниц через CGI, именно этой директивой лучше всего прикрывать всякие пароли к гостевым книгам и т.д. При попытке обращения к страницам из этого каталога пользователь получит сообщение о несуществующей странице.

    Кстати, тут между делом демонстрируется самостоятельная обработка ошибок: в данном случае — код 403, Forbidden. Аналогично обрабатывается и всеми любимая 404 — Not Found, и 401 — Unauthorized. Для этого достаточнодобавить в.htaccess директиву ErrorDocument код url :
    ErrorDocument 404 /cgi-bin/bad.pl
    ErrorDocument 403 /cgi-bin/badaccess.pl
    ErrorDocument 401 /cgi-bin/badaccess.pl

    Все, что делает скрипт — формирует сообщение об ошибке, используя переменную окружения REQUEST_URI, так что всместо него вполне можно просто указать какую-нибудь подходящую страницу.

    Для заключительного примера используем файл.htaccess со следующим содержимым:

    AuthType BasicAuthName TestAuthGroupFile /my/local/path/tgroupAuthUserFile /my/local/path/tuser
    require group test

    В файле tgroup всего одна строчка — test: login test , в файле tuser — зашифрованные пароли для login (password) и test (test). Обратите внимание, при повторном обращении к этой странице браузер понимает, что только что обращался к этой области, и не утруждает пользователялишним запросом пароля.

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

    Самый простой пример реализации формы входа на сайт


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

    Для этого необходимо создать два файла с расширением «php»:

    1. index.php – это главная страница сайта и здесь мы установим форму авторизации с двумя полями (логин и пароль) а ниже поставим надпись, которая просит авторизоваться и перейти по ссылке, а ссылка в свою очередь будет видна только авторизованному пользователю.
    2. proverca.php – на этой странице напишем код, который будет подключаться к базе данных и проверять существует ли пользователь с таким именем и паролем, если не существует, то выводим на экран сообщение об ошибке, а если существует, то автоматический переходим на главную страницу. При этом к нам привязывают две глобальные переменные (сессии : «$_SESSION[‘login’] и $_SESSION[‘id’]») которые служат как своеобразный пропуск.

    Теперь когда мы попали на главную страницу с логином и уникальном номером, то «php скрипт» принимает нас за своих и показывает нам скрытую ссылку.

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

    Для того чтобы выйти нам потребуется файл который удалит все глобальные переменные «сессии». Мы этот файл привяжем к ссылке «выйти», которая будет видна только авторизированному пользователю.

    Защита паролей в современном PHP

    Познакомьтесь с тем, каким образом в версии PHP 5.5 существенно повышена безопасность манипулирования паролями

    Серия контента:

    Этот контент является частью # из серии # статей: Обновленный PHP

    Этот контент является частью серии: Обновленный PHP

    Следите за выходом новых статей этой серии.

    С самого начала своего существования язык программирования PHP был предназначен для построения веб-сайтов. Эта идея встроена в PHP гораздо глубже, чем в любой другой язык программирования — возможно, это одна из причин, по которой язык PHP стал и остается столь популярным средством для создания веб-приложений. Однако в середине 1990-х годов, когда язык PHP разрабатывался, термин веб-приложение еще не существовал. В то время защита паролей не относилась к категории возможностей, на которые создатели PHP обращали внимание. В конце концов разработчику не нужно было волноваться о паролях, пока он использовал PHP только для того, чтобы поместить на своей веб-странице счетчик посещения сайта или метку даты изменения.

    Однако прошло 20 лет – и сегодня нельзя даже подумать о создании веб-приложения, не имеющего защищенных паролем учетных записей пользователей. Исключительно важно, чтобы PHP-программисты оберегали пароли учетных записей с помощью самых современных и безопасных методов. С этой целью в версии PHP 5.5 была добавлена новая библиотека хеширования паролей, которую создал Энтони Феррара, (@ircmaxell). Эта библиотека предоставляет доступ к нескольким функциям, которые можно использовать для реализации одностороннего шифрования пароля с помощью современных наилучших методик. Другие функции предвосхищают будущие потребности безопасности, чтобы можно было оставаться на шаг впереди злоумышленников, когда компьютеры и хакерские технологии станут более совершенными. Эта статья предлагает читателю углубленное введение в функции этой библиотеки и описывает способы ее наилучшего использования.

    Об этом цикле статей

    Непрерывно эволюционируя в рамках активного проекта с открытым исходным кодом, язык PHP в настоящее время обеспечивает функционирование значительной части мирового Web. Современный PHP значительно отличается от того языка сопоставления с шаблонами, каким он был в момент своего зарождения. Если вы много лет не использовали и не изучали технологию PHP, то вы с трудом узнаете некоторые из сегодняшних проектов на PHP. Этот цикл статей демонстрирует новейшие возможности PHP и рассказывает, как использовать сегодняшний язык PHP для создания современных безопасных веб-сайтов.

    Важность хешей для поддержания безопасности

    “ Относитесь к своему паролю как к зубной щетке. Не позволяйте никому другому пользоваться им и заводите новый каждые шесть месяцев ”

    Клиффорд Столл (Clifford Stoll)

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

    Что такое хеш?

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

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

    Скорость взламывания

    Не все хеши равноценны. Для создания хеша можно использовать различные алгоритмы. В прошлом обычно использовались два алгоритма MD5 и SHA-1. Современные мощные компьютеры способны довольно легко взломать оба этих алгоритма. Например, существует программное обеспечение, которое при работе на одном графическом процессоре взламывает хеши со скоростью 3650 миллионов вычислений в секунду для алгоритма MD5 и 1360 миллионов вычислений в секунду для алгоритма SHA 1. При таких скоростях не очень сложные и длинные пароли можно взломать менее чем час.

    Таким образом, большое значение имеет применение алгоритмов хеширования с более высокой вычислительной сложностью. Нам нужен не только длинный хеш (что уменьшает вероятность конфликтов хешей — когда две фразы дают один и тот же хеш), но медленно вычисляемый. Почему? Пользователь вашего веб-приложения должен ждать, пока сгенерируется хеш пароля, всего лишь один раз при каждом входе в систему. Если это ожидание длится секунду (или даже несколько секунд), пользователь не обратит внимания или вообще не заметит этого. Однако снижение скорости взлома с 3,6 миллиардов вычислений в секунду до 1 вычисления в секунду резко усложняет попытки взлома.

    Радужные таблицы

    Нам также необходимо защищаться от т. н. радужных таблиц (rainbow table). Радужные таблицы, например, таблица для алгоритма MD5, которую можно получить на сайте md5cracker.org, представляют собой таблицы обратного преобразования хешей. Создатель такой таблицы заранее вычисляет MD5-хеши для множества распространенных слов, фраз, измененных слов и даже случайных строк. Лицо, имеющее доступ к хешу, может ввести его в поисковый механизм, чтобы выявить пароль, который использовался для генерации этого хеша, то есть по существу инвертировать односторонний процесс. Относительно низкие вычислительные затраты на взламывание MD5-хеша обеспечивают возможность создания такой радужной таблицы.

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

    Совершенствование прежних PHP-практик в области паролей

    В листинге 1 показано пример того, что несколько лет назад считалось хорошей практикой в сфере защиты паролей в PHP.

    Листинг 1. Что было принято считать хорошей защитой паролей в PHP

    Примерами, подобными листингу 1, под видом «наилучших методик» наводнен весь Интернет. И на протяжении долгого времени этот подход действительно был наилучшей методикой — он, несомненно, был лучше, чем использование алгоритма MD5, и радикально лучше, чем хранение паролей в виде простого текста. В листинге 1 используется гораздо более сложный алгоритм SHA 512; он принудительно применяет соль ко всем паролям, чтобы нейтрализовать заранее сделанные радужные таблицы. Однако при применении этого подхода остается несколько проблем.

    Переход к случайной соли

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

    Дальнейшее повышение вычислительных затрат

    В листинге 1 также используется гораздо более сложный алгоритм SHA 512, который входит в комплект поставки PHP вместо алгоритмов MD5 и SHA 1. Тем не менее, даже хеши на основе SHA 512 можно взламывать со скоростью примерно 46 миллионов вычислений в секунду. Это медленнее, чем при использовании алгоритмов MD5 и SHA1, но тем не менее слишком быстро, чтобы обеспечить надлежащую защиту. Решение этой проблемы состоит в том, чтобы использовать алгоритмы с еще более высокой вычислительной сложностью и выполнять эти алгоритмы по несколько раз. Например, последовательная многократная (по 100 раз) обработка каждого пароля с помощью алгоритма SHA 512 значительно замедлила бы любую попытку взлома.

    Хорошая новость состоит в том, что разработчику нет необходимости пытаться реализовать это решение в виде собственного программного кода. В версии PHP 5.5 имеется новая библиотека хеширования паролей, удовлетворяющая именно эту потребность.

    Представляем функцию password_hash()

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

    Задание стоимости вычислений

    Вы также можете предоставить третий параметр, представляющий собой массив опций, которые изменяют порядок генерации хеша. Вы можете задать соль здесь, но лучше этого не делать, а разрешить генерацию случайной соли для вас. Что еще важнее, в этом массиве можно задать значение параметра cost . value. Это значение — равное по умолчанию 10 — определяет вычислительную сложность алгоритма и соответственно продолжительность генерации хеша (это значение можно рассматривать как количество повторных исполнений алгоритма «поверх себя» с целью замедления вычислений). Если вы хотите повысить безопасность пароля, а ваши аппаратные средства способны к этому, можно выполнить вызов следующим образом:

    При использовании моего компьютера MacBook Pro в качестве среды тестирования генерация хеша с помощью password_hash при значении cost, равном 10 (значение по умолчанию) занимает около 0,085 с. Повышение значения cost до 14 изменяет это время до серьезного значения: по 1,394 секунд в пересчете на одно вычисление.

    Верификация сгенерированных паролей

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

    Теперь осуществим рефакторинг класса в листинге 1, чтобы использовать встроенное расширение, хеширующее пароль (см. листинг 2).

    Листинг 2. Рефакторинг класса Password из листинга 1

    Реагирование на меняющиеся потребности в области безопасности

    С помощью нового расширения для хеширования паролей вы можете привести базу своего кода в соответствие с современными стандартами безопасности. Однако всего лишь несколько лет назад специалисты рекомендовали применять в качестве наилучшей методики алгоритм SHA-1. Что же произойдет, если — точнее, когда— потребуется более сильное шифрование паролей? К счастью, у нового расширения есть встроенная функция, которая учитывает эту возможность.

    С помощью функции password_needs_rehash() можно определить — не афишируя это — что сохраненный пароль не соответствует текущим требованиям безопасности, которые вы установили. Причина может состоять в том, что вы увеличили параметр cost или что в новой версии PHP негласно осуществлен переход к другому алгоритму хеширования. Вот почему при выборе алгоритма вам следует указывать опцию PASSWORD_DEFAULT ; в этом случае ваше программное обеспечение будет всегда использовать актуальную наилучшую методику.

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

    Это сбивает с толку некоторых программистов, поскольку функция password_needs_rehash() лишь сообщает о том, что пароль нуждается в повторном хешировании. Дальнейшие действия полностью остаются на вашей ответственности – вам нужно сгенерировать новый хеш пароля и сохранить его (поскольку расширение для хеширования паролей не знает, каким образом вам нужно сохранить пароль).

    В листинге 3 я представляю полный макет класса User , в котором с помощью вышеописанных инструментов я безопасно манипулирую паролем пользователя и делаю возможными будущие изменения требований к безопасности.

    Листинг 3. Макет класса User , демонстрирующий полномасштабное использование расширения для хеширования паролей

    Заключение

    Теперь вы знаете, как работает новая библиотека хеширования паролей для PHP и как она будет защищать ваших пользователей от нарушений безопасности. В следующей статье цикла Обновленный PHP я перейду от рассмотрения самого языка PHP к экосистеме и инструментам, которые начали развиваться на его основе — начиная с инструмента Composer для управления зависимостями в PHP, который быстро приобрел широкую популярность у PHP-сообщества.

    Ресурсы для скачивания

    Похожие темы

    • Документация по функции hash() на сайте php.net
    • Документация по хешированию паролей на сайте php.net
    • Оригинал статьи: PHP renewed: Password security in modern PHP
    • Ресурсы проекта PHP: Ознакомьтесь с ресурсами проекта PHP на сайте developerWorks, чтобы расширить свои навыки в области PHP.
    • The Rainbow Table Is Dead (блог ircmaxell, август 2011 г.). Узнайте, почему Энтони Феррара (Anthony Ferrara) считает метод грубой силы более серьезной угрозой, чем радужные таблицы.
    • PHP: The Right Way: Современный подход к построению PHP-проектов, включая использование хеширования паролей.
    • Документация по PHP: Официальный источник всей документации по PHP.
    • PHPDeveloper.org: Новости, представления и информация сообщества PHP.
    • php[architect]: Онлайновый и печатный журнал, публикующий учебные материалы и последние новости по PHP.
    • Другие материалы по PHP на сайте developerWorks: Просмотрите все остальные материалы по PHP на сайте developerWorks.

    Комментарии

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

    Добавить комментарий