Хеширование пароля, соль и устройство хранения данных хешированных значений
Я увидел эту ветку после публикации своего ответа на аналогичный вопрос. Я хотел предоставить ссылку, потому что я думаю, что тот же подход может быть полезным в зависимости от вашей ситуации. Это может быть излишним для этого точного вопроса, но я хотел бы поделиться, если это поможет кому-то еще.
https://stackoverflow.com/a/52348744/5046784
Короче говоря, вы можете создавать уникальные интерфейсы / классы для каждого именованного объекта (например, MyApiGson и ThirdPartyApiGson), а затем создавать @ Обеспечивает тех, кто не является общим классом Gson. Таким образом, вы можете внедрить экземпляры по классу / интерфейсу, а не по волшебному имени строки, которое вам нужно найти или запомнить. Это немного больше работы, но это помогает, когда у вас есть куча независимых модулей, которые предоставляют разные экземпляры одного и того же класса.
4 ответа
Соль просто должна быть случайной и уникальной. Это может быть свободно известно, поскольку это не помогает злоумышленнику. Многие системы сохраняют текстовую соль в базе данных в столбце рядом с хешированным паролем.
Соль помогает гарантировать, что если два человека (пользователь A и пользователь B) используют один и тот же пароль, это не очевидно. Без случайной и уникальной соли для каждого пароля значения хэшей будут одинаковыми, и, очевидно, если пароль для пользователя A будет взломан, то у пользователя B должен быть тот же пароль.
Это также помогает защитить от атак, когда словарь хешей может быть сопоставленным с известными паролями. например, радужные таблицы.
Также используется алгоритм с «коэффициентом работы» встроенный также означает, что по мере увеличения вычислительной мощности работа, которую должен пройти алгоритм для создания хэша, также может быть увеличена. Например, bcrypt . Это означает, что экономика атак методом перебора становится несостоятельной. По-видимому, становится намного сложнее создавать таблицы известных хэшей, потому что они создаются дольше; вариации в «коэффициенте работы» будут означать, что потребуется построить больше таблиц.
Я думаю, вам нужно спросить себя: «Что вы надеетесь получить, усложняя это более сложным, чем просто генерация случайного значения соли и его сохранение?» Чем сложнее вы сделаете свой алгоритм, тем больше вероятность непреднамеренного появления слабых мест. Это, вероятно, будет звучать язвительно, как бы я это ни сказал, но это полезно - что такого особенного в вашем приложении, что ему нужен новый модный алгоритм хеширования паролей?
Я думаю, что вы слишком усложняете проблему.
Начните с проблемы:
- Вы пытаетесь защитить слабые пароли?
- Вы пытаетесь защититься от радужных атак?
Предлагаемый вами механизм действительно защищает от простой атаки «радуга», потому что, даже если у пользователя A и пользователя B ОДИНАКОВЫЕ пароли, хешированный пароль будет другим. Кажется, что это довольно сложный метод подделки пароля, который слишком сложен.
- Что происходит, когда вы переносите БД на другой сервер?
- Можете ли вы изменить уникальное значение для каждой БД, если да, то может быть сгенерирована глобальная радужная таблица, в противном случае вы не сможете восстановить вашу БД.
Вместо этого я бы просто добавил дополнительный столбец и сохранил подходящую случайную соль. Это защитит от любого вида радужной атаки. В нескольких развертываниях.
Однако это не защитит вас от атаки грубой силы. Так что, если вы пытаетесь защитить пользователей с плохими паролями, вам нужно поискать в другом месте. Например, если у ваших пользователей четырехбуквенный пароль, его, вероятно, можно будет взломать за секунды даже с помощью соли и новейшего алгоритма хеширования.
Почему бы не добавить случайную соль к паролю и хешировать эту комбинацию. Затем объедините хэш и соль в один байт [] и сохраните его в db?
Преимущество случайной соли в том, что пользователь может изменить свое имя пользователя. Соль не обязательно должна быть секретной, поскольку она используется для предотвращения атак по словарю.