Як надійно надіслати пароль через HTTP?

Якщо на екрані входу користувач подає форму із своїм ім'ям користувача та паролем, пароль надсилається простим текстом (навіть із POST, виправте мене, якщо я помиляюся).

Отже, питання полягає в тому, що це правильний спосіб захисту користувача та його пароля від третьої сторони, яка може послухати дані зв'язку?

Мені відомо, що HTTPS - це вирішення проблеми, але чи є спосіб забезпечити хоча б якийсь рівень безпеки за допомогою стандартного протоколу HTTP (POST-запит)? (можливо, якось використовують javascript)

EDIT Я, можливо, залишив деякі важливі речі.

Те, про що я хотів, - це сторінка - це сторінка входу, створена PHP, яка, звичайно, надсилається користувачеві в HTTP GET-запиті як HTML-файл. Між сервером та клієнтом не встановлено (@Jeremy Powel) зв'язку, тому я не можу створити такий протокол рукостискання. І я хочу, щоб весь процес був прозорим для користувача - він хоче подати пароль, а не мати справу з криптографією.

Дякую.

Використання HTTP із SSL значно полегшить ваше життя, і ви можете спокійно відпочивати дуже розумними людьми (розумнішими, ніж я!), Роками вивчали цей спосіб конфіденційного спілкування.

Безпечна автентифікація - широка тема. У двох словах, як зазначав @ jeremy-powell, завжди надайте перевагу надсиланню облікових даних через HTTPS замість HTTP. Це забере багато головних болів, пов'язаних із безпекою.

Сертифікати TSL / SSL в наші дні досить дешеві. Насправді, якщо ви зовсім не хочете витрачати гроші, є безкоштовний letsencrypt.org - автоматизований орган сертифікації.

Ви можете піти ще на крок і скористатися caddyserver.com який викликає letsencrypt у фоновому режимі.

Тепер, як тільки ми вивели HTTPS з шляху ...

Ви не повинні надсилати логін та пароль через корисні навантаження POST або параметри GET. Використовуйте натомість Заголовок авторизації (Базова схема автентифікації доступу), який будується наступним чином:

• Ім'я користувача та пароль поєднуються в рядок, розділений двокрапкою, наприклад: ім'я користувача: пароль
• Отримана рядок кодується за допомогою варіанту RFC2045-MIME Base64, за винятком обмежень 76 char / line.
• Спосіб авторизації та пробіл, тобто "Basic", потім ставлять перед кодованим рядком.

джерело: Вікіпедія: Заголовок авторизації

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

Є декілька вагомих причин, щоб використовувати заголовок авторизації

1. Це стандарт
2. Це просто (після того, як ви навчитеся ними користуватися)
3. Це дозволить вам увійти на рівні URL-адреси, як-от так: https://user:password@your.domain.com/login(наприклад, Chrome автоматично перетворить його в Authorizationзаголовок)

ВАЖЛИВО:
Як вказував @zaph у своєму коментарі нижче, надсилання конфіденційної інформації як GET-запит не є гарною ідеєю, оскільки це, швидше за все, опиниться в журналах сервера.

Ви можете використовувати схему відповідей на виклик. Скажіть, що клієнт і сервер знають секрет S. Тоді сервер може бути впевнений, що клієнт знає пароль (не надаючи його):

1. Сервер відправляє клієнту випадкове число, R.
2. Клієнт відправляє H (R, S) назад на сервер (де H - криптографічна хеш-функція, як SHA-256)
3. Сервер обчислює H (R, S) і порівнює його з відповіддю клієнта. Якщо вони відповідають, сервер знає, що клієнт знає пароль.

Редагувати:

Тут виникає проблема зі свіжістю R та тим, що HTTP без громадянства. Це можна вирішити, якщо сервер створив секрет, назвемо його Q, що знає лише сервер . Тоді протокол виходить так:

Зауважимо, оскільки H (R, Q) не може бути підроблений клієнтом, H (R, Q) виконує функції cookie (і тому може бути реалізований фактично як cookie).

Ще одна редакція:

Попереднє редагування протоколу є невірним, оскільки, здається, кожен, хто спостерігав H (R, Q), може здати його на правильний хеш. Сервер повинен пам’ятати, які R вже не свіжі. Я відповідаю на цю відповідь, щоб ви, хлопці, могли відредагувати це питання і розробити щось хороше.

