Безопасное веб-программирование - Лучшая практика аутентификации пользователей

Question

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

Так есть некоторые вопросы, на стороне аутентификации вещей:

1. Как следует Введенный пароль на клиенте кодируются и отправляются на сервер - если HTTPS уже используется? Я слышал о некоторых, предполагающих, что для обеспечения безопасности, например, отправляется только хеш. Должна ли быть зашифрована клиентская сторона - как?
2. 1. Аналогичные, но на стороне сервера. Как сохранить пароли. Фактический, хеш и т. Д.? Должны ли они быть зашифрованы - как?
      Кроме того, существует ли архитектура, которая может защитить пароли таким образом, что если один пароль будет скомпрометирован, а не все остальные? Например, если все пароли хранятся в одном файле, доступ к только одному файлу может скомпрометировать каждого пользователя в системе.
   2. Если нужно хранить только хеши - как обрабатывать столкновения?
3. После аутентификации следует ли просто полагаться на идентификаторы сеансов, чтобы поддерживать аутентифицированный статус повсюду? Я читал о советах по сокращению сессионного highjacking и поэтому задавался вопросом, является ли это хорошей идеей/единственной идеей, в первую очередь, для обеспечения аутентификации пользователей.
4. Существует ли безопасный способ предоставления функции autoLogIn, чтобы браузер помнил пароль, похожий на клиентов социальной сети/веб-электронной почты?
------------- Дополнительные - предотвращение атак
5. 1. Существуют ли какие-либо инструменты или даже просто некоторые общие методы там, которые должны быть применены к имени пользователя/пароля записи, предоставленные для предотвращения инъекций или любых других видов атак?
   2. Если я использую среду разработки Java (с использованием PlayFrameWork btw), насколько вероятно, что злоумышленники могут включать вредоносные фрагменты кода любого вида в записи любой формы?

PS Как уже упоминалось, я, вероятно, будет с помощью Java PlayFrameWork для кодирования веб-сайт - вы можете предложить что-то я должен принять во внимание это?
Любые советы по шаблонам проектирования, которые должны соблюдаться в целях безопасности, были бы полезными.

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

Answer 1

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

Его нельзя отправлять на сервер таким образом, который может быть восстановлен. Проблема с SSL/TLS и PKI - это {имя пользователя, пароль} (или {имя пользователя, хэш (пароль)}) представляется практически любому серверу, который отвечает сертификатом. Этот сервер может быть хорошим или плохим.

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

Лучше всего интегрировать настройку канала SSL/TLS с помощью аутентификации. Это называется привязкой канала. Он обеспечивает взаимную аутентификацию и не делает ничего глупого, например, поместить на провод {username, password}, ​​чтобы его можно было легко восстановить.

SSL/TLS предлагает почти 80 шифровых наборов, которые не делают глупое {имя пользователя, пароль} на проводе. Они представляют собой предварительный ключ (PSK) и безопасный удаленный пароль (SRP). Даже если плохой парень отвечает (т. Е. Управляет сервером), злоумышленник не может узнать пароль, потому что он не надет на провод для восстановления. Вместо этого ему придется сломать AES (для PSK) или решить проблему дискретного журнала (для SRP).

Все это подробно описано в книге Петра Гутманна Engineering Security.

Аналогичные, но на стороне сервера. Как сохранить пароли. Фактический, хеш и т. Д.? Должны ли они быть зашифрованы - как?

См. Secure Password Storage Cheat Sheet и Secure Password Storage paper Джон Стивен написал для OWASP. Он проводит вас через всю модель угрозы и объясняет, почему все происходит определенным образом.

После аутентификации следует ли просто полагаться на идентификаторы сеансов, чтобы поддерживать аутентифицированный статус повсюду?

Да, но авторизация отличается от аутентификации.

Аутентификация - это «грубое зернистое» право. Он задает вопрос: «может ли пользователь использовать это приложение?». Авторизация - это «мелкозернистая» лицензия. Он отвечает на вопрос: «может ли пользователь получить доступ к этому ресурсу?».

Есть ли безопасный способ, чтобы обеспечить возможность автологина, так что браузер запоминает пароль - похожий на социальную сеть/веб-клиент электронной почты

Это зависит от того, что вы считаете безопасными и что в модель угрозы. Если ваша модель угрозы не включает злоумышленника, у которого есть физический доступ к компьютеру или устройству пользователя, то его, вероятно, «безопасно» по большинству стандартов.

Если злоумышленник имеет доступ к компьютеру или устройству, а пользователь не защищает его паролем или штырем, то его, вероятно, не считается «безопасным».

Существуют ли какие-либо инструменты или даже некоторые распространенные методы, которые должны применяться к записям имени пользователя/пароля, предоставленным для предотвращения инъекций или любых других видов атак?

Да, пользовательский логин страдает от инъекций.Таким образом, вы можете выполнить некоторую фильтрацию на пути, но вы должны выполнить кодирование HTML на выходе.

Его не просто имя пользователя/пароль и логины. Почти все должно иметь некоторую входную фильтрацию; и он должен иметь выходную кодировку в случае ее злонамеренного действия.

Вы должны обязательно провести время на OWASP web site. Если у вас есть локальная глава, вы можете даже рассмотреть возможность участия в собраниях. Вы узнаете много, и встретите много удивительных людей.

Если я использую среду разработки Java (с использованием PlayFrameWork btw), насколько вероятно, что злоумышленники могут включать вредоносные фрагменты кода любого вида в записи любой формы?

Java - восторг хакера. Качество и безопасность действительно снизились с тех пор, как Oracle купила его у Sun. Чем больше параноидальных (соображений безопасности?) Люди рекомендуют не подписывать любой Java-код, потому что песочница настолько сломана. Это делает законное приложение правильно изолированным. От http://threatpost.com/javas-losing-security-legacy:

... «Песочница является огромной проблемой для Oracle,» сказал Jongerius Threatpost. «Все ломаются. Их решение состоит в том, чтобы подписать код и выйти из изолированной песочницы из . Но тогда у вас есть полное разрешение на машину. Это не имеет смысла. "

Слишком плохо, что плохие парни не получили записку. Они подписывают свой код на вредоносное ПО и выходят из песочницы.

Любые советы по шаблонам проектирования, которые должны соблюдаться в целях безопасности, были бы полезными.

Вы также конфигурации сервера веб, как HTTPS Only и Secure печенья, HTTP Строгого Транспорт безопасность (HSTS) и содержание политика безопасности (CSP), Suhosin (закаленная PHP), SSL/TLS алгоритмов, и тому подобное.

Для этого есть много, и вам нужно будет найти подходящую направляющую для упрочнения.