Е-поштата со лозинка докажува повратност, а не шема

Услугата што ја испраќа тековната лозинка на корисникот по е-пошта докажа едно: може да ја добие таа тајна во форма што може да ја испрати. Но не докажа која колона, алгоритам или библиотека ја создаде. Разликата е важна зашто наодот е вистински, а заклучокот што луѓето го извлекуваат од него обично е премногу конкретен. Повратноста некаде на патот е механизмот; претпоставениот формат на чување не е.

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

Што докажува враќањето на старата тајна

Еднонасочниот проверувач не може да ја создаде оригиналната лозинка, зашто е дизајниран да не биде инвертибилен. Ако услугата може да ја испрати лозинката по е-пошта, тогаш во тој момент држи материјал од кој лозинката може да се врати, или го пресретнува и го чува чистиот текст пред хеширањето. Во секој случај патот на враќање е повратлив, и тоа е вистински безбедносен наод. Тоа не кажува ништо за тоа дали истата база на податоци користи скап хеш за други колони.

Обрнете внимание и на средниот случај: зачуван шифриран блок со клуч што го држи апликацијата е повратлив во практиката, иако зборот шифриран звучи смирувачки во извештај.

Зошто тоа е наод за дизајнот, а не карта на чувањето

Е-поштата докажува вратливост и не ја идентификува точната шема. Може да биде чист текст, детерминистичко шифрирање, рутина за замаглување од добавувач или одделно складиште на акредитиви што се користи само за враќање. Различни делови од производот често користат различно чување. Да се припише алгоритам врз основа на една е-пошта е вид тврдење што се распаѓа на следниот состанок.

Она што можете да го кажете е потесно и покорисно: овој пат може да ја врати тајната, па производот не може да тврди дека нема вратливи акредитиви. Сето останато над тоа бара докази од операторот.

Изградете го ресетирањето околу авторизацијата

Ресетирањето решава друг проблем: да се докаже дека барателот смее да избере нова лозинка. Упатството на OWASP за ова опишува безбедно генерирани токени или кодови за еднократна употреба со соодветен рок на важност и ја третира фазата на барање како нешто што треба да се заштити од набројување и преплавеност. Неавтентифицирано барање не смее само по себе да го промени сметачкиот профил. Проверете ја авторизацијата пред да ја прифатите замената и направете го токенот неупотреблив по една успешна употреба.

Каналот за е-пошта е дел од безбедносниот модел. Поседувањето име на профил не докажува ништо, а текот на ресетирање што открива дали профилот постои му дава на напаѓачот именик со кој да работи.

Оневозможете го она што лозинката го штитеше

Промената на лозинка не го прекинува автоматски пристапот што го дала. Активните VPN сесии, запаметените уреди и токените што ги издава серверот може секој да има сопствено однесување при оневозможување. Одлучете свесно кои од нив мора да завршат и проверете дали имплементацијата го прави тоа, зашто корисникот што претпоставува дека ресетирањето го одјавило насекаде често греши. Запишете ја таа одлука заедно со текот.

За операторите: документирајте која компонента го проверува барањето, која ги менува акредитивите и како се ракуваат поврзаните сесии. За корисниците: заштитете го легитимниот канал за враќање и третирајте секоја порака што враќа лозинка како сомнителна.

Точната проценка е кратка: што докажува пораката, што останува непознато и дали враќањето го заменува пристапот преку контролиран процес.