Каков наилучший дизайн входа для веб-приложений?

Question

Во-первых, давайте определим «лучший» здесь.«Лучший» дизайн / поток / алгоритм / метод входа в систему для целей этого вопроса должен быть:

• Простой .Я не думаю, что мне нужно объяснять, почему простая система лучше сложной.OAuth 2, например, на мой взгляд, очень сложная система.Он определяет, если я правильно помню, не менее девяти различных потоков для предоставления приложению доступа к данным человека.Я нахожу это излишним, но это не подлежит обсуждению здесь.

• Независимость от языка .Пожалуйста, не отвечайте, давая реализацию.Я не хочу реализации.Я хочу дизайн (или несколько ...).Вы можете приводить примеры, но предлагаемое вами решение должно легко кодироваться на любом (читай: большинстве) языке, не требуя значительных обходных путей для функций, которых нет.

• Secure .Дизайн должен охватывать наиболее распространенные проблемы безопасности в сети.XSS, CSRF, и т. Д. И т. Д. Я думаю, что хороший набор можно получить, перейдя в Coding Horror и в поиске «security» ...

Теперь длянекоторые мелкие детали:

• JavaScript разрешен.Если дизайн может вернуться к средам, не относящимся к тексту, крутоНо это не обязательно.

• Flash, Java-апплеты не допускаются.Это противоречит пункту, не зависящему от языка: если вашему дизайну требуется что-то, что доступно только через Flash или Java, это недостаток.

• Хранение пароля .Существует целый класс проблем, связанных с хранением пароля.Я не хочу об этом слышать.

• Передача пароля .Это важно .Передача пароля простым текстом - это просто зло.По SSL это может быть приемлемо, но если у вас может быть система (относительно) безопасная, не полагаясь на сквозное шифрование, это было бы здорово.

Учитывая всеДля этого предложите «лучший» дизайн пользователя / входа / выхода из системы / потока / алгоритма / техники, который, по вашему мнению, соответствует условиям, описанным выше.Или скажи мне, если думаешь, что это глупое поручение!;)

Answer 1

Я думаю, вы уже подумали над этим вопросом.Самый простой способ взглянуть на решение - разбить его на несколько слоев.

1) База данных

• Защищено от SQL-инъекций.Просто используйте готовые заявления.Лучший и самый безопасный!
• Всегда, и я имею в виду всегда, убедитесь, что пользователь БД имеет только те права доступа, которые ему необходимы.

2) Приложение

• Использовать HTTPS.Даже не пытайтесь использовать что-либо еще
• Не сохраняйте идентификатор пользователя в cookie-файле или в чем-либо другом.Используйте сессию, если вам необходимо
• Если у вас нет сессии, сгенерируйте случайный идентификатор, который будет использоваться для поиска пользователя.Важно, чтобы идентификатор cookie не был предсказуемым.

3) HTML / Javascript

• Защита от CSRF с помощью системы токенов.Это единственный законный способ
• Избегать всего пользовательского ввода и очищать его перед записью в поток.В JSP, например, следует использовать <c:out/>
• Не делать ничего безопасного в javascript.Это очевидный ответ, но иногда полезно напомнить

4) И т.д.

• Постоянно обновлять патчи
• Донне воссоздай колесо.В Rails уже есть несколько отличных жетонов авторизации.Используйте их!

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

Answer 2

Интересующий вопрос.

Я бы рассмотрел:

1. При необходимости Я думаю, что веб-контент должен быть публичным. Так что, как пользователь, я думаю, что лучше иметь логин только тогда, когда это необходимо
2. SSO У нас должен быть механизм для более удобного кросс-соединения веб-приложений. Я знаю, что приложения не реализуют разрешения одинаково, и мы не можем сходить с ума там. Вот где OAuth заполняет пробел.
3. Не используйте CAPTCHA ( считается недоступным ). Если вы не используете что-то подобное, вот так
4. csrf скрытое поле , чтобы убедиться, что отправляемая форма является действительной, а не случайной записью в конечную точку
5. Всегда используйте SSL Большие парни делают это, и нашим пользователям небезопасно отправлять свои пароли в виде открытого текста. Некоторые доказали это.
6. Всегда планируйте без javascipt На всякий случай, во всяком случае, это не потому, что мы можем это сделать, это хорошо делать.

Это мой тайм-аут на сегодня. :)