Slack зізнається у витоку хешованих паролів протягом трьох місяців

Популярний інструмент для спільної роботи Slack (не плутати з псевдонімом найстарішого у світі дистрибутива Linux, Slackware) щойно отримав SNAFU з кібербезпеки.

Згідно з випуском новин під назвою Повідомлення про скидання пароля Slack, компанія визнала, що ненавмисно надавала особисті дані «коли користувачі створили або відкликали спільне посилання для запрошення для своєї робочої області».

З 2022 по 04 (ми припускаємо, що обидві дати включно) Slack сказав, що дані, надіслані одержувачам таких запрошень, включали…

…зачекайте…

... хешований пароль відправника.

Що пішло не так?

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

Ми припускаємо, що це перекладається так:

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

Це хороша новина.

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

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

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

Це погана новина.

Сіль, хаш і стрейч...

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

Хеші — це, по суті, «необоротні» математичні функції, які легко обчислити в одному напрямку, але не в іншому.

Наприклад, легко підрахувати, що:

  SHA256("DUCK") = 7FB376..DEAD4B3AF008

Але єдиний спосіб працювати «задом наперед». 7FB376..DEAD4B3AF008 до DUCK це працювати вперед з усіх можливих слів у словнику та подивіться, чи знайде якесь із них значення, яке ви намагаєтеся знайти:

  SHA256("AARDVARK") = 5A9394..467731D0526A [X] SHA256("AARON") = C4DDDE..12E4CFE7B4FD [X] SHA256("ABACUS") = BEDDD8..1FE4DE25AAD7 [X] . . . 3400 пропущено SHA256("BABBLE") = 70E837..CEAD4B1FA777 [X] SHA256("BADGER") = 946D0D..7B3073C1C094 [X] SHA256("BAGPIPE") = 359DBE..BE193FCCB111 [X] . . . 3200 пропущених SHA256("CABAL") = D78CF4..85BE02967565 [X] SHA256("CACHE") = C118F9..22F3269E7B32 [X] SHA256("CAGOULE") = 5EA530..5A26C5B56DCF [X] . . . 5400 пропущено SHA256("DAB") = BBCC8E..E8B98CAB5128 [X] SHA256("DAFFODIL") = 75121D..D6401AB24A98 [X] SHA256("НЕБЕЗПЕКА") = 0BD727..4C86037BB065 [X] . . . 3500 пропущено SHA256("КАЧКА") =  7FB376..DEAD4B3AF008 [ЗНАЙДЕНО!]

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

Ви можете побачити ефект засолювання тут, коли ми перемішуємо слово DUCK з трьома різними префіксами:

  SHA256("RANDOM1-DUCK") = E355DB..349E669BB9A2 SHA256("RANDOM2-DUCK") = 13D538..FEA0DC6DBB5C <-- Зміна лише одного вхідного байта створює зовсім інший хеш SHA256("ARXXQ3H-DUCK") = 52AD92. .544208A19449

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

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

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

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

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

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

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

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

A словникова атака означає, що ви пробуєте лише ймовірні паролі, наприклад кожне слово, яке ви можете придумати aardvark до zymurgy, а потім здаючись. А груба атака означає спробувати всі можливі введення, навіть дивні та невимовні, з AAA..AAAA до ZZZ..ZZZZ (або від 0000..000000 до FFFF..FFFFFF якщо ви думаєте в шістнадцятковій формі байт за байтом).

Що ж робити?

Слак каже, що приблизно 1 з 200 його користувачів (0.5%, ймовірно, на основі записів про те, скільки спільних посилань із запрошенням було згенеровано в небезпечний період), і що це змусить цих користувачів скинути свої паролі.

Ще кілька порад:

• Якщо ви користуєтеся Slack, ви можете скинути свій пароль, навіть якщо компанія не сповістила вас про це. Коли компанія визнає, що недбало поводилася зі своєю базою паролів через витік хешів, ви також можете припустити, що це вплинуло на вашу, навіть якщо компанія вважає, що це не так. Як тільки ви змінюєте свій пароль, ви робите старий хеш марним для зловмисників.
• Якщо ви не використовуєте менеджер паролів, подумайте про те, щоб отримати його. Менеджер паролів допомагає вибрати правильні паролі, таким чином гарантуючи, що ваш пароль опиниться дуже, дуже далеко в списку паролів, які можуть бути зламані в такому випадку. Зазвичай зловмисники не можуть здійснити справжню атаку грубою силою, оскільки існує забагато можливих паролів, які можна спробувати. Таким чином, вони спочатку пробують найімовірніші паролі, такі як слова або очевидні комбінації слів і цифр, стаючи довшими та складнішими в міру продовження атаки. Менеджер паролів може запам’ятати випадковий пароль із 20 символів так само легко, як ви запам’ятаєте ім’я свого кота.
• Увімкніть 2FA, якщо можете. 2FA, або двухфакторная аутентифікація, означає, що вам потрібен не лише пароль для входу, а й одноразовий код, який щоразу змінюється. Ці коди зазвичай надсилаються на ваш мобільний телефон (або генеруються ним) і дійсні лише кілька хвилин кожен. Це означає, що навіть якщо кібершахраї зламають ваш пароль, цього недостатньо для того, щоб заволодіти вашим обліковим записом.
• Обирайте надійний алгоритм хешування та розтягування, коли самостійно обробляєте паролі.. У випадку, якщо ваша база даних паролів буде зламана, ви зможете надати своїм клієнтам точні відомості про алгоритм і налаштування безпеки, які ви використовували. Це допоможе добре обізнаним користувачам самостійно оцінити, наскільки ймовірно, що їхні викрадені хеші могли бути зламані за час, доступний зловмисникам.

---