безопасная аутентификация пользователя без javascript

Question

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

Это подводит меня к другой проблеме. Без сценариев на стороне клиента я понятия не имею, как я могу хэш-пароль пользователей на стороне клиента, чтобы избежать передачи паролей с открытым текстом. Как «чистый HTML + CSS» позволяет мне иметь хэширование пароля.

В настоящее время мне кажется, что единственным безопасным вариантом (без Javascript) было бы иметь безопасное (зашифрованное) соединение ssl/https и отправлять пароль в виде открытого текста?

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

[обновление] Я знаю, что SSL, пожалуй, самый близкий к идеальному. (как упоминалось в комментариях) Во всяком случае. Это уже улучшило бы безопасность, когда бы ни одно имя пользователя и пароль открытого текста не отправлялись через небезопасный канал. Хеши можно также обнюхивать, и там не может быть safty (например, шифрование). НО ни в коем случае сниффер сможет получить независимую версию имени пользователя и пароля. => преимущество заключается в том, что пользователи не будут публиковать свою комбинацию имени пользователя/пароля (потенциально используемую в другом месте).

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

Answer 1

Прежде всего, если вы используете SSL, пароль не отправляется простым текстом. Все, что находится за начальным рукопожатием, зашифровано и достаточно безопасно. Подумайте, что это безопасность, которую банки, военные, правительства во всем мире полагаются ежедневно. Я не говорю, что вы должны доверять ему только потому, что все остальные (argument from authority). Я просто говорю, что если бы с ним были проблемы, мы сразу узнаем об этом.

Во-вторых, вы никогда ничего не получаете от хеширования на стороне клиента. Основная атака, которую вы пытаетесь предотвратить, - атака man-in-the-middle (MITM). Независимо от того, кто-то перехватывает соединение, обнюхивает пароль для повторной атаки или активно захватывает сеанс (т. Е. Делает вид, что он является сервером и клиентом на противоположных концах соединения), вы не можете реально предотвратить его за счет дополнительной безопасности.

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

Я думаю, что вы ищете two-factor authentication.