Чи потрібно змушувати користувачів змінювати паролі кожні n днів / тижнів / місяць?

Питання каже все це. Ми розробляємо систему, де безпека дуже важлива. Однією з ідей, які у когось були, було змусити користувачів змінювати паролі кожні 3 місяці. Я вважаю, що, хоча його більш безпечно, оскільки пароль часто змінюється, він також змушує наших користувачів пам’ятати про постійно змінювані паролі та робить більш можливим, що вони просто запишуть його десь, щоб допомогти запам'ятати.

У тій же ідеї, чи дійсно добре змусити користувачів використовувати надзвичайно важко відгадати пароль. Примушуйте їх використовувати?% &% І малі літери. Я знаю, що це досить складно, щоб винайти такий пароль, а потім запам'ятати його.

Потім знову не хочемо, щоб хтось використовував 12345.

Так. Чи є якісь дописи на цю тему? Гарна практика?

Я говорю про веб-сайт, створений за допомогою PHP. MySQL в середовищі лампи, якщо це щось змінює.

Я думаю, що я міг би бути в меншості з цього приводу (виходячи з мого обмеженого досвіду роботи з ІТ-відділами в школі та на роботі), але я вважаю, що обов'язкові часові політики щодо зміни паролів в кращому випадку нічого не варті і в гіршому випадку шкідливі. Люди, як правило, дуже погано вибирають хороші паролі та зберігають їх у таємниці. Політики дії терміну дії пароля розроблені для того, щоб пом'якшити це шляхом обмеження часу, коли будь-який пароль може бути зламаний / соціальний інженер / викрадений; однак вони цього не досягають на практиці, насамперед тому, що вони змушують користувачів постійно вивчати свій пароль. Завдяки цьому користувачеві важче робити свої пам’яті паролі, ви змушуєте багатьох із них вибирати слабкіші паролі та / або записувати свої паролі там, де їх можуть знайти сторонні очі.

Крім того, коли вони змушені регулярно змінювати свій пароль, багато користувачів вибирають паролі, які відповідають дуже впізнаваному шаблону, наприклад [base string][digit]. Скажімо, користувач хоче використовувати ім'я своєї кішки Fluffy як свій пароль. Вони могли б почати з паролем fluffy, а потім змінити його fluffy1, fluffy2,fluffy3 і так далі. У цьому випадку політика насправді не допомагає безпеці; навіть якщо користувач вибирає більш захищену базову рядок, ніж fluffyнавіть якщо вони зберігають свій запам'ятований пароль, один символ суфіксу, який змінюється кожні кілька місяців, робить дуже мало, щоб пом'якшити розтріскування або напади соціальних інженерій.

Дивіться також: Термін дії пароля Вважається шкідливим , коротка стаття (не написана мною), яка, на мою думку, дає хороший вклад у ці проблеми.

Моя велика організація (15000+ користувачів) впроваджувала «зміни паролів» кожні 120 днів восени 2009 року. Це величезний ІТ-головний біль і витрата ресурсів підтримки. Щоразу, коли 120-денне вікно прокручується, у нас тисячі користувачів змушені змінювати свій пароль .... який багато з них або робить неправильно, і заблокує свій рахунок .... або забуде наступного дня. Наша служба технічної допомоги переповнена паролями, навіть якщо ми намагалися зробити її якомога більше самообслуговування.

Якщо ви хочете, щоб ваші користувачі / клієнти ненавиділи вас .... а ваш ІТ-персонал на передній лінії спалював вас у чудовому випадку, кожен шанс, що вони отримають ... впроваджуйте зміни пароля.

Політика щодо зміни пароля - це прапорець у тому, як десь забронювати IT Manager, і це було написано 15 років тому. Ніхто з траншей, хто насправді здійснює та не підтримує політику, ніколи не скаже вам, що це гарна ідея.

Я сперечався тут, щоб "пропустити фрази" замість паролів .... жирне багато хорошого, що зробили ... те світло в кінці тунелю БУЛО зустрічний потяг. :)

Фраза пропуску - це довгий майже непридатний рядок, який легко запам’ятати на кшталт «MyCatIsFromSpainAndICallHimElGato». А може, рядок із вірша чи пісні.

Якщо ви хочете зробити це по-справжньому важко розірвати .... зіпсуйте справи, додайте пунктуацію, змініть деякі на елл, ой на нулі, а на @ і т. Д. ... Але нехай це запам'ятовується ... .це ключ. Існують навіть способи підібрати їх, щоб вони легко перетікали з ваших пальців на клавіатуру .... так що ви не підстрибуєте поперек між руками або за допомогою SHIFT та дивних пунктуацій.

Так...

• Використовуйте довгі "передачі фраз".
• Випробуйте їх внутрішньо на міцність.
• Впроваджуйте "єдиний вхід" у всій своїй інфраструктурі, щоб клієнти повинні використовувати його лише один або два рази на день.
• Ніколи не змушуйте їх змінити це.
• І виховувати, виховувати, навчати їх правильному використанню.

