Имейл с парола доказва обратимост, а не схема за съхранение

Услуга, която изпраща текущата парола на потребителя по имейл, е доказала едно нещо: тя може да се сдобие с тази тайна във вид, който може да изпрати. Тя не е доказала коя колона, алгоритъм или библиотека са я създали. Разликата е важна, защото констатацията е истинска, а изводът, който хората правят от нея, обикновено е прекалено конкретен. Обратимост някъде по пътя е механизмът; предполагаем формат на съхранение не е.

Дръжте доказателствата на това ниво и останалата част от прегледа остава точна.

Какво доказва връщането на старата тайна

Еднопосочният верификатор не може да създаде оригиналната парола, защото е проектиран да не бъде обратим. Ако услугата може да изпрати паролата по имейл, то в този момент тя държи материал, от който паролата може да бъде възстановена, или прихваща и съхранява открития текст преди хеширането. И в двата случая пътят за възстановяване е обратим и това е истинска констатация за сигурността. Тя не казва нищо за това дали същата база данни използва скъп хеш за други колони.

Обърнете внимание и на междинния случай: съхранен криптиран блок с ключ, държан от приложението, е обратим на практика, дори думата криптиран да звучи успокоително в доклад.

Защо това е констатация за дизайна, а не карта на съхранението

Имейлът доказва възстановимост и не посочва точната схема. Тя може да е открит текст, детерминирано криптиране, рутина за затъмняване на доставчик или отделно хранилище за идентификационни данни, използвано само за възстановяване. Различните части на един продукт често използват различно съхранение. Да припишеш алгоритъм въз основа на един имейл е видът твърдение, което се разпада на следващата среща.

Това, което можете да кажете, е по-тясно и по-полезно: този път може да възстанови тайната, така че продуктът не може да твърди, че не съществуват възстановими идентификационни данни. Всичко останало изисква доказателствата на оператора.

Изградете нулирането около оторизацията

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

Имейл каналът е част от модела за сигурност. Притежаването на име на профил не доказва нищо, а поток за нулиране, който разкрива дали профил съществува, дава на нападателя указател, по който да работи.

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

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

За операторите: документирайте кой компонент проверява заявката, кой променя идентификационните данни и как се обработват свързаните сесии. За потребителите: защитавайте законния канал за възстановяване и третирайте всяко съобщение, което връща парола, като подозрително.

Точната оценка е кратка: какво доказва съобщението, какво остава неизвестно и дали възстановяването заменя достъпа чрез контролиран процес.