Должны ли пароли истекать?

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

Как вы думаете, пароли должны истекать?

100 голосов | спросил jrjensen 20 Jpm1000000pmTue, 20 Jan 2015 19:16:35 +030015 2015, 19:16:35

13 ответов


104

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

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

Я не думаю, что пароли должны истекать по уважительной причине , а потому, что прошло 6 месяцев, это не разумная причина good . Это период времени в воздухе. Почему 6, почему не 7 или 8.

Создание уникальных паролей каждый раз вызывает очевидную проблему: все предыдущие пароли пользователей хранятся в системе и даже если мы надеемся хэшировать /зашифровать, что действительно не хорошо от чьего-либо точка зрения!


См. также :

Я настоятельно рекомендую прочитать ответы на эти вопросы в разделе «Обмен файлами безопасности»:

Как сменить пароль каждые 90 дней увеличивает безопасность?

Требуется регулярное изменение пароля, но сохранение предыдущих паролей?


Точка интереса :

Экземпляры устаревших паролей не ограничены банками и другими финансовыми учреждениями. Этот пример приведен из Community College в Северной Вирджинии

  

введите описание изображения здесь>> </p>
</blockquote>

<hr>
<p> <strong>  Анекдот : </strong> </p>

<p> Я когда-то работал в компании, где нам нужно было вводить информацию о расписании и статусе проекта во внутреннюю централизованную систему. </p>

<p> Предполагалось, что это будет сделано еженедельно, но основное требование заключалось в том, что это делалось ежемесячно - до ежемесячного расчетного периода. Кроме того, пароли для входа в систему истекли через 30 дней. Любой предыдущий пароль нельзя использовать повторно. </p>

<p> Ежемесячное использование. Ежемесячный срок действия. Новый ежемесячный пароль. Сначала поддержка была затоплена людьми, забывающими свои пароли и вынужденными перезагружать их. </p>

<p> Итак, неудивительно, что было почти универсально, что все мы впали в рутину с использованием пароля, который был основан на текущем месяце и году, потому что это был самый простой способ запомнить текущий пароль и быть уверенным, что он не был используется раньше. </p>

<p> Эта система больше не работает. </p>

<p> Мораль состоит в том, что люди только люди. Не каждый является евангелистом безопасности. Мы легко забываем, и поэтому мы стараемся сделать это проще для себя. Мы пишем материал или, если есть много ограничений, мы делаем шаблоны, чтобы помочь себе. И шаблоны означают меньшую безопасность, недействительные сами причины, по которым безопасность была сделана в первую очередь. </p></div>
					 
						<div class=

ответил Roger Attrill 20 Jpm1000000pmTue, 20 Jan 2015 19:30:57 +030015 2015, 19:30:57
42

Нет.

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

Пароли, в лучшем случае, способ остановить доступ к оппортунистическому счету, т. е. запретить кому-либо просматривать ссылку на свой профиль и редактировать ваш профиль.

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

Что на самом деле достигается, безопасно?

Я оставлю вас читать это подробно, хотя и обобщить два лучших ответа: он не влияет на атаки грубой силы - независимо от того, сколько раз ваш пользователь изменил свой пароль, они все равно пострадают от this и this ; это помогает с возможными старыми резервными нарушениями безопасности данных, , но , это вопрос UX, и я бы сказал, что безопасность резервного копирования на 100% является вашей ответственностью как администратор системы, и поэтому я ссылаюсь на свою первую мысль о нажатии безопасности в домен пользователя.

Актуальные примеры финансовых услуг

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

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

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

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

ответил Toni Leigh 21 Jam1000000amWed, 21 Jan 2015 00:32:05 +030015 2015, 00:32:05
26

Быстрый ответ: Amazon, Google и мой банк не заставляют меня менять свой пароль каждые полгода или даже когда-либо. Что вы делаете, что требует большей безопасности *, чем они делают?

Будем надеяться на ваших пользователей, что это убедительный аргумент **, и вы решили не делать этого. Дополнительная дискуссия: зачем вам хранить свой пароль? Можете ли вы использовать OpenID или OAuth для их подписания, например. Войти в Google? Причина в том, что более безопасно позволять Google хранить свой пароль, чем пытаться сделать это самостоятельно.

И удачи! Надеюсь, что это произойдет:)

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

