Безопасный вход через дополнительную информацию о контексте (которая также должна быть безопасной) - PullRequest
1 голос
/ 13 июля 2010

Мое веб-приложение будет запущено через существующие толстые клиентские приложения. При запуске будет сгенерирован HTTP-запрос POST, включающий информацию, такую ​​как userID и дополнительную информацию о контексте (в основном такие вещи, как имя целевого пользователя, день рождения и т. Д.).

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

Мой вопрос заключается в том, как обезопасить это от MITM и других дыр в безопасности. Как запрос, генерируемый через толстый клиент, может быть подключен через SSL? Разве SSL-соединение не должно быть сначала аутентифицировано с именем пользователя (и паролем)? И если так, будет ли публичная информация о дополнительном контексте открыта до тех пор, пока пользователь не войдет в систему?

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

1 Ответ

2 голосов
/ 13 июля 2010

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

Если вы хотите использовать свой метод, просто опубликуйте идентификатор пользователя и другую информацию на своем сайте SSL. Пост и любой ответ будут зашифрованы. Если использовать веб-страницу, она будет выглядеть примерно так:

<form method="POST" action="https://mysite.com/login">

Генерация из приложения, просто используйте https: // при создании вашего URL для публикации.

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

...