Чи повинен я хеш-пароль, перш ніж надсилати його на сторону сервера?

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

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

ОП ніколи не згадувало надсилання пароля через HTTP - лише HTTPS, але багато хто, здається, чомусь відповідають на питання про надіслати пароль через HTTP. Це сказав:

Я вважаю, що паролі ніколи не повинні зберігатися (не кажучи вже про передані) у простому тексті. Це означає, що не зберігається на диску або навіть у пам'яті.

Люди, які відповідають тут, здаються, що HTTPS - це срібна куля, чого це не так. Однак це, безумовно, допомагає, і його слід використовувати в будь-якому аутентифікованому сеансі.

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

Отже, у нас є ключ. Тепер нам потрібно очистити будь-який слід пароля на пристрої клієнтів.

Далі нам потрібно отримати ключ до вашої системи. Ніколи не слід передавати ключ або пароль "на чистоту". Навіть не над HTTPS. HTTPS не є непроникним. Насправді, багато організацій можуть стати довіреною MITM - не з точки зору атаки, а для того, щоб проводити перевірки трафіку для реалізації власної політики безпеки. Це послаблює HTTPS, і це не єдиний спосіб, як це відбувається (наприклад, перенаправлення на HTTP MITM-атаки, наприклад). Ніколи не вважайте, що це безпечно.

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

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

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

TL; DR:

Використовуйте HTTPS. Безпечно паролі хешу, безповоротно, з унікальною сіллю на пароль. Зробіть це на клієнті - не передайте їх фактичний пароль. Передача користувача оригінальним паролем на ваші сервери ніколи не буває «ОК» або «Добре». Очистіть будь-який слід від оригінального пароля. Використовуйте нонсенс незалежно від HTTP / HTTPS. Це набагато безпечніше на багатьох рівнях. (Відповідь на ОП).

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

Ні, насправді це було б вразливістю. Якщо зловмисник може отримати хеш із бази даних, він може використовувати його для аутентифікації, не потребуючи зламу. Користувач або зловмисник ні в якому разі не може отримувати хеш-пароль.

Вся суть у хешировании паролів полягає у додаванні додаткового рівня безпеки. Якщо зловмисник має змогу отримати хеш-сіль із бази даних за допомогою SQL Injection або небезпечної резервної копії, він повинен знайти звичайний текст шляхом грубої змушування. Джон The Ripper зазвичай використовується для злому солоних хешей паролів.

Не використання https - це порушення OWASP Top 10: Недостатній захист транспортного шару A9

EDIT: Якщо у своїй реалізації ви обчислюєте a, sha256(client_salt+plain_text_password)а потім обчислюєте інший хеш на стороні сервера, sha256(server_salt+client_hash)це не є серйозною вразливістю. Однак він все ще піддається підслуховуванню та відтворенню запиту. Таким чином, це все ще є явним порушенням WASP A9. Однак це все ще використовує дайджест повідомлень як рівень захисту.

Найближче, що я бачив із заміною клієнта на https, - це непростий пекламен в обміні ключами в JavaScript . Однак це запобігає активним атакам MITM і, таким чином, поки технічно не є порушенням OWASP A9. Автори коду погоджуються, що це не повна заміна HTTPS, проте це краще, ніж нічого, і краще, ніж система хешування на стороні клієнта.

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

Пароль в простому тексті не показується ніколи (навіть при використанні HTTPS) не залишає клієнта. Перед тим, як вийти з клієнта, його слід безповоротно зафіксувати, оскільки сервер не повинен знати фактичний пароль.

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

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

Мій підхід до проблеми в веб-додатку на основі сокетів, який я створюю, полягає в тому, що при підключенні до клієнта сервер генерує сіль (довільна рядок, яку потрібно додати до хешування), і зберігає її в змінній sockets, а потім передає цей хеш до клієнта. Клієнт приймає пароль користувачів, хеширує його, додає сіль із сервера і перемиває все, перш ніж передавати його на сервер. Потім він надсилається на сервер, який порівнює цей хеш з хешем (хеш у БД + сіль). Наскільки я знаю, це хороший підхід, але, щоб бути справедливим, я не дуже багато читав на цю тему, і якщо я не в чомусь помиляюся, я хотів би виправитись :)

Використовуйте HTTP Дайджест - він захищає пароль навіть через http (але найкращим використанням буде http digest через https)

Вікіпедія:

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

Посилання: http://en.wikipedia.org/wiki/Digest_access_authentication

Якщо ви хочете побачити використання в реальному житті, ви можете подивитися на phpMyID - постачальник відкритих програм PHP, який використовує автентифікацію дайджеста http http://siege.org/phpmyid.php

.. або ви можете почати з зразків авторизації php на веб-сторінці http://php.net/manual/en/features.http-auth.php

Http дайджест rfc: http://www.faqs.org/rfcs/rfc2617

З моїх тестів це підтримують усі сучасні браузери ...

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