** , если нет, см. также:

  1. люди будут раздражаться вашей системой, поскольку они используют ее нечасто, и почему ваш единственный, кто это делает?
  2. заставить людей менять свой пароль, просто означает, что они выбирают очень похожие, или те, которые они записывают где-то; там не обойти это поведение
ответил Robert Grant 21 Jpm1000000pmWed, 21 Jan 2015 13:00:18 +030015 2015, 13:00:18
12

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

ответил Mark 21 Jam1000000amWed, 21 Jan 2015 01:30:15 +030015 2015, 01:30:15
10

Нет, смена паролей каждые шесть месяцев не сделает их более безопасными. Вы по-прежнему используете те же правила пароля (буква «Столица», число, символ, знак банды, иероглиф и кровь девственницы). Фактически, если вам требуется изменение, тем более вероятно, что пользователь запишет его необеспеченным способом.

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

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

Затем, и только тогда вы более безопасны, чем интервал смены пароля.

ответил 4rchit3ct 20 Jpm1000000pmTue, 20 Jan 2015 23:02:11 +030015 2015, 23:02:11
7

Это зависит.

Что делает ваш сайт? Каковы реальные последствия скомпрометированной учетной записи? Раздражение или украденная личность?

Outsource.

Есть ли у вас какая-то серьезная причина, чтобы не использовать и не допускать идентификацию и аутентификацию OpenID, Google, Facebook, Twitter и Yahoo?

Безопасность имеет свои затраты. Взвесьте их.

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

Думайте нестандартно.

Пароли сосут. Не используйте их только потому, что все остальные. Как насчет чего-то крутого, например Clef ?

ответил Dane 21 Jam1000000amWed, 21 Jan 2015 02:39:20 +030015 2015, 02:39:20
5

Для веб-сайта с клиентами ответ всегда отсутствует.

Это не имеет никакого отношения к безопасности.

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

Принудительные изменения пароля приемлемы для сотрудников и других пленных аудиторий, но для клиентов это ужасно.

ответил Dewi Morgan 25 Jam1000000amSun, 25 Jan 2015 06:28:24 +030015 2015, 06:28:24
4

Истечение срока действия пароля является ограничением для пользователей. Поэтому он должен иметь смысл для пользователей; в противном случае это вызовет плохой опыт.

Итак, я думаю, что ключевой вопрос: насколько важно для ваших пользователей защищать свой доступ к вашему веб-приложению?

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

ответил Florent Goumy 20 Jpm1000000pmTue, 20 Jan 2015 19:56:25 +030015 2015, 19:56:25
4

Мой пароль банковского счета не истекает, насколько я знаю, с точки зрения UX вы находитесь в одной из следующих ситуаций:

  • Вы не доверяете своим пользователям защищать свой пароль
    • Они записывают это на своих инструментах власти или хвастаются своим друзьям о том, насколько они любят Ovaltine.
  • У вас нет надлежащей инфраструктуры для обработки обнаружения вторжений.
    • Эй, вы не вошли в систему с этого компьютера до того, как мы отправили вам текст /электронную почту, введите проверочный код.
  • Вы система по своей сути небезопасна, и попытки грубой силы не смягчаются.
    • Заблокирована ли учетная запись после 3-5 неправильных попыток?

Если вам трудно выполнить произвольный срок действия пароля blah blah blah, тогда моя личная рекомендация состояла в том, чтобы разрешить им входить в систему один раз со старым паролем и отображать экран, в котором говорится: «Этот пароль старше 6 месяцев, не закрывайте это окно и, пожалуйста, измените свой пароль сейчас, иначе это будет полная PITA, чтобы изменить его позже, хорошо провести день ».

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

Если у вас нет этой настройки, вы, во всяком случае, исчерпаете пароль каждую неделю.

ответил MonkeyZeus 20 Jpm1000000pmTue, 20 Jan 2015 22:38:54 +030015 2015, 22:38:54
2

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

Насколько чувствительны ваши данные? Можете ли вы сделать частичный вход? Посмотрите на Amazon - вы можете просматривать, использовать свои предпочтения, видеть свои рекомендации и даже добавлять вещи в корзину, не будучи вынужденными снова входить в систему. Я также хотел бы отметить, что Amazon не требует поворотного пароля.

Это хорошая практика, но если вы не соблюдаете закон о финансах или HIPAA, лучше помнить, что безопасность - это проклятие юзабилити.

