Як запевнити користувачів, що веб-сайт та паролі захищені [закрито]

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

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

МОЕ ПИТАННЯ: Чи добре надати повідомлення про те, що "Усі паролі зашифровані та захищені", оскільки я не думаю, що пересічний користувач буде знати, в чому полягає різниця між хешированием і шифруванням, і, швидше за все, почуватиметься захищеним лише тому, що вони бачать слово комфорту "шифрування"? Або є альтернативне повідомлення, яке я повинен надати?

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

1. Користувачам все одно.

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

2. Майже в кожному випадку я бачив такі повідомлення, що вони вводили в оману. Найсмішніший з них був на веб-сайті, на якому на кожній сторінці розміщено ярлики стилю "безпечний військовий клас". Повідомлення надійшло, що сертифікат HTTP недійсний. Існувала ін'єкція SQL у формі для входу. Через кілька тижнів веб-сайт був зламаний, а потім назавжди зник.

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

   Це як ті "W3C дійсні XHTML" мітки. Чому вони зазвичай розміщуються на веб-сайтах, де навіть домашня сторінка містить щонайменше десятки помилок та кодів на кшталт <DIV COLOR='red'>?

Якщо ви все ще хочете заспокоїти користувачів, можете помістити щось на кшталт:

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

Відверто кажучи, форма "Скинути пароль" замінивши "Я забув пароль; надішліть мені електронною поштою" - набагато заспокійливіші за будь-які слова.

Підказки з різних коментарів:

• Не вигадуйте колесо: використовуйте OpenID. Таким чином, ви навіть не зберігаєте хеші.

  Джерело: коментар Яна Худека .

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

  Джерело: коментар Яна Доггена .

Не зберігайте паролі в першу чергу! Дотримуйтесь прикладу Stack Exchange та дозвольте користувачам увійти зі своїм посвідченням на інший сайт, який забезпечує аутентифікацію через OpenID . Реалізація є вільною для більшості загальних веб-рамок.

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

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

Говорячи:

"Це безпечно".

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

Значення: Ця заява загрожує застарілістю, можливо, навіть не усвідомлюючи цього.

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

Це дійсно залежить від контексту вашого конкретного веб-сайту.

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

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

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

Наприклад, для нетехнічних споживачів досить мати загальні, прості коментарі, такі як:

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

(І, як уже говорили інші, вам краще навіть не мати паролів, використовуйте такі стандарти, як OpenId або OAuth.)

Для високотехнологічних підприємств вам потрібно мати повну сторінку технічних та процедурних деталей, таких як:

Ми впровадили повний SDL (безпечний життєвий цикл розробки) протягом нашого процесу розробки та розгортання.
...
Наша архітектура безпеки ... Це дає переваги ...
Ми забезпечуємо безпечне кодування, наприклад ... від ... Ми виконуємо ці та ті тести.
Наша криптографія включає ці алгоритми ... і ... Ми відповідаємо будь-якому регулюванню галузі, яке вам потрібно, і сертифіковано на ...
Нашу безпеку перевіряє цей незалежний сторонній консультант.
...
Щоб отримати детальнішу інформацію та переглянути нашу політику чи влаштувати незалежний аудит, будь ласка, обговоріть із відділом маркетингу.

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

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

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

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

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

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

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

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