Допустимо ли публично обнажать соли?

Question

Я создаю REST API для мобильного приложения. Мне нужно обработать аутентификацию. Насколько мне удалось найти, это лучшие методы хранения паролей.

На стороне клиента зарегистрировать

1. Пусть пользователь выбрать пароль
2. Создать достаточно длинную случайную соль из генератора случайных чисел
3. добавьте соль к паролю и хэш Это.
4. Отправить хэш и соль на сервер и сохранить его в базе данных побочного журнал

сервера в

1. Expose метода, который возвращает соль пользователя для данного идентификатора пользователя (электронной почты)

Клиент бокового журнала в

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

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

Альтернатива этому заключается в том, чтобы отправить пароль в виде открытого текста и обработать все соления и хэширования на стороне сервера. Я бы использовал HTTPS.

Какой из этих подходов предпочтительнее? Есть ли у меня третий?

Answer 1

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

Нет, слабый момент заключается в том, что ваш сервер доверяет клиенту. Вот краткое и острое заключение MSDN о ситуации:

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

Источник: Do Not Trust User Input Directly

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

Если вы не защищаете соединение с клиентом HTTPS, вы всегда уязвимы для атаки «Человек-в-центре». Несмотря на то, что при возврате на ваш сервер номинально скрывается пароль, злоумышленник может вместо этого выдавать себя за клиента клиенту, отправляя HTML-форму, которая пропускает хэш или отправляет пароль в текстовом виде на свой сервер.

Разоблачение соли по вашему сценарию - - дополнительное отверстие для безопасности, но оно незначительно рядом со сверкающим отверстием, которое позволит злоумышленнику получить пароль напрямую. Я могу объяснить эту атаку дальше, если вы пожелаете, но это абсолютно бессмысленная атака, если только сам пароль не будет лучше защищен; и как только это произойдет, вам не нужно подвергать соль в первую очередь.

---

В ответ на замечания, это правда, что соли могут быть общеизвестные без снижения безопасности, если вы уверены, что они были созданы правильно. Для соли это означает, что они имеют достаточную длину, достаточно случайную, а в некоторых схемах - cryptographically secure. Проблема в том, что вы разрешаете клиенту генерировать соль, а это значит, что мы все согласны сейчас, что им нельзя доверять. Возможно, злоумышленник испортил внешнюю библиотеку, на которую вы полагаетесь для PRNG. Возможно, у некоторых пользовательских устройств недостаточно entropy pool. Возможно, их устройство не защищено от side-channel attacks. Если вы создаете приложение для Android, там, безусловно, есть некоторые очень небезопасные устройства. В огороженном саду Apple эти риски могут быть довольно низкими, но вы никогда не сможете их устранить.

Как я уже сказал, эти риски являются незначительными рядом с реальными опасностями вашей схемы. А именно, вы передаете хеш-код, переданный в поле clear на ваш сервер. Даже если вы добавили его еще до его хранения в своей базе данных, поэтому SQL-инъекция не может просто сбросить все пароли пользователей, вы все еще уязвимы для атак типа «человек в центре». Незашифрованный HTTP-трафик можно наблюдать и записывать любым маршрутизатором, через который он проходит. После того, как злоумышленник соблюдает хешированный пароль, они могут повторно отправить тот же запрос на ваш сервер и пройти проверку подлинности неправильно.

Answer 2

Вы должны строго пойти на альтернативу: «отправить пароль в виде открытого текста и обработать все соления и хэширования на стороне сервера. Я бы использовал HTTPS».

Конечно, предложение, приведенное выше, очень противоречиво: если вы будете использовать HTTPS, тогда пароль не будет иметь открытого текста. Вы должны использовать HTTPS.

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

Соль существует, если ваша БД украдена: соль будет гарантировать идентичность идентичных паролей. Кроме того, соль сделает невозможным использование радужных столов с предварительно вычисленными хэшами паролей.

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