Метт

EDIT: 24.08.2011 XKCD погоджується і сказав це краще, ніж я.

Ні. Моя особиста думка полягає в тому, що це непотрібно і навіть контрпродуктивно . Я побіг у своєму блозі, але ви можете полювати за цим, якщо вам цікаво.

Коротше кажучи, це зводиться до двох причин:

1. Примушування користувача постійно змінювати свій пароль призводить до неправильних паролів.

Про це не бракує анекдотичних доказів, але це має сенс, що якщо я змушу згадувати нову річ кожні х днів, я зроблю ці речі легко запам’ятовуватими і, ймовірно, пов’язаними між собою.

Користувачі набагато частіше вибирають "вподобані" паролі на зразок "Jan2010" або "Password05", якщо вони знають, що це доведеться скоро змінити. Забезпечення суворої політики щодо символів, швидше за все, призведе до додавання знака оклику або повністю написаного імені, а не абревіатури. Існує велика різниця між технічно складним паролем і паролем, про який не можна здогадатися.

2. Примусові регулярні зміни паролів не запобігають атакам, вони лише знижують ризик (а не набагато)

Подумайте над цим - якщо ваш пароль вгадується чи виявляється якимось чином, скільки часу зловмисникові потрібно буде використовувати цю інформацію? Поставте себе у взутті нападника. Ви щойно відкрили пароль. Чи не входитимете ви та витягувати будь-яку частину інформації, яку ви могли б одразу ж на випадок, коли хтось дізнається? За 30 днів ви вже отримали все, що хочете.

Моя рекомендація:

• Застосовуйте надзвичайно сувору політику щодо паролів (наприклад, 15 символів із верхніми, нижніми цифрами та спеціальними символами, без англійських слів> 3 символи)
• Ніколи не змушуйте користувача змінювати свій пароль. Якщо їм доведеться написати пароль на аркуші паперу і зберегти його в гаманці, це насправді добре. Люди хороші в закріпленні аркушів паперу, але не так добре запам'ятовують випадкові рядки символів.

З точки зору користувача, зміна мого пароля неймовірно незручна. Я абсолютно ненавиджу це робити, і буду дуже обережно використовувати сайти, які мені абсолютно потрібні, якщо вони вимагають від мене змінити пароль.

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

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

Як користувач досить суворого середовища щодо політики паролів ("супер важко вгадати паролі" та змінити пароль), я вважаю, що потрібен лише жорсткий пароль. Хоча ваші користувачі знадобиться трохи звикати до нього (особливо якщо вони є 12345-тими користувачами), вони повинні мати можливість згадати та набрати це легко протягом тижня.

Однак я можу передбачити незручних кінцевих користувачів, якщо у вас є такі надійні паролі та змусять їх змінюватись.

З точки зору адміністрування ІТ, ваш найкращий варіант - дослідити можливість дозволити вашій програмі використовувати можливості єдиного входу в існуючій схемі аутентифікації, яку використовують ваші клієнти. Очевидно, що Active Directory є великим гравцем, але якщо ваша програма працює з політикою, яка вже налаштована на ІТ-майданчику, вам не доведеться турбуватися про винахід колеса.

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

