Меры защиты от взлома хэша при передаче хешированных учетных данных с использованием одноразового номера

Мне нужно аутентифицировать пользователей с помощью ключа API, но прежде чем передать его им, мне, очевидно, нужно проверить их учетные данные. Я думаю, что процесс должен идти так:

клиент->сервер: GET /user?username=fred

сервер-> клиент: nonce=XYXY

клиент-> сервер: POST /login?hashval={хэш(имя пользователя + пароль + одноразовый номер)}&nonce=XYXY&username=fred

сервер сравнивает результат hash(username + passwordFromDB + nonce) с hashval и отвечает API-ключом, если он равен

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

Я знаю, что подключение через HTTPS и надежный пароль сделают этот процесс безопасным, но есть ли другие рекомендации или способы сделать этот процесс более безопасным?

Спасибо


person Yuri Borges    schedule 24.04.2014    source источник


Ответы (1)


По сути, это форма дайджест-проверки подлинности, поэтому она имеет те же ограничения.

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

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

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

person Bogdan    schedule 26.04.2014