Şifrə e-poçtu geri qaytarıla bilməni sübut edir, sxemi yox

İstifadəçinin cari şifrəsini e-poçtla göndərən xidmət bir şeyi sübut etdi: o, bu sirri göndərə biləcəyi formada əldə edə bilir. Lakin onu hansı sütunun, alqoritmin və ya kitabxananın yaratdığını sübut etmədi. Bu fərq vacibdir, çünki tapıntı realdır və insanların ondan çıxardığı nəticə adətən lazım olduğundan daha konkretdir. Yolda hansısa yerdə geri çevrilmə mexanizmdir; təxmin edilən saxlama formatı isə deyil.

Sübutları bu səviyyədə saxlayın və baxışın qalan hissəsi dəqiq qalır.

Köhnə sirrin geri göndərilməsi nəyi sübut edir

Birtərəfli yoxlayıcı orijinal şifrəni yarada bilməz, çünki o, geri çevrilməyəcək şəkildə dizayn edilib. Əgər xidmət şifrəni e-poçtla göndərə bilirsə, deməli o anda şifrənin bərpa oluna biləcəyi materialı saxlayır və ya açıq mətni tutub heşləmədən əvvəl saxlayır. Hər iki halda bərpa yolu geri çevriləndir və bu, həqiqi təhlükəsizlik tapıntısıdır. Bu, eyni verilənlər bazasının digər sütunlar üçün bahalı heş istifadə edib-etmədiyi barədə heç nə demir.

Aralıq halı da nəzərə alın: tətbiqin saxladığı açarla saxlanılan şifrələnmiş blok praktikada geri çevriləndir, hərçənd şifrələnmiş sözü hesabatda təskinlik verici səslənir.

Niyə bu dizayn tapıntısıdır, saxlama xəritəsi deyil

E-poçt bərpa oluna bilməni sübut edir və dəqiq sxemi müəyyən etmir. Bu, açıq mətn, deterministik şifrələmə, təchizatçının gizlətmə rutini və ya yalnız bərpa üçün istifadə olunan ayrı etimad məlumatları anbarı ola bilər. Məhsulun müxtəlif hissələri çox vaxt fərqli saxlama istifadə edir. Bir e-poçta əsaslanaraq alqoritm təyin etmək, növbəti görüşdə dağılan iddia növüdür.

Deyə biləcəyiniz daha dar və daha faydalıdır: bu yol sirri bərpa edə bilir, ona görə məhsul bərpa oluna bilən etimad məlumatı olmadığını iddia edə bilməz. Bundan sonrası operatorun sübutlarını tələb edir.

Sıfırlamanı avtorizasiya ətrafında qurun

Sıfırlama başqa bir problemi həll edir: sorğu göndərənin yeni şifrə seçə biləcəyini sübut etmək. OWASP-ın bu barədə təlimatı təhlükəsiz yaradılan, bir dəfəlik istifadə olunan tokenləri və ya kodu müvafiq bitmə müddəti ilə təsvir edir və sorğu mərhələsini sadalama və sel basqınına qarşı qorunmalı bir şey kimi qəbul edir. Doğrulanmamış sorğu hesabı tək başına dəyişməməlidir. Əvəzləməni qəbul etməzdən əvvəl avtorizasiyanı yoxlayın və tokendən bir uğurlu istifadədən sonra yararsız hala gətirin.

E-poçt kanalı təhlükəsizlik modelinin bir hissəsidir. Hesab adına sahib olmaq heç nəyi sübut etmir və hesabın mövcud olub-olmadığını açan sıfırlama axını hücumçuya işləyəcəyi bir bələdçi verir.

Şifrənin qoruduğunu etibarsız edin

Şifrənin dəyişdirilməsi onun verdiyi girişi avtomatik bitirmir. Aktiv VPN seansları, yadda saxlanılan cihazlar və serverin verdiyi tokenlər hər birinin öz etibarsızlaşdırma davranışı ola bilər. Onlardan hansının bitməli olduğunu qəsdən qərarlaşdırın və tətbiqin bunu etdiyini yoxlayın, çünki sıfırlamanın onu hər yerdən çıxardığını güman edən istifadəçi çox vaxt yanılır. Bu qərarı axınla birlikdə qeyd edin.

Operatorlar üçün: sorğunu hansı komponentin yoxladığını, etimad məlumatını hansının dəyişdirdiyini və əlaqəli seansların necə idarə olunduğunu sənədləşdirin. İstifadəçilər üçün: qanuni bərpa kanalını qoruyun və şifrə qaytaran hər hansı mesaja şübhəli kimi yanaşın.

Dəqiq qiymətləndirmə qısadır: mesaj nəyi sübut edir, nə naməlum qalır və bərpa girişi nəzarət olunan proseslə əvəz edirmi.