Лист із паролем доводить оборотність, а не схему зберігання

Сервіс, який надсилає поточний пароль користувача електронною поштою, довів одну річ: він може отримати цей секрет у формі, яку здатен надіслати. Він не довів, який стовпець, алгоритм чи бібліотека його створили. Ця різниця важлива, бо знахідка реальна, а висновок, який з неї роблять, зазвичай надто конкретний. Оборотність десь на шляху — це механізм; припущений формат зберігання — ні.

Тримайте докази на цьому рівні, і решта огляду залишиться точною.

Що доводить повернення старого секрету

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

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

Чому це знахідка про проєктування, а не карта зберігання

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

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

Будуйте скидання навколо авторизації

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

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

Анулюйте те, що захищав пароль

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

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

Точна оцінка коротка: що доводить повідомлення, що залишається невідомим і чи замінює відновлення доступ через контрольований процес.