ответил Imperative 20 Jpm1000000pmTue, 20 Jan 2015 21:24:30 +030015 2015, 21:24:30
2
  

Если срок действия паролей истекает?

У меня есть ответ из двух частей, потому что это касается User Experience и Безопасность , но первые вещи сначала:

Ответ: да!


Сначала я буду использовать Пользовательский опыт , так как это сайт, на котором мы находимся. Это было продемонстрировано с помощью очень популярного webcomic от xkcd каждый, вероятно, узнает:

 xkcd Сила пароля

Теперь давайте протестируем правильный скот для батареи лошади на HowSecureIsMyPassword :

На обычном настольном ПК, выполняющем 4 миллиарда вычислений в секунду, вы получаете:

результаты настольных ПК

Я знаю, вы говорите: «Да, но это обычный настольный ПК. Что-нибудь быстрее?»

OK. Что насчет

Это действительно долго! Невозможно!

Вы, должно быть, говорите: «Хорошо держись! Подождите минуту! Как насчет другого пароля Tr0ub4for & 3 в комиксах? Конечно, это займет много времени, чтобы взломать это тоже, правильно? "

Хорошо, посмотрим, что Китай делает с этим!

введите описание изображения здесь>> </p>

<h1> Всего 4 часа!?!?! </h1>

<p> Да! Просто помните: </p>

<p> <strong>  Длина и легко запоминающийся  </strong>> <Сильный> <EM> сложность! </EM> </STRONG> </p>

<p> Теперь, это правда, вам нужно  также  помнить, что двухфакторная аутентификация - это путь в настоящее время и <strong>  <a href = Clef имеет потрясающую настройку в этом направлении.


Теперь, насколько это возможно, Безопасность , этот конкретный вопрос уже задан (другая формулировка, но обходной те же) с помощью < em> Билл Lizardâ ™ | на < em> Security.SE :

Как смена пароля каждые 90 дней повышает безопасность?

Можно было бы отметить, что в своем вопросе он отредактировал его, указав:

  

Этот вопрос был Вопрос о безопасности в Интернете .
  Прочитайте 15 июля 2011 г. запись в блоге для более подробной информации ....

Это был принятый ответ из < strong> Джастин Кейв , что Bill the Lizardâ ™ | выбрал:

  

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

     

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

     

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

Но для меня лучший ответ , и тот, который я проголосовал, был Hendrik Brummermannâ ™ | :

  

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

     

В каких ситуациях влияние смягчающего воздействия с принудительным паролем влияет?

     

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

     

Посмотрим, вероятен ли этот сценарий:

     

Как он узнал пароль?

     
  • Жертва, возможно, сказала ему (например, новый стажер, который должен начать работать, прежде чем он получит свою собственную настройку учетной записи, другой человек, который должен выровнять учетную запись в онлайн-игре
  •   
  • Злоумышленник, возможно, просмотрел ключевое слово
  •   
  • У злоумышленника мог быть доступ к другой базе паролей, в которой пользователь использовал один и тот же пароль
  •   
  • Один раз только вход в систему с использованием компьютера, принадлежащего (подготовленного) злоумышленником.
  •   

Что могло помешать ему создать бэкдор?

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

Почему не следует использовать принудительный пароль?

     

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

     

В заключение

     

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

ответил Code Maverick 23 Jam1000000amFri, 23 Jan 2015 00:48:34 +030015 2015, 00:48:34
1

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

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

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

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

ответил Jason Hutchinson 22 Jpm1000000pmThu, 22 Jan 2015 17:16:02 +030015 2015, 17:16:02
1

Да, в идеальном мире пароли должны истечь, и пользователи должны изобретать и запоминать новые.

Почему?

Только причины безопасности. Истечение срока действия означает, что пароль периодически изменяется, и это предотвращает использование учетных данных с использованием взломанных /пропущенных /украденных учетных записей. Это хорошо для проверки подлинности пользователя и аутентификации (низкий уровень, а не в реальном времени).

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

  • Если кто-то найдет вашу истекшую кредитную карту, это бесполезно.

  • Если кто-то найдет ваш пароль, вы можете надеяться, что он истек -> бесполезно.

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

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

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

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

ответил Samuel M 20 Jpm1000000pmTue, 20 Jan 2015 19:40:02 +030015 2015, 19:40:02

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132