CouchDB Аутентификация

Question

Я прочитал много вещей об аутентификации в CouchDB, особенно относительно Аутентификации Cookie. Я все еще делаю некоторые тесты, и все, кажется, работает хорошо, например с этой командой:

curl -vX POST $ HOST / _session -H 'application / x-www-form-urlencoded' -d 'name = foo & password = bar'

Я получил печенье, которое я могу использовать. Но моя точка зрения такова, что каждый раз, когда я вижу, что в Интернете, например, имя пользователя и пароль всегда отправляются в виде простого текста.

Я действительно плохо знаком с безопасностью, но какой интерес от метода Cookie Auth, если мне сначала нужно отправить свои учетные данные в открытом виде?

Есть ли способ отправить хотя бы хешированный пароль? С чем-то вроде этого IDK:

curl -vX POST $ HOST / _session -H 'application / x-www-form-urlencoded' -d 'name = foo & hashed_password = hashed_bar'

Приветствия

Arnaud

Answer 1

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

Также помните, что даже если это решит проблему, вы все равно будете отправлять свой cookie в открытом виде, будучи уязвимым для перехвата сеанса.

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

Что вы должны сделать, это всегда использовать HTTPS для любого аутентифицированного доступа CouchDB с любой задействованной сетью, за исключением, может быть, сети 127.0.0.0.

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

Answer 2

Использование Https - правильный ответ.

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

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

Таким образом, для защиты базы данных паролей требуется применение на стороне сервера криптографически защищенной односторонней функции (например, e.sha256) со случайным / случайным начальным числом для переданного пароля.

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

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

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

Грубое форсирование паролей может быть затруднено на стороне сервера из-за увеличения промежутка времени между попытками. Но это обычно работает для одного конкретного соединения. Атакующий может восстановить соединение после каждых двух попыток. Затем необходимо отслеживать IP-адреса для распознавания атак такого типа.

Answer 3

Начиная с версии 1.1, CouchDB поддерживает доступ к API через HTTPS. Вместо использования HTTPS-прокси вы можете использовать HTTPS напрямую, защищая пароли, передаваемые по проводам. См. Руководство по функциям для 1.1.