Щойно отримавши електронний лист від постачальника, який повідомив нам, що вони змушують нас змінювати свій пароль кожні півроку, мені цікаво дізнатися, якими політиками щодо терміну дії пароля користуються люди та чому вони їх використовують.
Відповіді:
Тут є тонка грань між тим, що ніколи не змінювати його і занадто часто змінювати. Мати однакові паролі роками часто не є вдалим рішенням, особливо якщо він доступний для загального доступу. Але примушування до жорсткої політики її зміни занадто часто також має погані побічні ефекти. Одне місце, в якому я працював, змусило всіх користувачів внутрішньої мережі змінювати паролі кожні 6 тижнів, і passowrd не міг бути таким, як шість попередніх паролів. Три неправильні паролі заблокували робочу станцію, і ІТ-персонал повинен був її розблокувати. Це призвело до того, що кожен написав пароль на примітках Post-It, які висіли на екрані або поміщені в ящик. Кошмар.
Я б сказав, що зміна пароля раз на 6 місяців має бути достатньою. Це дозволить уникнути тих жахливих записів Post-It.
Я б запропонував використовувати трохи математики, яка враховує вашу мінімальну складність пароля, як швидко зловмисник може відгадати паролі, кількість наявних у вас розблокованих облікових записів та деяку інформовану інформацію про ваші ризики.
Сподіваємось, у вас є якесь обмеження швидкості для вгадування пароля. Як правило, це було б через щось, що тимчасово блокує акаунти після деякої кількості поганих паролів.
І, сподіваємось, у вас є якісь вимоги щодо складності пароля, так що "А" та "пароль" заборонені.
Припустимо, що після 30 відмов пароля за 10 хвилин ви заблокуєте обліковий запис на 20 хвилин. Це фактично обмежує швидкість відгадки пароля до 174 на годину, або 4176 на день. Але припустимо, це на кожного користувача.
Припустимо, вам потрібні 8-символьні паролі, що містять верхні, нижні та цифри, і ви робите кілька перевірок словника, щоб переконатися, що ці паролі є досить випадковими. Найгірше, що ваші користувачі ставлять один верхній і один номер на одне місце, і ваш зловмисник це знає, тому у вас є 10 * 26 ^ 7 (80G) можливих паролів. Кращий випадок - 62 ^ 8 (218T).
Отже, зловмисник, який намагається ввести всі можливі паролі, в найгіршому випадку вразив би їх усі протягом 50 000 років, а в кращому - майже 600 мільйонів тисячоліть. Або, інакше кажучи, зважаючи на рік, вони мали б від 1 до 50 000 та 1 з 52 000 000 000 здогадок. Якщо у вас є база даних у 50000, це майже гарантовано, що в гіршому випадку вони потраплять до одного облікового запису на рік і мають приблизно 50% шансів отримати один обліковий запис кожні 6 місяців.
І якби у вас не було обмеження швидкості, і зловмисник міг здогадатися мільярд паролів на день? Один з 600 шансів потрапити в обліковий запис за рік, або віртуальна гарантія отримання приблизно 80 з ваших 50 000 користувачів щороку.
Попрацюйте над тією математикою і з’ясуйте, де ваш прийнятний рівень ризику. І пам’ятайте, що чим коротше ви його встановите, тим складніше буде запам’ятати користувачам і тим більше шансів у них записатись десь зручно для зловмисника на місці.
Як додатковий бонус: якщо хтось пробує тисячі паролів на користувача на день проти ваших систем, я дуже сподіваюся, що у вас є якийсь моніторинг, який би підняв це.
EDIT: Забув зазначити: наша фактична політика становить 90 днів, але це має все стосунок до висновків неправильно проведених аудиторів безпеки і нічого спільного з реальністю.
90 днів, здається, достатньо для більшості сценаріїв. Моя найбільша турбота - складність пароля. Більше, ніж питання часових рамок при створенні пост-це приміток, - це вимушена складність. Одне - уникати словникових слів, а інше - мати спеціальних символів, але коли ви починаєте говорити, що жоден символ не може повторюватися чи бути у порядку зростання чи зменшення, ви ускладнили життя своїх користувачів. Додайте це до короткого терміну дії пароля, і ви щойно вітали більше питань.
Термін дії пароля дратує і знижує безпеку.
Термін дії пароля захищає ситуацію, коли зловмисник вже один раз скомпрометував пароль користувача, але не має механізму з'ясувати, що це на постійній основі (наприклад, кейлоггер)
Однак, це також ускладнює запам'ятовування паролів, роблячи більш імовірним, що користувачі записують їх.
Оскільки захист від уже скомпрометованого пароля насправді не потрібен (сподіваєтесь), я вважаю термін дії пароля марним.
Змусити користувачів вибрати сильний пароль для початку; спонукайте їх пам’ятати про це, тоді не вимагайте від них будь-коли їх змінювати, інакше вони все-таки запишуть їх скрізь.
Якщо у вас є пристрій, який потребує гарантій безпеки "від високої до надвисокої", вам краще скористатися апаратним маркером, який генерує одноразові паролі, а не покладатися на термін дії пароля.
Основна "виграш" для системи закінчення терміну дії пароля полягає в тому, що ви, зрештою, будете вимкнено обліковий запис, якщо власник рахунку покине організацію, оскільки додатковий "чек і баланс" до "облікового запису повинен бути відключений, коли власник облікового запису листя ».
Забезпечення терміну дії пароля призводить, у кращому випадку, до високоякісних записаних паролів, а в гіршому - до поганих паролів (на попередньому робочому місці, коли нас змусили використовувати термін дії пароля, я в кінцевому підсумку використовував (по суті) префіксJan2003, prefixFeb2003 тощо далі, оскільки мій кращий метод генерування паролів (48 випадкових біт, закодованих Base64) не масштабується до "нових паролів щомісяця").
Думаю, якщо ви задасте цьому питанню 10 різних фахівців із безпеки - ви отримаєте 10 різних відповідей.
Це значною мірою залежить від того, наскільки критично важливий актив захищає пароль.
Якщо у вас є активний захищений актив, вам потрібно встановити політику терміну дії пароля досить короткою, щоб будь-який сторонній зловмисник не встиг обрати пароль. Ще одна змінна в цій ситуації полягає в тому, який рівень складності необхідний для паролів.
Що стосується систем із низьким та середнім рівнем безпеки, я вважаю, що політика на строк дії на 6 місяців є дуже справедливою.
Для забезпечення високого рівня безпеки я вважаю, що місяць був би кращим - а для "ультра" безпечних установок можна очікувати навіть більш короткі періоди часу.
Ми застосовуємо 90-денний термін дії пароля для всіх, хто тут, включаючи себе.
Переважно тому, що це просто найкращі практики. Шанси того, що хтось скористається "слабким" паролем, порівняно з більш сильним, тим більше, і чим довше ви його залишите, можливо, це призведе до довгострокового, невиявленого порушення безпеки.
Ми щороку закінчуємо термін дії паролів і вимагаємо міцних (бажано випадкових) паролів, довших ніж 10 символів. Ми проводимо напади словників на паролі людей, коли вони змінюють їх. Ми зберігаємо попередні хеші паролів, щоб паролі не могли бути використані повторно. Ми також перевіряємо потенційні дати в паролі, як сказано в vatine. ;) Останнє було моїм доповненням ...
На колишній роботі ми намагалися закінчувати термін дії, частіше, за новим запитом адміністратора мережевої безпеки - кожні два місяці. Через два тижні після першої вимушеної зміни я провів його по наших адміністративних кабінетах, і ми заглянули під клавіатури та клавіатури людей. Більше 50% з них мали пароль, написаний на пості під ним. Він із задоволенням розпустив політику після того, як ми сіли та поговорили з адміністративним персоналом - їх думка полягала в тому, що вони не мають її досить довго запам'ятовувати.
Більшість наших матеріалів сьогодні є одноразовим входом за декілька силосів. Ресурси кампусів (рідко використовуються для більшості людей) знаходяться в одному силосі, і цим паролем керує наша центральна ІТ-група. Ресурсні відомчі (використовуються щодня - авторизація, електронна пошта, редагування веб-сайтів, ксерокс) - це пароль, керований нашою групою, також закінчується щорічно. Якщо люди захоплюються розчаруванням, ми зазначимо, що вони дійсно мають пам’ятати лише один пароль.
Ці дні я генерую md5sum на випадковому файлі в / var / log і використовую підмножину цього для своїх паролів.
Ми багато дискутували з цього приводу пару років тому, коли ми розпочали політику терміну дії пароля. Ми щойно закінчили l0phcract пробіг з веселковими столами проти дерева AD, щоб побачити, як це було погано, і це було досить жахливо. Очевидна кількість користувачів все ще використовувала свій пароль "Температурна допомога" після входу / відмови для скидання пароля, щось жахливе, як 30%, використовувало "пароль" або якийсь варіант як свій пароль (p @ $$ w0rd тощо) . Це переконало керівництво , що це необхідно , щоб відбулося.
Будучи вищим редактором, нам довелося зіткнутися з літа, коли вибирали інтервал. Багато хто з наших викладачів не викладає влітку, тому наша служба технічної допомоги повинна була підготуватися до дзвінків "Я забув пароль", коли всі вони повертаються у вересні. Я думаю, і я можу помилятися, що наш інтервал становить 6 місяців за винятком літньої чверті. Отже, якщо термін дії вашого 6-місячного пароля закінчується в середині серпня, його буде випадково перепрограмовано для скидання в кінці вересня на початку жовтня.
Краще питання - як часто ваші облікові записи та паролі адміністратора змінюються. Занадто часто вони, здається, звільняються від політики зміни пароля. Хто хоче пройти всі ці сценарії для зміни пароля облікового запису утиліти? А деякі системи резервного копіювання ускладнюють зміну використаних паролів, що забезпечує перешкоду змінювати паролі адміністратора.
Однією з головних проблем, пов’язаних із закінченням терміну дії пароля, є те, що люди будуть намагатися запам'ятати їх, тому у вас будуть або люди, які використовують слабкі або подібні паролі, або якщо ваша політика цього не дозволяє, вони почнуть записувати паролі, щоб допомогти їх запам'ятати. . Також у вас буде більше запитів на зміну пароля, коли люди їх забудуть.
Особисто це залежить від того, для чого використовується пароль, але я, як правило, не зберігаю пароль більше 3 місяців, якщо це не повний обліковий запис. Що стосується більш високих ризиків, кожен місяць або близько того є корисним, і викликати заперечні зміни, якщо хтось інший, хто його знає, піде. Оскільки я працюю в невеликому бізнесі з комп'ютерної підтримки, у нас є декілька паролів, які ділиться між багатьма людьми, тому ми не хочемо їх змінювати дуже часто через зриви, які це може спричинити.
Цікаві коментарі поки що. Звичайно, чому завжди дискутується, що запам’ятовування паролів - це технічний, а не нетехнічний персонал у компанії? Що означає чиясь здатність комп'ютерного обладнання та програмного забезпечення пов'язана з їх здатністю сприймати безпеку? Чи видасть нетехнічна особа свою кредитну карту чи дебетові шпильки #? Крім того, люди, які розміщують паролі на пост-записках на своєму столі, повинні бути підставою для звільнення. Дивовижно, як покращиться пам’ять людей, коли вони насправді зрозуміють, що безпека є важливою і її потрібно сприймати серйозно. Я не бачу нічого різного в тому, що роль дрес-кодів та поведінка політики на роботі. Дотримуйтесь правил або до побачення!
Я думаю, що мати більш захищений пароль набагато важливіше, ніж часто змінювати його, але обидва, безумовно, необхідні для безпечної системи.
Аргумент іде, що складні паролі важко запам'ятати, і це призводить до того, що їх працівники записують. Моя переконання з цього приводу полягає в тому, що переважна більшість атак відбувається ззовні , і навіть записування складного пароля та приєднання його до монітора є більш безпечним, ніж запам'ятовування простого пароля.
Я реалізую одноразову аутентифікацію на основі прокладки та часових маркерів, тому, теоретично, кожен раз, коли користувач входить у систему.
Хоча це, мабуть, поза темою, одноразовий килимок здається чудовим рішенням.
Аналогічно, і в основному, гарантування того, що користувач створить надійний пароль, і зрозуміє етику вашої політики безпеки (не записуйте її, не робіть її на день народження, не даруйте нікому) далі, ніж просто примушувати їх змінювати кожен n-й часовий інтервал.