Лучшие практики для аутентификации / безопасности веб-приложений (любая платформа)


12

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

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

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

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

Есть ли серьезные недостатки в этом подходе? У вас есть предложения получше?


При хранении одностороннего зашифрованного (т.е. хешированного) пароля убедитесь, что вы используете надежный хеш (т.е. не MD5) или солите пароль (см. Stackoverflow.com/questions/420843/… ) или оба.
Джордан Рейтер

Посетите веб-сайт OWASP ( owasp.org ). У них есть много очень полезной информации о безопасности, включая «шпаргалки» для различных протоколов.
Ральф

Здесь приведены некоторые рекомендации по аутентификации веб-сайтов на основе форм. Stackoverflow.com/a/477578/463478
Only You

Ответы:


13

Несколько советов высокого уровня:

  1. Храните только те данные, которые вам нужны
  2. Всегда шифруйте конфиденциальные данные (SSN, пароль, номер кредитной карты и т. Д.) При хранении
  3. Всегда шифруйте трафик с использованием SSL при передаче / получении конфиденциальных данных.
  4. Если вы сомневаетесь в секретности информации, зашифруйте ее
  5. Не доверяйте пользовательскому вводу (кто-то попытается ввести что-то плохое)
  6. Не доверяйте своим данным (кто-то может изменить их в базе данных - например, внедрить вредоносный скрипт)
  7. Не катите свое собственное шифрование
  8. Защитите серверы, на которых размещены приложения / базы данных
  9. Увеличьте нагрузку на конечных пользователей в целях безопасности (ограничения по паролям, никогда не раскрывайте пароли, не отправляйте URL-адреса по электронной почте, сокращайте время сеанса и т. Д.)

Мое предложение для вас будет получить книгу по защите веб-приложений. В одном ответе / блоге / статье слишком много информации, чтобы передать ее. Тема шифрования сама по себе является существенной.


В чем причина использования SSL вместо собственного шифрования? Рассматриваете ли вы использовать что-то вроде WS-Security для шифрования собственного шифрования? Настройка SSL может быть проблемой.
г-н Джефферсон

Это хороший контрольный список. Я удивлен, что больше нет голосов за это.
Кристофер Хох

2
@ Mr.Jefferson Я бы сказал, 99,999999% случаев, когда вы НИКОГДА не хотите «свернуть свое собственное шифрование».
Зак Лейтон

2

Вы можете попытаться изменить поведение браузера - вот несколько полезных советов:

/programming/32369/disable-browser-save-password-functionality


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

1

Я бы сказал, что с тобой все будет в порядке.

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

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

Если вы все еще хотите, есть способы отключить поведение браузера, как указал Чад. Я сам видел это только на сайте моего банка и в системе Microsoft Live.


Отличный пост, я забыл добавить, что имя пользователя не будет адресом электронной почты, однако у пользователя будет адрес электронной почты, сохраненный в системе. Забавно, что вы упоминаете об этом, потому что даже популярные сайты, такие как Facebook, подвержены перехвату пакетов для адресов электронной почты и паролей.
maple_shaft

Я также хочу добавить, что я не указываю на недостатки безопасности в Facebook как на «оправдание», необязательно для плохой модели безопасности в моем приложении. Только потому, что мама Джо позволяет ему смотреть фильмы с рейтингом R, это не правильно :)
maple_shaft

1

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

То есть до тех пор, пока кто-то не успешно судится и не меняет правила. Смотрите также: «Внимание: содержимое может быть горячим».


0

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

Я думаю, что вы могли бы сделать, это рандомизировать имена полей в вашей форме входа в систему каждый раз. Вместо того <input name="username", чтобы использовать что-то вроде <input name="user658667587". Это сделало бы кэшированные имена пользователей совершенно бесполезными. Но я не знаю, стоит ли это накладных расходов. Не говоря уже о стеснить пользователей , которые ARENT на общественных компьютерах.

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.