Собственно для этого и был придуман метод аутентификации challenge-response, чтобы передавать не сам секрет, а косвенную информацию о секрете, которую обе стороны могут проверить. Но тогда, хранимый в бд хэш позволяет воссоздать необходимый для успешной аутентификации ответ клиента.
Но тогда для хакера возникает вторая задача, которая может быть сформулирована так: изменить client side логику(js скрипт и ajax запросы) таким образом, чтобы не вычислять хэш от пароля, а сразу использовать значение подсоленного хэша. Задача тривиальна. Ее можно решить, например, написав своего клиента и использовать его вместо браузера. Либо использовать прокси, например, burp suite, для вычисления и подмены значений, отправляемых во время аутентификации.
то что во втором варианте будет медленнее на N ms - очевидно.
то что это не узкое место дает понять следующий ход:
если сделать host[ip] = 0, а потом просто каунтить строки лога per ip, то скрипт будет работать от 8,7 до 8,9 сек.
во втором случае, когда используется вложенный хэш, то скрипт будет работать от 8,7 до 8,8 сек.
разница не критична.
но идея теста: оценить скорость построчного чтения файлов и то, как расходуется память.
из теста становится ясно, что питоновские строки имеют какой-то оверхед, и на гигабайтном файле этот оверхед дает о себе знать.
используется хэш в хэше, это не узкое место
обращение к host[key] либо к host[ip][key] - не сильно отличаются по времени
Конечно во втором варианте используется двойное хеширование для доступа к ключу, но это не узкое место в данном тесте.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
