Неправильный алгоритм аутентификации пользователя?

Ответ 1

Мое представление о человеко-дружественном низкотехнологичном инструменте "вызов-ответ":

• Боб меняет задачу каждый раз, когда получает правильное сообщение (например, он делает соленый хеш текущего времени)
• каждое неверное сообщение, отправленное Бобу, заставляет его ответить с текущим вызовом, поэтому Алиса может запросить его, отправив пустую почту
• как только Алиса знает вызов, она отправляется в https://www.pwdhash.com/
  • в "Адрес сайта" она вводит текущий вызов
  • в "Пароль сайта" она вводит свой личный пароль (который известен Бобу)
  • PwdHash генерирует "хешированный пароль"
• Алиса пишет сообщение Бобу, используя хеш, только что созданный в качестве темы
• Боб получает сообщение, хеширует текущий вызов и пароль Алисы в соответствии с алгоритмом PwdHash и видит, соответствует ли его результат теме сообщения
• если это так, Боб принимает сообщение и отправляет подтверждение, содержащее новый вызов (по существу это шаг 1).

Преимущества:

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

Недостатки:

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

Обратите внимание, что PwdHash - это открытый алгоритм хэширования, Bob может легко реализовать его. Веб-сайт PwdHash работает без обратной связи, все зависит только от JavaScript на стороне клиента, никаких следов не осталось.

Ответ 2

Два варианта, о которых я могу думать:

• Выдать карточку с одноразовыми паролями (сообщение перед факсом, записная книжка)
• Электронное устройство, которое создает пинкоды (избегает повторных атак)

Ответ 3

В дополнение к Treb answer вы можете использовать одноразовые пароли, которые вы можете распечатать вместо SecurID. Подробнее см. " Perfect Paper Passwords".

Ответ 4

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

В Firefox есть как минимум одно расширение, позволяющее GPG в веб-почте.

Ответ 5

Разработка lassevks answer:

В моей компании мы используем токены SecurID от RSA для удаленной аутентификации.

Это дает вам 6-значное число, которое каждые 60 секунд меняется как токен аутентификации, предположительно, ваш генератор токенов и сервер являются единственными в юниверсе, которые знают токен, который действителен прямо сейчас.

Как низкотехнологичная альтернатива, набор из n (10, 20, 100 - все, что разумно в вашем конкретном случае), однократные коды аутентификации могут быть предоставлены Алисе. Я бы попросил у нее конкретный код (например, номер 42 в списке). После использования этого кода он становится недействительным для дальнейшего использования.

Изменить: См. ответ lacop для хорошей реализации низкотехнологичного решения.

Ответ 6

Если Алиса может запускать код на своем компьютере (например, используя JavaScript, который находится на каком-то общедоступном сайте, например: http://www.functions-online.com/en/sha1.html), она может получить вызов, хешировать его вместе с паролем и отправить его обратно.

Ответ 7

Подумайте о создании веб-страницы, содержащей алгоритм как JavaScript, возможно, как загрузку (чтобы она могла скачать ее один раз и перенести на USB-накопитель).

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

После того, как у нее есть код, она может ее где-то скопировать.

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

См. этот сайт для примера: https://www.pwdhash.com/

Ответ 8

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

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

Ответ 9

Вот еще одно предложение:

• Начните с обмена ключами Diffie-Hellman, в результате получив общий закрытый ключ, известный только предположительно - Алиса и Боб.
• У вас есть предопределенный пароль, известный только Алисой и Бобом.
• У Алисы зашифровать пароль с помощью общего ключа и отправить его Бобу
• Теперь Боб может видеть, что, по-видимому, Алиса действительно Алиса.

Проблемы:

• Диффи-Хеллман небезопасен, используя небольшие числа.
• Что будет простым симметричным алгоритмом шифрования (для шифрования пароля)?

Ответ 10

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

Как и многие из схем проверки электронной почты.

Недостаток: это только доказывает, что злоумышленник имеет доступ к почтовой учетной записи Алисы, а не то, что это на самом деле Алиса. Чтобы решить эту проблему, вы можете сказать Алисе пароль и использовать трюк "HTML HTML", чтобы она могла закодировать ключ от Боба, используя свой пароль.

Это докажет, что она имеет доступ к своей учетной записи электронной почты и что она знает пароль.

Ответ 11

Есть несколько методов, о которых я могу думать:

Установите зашифрованную службу https, похожую на:

http://webnet77.com/cgi-bin/helpers/blowfish.pl

или

http://cybermachine.awardspace.com/encryption.php/

Или вы можете отправлять одноразовые пароли в сочетании с XOR-шифрованием

Или вы можете написать простое Java-приложение (если Java может быть запущен на машине), который может быть загружен через www и обеспечивает шифрование с открытым ключом.

Ответ 12

Простым способом защиты данных в пути без обмена паролями является трехсторонний-XOR:

• Алиса создает несколько байтов, используя свой собственный ключ.
• Она хранит данные с этими байтами, чтобы сделать их нечитаемыми.
• Алиса отправляет зашифрованные данные в Bob
• Боб создает несколько байтов, используя свой собственный ключ.
• Он записывает данные с этими байтами.
• Боб отправляет данные с двойным зашифрованием в Alice
• Алиса снова применяет свой шаблон XOR. Теперь данные кодируются только с шаблоном Bob
• Алиса отправляет данные Бобу
• Боб теперь может декодировать данные своим собственным шаблоном

Ответ 13

Хм... это будет считаться парикой?

Настройте брата Боба - Чарли, который доступен из Интернета через HTTPS. Чтобы отправить сообщение Бобу Алисе, сначала нужно войти в Чарли (через простой старый пароль), а затем Чарли даст ей одноразовый токен. Затем она отправляет свой адрес электронной почты вместе с токеном Бобу.