Инциденты с паролями

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


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


Но прежде чем говорить о решении споров, нужно создать закон, по которому будут решать. Каким критериям должна отвечать парольная политика? На какие ментальные усилия со стороны пользователя можно рассчитывать? Какие требования разумны, а какие – излишни? Среди RFC и стандартов ITU подобные документы вашему покорному слуге не попадались. При этом за такой "парольной конституцией" должен стоять авторитет известной и представительной организации.

К примеру, информационная система предусматривает обязательную смену пароля раз в три месяца. Пользователь их менял и записывал в особую книжечку (запомнить – нереально). Книжечка как-то раз закончилась. Он записал где попало и потерял. Обе стороны виноватят друг друга в этом инциденте. Принципы парольной политики должны нам дать ответ: была ли принятая политика адекватной; следовало ли рассчитывать на память пользователя или объём его блокнота? Отсюда и станет понятно, кто больше виноват.

А убытки от такого инцидента бывают шестизначные.

Telegram AMПодписывайтесь на канал "Anti-Malware" в Telegram, чтобы первыми узнавать о новостях и эксклюзивных материалах по информационной безопасности.

RSS: Новое в блогах на Anti-Malware.ru Новое в блогах