#security #hash #salt
#Безопасность #хэш #соль
Вопрос:
Соль используется при хранении паролей в базах данных для защиты от атак по словарю и радужных таблиц.
Однако давайте предположим, что нам нужно хранить уникальную и случайную (конфиденциальную) информацию о пользователях. Есть ли еще преимущество в обработке этой информации перед ее хэшированием ?
Разве использование salt в этом случае не просто добавило бы случайности к уже случайным данным (в отличие от паролей, набранных человеком)?
Комментарии:
1. что вы подразумеваете под уникальным и случайным? Соль помещена просто для предотвращения расшифровки. Вот и все. Если вы должны защитить эту уникальную и случайную информацию, используйте salt. Если вы этого не сделаете, оставьте это как есть.
2. Не могли бы вы уточнить
unique and random?3. Хэш @Kianii не шифрует, они хэшируют. Что такое атака по словарю и rainbow на самом деле пытается найти предварительное изображение или вторичное изображение хэш-функции, которые трудно инвертировать.
4. @kelalaka Как насчет детерминированного шифрования?
5. случайный: шаблон не может быть идентифицирован, уникальный: для каждого r1 в базе данных не существует r2 такого, что r1 = r2
Ответ №1:
Это зависит от того, насколько конфиденциальна ваша информация и каковы последствия, когда эти данные подвергаются риску. Является ли это информацией PII, такой как SSN или DOB?
Вы упомянули, что ваши данные являются случайными и уникальными. Что означает, что трудно идентифицировать шаблон. Если шаблон достаточно случайный, то соление ваших данных может не потребоваться. если вы выберете соление, то на вас также ляжет дополнительная ответственность за защиту этих солей.
Я бы рекомендовал использовать учетную запись с низкими привилегиями, усиление защиты сервера, аутентификацию, авторизацию для защиты ваших данных и минимизации поверхности атаки.
Опять же, вы должны прийти к выводу после классификации ваших данных на основе принципов CIA.
Комментарии:
1. Если размер случайных и уникальных данных невелик, их легко найти. Майнеры биткойнов достигли хэша ~ 2 ^ 90 в год.
2. Согласен с вашим комментарием, это был мой общий ответ, не зная специфики данных из сообщения. На основе классификации данных (высокий, средний, низкий), а затем мы должны принять решение, солить ее или нет. В противном случае мы можем использовать другие меры для защиты данных.
3. «тогда на вас также ляжет дополнительная ответственность за защиту этих солей» Что вы имеете в виду под этим? Соль, но определение, не является конфиденциальной информацией. Если вам нужно защитить соль, то это не соль, а перец, и обработка перца сильно отличается от обработки солей (а также намного слабее, чем соли).
Ответ №2:
Это очень сильно зависит от размера пространства поиска. Например, мы могли бы притвориться, что номера социального страхования являются случайными и уникальными (на самом деле они ни тем, ни другим не являются, но для целей этого обсуждения мы притворимся, что это так). Если вы хэшируете SSN, вам не только нужна соль, но и соли недостаточно. Почему? Потому что существует менее 10 миллиардов SSN. Создание радужной таблицы для них тривиально. Даже с солью не так сложно применить грубую силу, даже если значения уникальны и случайны.
Итак, чтобы защитить случайное и уникальное значение, которое находится в небольшом пространстве поиска, мы должны использовать алгоритм растяжения, такой как PBKDF2, а не просто хэш. Смысл алгоритма растяжения в том, чтобы сделать вычисление хэша очень медленным.
Алгоритмы растяжения всегда включают соль. Но это не обязательно должна быть случайная соль. Это может быть детерминированным (некоторый идентификатор базы данных идентификатор пользователя, например, «com.example.mygreatapp: alice»). Но для небольшого пространства поиска вам все равно нужно, чтобы она была уникальной для каждого пользователя, потому что в пространстве поиска так мало элементов.
С другой стороны, если ваши случайные и уникальные данные представляют собой большое пространство поиска (не менее 2 ^ 64, а в идеале не менее 2 ^ 80), и это пространство поиска является разреженным (вы используете только очень малую часть разрешенных элементов), то соление и растяжение, скорее всего, не требуется.