🪿 Что отличает обычного аналитика от прожжённого? Второго дружно прожарила кибербеза, юристы и сопроводы, и теперь он знает, как быть с персухой. Если же вам не хочется прыгать через костёр на ПСИ, то предлагаю заранее задуматься об обработке разного рода чувствительных данных. И в этом нам поможет герой моей сегодняшней рецензии в рамках конкурса "Продолжи мысль" от @systems_education, Артём Лещев с заметкой "Что такое хэширование пароля?"
🦧 Я сам устал видеть LLM-суммаризации и нейрообзоры, поэтому напишу обзор как человек, со своими человеческими недостатками.
🐙 Пост важен уже самим своим существованием. Если видите "особенные" данные (не только пароли, на которых фокус в публикации) — задумайтесь о виде, в котором они будут как храниться, так и передаваться.
Пароли пользователей хранятся в базе данных не в открытом виде. Их принято хэшировать. Так, злоумышленник, получив доступ к БД, все равно не узнает точную комбинацию символов которую вводит пользователь.
Здесь дополню, что уязвима к атаке злобного гуся у нас не только база, но и:
• Кэш — как серверный, так и клиентский c cookie. В идеале хранить только токены сессии, а не пароли.
• Логи — разраб автоматом логгирует тело запросов в plain text — и привет утечка
• Config файлы — киньте камень, кто ничего не хардкодил в
.env на тесте и сразу вписывал ${USR_PSW}Шифрование и хэширование — разные методы защиты информации. Первый подразумевает наличие ключа, которым можно расшифровать данные. Второй — необратимый процесс, потому что алгоритма дехэширования нет. Символы пароля и хэша не маппятся друг с другом один-в-один. Чтобы "дехэшировать" нужно банально подобрать хэш, но число вариантов для перебора будет огромно. Так называемые "радужные таблицы" позволяют его подбирать более оптимальным способом
Здесь соглашусь и дам задачку Жака Фреско, на размышление даётся 5 LLM-токенов: какие данные (объединённые каким общим смыслом) легко перебираются радужной таблицей прямо в Excel на моём компе? Так, что я беру 10 популярных хэш функций, растягиваю уголок и получаю инфу о том, что за хэш попал мне в руки.
🦎 Ответ: любые сильно типизированные данные, например, номера телефона. Берём 0 000 000 00 00 и растягиваем до 9 999 999 99 99.
Далее в соседних колонках растягиваем хэш-функции и получаем хэши от каждого НТ. Теперь делаем поиск по перехваченным хэшам и смотрим, с кем они совпали в таблице. PROFIT. И как же быть?
Чтобы обеспечить дополнительную защиту, хэш-функции усложняют пароль, добавляя так называемую "соль" (salt), т.е. сторонние символы.
Т.е. докидываем к любому исходному тексту тарабарщину в ~16 байт криптографически случайной строки и затем хэшируем. Храним саму соль на сервере в открытом виде. Для одинаковых паролей разных гусей: goose_1: PWNAO, goose_2: PWNAO уникальная per-user соль помогает получить разные хэши.
🦂 Здесь помните: солить на клиенте — небезопасно, и в таком случае нужен уже аналог секретного ключа в шифровании, который зовётся, не поверите, перчиком (pepper). Это тайный общий ингредиент, который хранится отдельно от базы.
🦄 Далее автор показывает примеры отработки хэш-функций и как всё это можно воспроизвести в домашних условиях, не спрашивая разрешения родителей, что здорово: один раз практики всегда лучше ста статей.
🪼 Подводя итог, спасибо Артёму за поднятие этой узкой, но очень важной в работе аналитика темы. Надеюсь, с моим комментариями она стала чуть яснее.
#продолжи_мысль_SE | Analyst Boost