Нещодавно декілька організацій зіткнулися з критикою через зберігання паролів у відкритому, не зашифрованому вигляді. Уявіть собі, що ваш пароль лежить у звичайному текстовому файлі, наприклад, у блокноті з розширенням .txt. Для забезпечення належної безпеки, паролі мають бути зашифровані з використанням “солі” та хешування. Чому ж у 2024 році деякі компанії досі не дотримуються цих елементарних правил?
Небезпека відкритого зберігання паролів
Якщо організація зберігає паролі у відкритому форматі, будь-хто, хто отримає доступ до бази даних або файлу з паролями, може їх прочитати. У випадку успішної хакерської атаки, зловмисники одразу отримають доступ до всіх паролів.
Зберігання паролів у вигляді відкритого тексту є неприпустимою практикою. Замість цього, компанії зобов’язані використовувати процеси підсолювання та хешування. Це означає додавання випадкових даних до пароля та його подальшу обробку за допомогою алгоритмів, які унеможливлюють відновлення початкового значення. Навіть якщо зловмисники отримають доступ до захешованих паролів, вони не зможуть їх використати. Під час вашого входу в систему, компанія порівнює введений вами пароль з його збереженою захешованою версією, але не може відновити ваш оригінальний пароль із бази даних.
Чому ж тоді деякі компанії досі нехтують цими правилами? На жаль, інколи причиною є недбале ставлення до безпеки або ж пріоритет зручності над захистом даних. Іноді, компанії, які в цілому дотримуються правил, можуть створювати надмірні можливості для ведення журналів, які можуть записувати паролі у відкритому вигляді.
Відомі випадки неналежного зберігання паролів
Можливо, ви вже стали жертвою небезпечних практик, адже такі компанії, як Robinhood, Google, Facebook, GitHub, Twitter та інші, в минулому допускали зберігання паролів у вигляді відкритого тексту.
Google, наприклад, використовував належне хешування та соління для більшості користувачів. Однак, паролі облікових записів G Suite Enterprise зберігалися у відкритому форматі. Компанія пояснила це тим, що дана практика застосовувалася для надання адміністраторам доменів інструментів відновлення паролів. За умови належного зберігання паролів це було б неможливо, і єдиним варіантом відновлення пароля був би процес його скидання.
Коли Facebook допустив зберігання паролів у відкритому тексті, точна причина не була одразу названа. Проте, із пізніших оновлень можна зрозуміти, що проблема полягала у наступному:
…ми виявили додаткові журнали паролів Instagram, що зберігаються у форматі, який можна прочитати.
Іноді компанія може правильно зберігати пароль спочатку, але потім, впроваджуючи нові функції, створити вразливості. Крім Facebook, Robinhood, Github, і Twitter випадково створювали журнали, де паролі зберігалися у відкритому вигляді.
Журналування є корисним інструментом для діагностики проблем у програмному забезпеченні, обладнанні та системному коді. Проте, якщо компанія не перевіряє належним чином функцію ведення журналів, це може спричинити більше проблем, ніж вирішити.
У випадку з Facebook та Robinhood, коли користувачі вводили свої логіни та паролі для авторизації, функція реєстрації могла перехоплювати та записувати ці дані у незміненому вигляді. Потім журнали зберігалися в іншому місці. Будь-хто, хто мав доступ до цих журналах, міг отримати доступ до облікових записів.
Трапляються також випадки, коли компанії, такі як T-Mobile Australia, нехтують безпекою даних, можливо, заради зручності. У публічній дискусії в Twitter, представник T-Mobile пояснив, що їх компанія зберігає паролі у відкритому вигляді. Зберігання паролів таким чином дозволяло співробітникам служби підтримки бачити перші чотири символи пароля, що використовувалося для ідентифікації користувача. Інші користувачі Twitter справедливо вказували на те, наскільки небезпечною є така практика.