Пробел в безопасности при смене пароля с помощью .NET FormsAuthentication и постоянных файлов cookie? - PullRequest
Новая
       38

Пробел в безопасности при смене пароля с помощью .NET FormsAuthentication и постоянных файлов cookie?

14 голосов
/ 30 марта 2012

ОК, вот сценарий:

  1. Боб входит на mysite.com, который использует аутентификацию форм .NET и ставит галочку «запомнить меня».
  2. Ева ворует ноутбук Боба
  3. Боб получает новый ноутбук и меняет свой пароль.

Теперь у Евы есть украденный ноутбук, на котором хранятся постоянные куки-файлы, которые будут регистрировать ее на mysite.com как Боб - и, насколько я могу судить, это будет работать даже после того, как Боб сменил свой пароль .

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

Это достаточно простая лазейка, которую можно обойти - просто установив FormsAuthentication.SetAuthCookie («username: passwordHash») или что-то еще, а затем расшифровав и разделив cookie в вашем обработчике аутентификации, - но у меня возникли проблемы, полагая, что эта проблема существует из-за коробка "... я что-то упустил?

РЕДАКТИРОВАТЬ : Обратите внимание, что я предполагаю, что цель кнопки «запомнить меня» состоит в том, чтобы не вводить пароль каждый раз, когда вы посещаете веб-сайт. Это работает на Facebook, Twitter, Gmail и практически на всех других веб-сайтах, о которых я только могу подумать, и я был бы очень удивлен, если бы это не было целью опции «постоянный cookie» в .NET FormsAuthentication.

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

EDIT 2 : Похоже, что по крайней мере один крупный сайт .NET - CodePlex.com - уязвим для этого; см http://codeplex.codeplex.com/discussions/350646

Ответы [ 2 ]

9 голосов
/ 30 марта 2012

Возможно, имеет смысл принимать только билеты FormsAuth, выпущенные после последнего сброса пароля.

Так что в Global.asax AuthenticateRequest извлеките FormsAuthenticationTicket.IssueDate из зашифрованного билета и сравните его с датойчто пользователи сбрасывали пароль в последний раз (вам нужно будет сохранить его в своей базе данных, когда они сбросят свой пароль).

Если билет был выпущен до этой даты, то отклоните билет, не аутентифицируйте его и не попросите его войти снова.

Я не реализовал это сам, так что я мог бы бытьгде-то не хватает дыры в теории ...

1 голос
/ 30 марта 2012

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

Вы можете легко решить проблему, связанную с идентификатором в разделе пользовательских данных cookie-файлов форм. Обратите внимание, что если вы создаете cookie самостоятельно, вы можете ввести туда произвольные данные, например, идентификатор записи пароля.

Теперь вы можете добавить обработчик AuthenticateRequest в ваш global.asax. Вы пытаетесь извлечь пользовательские данные из cookie и сравниваете полученный из cookie идентификатор с идентификатором в базе данных. Если они не совпадают, вы возвращаете ошибку и / или выходите из приложения.

...