Лучшая практика для обеспечения имени пользователя/пароля между клиентами и сервером

У вас есть две отдельные проблемы: аутентификация зарегистрированного пользователя и создание новой учетной записи.

Аутентификация пользователя

Это простая часть. У вас есть несколько вариантов:

• HTTP-аутентификация ( базовая или дайджест ). Базовый - это шутка, поэтому в качестве серьезной альтернативы он оставляет только дайджест.
• HTTP NTLM / Kerberos-аутентификация (также известная как встроенная аутентификация Windows) является пуленепробиваемой, если ваши клиенты присоединены к домену NT (маловероятно).
• Взаимная аутентификация SSL / TLS
• Аутентификация HTTP с помощью форм. Не стоит и упоминать.
• Базовая аутентификация или проверка подлинности с помощью форм по защищенному каналу ( HTTPS )

Таким образом, остаются реальные варианты: дайджест, взаимный SSL или базовая / форма по зашифрованному каналу.

HTTP Digest очень легко реализовать на стороне клиента, просто добавьте имя пользователя и пароль в CredentialCache , используемый с WebRequest , и все готово. Повторно используйте экземпляр CredentialCache между вызовами, чтобы получить преимущества от предварительной аутентификации. К сожалению, на стороне сервера дела обстоят не так радужно: дайджест-аутентификация поддерживается должным образом только при интеграции с AD, см. Настройка дайджест-аутентификации .

Взаимная аутентификация SSL / TLS поддерживается как клиентом, так и сервером, но опять же, серверная сторона действительно поддерживает ее только при интеграции с AD, а не реальный вариант (см. Настройка аутентификации сопоставления сертификатов клиента ]).

Вот почему я считаю, что единственными реальными вариантами для приложения, которое не предназначено для использования через VPN в корпоративной среде, является использование базовой проверки подлинности или проверки подлинности с помощью форм по безопасному каналу (HTTPS). Для Basic вы должны предоставить пароль в виде открытого текста, и то же самое для Forms (в его обычном немодифицированном воплощении), поэтому клиент должен иметь доступ к паролю в виде открытого текста, и то же самое относится к серверу. Одностороннее хеширование не сработает, вам нужно надлежащее безопасное хранилище с шифрованием.

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

Сохранение пароля: Для Basic / Digest / Forms клиент не сохраняет пароль, поскольку пароль фактически предоставляется пользователем. В лучшем случае пароль может быть сохранен, чтобы избежать повторного ввода, и это следует делать так же, как любой секрет пользователя, хранящийся на клиенте, зашифрованный с помощью DPAPI через класс ProtectedData . На стороне сервера, если используется таблица пользователей, пароли должны храниться как односторонний хэш. Для Basic и Form подойдет любая схема хеширования (желательно солёная). Но для дайджеста хеш должен быть хешем HA1 из схемы дайджеста: md5 (имя пользователя: область: пароль) , чтобы сервер мог завершить квитирование аутентификации.Хотя для этого требуется довольно агрессивное переписывание готовых поставщиков членства, которые поставляются с ASP, я все же рекомендую этот способ.

Инициализация пользователя

Это немного сложнее, поскольку включает в себя установление начального доверия. Если вы просмотрите все схемы, упомянутые выше, вы увидите, что ни одна, кроме Basic / Forms через HTTPS, не может сделать это внутри полосы: любое другое решение требует первоначального развертывания учетной записи пользователя, настроенной внешними средствами ( где внеполосные относятся к используемой схеме). Взаимный SSL требует предоставления сертификата, NTLM / Kerberos требует предоставления пользователя AD, дайджест требует предоставления пароля пользователя. Для Basic / Forms и Digest существует удобное внеполосное решение: безопасный канал HTTPS, по которому отправляется форма для создания учетной записи. Для сертификатов SSL / TLS и для AD все сложнее.

OpenID / OAuth

Совершенно другой подход - делегировать аутентификацию. Используйте OpenID с такими поставщиками, как Google или Yahoo, и OAuth с такими поставщиками, как Facebook или Twitter. Это феноменально хорошо работает с веб-приложениями (сам StackOverflow использует такую ​​схему, как вы могли заметить, см. OpenID, One Year Later ). Существуют библиотеки и поставщики интеграции, которые действительно упрощают эту задачу, как 3 щелчка мышью и одна строка кода, например JanRain .

Единственная проблема с OpenID и OpenAuth заключается в том, что это интерактивная схема. Он работает только в том случае, если пользователь активно участвует в процессе входа в систему / аутентификации и, таким образом, устраняет все автоматизированные решения.Если ваше приложение выполняет какие-либо фоновые операции (например, работает в качестве службы) или использует идентификатор приложения для «домашнего телефона» без участия пользователя, тогда OpenID / OAuth не работает.