Разъяснение по аутентификации HMAC с помощью WCF

Я следил за несколькими статьями о веб-сервисах RESTful с WCF и, в частности, о том, как в них проходить аутентификацию. Основная статья, на которую я ссылался, — это веб-службы RESTful с WCF 3.5. Другой документ, посвященный аутентификации HMAC, — Статья Итая Гольдстина, основанная на статье Сконнарда.

Меня смущает «Ключ пользователя», на который ссылаются в обеих статьях. У меня есть клиентское приложение, которое потребует от пользователя наличия имени пользователя и пароля.

  • Означает ли это, что ключ, который я использую для инициализации класса System.Security.Cryptography.HMACMD5, является просто паролем пользователя?
  • Учитывая метод, использованный для создания Mac в статье Итаи (показан ниже), я прав, думая, что key — это пароль пользователя, а text — это строка, которую мы используем, чтобы подтвердить, что детали на самом деле верны?

    public static string EncodeText(byte[] key, string text, Encoding encoding)
    {
        HMACMD5 hmacMD5 = new HMACMD5(key);
        byte[] textBytes = encoding.GetBytes(text);
        byte[] encodedTextBytes =
            hmacMD5.ComputeHash(textBytes);
        string encodedText =
            Convert.ToBase64String(encodedTextBytes);
        return encodedText;
    }
    

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

Подходит ли эта форма аутентификации? Я столкнулся с другим потоком, который предполагает, что метод, определенный в приведенных выше статьях это «... (так в оригинале) уродливый взлом». Автор не объясняет, почему, но это обескураживает, учитывая, что я провел несколько часов, читая об этом и заставляя его работать. Однако стоит отметить, что принятый ответ на этот вопрос говорит о пользовательской схеме авторизации HMAC, поэтому, возможно, уродливая ссылка на взлом — это просто ее реализация, а не использование самих алгоритмов HMAC.

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

Показывает, как работает аутентификация MAC между отправителем и получателем


person Mr Moose    schedule 29.03.2012    source источник


Ответы (1)


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

  • Во-первых, ключ имеет оптимальную длину, равную размеру выходного хеша, а пароль пользователя редко будет равен этому.
  • Во-вторых, никогда не будет достаточно случайности (энтропии, если использовать технический термин) в этих байтах, чтобы быть адекватным ключом.
  • В-третьих, несмотря на то, что вы предотвращаете повторные атаки, вы потенциально позволяете любому подписать запрос любого типа, предполагая, что они также могут получить общий секрет (который передается сервером в какой-то момент или он получен только на клиент и сервер?Если транслируется, атака «человек посередине» может легко захватить и сохранить это - верх паранойи, да, но я думаю, вам следует подумать об этом), если пользователь не изменит свой пароль.
  • Четвертое — перестаньте использовать HMACMD5 — используйте как минимум HMAC-SHA-256.

Этот ключ должен быть как минимум серией байтов, сгенерированных из пароля пользователя — обычно с использованием чего-то вроде PBKDF2 — однако вы также должны включить что-то временное, основанное на сеансе и в идеале не известное злоумышленнику.

Тем не менее, многие люди могут сказать вам, что я слишком параноик.

Лично я знаю, что не являюсь экспертом в аутентификации — это очень тонкий баланс — поэтому я полагаюсь на проверенные и проверенные технологии. SSL (в данном случае аутентификация через клиентские сертификаты), например, может иметь свои недостатки, но большинство людей используют его, и если одна из моих систем будет взломана из-за слабости SSL, это не будет моей ошибкой. Однако, если эксплойт происходит из-за какой-то слабости, которую я не был достаточно умен, чтобы идентифицировать? Я выталкивал самого себя из парадной двери.

Кстати, для остальных сервисов я теперь использую SCRAM для аутентификации, используя SHA512 и 512 бит случайной соли. для операции растяжения (многие люди скажут, что это излишне, но мне не придется менять его какое-то время!), а затем использовать безопасный токен (подписанный с помощью HMAC и зашифрованный с помощью AES), полученный от аутентификации и другого сервера -только известная информация для сохранения аутентифицированного сеанса. Маркер не имеет состояния так же, как и файлы cookie проверки подлинности форм Asp.Net.

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

person Andras Zoltan    schedule 29.03.2012
comment
спасибо за Ваш ответ. Я просто хотел бы уточнить еще пару вещей. Если я использовал PBKDF2 для генерации достаточно большого ключа, правильно ли я думаю, что алгоритм PBKDF2 на клиенте и на сервере даст одинаковый результат? Я помогаю писать службу WCF, но не буду участвовать в клиентском приложении для iPhone. Я надеюсь, что это охватывает пункты 1 и 2. Что касается пункта 3, общий секрет будет частью приложения iPhone и конфигурации WCF и не будет транслироваться. Что касается пункта 4, я буду винить в этом ужас кодирования. .com/blog/2009/05/the-bathroom-wall-of-code.html - person Mr Moose; 29.03.2012
comment
Привет! Алгоритм PBKDF2 действительно даст тот же результат, однако следует отметить, что реализация .Net RFC2898DeriveBytes(msdn.microsoft.com/en-us/library/) привязан только к одной хэш-функции, тогда как официально вы должны иметь возможность выбрать свою собственную - есть другие реализации вокруг, если вы Google. 3) Не рекомендуется компилировать секрет в приложение - существуют декомпиляторы :) - лучше использовать случайный одноразовый номер, который подходит только для этого одного сеанса. - person Andras Zoltan; 30.03.2012
comment
знаете ли вы, является ли обычным (или целесообразным) использование функций PBKDF2 на мобильном устройстве (например, iPhone/Android). При написании простого тестового клиента javascript на основе браузера я заметил, что в некоторых браузерах он может работать довольно медленно. Я предполагаю, что это будет усугубляться на мобильном устройстве. В другой моей ветке было высказано предположение, что PBKDF2... будет очень плохим выбором, потому что он добавит значительная загрузка ЦП. Буду признателен за ваше мнение о его пригодности. - person Mr Moose; 10.04.2012
comment
Действительно, смысл PBKDF2 состоит в том, чтобы клиент выполнял работу. Сам iPhone использует PBKDF2 для получения ключей для зашифрованного личного хранилища. Решение здесь состоит в том, чтобы делать это только тогда, когда вам нужно, например, при запуске приложения; или один раз в день - используйте PBKDF2 (возможно, получая параметры с сервера) для получения вашего ключа. Точно так же вы можете сделать это при первом запуске, сохранив результат в зашифрованном хранилище пользователя. - person Andras Zoltan; 10.04.2012
comment
Дох. Я думаю, что тогда я мог неправильно использовать PBKDF2. По сути, я запустил PBKDF для пароля с солью, представляющей собой комбинацию sharedsecret и метки времени (чтобы сделать его динамическим). Возможно, вы правы в том, что я должен просто сделать это при запуске приложения, а затем добавить динамические элементы в алгоритм HMAC и иметь постоянную соль (возможно, в виде одноразового номера). Боже, я чувствую, что просто придумываю все это на ходу. Еще раз спасибо за ваш вклад. - person Mr Moose; 10.04.2012
comment
«Я чувствую, что просто придумываю все это на ходу» — да, я знаю это чувство :) - person Andras Zoltan; 10.04.2012