Якщо ваш веб-хостинг дозволяє, або вам доведеться мати справу з конфіденційними даними, тоді використовуйте HTTPS, періодично. (Це часто вимагає закон afaik).

Інакше, якщо ви хочете щось зробити через HTTP. Я б робив щось подібне.

1. Сервер вбудовує свій відкритий ключ на сторінку входу.
2. Клієнт заповнює форму для входу та натискає кнопку.
3. Запит AJAX отримує поточну позначку часу від сервера.
4. Сценарій клієнтської сторони об'єднує облікові дані, часову позначку та сіль (хеширується з аналогових даних, наприклад, рухи миші, події натискання клавіш), шифрує її за допомогою відкритого ключа.
5. Подає отриманий хеш.
6. Сервер розшифровує хеш
7. Перевіряє, чи часова мітка досить недавня (дозволяє лише коротке вікно 5-10 секунд). Відхиляє вхід, якщо позначка часу занадто стара.
8. Зберігає хеш 20 секунд. Відхиляє той самий хеш для входу протягом цього інтервалу.
9. Аутентифікує користувача.

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

Про безпеку маркера сеансу. Це трохи складніше. Але можливо повторно використовувати маркер вкраденого сеансу трохи складніше.

1. Сервер встановлює додатковий cookie сеансу, який містить випадкову рядок.
2. Веб-переглядач повертає цей cookie на наступний запит.
3. Сервер перевіряє значення файлу cookie, якщо воно інше, воно знищує сеанс, інакше все в порядку.
4. Сервер знову встановлює файл cookie з різним текстом.

Отже, якщо маркер сеансу був викрадений, а запит надіслав хтось інший, то при наступному запиті початкового користувача сеанс буде знищений. Тож якщо користувач активно переглядає сайт, часто клацаючи посилання, то злодій не піде далеко з викраденим маркером. Цю схему можна зміцнити, вимагаючи іншої автентифікації для чутливих операцій (наприклад, видалення облікового запису).

EDIT: Зверніть увагу: це не запобігає атакам MITM, якщо зловмисник налаштовує свою власну сторінку з іншим відкритим ключем та проксі-сервісами на сервер. Для захисту від цього відкритий ключ потрібно закріпити в локальній пам’яті браузера або в додатку, щоб виявити подібні хитрощі.

Про реалізацію: RSA, мабуть, є найбільш відомим алгоритмом, але для довгих клавіш він досить повільний. Я не знаю, якою швидкою була б реалізація PHP або Javascript. Але, ймовірно, є більш швидкі алгоритми.

Я б використовував систему обміну ключами Diffie-Hellman на стороні сервера та клієнта з AJAX або декількома формами подання (я рекомендую попередню), хоча я не бачу в Інтернеті жодної хорошої реалізації. Пам’ятайте, що бібліотека JS завжди може бути пошкоджена або змінена MITM. Локальне сховище може використовуватися для боротьби з цим, певною мірою.

Ви можете використовувати SRP для використання захищених паролів через незахищений канал. Перевага полягає в тому, що навіть якщо зловмисник нюхає трафік або компрометує сервер, вони не можуть використовувати паролі на іншому сервері. https://github.com/alax/jsrp - бібліотека javascript, яка підтримує захищені паролі через HTTP у веб-переглядачі або на сервері (через вузол).

HTTPS настільки потужний, оскільки використовує асиметричну криптографію. Цей тип криптографії не тільки дозволяє створити зашифрований тунель, але ви можете перевірити, чи говорите ви з потрібною людиною, а не з хакером.

Ось вихідний код Java, який використовує асиметричний шифр RSA (використовується PGP) для зв'язку: http://www.hushmail.com/services/downloads/

ви можете використовувати ssl для свого хоста, є безкоштовний проект для ssl, як letsencrypt https://letsencrypt.org/

Використання https звучить тут найкращим варіантом (сертифікати зараз не такі дорогі). Однак якщо http - вимога, ви можете скористатися якоюсь підпискою - записати її на стороні сервера та розшифрувати в браузері користувачів (ключ надсилання окремо).

Ми використовували це під час реалізації safevia.net - реєстрація проводиться на сторонах клієнтів (відправника / одержувача), тому дані користувачів не доступні на мережевому та серверному рівні.