Имејл са лозинком доказује повратност, а не шему

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

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

Шта доказује враћање старе тајне

Једносмерни верификатор не може да произведе изворну лозинку јер је дизајниран тако да не буде инвертибилан. Ако сервис може да пошаље лозинку имејлом, тада у том тренутку држи материјал из којег се лозинка може вратити, или пресреће и чува чист текст пре хеширања. У сваком случају пут опоравка је повратив, и то је стварни безбедносни налаз. То не говори ништа о томе користи ли иста база података скуп хеш за друге ступце.

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

Зашто је то налаз о дизајну, а не мапа складиштења

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

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

Градите ресетовање око ауторизације

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

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

Поништите оно што је лозинка штитила

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

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

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