#encryption #salt #pkcs#5
#шифрование #соль #pkcs #5
Вопрос:
Я не знаю, как использовать «концепцию соли» в моем сценарии.
Предположим, у меня есть клиентское настольное приложение, которое шифрует данные для определенных пользователей и отправляет их на удаленный сервер. Клиентское приложение генерирует ключ с помощью PKCS # 5, содержащий пароль пользователя и соль. Удаленный рабочий стол НИКОГДА не должен быть связан с паролем пользователя.
Предположим, мы генерируем случайную соль для шифрования. Клиентское приложение может зашифровать данные и отправить их на удаленный сервер. Если пользователь попытается получить доступ к своим данным на другом компьютере, как он сможет их расшифровать, поскольку соль неизвестна?
Я думаю, что постоянно использовать одну и ту же соль (жестко закодированную в приложении) — плохая идея (защита от запутывания).
Как я могу решить свою проблему?
Ответ №1:
Соль хранится в незашифрованном виде вместе с зашифрованными данными.
Цель соли — помешать злоумышленнику предварительно вычислить словарь зашифрованных паролей. (Например, злоумышленник тратит год или что-то еще на создание зашифрованной формы каждого слова на каждом языке.)
Другая цель соли — убедиться, что у двух пользователей будут разные зашифрованные пароли, даже если их незашифрованные пароли одинаковы.
Ни одна из целей не требует, чтобы соль оставалась секретной.
[обновление, для уточнения]
Смотрите статью Википедии о Соли (криптография). В частности, прочитайте вводные параграфы.
Цель соли — принимать неслучайные входные данные (например, предоставленные пользователем данные) и делать их случайными перед передачей через криптографическую функцию. Чтобы это сработало, соль должна генерироваться случайным образом для каждого ввода.
Традиционным примером является хранение зашифрованных паролей. Большинство пользователей надежно выбирают неслучайные пароли, поэтому без соли каждый, кто выбирает «SEKRIT» в качестве пароля, получит один и тот же зашифрованный пароль в базе данных паролей. Решение состоит в том, чтобы добавить случайную соль перед шифрованием пароля, а затем сохранить ее (в виде открытого текста) вместе с зашифрованным паролем.
Комментарии:
1. как общедоступная соль предотвращает предварительное вычисление злоумышленником пароля, зашифрованного по словарю?
2. @0verbose Соль добавляется к паролю перед шифрованием. Итак, чтобы предварительно вычислить словарь для всех слов, вам нужно будет объединить каждую возможную соль с каждым возможным словом. Легко сделать количество возможных солей настолько большим, что это невозможно.
3. @0verbose Соль отличается для каждого пароля, хранящегося в базе данных. В этом весь смысл соли! (Вы отклонили мой ответ, который на самом деле на 100% правильный?)
4. Да, я отклонил это. Но если вы меня убедите, я удалю это. Не бойтесь :). В любом случае ваше объяснение соли на 100% верно, но о какой базе данных вы говорите? это не сохранение пароля на сервере, они только на стороне клиента, так какова цель соли в этом сценарии?
5. Nemo верен. Соль должна быть общедоступной, аналогично исходному вектору алгоритмов блочного шифрования. Соль затрудняет расшифровку зашифрованной ключевой фразы, дополняя ее случайными данными.
Ответ №2:
Если вы добавите соль к зашифрованным данным, то клиентское приложение на другом компьютере сможет успешно вычислить хэш пароля.
Комментарии:
1. Уточнение: не шифруйте соль. Просто отправьте ее открытым текстом вместе с зашифрованным блоком данных.
2. Какова должна быть цель передачи соли в открытом виде? Если злоумышленник может перехватить трафик, то он может прочитать соль, и сама соль станет непригодной.
3. Ответ Nemo — отличное объяснение того, почему соль полезна. Предположим, злоумышленник атакует хэшированный пароль методом перебора или по словарю и успешно обнаруживает исходный пароль. Достаточно большая и случайная соль не позволяет немедленно применить этот успешный результат к другим пользователям, которые использовали тот же пароль. Поэтому злоумышленник вынужден каждый раз атаковать каждый пароль по отдельности. Общедоступная текстовая соль не ставит под угрозу это.
4. Я это понимаю. Но это не тот же сценарий. Я имею в виду, пароль никогда не передается и не сохраняется на сервере. Итак, даже если злоумышленник обнаружит, что пароль клиента имеет хэш, как он узнает хэши паролей других клиентов?
5. @0verbose: После дальнейших размышлений: необходимо использовать некоторый тип случайных данных во время шифрования, чтобы один и тот же ввод открытого текста никогда не приводил к одному и тому же выводу зашифрованного текста каждый раз при использовании одного и того же пароля. Это особенно важно, если начало зашифрованных данных всегда одно и то же или очень похоже (например, некоторый тип заголовка). Соли паролей — это один из способов добавить некоторую случайность. Другим способом было бы использовать симметричный алгоритм шифрования со случайным вектором инициализации, передаваемым в открытом виде; в этом случае вам не понадобится пароль salt.
Ответ №3:
Существует аспект соления в распределенной среде, который не рассматривается ни в одном из ответов, которые я видел до сих пор. Если на сайте имеется несколько баз данных, которые необходимо синхронизировать, как можно защититься от состояния гонки, при котором случайная соль генерируется на двух или более сайтах почти одновременно. Когда базы данных согласованы, как узнать, какой столбец соли для данной строки является правильным?
ИМХО, аргумент в пользу идеи о том, что значение соли должно быть постоянно пересчитываемой случайной строкой, не был сделан против использования чего-то вроде первичного ключа (PK) для пользовательской строки. Прежде чем ответить ошеломленно, выслушайте меня.
- Любая разумная хэш-функция будет выдавать совершенно другой хэш независимо от того, насколько изменен обычный текст (добавлен один или 100 символов).
- Если вы используете PK, то значение не зависит от всей предоставленной пользователем информации.
- Так же, как и любое действие по засолке, PK-as-salt может быть вставлен в любом месте обычного текста с помощью алгоритма. Это не обязательно должно быть в начале или в конце.
- В распределенной среде нет условия гонки для столбца соли, потому что нет столбца соли.
- Использование подразумеваемой соли, такой как PK, по-прежнему заставляет каждый хэш выглядеть по-разному, даже если два пользователя используют один и тот же пароль. Таким образом, идея PK-as-salt делает то, что должна делать соль, без сложностей с согласованиями.