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

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

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

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

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

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

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

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

Non-цели:

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

Некоторые идеи, которые помогут вам начать:

  • Обычный старый жесткий пароль.
    Проблемы:

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

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

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

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

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

Edit:

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

ОТВЕТЫ

Ответ 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. Чтобы отправить сообщение Бобу Алисе, сначала нужно войти в Чарли (через простой старый пароль), а затем Чарли даст ей одноразовый токен. Затем она отправляет свой адрес электронной почты вместе с токеном Бобу.