Зараз я працюю над постачальником PHP OpenID, який буде працювати через HTTPS (отже, зашифрований SSL).
Чи неправильно мені передавати пароль як звичайний текст? Теоретично HTTPS не може бути перехоплений, тому я не бачу нічого поганого. Або це небезпечно на якомусь рівні, і я не бачу цього?
Відповіді:
Це безпечно. Ось так працює вся мережа. Усі паролі у формах завжди надсилаються у вигляді простого тексту, тому HTTPS має захистити його.
Вам все одно потрібно переконатися, що ви надсилаєте його через запит POST, а не GET. Якщо ви надішлете його через запит GET, він може бути збережений у відкритому тексті в журналах історії браузера користувача або журналах доступу веб-сервера.
Якщо HTTP вимкнено, а ви використовуєте лише HTTPS, тоді ви насправді не передаєте пароль як звичайний текст.
Хеш на стороні клієнта. Чому? Дозвольте розповісти вам про невеликий експеримент. Підійдіть до комп’ютера в їдальні компанії. Відкрийте браузер на сторінці входу на веб-сайт компанії (https). Натисніть клавішу F12, клацніть вкладку мережі, поставте галочку біля журналу збереження, згорніть консоль, але залиште веб-сторінку відкритою для входу в систему. Сідайте і їжте обід. Подивіться, як працівник після того, як працівник входить на веб-сайт компанії, і як хороший маленький працівник виходить із системи, коли це робить. Закінчіть обід, сядьте за комп’ютер, відкрийте вкладку мережі та перегляньте кожне ім’я користувача та пароль у вигляді простого тексту у формі тіла.
Ніяких спеціальних інструментів, ніяких спеціальних знань, жодного вишуканого обладнання для злому, ніяких кейлогерів просто старий добрий F12.
Але привіт, продовжуйте думати, все, що вам потрібно - це SSL. Погані хлопці будуть вас за це любити.
Давайте зробимо кілька приміток до попередніх відповідей.
По-перше, це, мабуть, не найкраща ідея використовувати хеш-алгоритми на стороні клієнта. Якщо ваш пароль посолений на стороні сервера, ви не зможете порівнювати хеші (принаймні ні, якщо ви не зберігаєте хеш-пам'ять клієнта в базі даних в одному з шарів хешування від пароля, який є однаковим або гірше). І ви не хочете реалізовувати алгоритм хешування, який використовується базою даних на стороні клієнта, це було б безглуздо.
По-друге, торгівля криптографічними ключами теж не є ідеальною. Теоретично MITM може (враховуючи, що на клієнті встановлений кореневий сертифікат) змінити криптографічні ключі та змінити за допомогою власних ключів:
Оригінальне з'єднання (не враховуючи tls) з теоретичного сервера, який обмінюється ключами:
Запит клієнта відкриті ключі> сервер містить приватні ключі, генерує відкриті ключі клієнту> сервер надсилає відкриті ключі клієнту
Тепер, у теоретичному нападі на MITM:
Запит клієнта на відкриті ключі> MITM генерує підроблені приватні ключі > Сервер утримує приватні ключі, генерує відкриті ключі для клієнта> MITM отримує відкриті ключі від оригінального сервера, тепер ми можемо відправити наші підроблені відкриті ключі клієнту, і кожного разу, коли запит надходить від клієнта, ми будемо розшифровувати дані клієнта за допомогою підроблених ключів, змінювати корисне навантаження (або читати його) та шифрувати оригінальними відкритими ключами > MITM надсилає підроблені відкриті ключі клієнту.
У цьому полягає сенс довіри сертифіката ЦС у TLS, і саме так ви отримуєте повідомлення від попередження браузера, якщо сертифікат недійсний.
У відповідь на ОП: на мою скромну думку, ви не можете цього зробити, тому що рано чи пізно хтось захоче напасти на користувача із вашої служби і спробує порушити ваш протокол.
Однак ви можете застосувати 2FA, щоб люди не намагалися ввійти з тим самим паролем. Однак пам’ятайте про повторні атаки.
Я не чудовий з криптографією, будь ласка, виправте мене, якщо я помиляюся.
Інші плакати правильні. Тепер, коли ви використовуєте SSL для шифрування передачі пароля, переконайтеся, що ви хешуєте його з хорошим алгоритмом і соллю, щоб він також був захищений, коли він у спокої ...
Приклад @CodeDog має проблеми ..
Так, я можу повірити, що користувачі увійдуть у вікно з кафе. Якщо ви захоплюєте журнали з корпоративної кафетерії, то ви є порушенням безпеки. Корпоративні ящики для кафе можна відключити, наприклад, відсутність термінів, відсутність реєстраторів, відсутність віддаленого доступу тощо. Щоб запобігти вам, внутрішній хакер.
Прикладом є хороший приклад захисту комп'ютерного доступу, який насправді не пов'язаний з безпекою мережі. Це надається як виправдання хешування на стороні клієнта, але якщо у вас є доступ до комп’ютера, ви можете просто використовувати реєстратор натискань клавіш і обійти це. Хеш клієнтської сторони знову не має значення. Приклад @CodeDog - це злом доступу до комп’ютера, який вимагає прийомів, відмінних від злому мережевого рівня.
Крім того, загальнодоступний комп’ютерний захист захищений шляхом каліцтва системи від загроз, як уже згадувалося вище. наприклад, використовувати хромбук для загальнодоступного комп’ютера з кафе. Але це обходить фізичний злом. У неробочий час заходьте до кафетерії та налаштовуйте секретну камеру для запису натискань клавіатури користувачами. Тоді не має значення, якщо комп'ютер з кафетерією скалічений, АБО який тип шифрування використовується.
фізичний рівень -> рівень комп'ютера -> рівень клієнта -> рівень мережі -> рівень сервера
Для мереж не має значення, якщо у вас хеш на стороні клієнта, оскільки рівень https / ssl буде шифрувати звичайний пароль. Отож, як зазначають інші, хешування клієнта надлишкове, якщо TLS захищений.