Хеширование против шифрования: как ваш пароль хранится на сервере

Предположим, вы создали аккаунт на VerySecureWebsite.com. Вы вводите свой адрес электронной почты и пароль и создаете свой аккаунт. Ненадолго позже вы получаете электронное письмо с сообщением о том, что иронично, веб-сайт был взломан, и имена пользователей и пароли каждого пользователя, которые хранились в открытом виде, теперь продаются в даркнете. Пока вы начинаете менять пароли на всех своих аккаунтах (вы используете только один, вы чудовище), вы задаетесь вопросом: “ Разве это не плохая идея? Не должен ли мой пароль быть в каком-то секретном коде, чтобы хакеры не могли просто его прочитать? “

Вы правы. Любое веб-приложение или сервис, который использует систему входа с именем пользователя и паролем, должен хранить пароли своих пользователей с использованием соли и хеширования, возможно, даже с использованием медленного хеширования с добавлением перца. Если это начинает звучать скорее как завтрак, чем криптография, не волнуйтесь: в отличие от вашего пароля (надеюсь), безопасное хранение паролей не является слишком сложной темой для понимания.

Также читайте: Почему ограничения на пароли на сайте не защищают вас

Открытый текст и базовое шифрование

Хранение паролей в открытом виде в базе данных, подключенной к Интернету, — это довольно плохая идея: если база данных будет взломана, любой, кто использовал один из этих паролей, теперь находится под угрозой. Тем не менее, тревожное количество веб-сайтов все еще делает это, вероятно, потому что обновления безопасности больше рассчитаны на клиента, чем на компанию. Если вы хотите проверить, делает ли сайт это, попробуйте выбрать опцию “забыли пароль”. Если они просто отправляют вам ваш пароль вместо ссылки на сброс, значит, он хранится в открытом виде.

Шифрование может показаться надежным способом хранения паролей, но на самом деле это всего лишь шаг вперед от открытого текста. Зашифрованный пароль обычно можно расшифровать с помощью ключа, и если хакеры смогут его найти или угадать, шифрование станет бесполезным.

Хеширование > шифрование

| UnwittingUser | WeakPassword | WeakPassword | 252E2406732308F9A7
B378ED94E78467D14
077D19C8282443FCD
3D6190FCABFA |

Хеш-функция — это, по сути, одностороннее шифрование: вы преобразуете открытый текст пароля в секретный код, но нет ключа для его обратного преобразования, что означает, что вы никогда не сможете восстановить фактический пароль из хешированной версии.

Таким образом, большинство безопасных веб-сайтов управляют своими паролями:

1. Пользователь создает аккаунт
2. Пароль пользователя проходит через хеш-функцию и хранится в базе данных
3. Каждый раз, когда пользователь входит в систему, база данных хеширует введенный пароль и проверяет, совпадает ли введенный хеш с хешем, который у них на хранении.
4. Если да, пользователь может войти в систему

С помощью хеша приложение/сайт никогда не хранит ваш фактический пароль нигде, и хакер, который проникнет в систему, получит только список букв и цифр, которые невозможно расшифровать. В зависимости от силы алгоритма, эти хеши могут быть довольно сложны для взлома.

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

Чтобы сэкономить время и вычислительную мощность, многие нападающие используют таблицы для поиска (или “радуга-таблицы”, экономящую место версию таблиц для поиска), предварительно сгенерированные таблицы, полные потенциальных паролей и их хешей. Вы можете на самом деле попробовать хешировать слово в открытом виде и затем самостоятельно использовать таблицу для поиска на хеше; это не слишком сложно. По сути, если ваш пароль вообще распространен, хеш этого пароля, вероятно, уже находится в таблице для поиска. Это отличная причина не использовать распространенные пароли.

Также читайте: Создайте надежный пароль, используя эти советы и инструменты

Хеши с солью > хеши

| Имя пользователя | Введенный пароль | Строка для хеширования | Хешировано с помощью SHA-256,
соль = XcyKn42, добавлена в начало | | — | — | — | — | | UnwittingUser | WeakPassword | XcyKn42WeakPassword | 13EB660FF7FBD29A728FC5
92297D78DF19AFF8797363
15FBF1F1C4B7123BD10C |

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

Конечно, хешированные с солью пароли также могут быть взломаны. Хакеры могут просто добавить соль к паролю, который они пытаются угадать, хешировать комбинацию и ждать совпадений — стандартная атака по словарю. Поскольку современные графические процессоры могут делать миллиарды попыток в секунду, это вовсе не невозможно, но этот процесс становится значительно более неприятным. В противном случае атаки полного перебора медленны, но очень эффективны.

Укрепление хешей: другие тактики

| Имя пользователя | Введенный пароль | Строка для хеширования | Хешировано с помощью Bcrypt,
соль = XcyKn42, добавлена в начало,
12 раундов | | — | — | — | — | | UnwittingUser | WeakPassword | XcyKn42WeakPassword | $2y$12$6OleutQBO2iPoNvg
pyDndOU26Lqt9Y34f6PLEOx
mCELP5GoswrJT. |

Медленные алгоритмы хеширования, такие как PBKDF2 или bcrypt, используют технику, известную как “растяжение ключа”, чтобы замедлить атаки по словарю и полного перебора. Это, по сути, включает в себя установку хеш-функции на выполнение определенного количества итераций (хотя это немного сложнее, чем просто повторять одно и то же снова и снова), так что для достижения правильного хеша вам нужно использовать много вычислительной мощности. Если сайт делает все это, их безопасность довольно хороша.

| Имя пользователя | Введенный пароль | Строка для хеширования | Хешировано с помощью Bcrypt,
соль = XcyKn42, добавлена в начало,
12 раундов,
перец = |4|\/|@p3pp3r, добавлен в конце | | — | — | — | — | | UnwittingUser | WeakPassword | XcyKn42WeakPassword|4|\/|@p3pp3r | $2y$12$njmWr5UMydCzdCE44ElW/
OIfYp2PH9sgonCATyVY.OVKSpmoSaZlu |

Для дополнительной безопасности вы также можете “добавить перец” к своим хешам — которые, надеюсь, уже имеют соль. Перец, подобно соли, представляет собой набор значений, прикрепленных к паролю перед его хешированием. В отличие от соли, однако, существует лишь одно значение перца, и оно остается секретным, отдельно от солей и хешей. Это добавляет еще один уровень безопасности к хешу с солью, но если нападающему удастся его найти, он больше не будет очень полезным, поскольку нападающий может просто использовать его для вычисления новых таблиц поиска.

Не делайте кашу из вашего хеша

Безопасность паролей сделала большие шаги вперед — и так же искусство взлома этой безопасности. К сожалению, люди по-прежнему плохо управляют паролями, а базы данных не обновляют безопасность так часто, как должны. В общем, предполагайте, что всякий раз, когда вы создаете аккаунт, пароль хранится с относительно слабой безопасностью. Если ваш пароль распространен или представляет собой слово из словаря, то он находится под довольно высоким риском взлома. Давайте делать ваши пароли длинными, смешивая буквы, цифры и символы, и вы будете помогать хеш-функциям делать свою работу наилучшим образом.