Сьогодні все ще більшість сайтів працює по протоколу http, а не https. Це гірше в плані безпеки, але дешевше і простіше в підтримці. Безпека аутентифікації на таких сайтах - проблема, так як найчастіше вона реалізується простий відправкою форми c логіном / паролем на сервер, де хеш пароля звіряється c хешем, який відповідає зазначеному логіну. Входячи на такий сайт у відкритій Wi-Fi мережі або іншому публічному місці будь-хто вміє користуватися google зможе без особливих зусиль перехопити ваш пароль. Деякі йдуть трохи далі, відправляючи на сервер хеш пароля, але і це не на багато краще так як маючи райдужну таблицю (особливо для md5) можна спробувати знайти пароль, маючи не нульовий на успіх, і кожен день ймовірність успіху зростає.
У цій статті я пропоную альтернативний, більш складний спосіб аутентифікації, при якому пароль ні в чистому вигляді, ні в вигляді хеша не світиться, а заодно такий підхід практично виключить необхідність в додаванні captcha до форми входу.
Все описане вже використовується на практиці, тому приклади будуть реальні, і враховують контекст їх використання.
Аутентифікація буде проходити в два етапи c використанням AJAX.
Випадковий хеш генерується на сервері. PHP приклад:
Випадковий хеш запам'ятовується на сервері, і зв'язується c логіном.
Як можна побачити, для пароля використовується sha512 хеш. public_key - це глобальна змінна, яка містить рядок довжиною в 56 знаків, і використовується як сіль. Ця змінна є відкритою, але завдяки тому, що використовується відносно складний алгоритм отримання хеша sha512 (двічі) - генерація райдужних таблиць для кожного окремого сайту буде досить складною, дорогою і тривалою процедурою, щоб це мало великий сенс.
Маючи хеш логіна, ми можемо знайти на сервері відповідний пароль, випадковий хеш, згенерувати відповідний auth_hash і порівняти c тим, який був отриманий від користувача. У разі збігу заводимо сесію, і оновлюємо сторінку користувача. Реалізація обробки помилок залишається на ваше міркування.
Що тоді c реєстрацією
Дуже просто, генерувати пароль за користувача, і відправляти на пошту. Будь-який поважаючий себе і користувача поштовий сервіс підтримує доступ до пошти по шифрованому каналу. Користувач при бажанні зможе змінити пароль.
Зміна пароля / відновлення
Відновлення пароля в даній схемі теж виробляється на поштову скриньку.
Зміну пароля можна реалізувати наступним чином:
- зі старого і нового паролів генеруємо хеші як в прикладі вище:
Додаткові заходи безпеки
Додатково рекомендую додавати в запит id поточної сесії користувача, і при його відсутності або не збігом c поточної сесією обнуляти дані POST запиту.
На цьому все
Код можете вільно використовувати в своїх цілях, змінювати типи і розміри хеш для ускладнення або прискорення процедури.
Буду радий зауважень / побажанням, спасибі що дочитали до цього місця.