Чому ви повинні турбуватися кожного разу, коли базу даних паролів служби просочилися

«Вчора була вкрадена наша база даних про паролі. Але не хвилюйтеся: ваші паролі були зашифровані. ”Ми регулярно бачимо такі заяви в Інтернеті, в тому числі вчора, з Yahoo. Але чи дійсно ми повинні взяти ці гарантії за номінальною вартістю?

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

Як зберігати паролі

Ось як компанії повинні зберігати паролі в ідеальному світі: Ви створюєте обліковий запис і надаєте пароль. Замість того, щоб зберігати сам пароль, служба генерує "хеш" з пароля. Це унікальний відбиток, який не можна скасувати. Наприклад, пароль «пароль» може перетворитися на те, що виглядає більше як «4jfh75to4sud7gh93247g…». Коли ви вводите свій пароль для входу, служба генерує хеш з нього і перевіряє, чи відповідає значення хешу значенню, що зберігається в базі даних. Служба ніколи не зберігає ваш пароль на диску.

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

Щоб запобігти цьому, послуги повинні "солити" хеші. Замість того, щоб створювати хеш з самого пароля, вони додають до фронту або кінця пароля довільний рядок, перш ніж його хешувати. Іншими словами, користувач буде вводити пароль "пароль", а сервіс буде додавати сіль і хеш пароль, який виглядає більше як "password35s2dg". Кожен обліковий запис користувача повинен мати свою власну унікальну сіль, і це гарантує, що кожен обліковий запис користувача буде мати інше значення хеша для свого пароля в базі даних. Навіть якщо кілька облікових записів використовували пароль "password1", вони мали б різні хеши через різні значення солі. Це переможе зловмисника, який намагався попередньо обчислити хеші для паролів. Замість того, щоб генерувати хеші, які застосовуються до кожного облікового запису користувача в цілій базі даних відразу, їм доведеться генерувати унікальні хеши для кожного облікового запису користувача та його унікальної солі. Це займе набагато більше часу обчислень і пам'яті.

Ось чому сервіси часто говорять, що не турбуватися. Служба, яка використовує належні процедури безпеки, повинна сказати, що вони використовують солоні хеши паролів. Якщо вони просто говорять, що паролі «хешировані», це більше хвилює. LinkedIn, наприклад, хешировав свої паролі, але вони не соляли їх, тому це було дуже важливо, коли LinkedIn втратив 6,5 мільйонів хешованих паролів у 2012 році.

Поганий пароль

Це не найважча річ для реалізації, але багатьом веб-сайтам все ще вдається завадити їх різними способами:

• Зберігання паролів у звичайному тексті: Замість того, щоб турбуватися про хешування, деякі з найгірших правопорушників можуть просто скинути паролі у вигляді звичайного тексту в базу даних. Якщо така база даних скомпрометована, ваші паролі, очевидно, скомпрометовані. Неважливо, наскільки вони сильні.
• Хешування паролів без їх посолування: Деякі служби можуть хешувати паролі і відмовитися від них, вирішивши не використовувати солі. Такі бази даних паролів будуть дуже вразливі до таблиць пошуку. Зловмисник може генерувати хеші для багатьох паролів, а потім перевіряти, чи вони існували в базі даних - вони могли б зробити це для кожного облікового запису одночасно, якщо не було використано солі.
• Повторне використання солей: Деякі служби можуть використовувати солі, але вони можуть повторно використовувати ту ж саль для кожного пароля облікового запису користувача. Це безглуздо - якщо для кожного користувача використовувалася одна й та сама сіль, то два користувачі з таким самим паролем матимуть один і той же хеш.
• Використання коротких солей: Якщо використовуються солі лише кількох цифр, можна створити таблиці пошуку, які включають всі можливі солі. Наприклад, якщо в якості солі використовувалася одна цифра, зловмисник може легко створювати списки хешей, які включали всі можливі солі.

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

Інші проблеми

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

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

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

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

Допомога, що мені робити?

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

По-перше, не використовуйте повторно паролі на декількох веб-сайтах. Використовуйте менеджер паролів, який генерує унікальні паролі для кожного веб-сайту. Якщо зловмисникові вдається виявити, що ваш пароль для служби "43 ^ Sd% 7uho2 # 3", і ви використовуєте цей пароль лише на одному конкретному веб-сайті, вони нічого корисного не дізналися. Якщо ви використовуєте один і той же пароль скрізь, вони можуть отримати доступ до інших ваших облікових записів. Саме так багато рахунків людей стають "зламаними".

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

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

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

Зображення: Marc Falardeau на Flickr, Вікісховище