Каков наилучший способ отправки данных аутентификации веб-формы по HTTP?

Question

Компания, которую я знаю, обсуждает вопрос о разработке политики безопасности паролей для всех своих продуктов веб-приложений.

Сейчас они отправляют аутентификацию по имени пользователя / паролю в формах POST по HTTP, и, следовательно, они отправляются в виде открытого текста.

Самое простое решение проблемы - просто потребовать HTTPS для входа во все наши приложения, верно?

Что ж, есть внутренняя дискуссия о том, чтобы вместо этого сделать своеобразное шифрование паролей на стороне клиента (пароль + соль и т. Д.).

Есть ли приемлемое решение только для HTTP?

Мнения похожи ... ну, у всех есть мнение, поэтому я ищу заслуживающую доверия литературу по безопасности, которая может поддержать вашу рекомендацию Не просто гуглить и отправлять меня в блог ... Я уже сделал это и дальше.

Я нашел рекомендации OWASP: http://www.owasp.org/index.php/Top_10_2007-A7#Protection

А также Microsoft: http://msdn.microsoft.com/en-us/library/aa302420.aspx

РЕДАКТИРОВАТЬ: Недостаточно дать рекомендации по использованию SSL. Мне нужна какая-то подтверждающая документация. Я ЗНАЮ, что использование нашего собственного шифрования на стороне клиента - это плохо. Я должен быть в состоянии продать это коллегам и руководству.

Также упоминается HTTP Digest. Вроде бы неплохо, но дайджест предназначен ТОЛЬКО для HTTP-аутентификации, а не для данных, отправляемых через POST.

Answer 1

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

Использование собственных решений для обеспечения безопасности может быть очень опасным, и даже если оно реализовано должным образом (с вероятностью 0,000001%), оно будет дорогим.

Answer 2

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

Если вам нужно достойное объяснение того, как реализовать дайджест-проверку подлинности HTTP в вашем приложении, Пол Джеймс написал отличную статью об этом .

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

Вы можете надежно хранить пароли, сохраняя хэш A1.

ОБНОВЛЕНИЕ: Как уже упоминалось в других ответах, хотя сервер может избежать атак MITM, не принимая базовую аутентификацию, клиент по-прежнему уязвим, поскольку он будет.

ОБНОВЛЕНИЕ: Вы не можете защитить данные с помощью POST, если только вы (а) не выполняете шифрование в JavaScript на клиенте или (б) не делаете все через SSL.

Вы можете , с небольшим количеством волшебства, использовать HTTP-аутентификацию с формами. В конце концов, статья, на которую я ссылался, называется «HTTP-аутентификация с HTML-формами». Но это не будет сделано по почте.

Если вам действительно нужно использовать POST, используйте SSL и запишите пароли в вашей базе данных.

Если вы хотите избежать CSRF, я рекомендую использовать formkeys , хотя идея идет под разными именами, я взял это имя после взлома Slashcode для собственного использования несколько лет назад, где я наткнулся на это первым.

Answer 3

+ 1 до ответ Мехрдада . Идти дальше с криптографией собственного производства рискованно.

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

TLS / SSL решает проблему не только безопасного обмена ключами, но и безопасной передачи данных.

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

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

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

Answer 4

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

время == деньги

Купите сертификат и проведите время за работой над приложением вместо безопасной формы входа.

Answer 5

Шифрование на стороне клиента беспомощно против большинства атак MITM. Атакующий может просто удалить ваш скрипт.

Это защитит только от пассивного прослушивания. Если это достаточно хорошо для вас, вы можете использовать:

• Хеширование реализовано в Javascript. Реализовать запрос-ответ для первоначального входа в систему легко, но не забывайте, что для cookie-файла сеанса злоумышленника почти так же, как и для пароля (вам придется ограничить вход в систему одним IP-адресом и / или использовать скрипт для создания одноразового cookie-файла каждый запрос, который я себе представляю, будет трудным и хрупким решением).
• HTTP Digest аутентификация. Более безопасный, поскольку он может использовать одноразовые хеши, взаимную аутентификацию и т. Д., Но стандартный пользовательский интерфейс абсолютно отвратителен.

... просто используйте SSL.

Answer 6

Решения только для HTTP всегда будут подвержены атакам типа «человек посередине».

РЕДАКТИРОВАТЬ: Сетевая трассировка будет простым способом доказать, что HTTP не является безопасным.

Answer 7

Мы просто выпустили веб / мобильное приложение, чтобы сделать некоторые из этих вещей. Он создает случайные URL-адреса для входа в систему, используя HTTPS и метод хешированного / AES-шифрования для хранения базы данных. Вот простой JSON API, который можно использовать без нашего пользовательского интерфейса, вот наша рецензия, посмотрите на нее .. http://blog.primestudiosllc.com/security/send-time-limited-secure-logins-with-timebomb-it

Answer 8

Ну, есть внутренняя дискуссия о вместо того, чтобы делать какие-то свернуть наше собственное шифрование на стороне клиента пароли (пароль + соль и т. д.).

Первое, что нам нужно рассмотреть - это данные в пути и данные в состоянии покоя. С ОП звучит так, что большое беспокойство вызывает имя пользователя / пароль в открытом виде через Интернет. Итак, вы действительно заботитесь о данных в пути. HTTPS через SSL - это проверенный способ сделать это (и это довольно легко исправить!). Теперь, если вы действительно хотите свернуть свои собственные данные в состоянии покоя (в БД, на файловом сервере и т. Д.), Это другой зверь, но существующие методы шифрования данных будут лучше, чем ваши собственные. .

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

Roll-your-own не будет подвергаться проверке, которую имеет существующее решение. Вы можете добавить дополнительные проблемы безопасности из-за кода.

Answer 9

Хорошо, вот единственный ответ, который вам нужен: ваш БАНК поддерживает только логин / аутентификацию через SSL. Если бы был лучший способ сделать это, они бы.

Answer 10

вы упомянули, что делаете свое собственное шифрование плюс соль ... Я предлагаю использовать javascript md5 (он также используется Yahoo на своих страницах, не относящихся к ssl, или так он утверждает) ...

И вы дважды хешируете пароль ... некоторые могут утверждать, что двойное хеширование делает его подверженным атакам коллизий. Я должен был бы не согласиться, потому что люди до сих пор могли делать конфликты сигнатур md5 только для файлов, где большой объем данных md5'ed ...

Если это большой корпоративный сайт (и были бы причины взломать), нет оправдания тому, чтобы не использовать SSL.