Однак основна обфускування пароля на стороні клієнта (не хеш), що надсилається через HTTPS, має деяке значення. Якщо я не помиляюся, ця методика фактично використовується деякими банками. Мета цієї методики - не захищати пароль від обнюхування дроту. Швидше, це не дозволяє паролю використовуватись для німих шпигунських інструментів та плагінів браузера, які просто захоплюють кожен запит HTTPS GET / POST, який вони бачать. Я бачив файл журналу, зібраний із шкідливого веб-сайту, на якому розміщено 400 МБ випадкових транзакцій GET / POST, захоплених сеансами користувача. Ви можете собі уявити, що веб-сайти, які використовують лише HTTPS, відображатимуться з паролями з чітким текстом у журналі, але веб-сайти з дуже базовою обфузацією (ROT13) також відображатимуться із паролями, які не одразу використовуються.

Якщо ви підключені до https-сервера, потік даних між сервером та браузером повинен бути зашифрований. Дані - це лише звичайний текст перед відправленням та після отримання. Стаття у Вікіпедії

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

Зробіть і те, і інше

Зробіть те й інше, тому що:

1. Захоплення на дорозі допомагає покрити вразливості транспорту, якщо з’єднання SSL порушено, вони все ще не можуть побачити необроблений пароль. Це не має значення з точки зору можливості представити себе уповноваженими користувачами, але це захистить ваших користувачів від того, щоб вони читали їхні паролі разом із електронною поштою. Більшість людей не дотримуються найкращих практик і використовують один і той же пароль для багатьох своїх облікових записів, тому це може стати серйозною вразливістю для ваших відвідувачів.

2. Якщо хтось якимось чином зміг прочитати паролі з бази даних (це трапляється, думаю, введення SQL), він все одно не зможе виконати привілейовані дії, що представляють себе користувачами через мій API. Це через хеш-асиметрію; навіть якщо вони знають хеш, збережений у вашій БД, вони не знають оригінальний ключ, який використовується для його створення, і саме це ваша аутентична програма використовує для автентифікації. Це також, чому ви завжди повинні посолити своє хеш-сховище.

Зрозуміло, вони могли б заподіяти чимало іншого шкоди, якби мали змогу прочитати, що хочуть, з вашої бази даних.

Я просто хочу наголосити на тому, що якщо ви вирішите заштрихувати ключ перед від'їздом від своїх клієнтів, цього недостатньо - хекшер хеш-пам'яті є, набагато важливішим, і ось чому: Якщо хтось перехоплює трафік від вашого клієнт, тоді вони побачать вміст passwordполя. Це хеш чи звичайний текст, не має значення - вони можуть копіювати його дослівно, щоб представити себе авторизованим клієнтом. (Якщо ви не дотримуєтесь кроків, які @ user3299591 намічає, і я рекомендую вам виконати). З іншого боку, хеш-колонка БД є необхідністю і зовсім не складною для реалізації.

Чи SSL / TLS не замінює поняття? Я не бачу додаткової цінності цього, оскільки SSL / TLS також захищає від Replay Attacks.

Реф. https://en.wikipedia.org/wiki/Cryptographic_nonce

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

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

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

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

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

Якщо зловмисник отримав доступ до бази даних, можливо, через копію резервної копії, тоді ви хочете переконатися, що хтось не міг увійти, використовуючи лише ці знання. Якщо, наприклад, ви зберегли хеш-солон з іменем входу як hash(login_name+password)і ви передали цей самий хеш від клієнта для прямого порівняння, то зловмисник може обрати користувача навмання, надіслати хеш-прочитання з бази даних та увійти як цей користувач, не знаючи пароля, збільшує обсяг порушення. У такому випадку відправлення пароля в простому тексті було б більш безпечним, оскільки зловмисникові потрібно було б знати простий текст, щоб увійти, навіть маючи копію бази даних. Саме тут ключова реалізація. Незалежно від того, ви надсилаєте пароль простого тексту або хеш на цьому клієнті, ви повинні хеш цього значення на стороні сервера і порівняти цей хеш із хешем, збереженим у записі користувача.

Поняття, які слід пам’ятати:

• Ви "соліть" хеш, змішуючи в якомусь унікальному обсязі значення до вашого хешу, як правило, унікального для рядків. Його мета - гарантувати унікальність хешів один від одного, навіть якщо значення прямого тексту, які вони представляють, однакові, тож два користувачі з одним паролем все одно матимуть різні хеші. Не варто ставитися до солі як до секрету.
• Під час автентифікації завжди хешуйте на стороні сервера будь-яке значення, яке ви передаєте від клієнта як пароль (навіть якщо воно вже хешоване) і порівнюйте його з попередньо хешованим значенням, збереженим у базі даних. Це може зажадати збереження подвійної хешированной версії оригінального пароля.
• Коли ви робите хеш, розгляньте, як додати хеш-сервер / унікальну кластерну сіль, а також унікальну для рядків сіль для захисту від узгодження будь-яких попередньо обчислених хешів у таблицях пошуку.