Алгоритм аутентификации бедного человека?

Question

Запрос на мозговой штурм

Мне нужна идея алгоритма аутентификации с некоторыми необычными требованиями.

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

Ограничения:

1. «Транспортный слой» - это электронная почта
   • отправитель (' Алиса ') - человек
   • Алиса имеет доступ только к веб-браузеру и доступу в Интернет (включая учетную запись веб-почты) в качестве своих инструментов; поэтому она не может делать очень сложные вычисления
   • Ресивером (' Bob ') является компьютер без прямого доступа из Интернета.
   • Боб имеет учетную запись электронной почты, которую он периодически проверяет.
   • Боб может отправить электронное письмо.
   • Нет отправки информации третьим лицам: Алиса и Боб не может отправлять какую-либо внеполосную информацию. Чтение некоторой общедоступной информации (например, времени с сервера времени) можно.

Предположения:

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

Non-цели:

• кодирование фактической полезной нагрузки сообщения не требуется.
• скорость / задержка не являются (большими) проблемами

Некоторые идеи, с которых можно начать:

1. Простой старый жестко запрограммированный пароль.
   Проблемы :

   • атака грубой силой (маловероятно)
   • подслушивание возможно, если общение осуществляется открытым текстом, тогда возможны повторные атаки

2. Простой алгоритм, основанный на текущей дате / времени
   Пример: Алиса добавляет текущую дату, час и минуту и ​​отправляет результат в качестве токена аутентификации, который Bob может проверить. Предположим, что доступ только для чтения к серверу времени не нарушает правило № 7 (без участия третьих лиц).
   Проблемы

   • безопасность через неизвестность : алгоритм несколько безопасен только потому, что он не является общедоступным (ну, теперь он ... упс!)

3. Какой-то механизм ответа на вызов - Алиса отправляет запрос на аутентификацию, Боб отвечает с запросом, Алиса отправляет ожидаемый ответ и фактическая полезная нагрузка.
   Какие детали механизма? Я не знаю:)

Что может ты подумать? Я надеюсь увидеть креативные ответы; -)

Edit:

Может быть, пример прояснит правило # 3: предположим, что Алиса использует проприетарное устройство с закрытым исходным кодом <cough> iPhone <cough> для доступа в Интернет, или она стоит перед общественным интернет-киоском.

Answer 1

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

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

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

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

Недостатки:

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

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

Answer 2

Я могу придумать два варианта:

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

Answer 3

Помимо ответа Треба , вы можете использовать одноразовые пароли, которые можно распечатать, вместо SecurID. Подробнее см. Пароли к идеальной бумаге .

Answer 4

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

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

Answer 5

Разработка над lassevks ответ :

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

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

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

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

Answer 6

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

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

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

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

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

Answer 7

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

Answer 8

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

Так же, как работают многие схемы проверки электронной почты.

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

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

Answer 9

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

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

Проблемы:

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

Answer 10

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

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