защитить хэш-код?

Я уверен, что во всем этом есть что-то фундаментальное, что упрощает всю концепцию, которую я упускаю, но вот:

Хорошо, вы солите и хэшируете пароли для безопасности, но как насчет кода, который это делает?

Если вы находитесь на хосте или vps, не может ли «кто-то» получить ваш исходный код, потому что вы скомпилировали его там? Или, если они могут получить доступ к вашей базе данных, не могут ли они получить доступ к программе, которая выполняет шифрование/дешифрование и перебором, пока они не получат алгоритм?

Я знаю, что ничто никогда не может быть защищено на 100%, но как можно улучшить безопасность в этом контексте?


security vps hash shared-hosting salt
person Community    schedule 04.03.2013    source источник
comment
en.wikipedia.org/wiki/Kerckhoffs_principle   -  person SomeWittyUsername    schedule 04.03.2013

Ответы (2)


arrow_upward
3
arrow_downward

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

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

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

person PinnyM    schedule 04.03.2013
comment
лол, в последнем абзаце все сказано - person ; 04.03.2013
comment
@PinnyM: Помогите мне понять утверждение о том, что соль не нужно защищать. Если я знаю соль, используемую в связи с конкретной учетной записью, могу ли я создать радужную таблицу так же легко, как если бы пароль был без соли? - person Eric J.; 04.03.2013
comment
@ЭрикДж. - Да, вы могли бы использовать эту соль для построения радужной таблицы, но когда вы применяете разные соли для каждого пароля, вам придется создавать такую ​​таблицу для каждого пароля. Никто этого делать не будет, потому что брутфорс быстрее, если вы нашли совпадение, то нет смысла строить остальную часть радужной таблицы. К соли и перцу: они не исключают друг друга, соль обязательна, перец помогает в некоторых случаях защитить слабые пароли. - person martinstoeckli; 04.03.2013
comment
@martinstoeckli: Если соль известна, перебор становится намного более тривиальным, поскольку мне нужно только угадать пароль плюс соль и создать хэш, а не переставлять все возможные значения пароля плюс соли. Поэтому слабые пароли остаются слабыми. - person Eric J.; 04.03.2013
comment
@ЭрикДж. соление не предназначено для защиты слабых паролей как таковое. Он разработан, чтобы не позволить одной радужной таблице взломать их все за один проход. Поскольку для каждого из них необходимо будет создать отдельную таблицу, это значительно увеличивает время перебора всех паролей на несколько порядков. Однако вы правы в том, что один и тот же пароль может быть взломан за один и тот же период времени. Попытка скрыть соль, скорее всего, не принесет большой пользы, поскольку в случае взлома базы данных какова вероятность того, что кодовая база (и соль) не была взломана? - person PinnyM; 04.03.2013
comment
@EricJ - кроме того, атака методом грубой силы имеет большее преимущество, когда для выборки доступно большое количество паролей. Однако при добавлении соли это преимущество устраняется, поскольку каждую соль необходимо тестировать отдельно. Подробнее об этом см. здесь. - person PinnyM; 04.03.2013
comment
@ЭрикДж. - Цель соли в том, что вы должны взламывать каждый пароль отдельно. Цель перца состоит в том, что (пока он остается секретным) слабые пароли становятся надежными комбинациями пароля и перца. Чтобы помешать перебору одного пароля, вам нужна медленная хэш-функция, такая как BCrypt. Дополнительную информацию см. в моем руководстве. - person martinstoeckli; 05.03.2013

arrow_upward
1
arrow_downward

В вашем исходном коде нет ничего «скрытого» относительно алгоритма хеширования. Фактически, вы должны использовать проверенную, хорошо известную реализацию сильного хэша, а не реализовывать алгоритм самостоятельно.

Соль — это та часть, которую необходимо защищать. Эта соль не является частью вашего кода (или не должна быть), а скорее должна храниться в каком-то хранилище файлов/базе данных (в зависимости от вашего приложения) и должна применяться для каждого пользователя (пользователь Джо должен иметь другая соль для его пароля, чем у пользователя Fred).

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

С другой стороны, ваш код также должен быть защищен от любого неавторизованного пользователя, но не по причине защиты соли (по крайней мере, не напрямую... если кто-то может получить доступ к соли или просто заменить ваш код собственным, полностью минуя проверку подлинности).

person Eric J.    schedule 04.03.2013
comment
Соль вообще не считается секретом. - person Gumbo; 04.03.2013