Часто зміна паролів може призвести до того, що користувач записує їх. На думку Брюса Шнейера, що не є такою поганою ідеєю ( http://www.schneier.com/blog/archives/2005/06/write_down_your.html ).

Я б навіть заперечував, що колись безпека перешкоджає користуванню, колись може бути хорошою справою, просто тому, що це нагадує користувачеві діяти безпечно. Наприклад, у банку, де я працюю, багато заходів безпеки є театром безпеки (наприклад, розпізнавання обличчя біля дверей, але хлопець відчинить вам двері, якщо розпізнавання не вдасться). Хоча ці заходи не покращують безпеку самі по собі, вони завжди є для того, щоб нагадати нам, що безпека є важливим концерном на роботі, що відбувається деяка кількість реєстрації та перевірки, і що якщо вас зачеплять, роблячи щось "незахищене" ви буде в біді.

Звичайно, це стосується безпеки працівників банку, можливо, це не стосується користувачів вашого веб-сайту ...

Ви повинні змусити своїх користувачів змінювати кожні n днів, якщо цього вимагає ваша політика безпеки. Я працюю в державному агентстві, і це вимога виконується в органах державного аудитора. Я нічого не можу з цим зробити, тому мені доводиться примушувати зміни.

Якщо ви не зобов'язані регулюванням примушувати зміни пароля, не примушуйте їх. Переконайтесь, що встановлені паролі відповідають певним вимогам щодо мінімальної складності. Складність козирів для більшості систем паролів, тому мінливий стандарт є найкращим на мою думку. Як от:

• Ні один пароль не повинен бути менше 10 символів.
• Для паролів між 10-25 символами знадобляться принаймні 3 набори символів.
• Для паролів між 25-40 символами знадобиться принаймні 2 набори символів.
• Паролі, що перевищують 40 символів, можуть використовувати один набір символів.

Вбудовані схеми складності для таких речей, як Active Directory, не підтримують такого рівня багаторівневу систему. Якщо ви створюєте власне середовище зміни пароля, ви можете робити такі речі. Оскільки кожне використання клавіші зсуву збільшує ймовірність події жиру пальцем, довгі паролі з декількома наборами символів набагато більше шансів на те, що трапляються події, які не відбулися, особливо на етапах навчання. Якщо у вас є система блокування облікових записів, це може бути великою проблемою. Для людини, яка використовує 3-й рядок улюбленого вірша (63 символи!) Як свою фразу, не маючи h @ x0r, це робить запис швидким та ефективним.

Якщо технологія чи середовище ризику істотно змінюються, а ваші паролі зараз не такі складні, як повинні бути, введіть таким чином, щоб термін дії паролів закінчувався протягом певного періоду часу. Люди будуть бурчати над необхідністю, особливо якщо ви ніколи раніше не примушували змін, але це допоможе вам зберегти свою безпеку.

Важко здогадатися про паролі. Підвищити рівень складності, в результаті якого користувачі забудуть свої паролі або повинні записувати їх - це погано, адже будь-яка безпека, здобута складністю, повністю втрачається в процесі. В ідеальному світі (який, на жаль, не там, де ми живемо), повинен бути баланс між складністю та зручністю використання. Звичайно, різні люди побачать цю рівновагу в різних місцях.

Логіка, за якою регулярно змінюються паролі за X днів, на мене трохи втрачається. Причиною, про яку я зазвичай чую, є обмеження корисності викраденого пароля, на що я відповідаю, що будь-який реальний збиток майже напевно буде зроблений протягом перших кількох годин. наприклад, Фред "знайомиться з" паролем Мері. Якщо це не відбувається майже в той самий час, коли Марія змінює цей пароль, яку різницю він має, якщо він зміниться завтра чи наступного місяця? Чи дійсно ймовірно, що Фред чекатиме ще тиждень-два, перш ніж використовувати пароль (якщо вважати, що це був намір весь час)?

Очевидно, що зміни паролів, якщо є якісь причини чи підозри, що це може знадобитися, - це зовсім інша справа.

Якщо програмі потрібен такий високий рівень безпеки, чи планували ви використовувати щось на зразок маркерів SecurID? Це означає, що користувач отримує новий пароль кожні 60 секунд; вам не доведеться турбуватися про них, використовуючи записування паролів. Однак це коштує грошей. Наскільки безпечним має бути рішення?

Я думаю, що інформація для користувачів важлива. Поясніть їм, як створити пароль і як важливо не використовувати один і той же пароль два рази. Найпростіший спосіб створити пароль - взяти речення і взяти першу букву в кожному слові та додати кілька цифр.

Вих. Мені подобається правити світом = Iltrw99

Не змушуйте їх змінювати пароль, це лише заплутає їх.

Хоча я не погоджуюся зі зміною паролів кожні три місяці, це вимога, якщо ваша компанія публічно торгується, і це частина сумісності з SOX. Бічна примітка: Сарбанес-Окслі смокче.

Щось я не бачив, це зовнішній доступ до ресурсів.

Я схильний погоджуватися, що якщо ви виберете розумну політику щодо паролів, якщо хтось не запише її, ніхто, ймовірно, не вгадає цього пароля.

Однак скажімо, у вас є веб-адреса, доступна для веб-пошти, тепер у вас потенційно є користувачі, які вводять свої облікові дані на "будь-якому старому ПК" та IMO, що збільшує ризик для ваших бізнес-даних, спричинених шпигунськими програмами / зловмисними програмами / троянами тощо, які можуть нюхати / красти ці паролі .

Якщо люди записують прості паролі, змушує вас думати, що вони не запишуть величезну парольну фразу чи надскладний пароль. Досягнення додаткових змін пароля - це очищення ідентифікаторів користувача, які вже не використовуються автоматично, і це дозволяє окремому користувачеві нести певну відповідальність за все це. Люди будуть людьми, шукаючи легкої дороги, щоб щось досягти; повторні паролі та поступово змінені паролі можна виявити та відхилити. Вимоги до складності можуть бути посилені, примусові зміни паролів також можуть відкрити очі користувачам, які не є ІТ, на їхню відповідальність у всьому цьому. Більшість користувачів, які скаржаться на зміну пароля, - ледачі, які роблять вигляд, що змінюють свій пароль - це як операція на відкритому серці. Перестаньте скуголити, будьте відповідальні та намагайтеся знайти легку вулицю,