Surel kata sandi membuktikan keterbalikan, bukan skema

Layanan yang mengirim kata sandi pengguna saat ini lewat surel telah membuktikan satu hal: ia dapat memperoleh rahasia itu dalam bentuk yang dapat dikirimnya. Ia tidak membuktikan kolom, algoritme, atau pustaka mana yang menghasilkannya. Perbedaannya penting karena temuannya nyata dan kesimpulan yang orang ambil darinya biasanya terlalu spesifik. Keterbalikan di suatu titik pada jalur adalah mekanismenya; format penyimpanan yang diduga bukan.

Pertahankan bukti pada tingkat itu, dan sisa tinjauan tetap akurat.

Apa yang dibuktikan oleh pengiriman kembali rahasia lama

Verifikator satu arah tidak dapat menghasilkan kata sandi asli, karena ia dirancang untuk tidak dapat dibalik. Jika layanan dapat mengirim kata sandi lewat surel, maka pada saat itu ia menyimpan materi yang darinya kata sandi dapat dipulihkan, atau ia menyadap dan menyimpan teks polos sebelum hashing. Bagaimanapun, jalur pemulihannya dapat dibalik, dan itu temuan keamanan yang nyata. Itu tidak mengatakan apa pun tentang apakah basis data yang sama memakai hash yang mahal untuk kolom lain.

Perhatikan juga kasus perantaranya: blob terenkripsi yang disimpan dengan kunci yang dipegang aplikasi dapat dibalik dalam praktik, meskipun kata terenkripsi terdengar menenangkan dalam laporan.

Mengapa ini temuan desain, bukan peta penyimpanan

Surel membuktikan keterpulihan dan tidak mengidentifikasi skema persisnya. Bisa jadi teks polos, enkripsi deterministik, rutinitas pengaburan dari vendor, atau penyimpanan kredensial terpisah yang hanya dipakai untuk pemulihan. Bagian berbeda dari suatu produk sering memakai penyimpanan berbeda. Menetapkan algoritme berdasarkan satu surel adalah jenis klaim yang runtuh dalam rapat lanjutan.

Yang dapat Anda katakan lebih sempit dan lebih berguna: jalur ini dapat memulihkan rahasia itu, jadi produk tidak dapat mengklaim bahwa tidak ada kredensial yang dapat dipulihkan. Segala hal di luar itu membutuhkan bukti dari operator.

Bangun pengaturan ulang di sekitar otorisasi

Pengaturan ulang menyelesaikan masalah lain: membuktikan bahwa pemohon berhak memilih kata sandi baru. Panduan OWASP tentang hal ini menjelaskan token atau kode sekali pakai yang dibuat dengan aman dan masa berlaku yang memadai, serta memperlakukan tahap permintaan sebagai sesuatu yang harus dilindungi dari enumerasi dan banjir permintaan. Permintaan yang tidak terautentikasi tidak boleh mengubah akun dengan sendirinya. Validasi otorisasi sebelum menerima penggantinya, dan buat token tidak dapat dipakai setelah satu penggunaan berhasil.

Kanal surel adalah bagian dari model keamanan. Memiliki nama akun tidak membuktikan apa pun, dan alur pengaturan ulang yang mengungkap apakah suatu akun ada memberi penyerang direktori untuk dijadikan dasar kerja.

Batalkan apa yang dilindungi kata sandi

Mengubah kata sandi tidak otomatis mengakhiri akses yang diberikannya. Sesi VPN aktif, perangkat yang diingat, dan token yang diterbitkan server dapat memiliki perilaku pembatalannya masing-masing. Putuskan dengan sengaja mana yang harus berakhir, dan pastikan implementasinya melakukannya, karena pengguna yang menganggap pengaturan ulang telah mengeluarkannya dari semua tempat sering keliru. Catat keputusan itu bersama alurnya.

Untuk operator: dokumentasikan komponen mana yang memverifikasi permintaan, mana yang mengubah kredensial, dan bagaimana sesi terkait ditangani. Untuk pengguna: lindungi kanal pemulihan yang sah dan perlakukan setiap pesan yang mengembalikan kata sandi sebagai mencurigakan.

Penilaian yang tepat itu singkat: apa yang dibuktikan pesan itu, apa yang tetap tidak diketahui, dan apakah pemulihan menggantikan akses melalui proses yang terkendali.