Ліст з паролем даказва вяртальнасць, а не схему захоўвання

Сэрвіс, які дасылае бягучы пароль карыстальніка па пошце, даказаў адно: ён можа атрымаць гэты сакрэт у форме, якую можа адправіць. Ён не даказаў, які слупок, алгарытм ці бібліятэка яго стварылі. Гэтая розніца важная, бо знаходка рэальная, а выснова, якую з яе робяць людзі, звычайна занадта канкрэтная. Вяртальнасць дзесьці на шляху — гэта механізм; а здагадка пра фармат захоўвання — не.

Трымайце доказы на гэтым узроўні, і астатні агляд застанецца дакладным.

Што даказвае вяртанне старога сакрэту

Аднабаковы правяральнік не можа стварыць зыходны пароль, бо ён быў створаны так, каб не быць абарачальным. Калі сэрвіс можа даслаць пароль па пошце, значыць, у гэты момант ён захоўвае матэрыял, з якога пароль можна аднавіць, або перахоплівае і захоўвае адкрыты тэкст да хэшавання. У любым выпадку шлях аднаўлення зваротны, і гэта сапраўдная знаходка бяспекі. Яна нічога не кажа пра тое, ці выкарыстоўвае тая самая база даных дарагі хэш для іншых слупкоў.

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

Чаму гэта знаходка дызайну, а не карта захоўвання

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

Сказаць можна менш, але з большай карысцю: гэты шлях можа аднавіць сакрэт, таму прадукт не можа сцвярджаць, што аднаўляльных уліковых даных не існуе. Усё астатняе патрабуе доказаў аператара.

Будуйце скід вакол аўтарызацыі

Скід вырашае іншую праблему: даказаць, што запытнік можа выбраць новы пароль. Кіраўніцтва OWASP пра гэта апісвае бяспечна згенераваныя аднаразовыя токены або коды з адпаведным тэрмінам прыдатнасці і разглядае этап запыту як тое, што трэба абараняць ад пералічэння і наплыву. Неаўтэнтыфікаваны запыт не павінен змяняць уліковы запіс сам па сабе. Праверце аўтарызацыю перад прыняццем замены і зрабіце токен непрыдатным пасля аднаго паспяховага выкарыстання.

Канал пошты — частка мадэлі бяспекі. Валоданне назвай уліковага запісу нічога не даказвае, а паток скіду, які выкрывае, ці існуе ўліковы запіс, дае зламысніку каталог для працы.

Абясцэньце тое, што абараняў пароль

Змена пароля не спыняе аўтаматычна доступ, які ён даваў. Актыўныя сеансы VPN, запомненыя прылады і токены, выдадзеныя серверам, могуць мець уласныя паводзіны анулявання. Свядома вырашыце, якія з іх мусяць скончыцца, і праверце, што рэалізацыя гэта робіць, бо карыстальнік, які мяркуе, што скід выйшаў яго ўсюды, часта памыляецца. Запішыце гэтае рашэнне разам з патокам.

Для аператараў: дакументуйце, які кампанент правярае запыт, які змяняе ўліковыя даныя і як апрацоўваюцца звязаныя сеансы. Для карыстальнікаў: абараняйце легітымны канал аднаўлення і стаўцеся да любога паведамлення, якое вяртае пароль, з падазрэннем.

Дакладная ацэнка кароткая: што даказвае паведамленне, што застаецца невядомым і ці замяняе аднаўленне доступ праз кантраляваны працэс.