Як поставити пароль на сторінку

Пароль на сторінку. Частина 1. Швидше теоретична

Додам дві речі. Перше - це куди класти файл .htpasswd. Експериментальним шляхом я з'ясував, що якщо, наприклад, шлях до документа з повідомленням про помилку (ErrorDocument) пишеться щодо системної змінної DocumentRoot. Але шлях до файлу з паролями (UserFile) пишеться щодо ServerRoot. Наскільки я зрозумів, вище ServerRoot покласти .htpasswd не можна - "../" не сприймається. Все це зроблено для того, щоб можна було помістити файл з паролями, наприклад, одним рівнем вище кореневої директорії сайту, щоб з мережі доступу до файлу не було взагалі.

Друге - це те, що скрипт може дізнатися, хто його відкриває і пароль: змінні $ PHP_AUTH_USER і $ PHP_AUTH_PW.

Кожна сторінка закритій території підключає файл з ось таким кодом:

У першому рядку з логіна видаляються всі символи крім літер, цифр, тире і символу підкреслення. Потім перевіряється кількість отриманих рядків, і тільки якщо це один рядок, дається доступ. В інших випадках користувач побачить в браузері вікно, яке пропонує ввести логін і пароль. Якщо ж користувач увійшов успішно, в масиві $ user_row ми маємо всю інформацію про нього.

Звичайно ж, приклад, який я навів, має ряд істотних недоліків. Чи не переписуйте його один-в-один, щоб потім не стати жертвою спроб підбору пароля, тому що
  • захисту від підбору тут немає
  • якщо таблиця користувачів велика, при підборі пароля зловмисник, швидше за все, "завалить" базу

І останній на сьогодні спосіб - зберігання зашифрованих даних в куках.

Вхідний скрипт перевіряє логін і пароль і видає дві куки. У першій - логін, щоб відразу впізнати користувача (в базі поле логіна, природно, унікальне або навіть ключове). У другій Кука - хеш від часу входу і пароля (для повноти конспірації я додаю до цих рядків букву "И" - тоді хеш підібрати майже неможливо :).

Всі інші програми підключають код, який робить наступне. Робить запит до бази - вибирає рядок з отриманим логіном. З цього рядка бере поле "log_time" і пароль і робить з них, як і описано вище, хеш. Порівнює його з тим, що отримав, і якщо вони збігаються, видає нову куку хеша, знову ж таки, від пароля, часу і букви "И" та робить запит до бази даних "UPDATE user SET log_time = '.' WHERE login = '$ cookie_login ' ".

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

Коли я виклав цей випуск в минулий раз, мене зупинили на місці, мовляв таким блокуванням можна і сервер "пустити під укіс".

Але спочатку про блокування підбору. Банальності, але все-таки. Пароль довгою десять символів з букв латиниці і цифр - це дуже багато варіантів. Якщо підбирати пароль по 1 000 000 варіантів в секунду, знадобиться кілька тисяч років. Але оскільки таку абракадабру запам'ятати складно, ми частіше робимо пароль з осмислених слів. Кілька років тому виявилося, що більшість паролів можна підібрати за допомогою словника з 10 000 слів. Свого часу в мережі з'явився черв'як (вірус такої), який лазив по юніксовим серверів, використовуючи їх дірки в захисті, і підбирав паролі прівелігірованих користувачів за допомогою. системного орфографічного словника Юнікса. Нічого тягати не треба було!

Кожен користувач, поки він не ввів правильний логін і пароль, вважається злісним хакером. З чим же ми маємо справу, коли користувач вводить щось неправильно?
  • забудькуватість (на це на пристойних сайтах є формочка "забув пароль", щоб відправити на введений в системних настройках email цей самий пароль)
  • баловство ( "бо нєфіг")
  • підбір пароля за словником (ймовірність вдалого підбору велика, тому закривати треба, тим більше, якщо сайт комерційного характеру)
  • DoS-атака (щоб не перевантажити сервер, треба мінімізувати дії, які буде виконувати скрипт в такому випадку)

я довго думав, як можна викликати перевантаження на сервері, якщо механізм захисту стоїть на файлах. Виявилося, нескладно (скільки це буде коштувати - інше питання). Отже, припустимо, сервер не витримає, якщо скрипт буде намагатися 1000 разів в секунду відкривати файли на запис і писати в них дані. Оскільки після 5 невдалих спроб увійти в систему користувач буде відразу отримувати відмову в доступі (без будь-якої записи даних в файл), треба знайти 200 унікальних IP, з яких по п'ять разів і звернутися. Це можливо. Вішаємо в баннерокрутілке html-банер з п'ятьма тегами:

Користувач моментально робить п'ять звернень сервер п'ять разів пише в файл (до речі, в деяких браузерах, можливо, вискочить вікно для введення логіна і пароля). Можна зробити html-сторінку з п'ятьма такими картинками, а саму сторінку вставити через iframe на відвідуваний сайт (через iframe - щоб по полю referer не знайшли. Навряд чи служба підтримки халявного хостингу буде займатися такими речами як копання в лог-файлах в пошуках реферерів) . Ті приклади, які я навів, зрозуміло, натягнуті, але сам факт того, що можна скористатися таким недоліком системи, доведений. До речі, щось подібне вже було.

А ось код програми:

І замість звернення до файлів працюємо з базою.

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

Пароль на сторінку. Частина 3. Пароль від бази

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

На початку програми вказуються хост сервера БД і, якщо треба, ім'я бази:

А для з'єднання з базою беруться змінні сервера: $ PHP_AUTH_USER і $ PHP_AUTH_PW.

І все. Тепер про недоліки. Зрозуміло, з таким захистом можна пробувати підбирати пароль (в принципі, можна приробити блокування, але тоді загубиться вся краса методу). Пароль, як і в разі захистом засобами сервера, пересилається в відкритому вигляді. Але для простих завдань таке цілком згодиться.