Ketika email akses akun datang terlambat, pengguna sering kali meminta beberapa email lagi. Hal ini dapat membuat pesan duplikat, jendela validitas yang membingungkan, dan beban antrian tambahan. Diagnosis perjalanan dari permintaan hingga penggunaan yang berhasil sebelum menyalahkan DNS atau memperpanjang masa pakai setiap token.
Buat garis waktu acara yang telah disunting
Gunakan pengidentifikasi korelasi internal untuk menggabungkan permintaan yang diterima, token dibuat, antrian pekerjaan, penyedia diterima, respons penerima, dan token ditukarkan atau ditolak. Jangan letakkan token, reset URL, atau OTP di log rutin. Catat pengidentifikasi dan kategori alasan dengan akses sangat terbatas ke sampel pesan apa pun yang diperlukan untuk pemecahan masalah.
Penerimaan SMTP berarti server telah menerima tanggung jawab pada tahap tersebut; itu tidak menunjukkan penempatan kotak masuk atau manusia membaca pesan tersebut. Pertahankan perbedaan itu dalam peralatan pendukung. RFC 5321.
Panduan pencatatan OWASP mendukung korelasi sambil mengecualikan rahasia dari log rutin.
Pisahkan otentikasi dari validitas aplikasi
Periksa pesan akhir yang dikontrol untuk identitas pengirim yang dituju dan hasil autentikasi penerima tepercaya. Konfigurasi vendor yang sudah ketinggalan zaman dapat memutus rute ini bahkan saat buletin berfungsi. Sebaliknya, meneruskan autentikasi email tidak dapat membuat token aplikasi yang kedaluwarsa atau sudah digunakan menjadi valid.
OWASP merekomendasikan token atau kode sekali pakai yang dihasilkan secara aman dengan masa berlaku yang sesuai, penyimpanan yang aman, dan perlindungan terhadap penghitungan akun dan permintaan yang berlebihan. Panduan pengaturan ulang kata sandinya memberikan dasar keamanan untuk alur pengaturan ulang, bukan janji tentang latensi pengiriman email. Panduan Lupa Kata Sandi OWASP.
Kode yang dikirimkan melalui email untuk penggunaan autentikasi lainnya memerlukan penilaian keamanannya sendiri. Jangan menggambarkan kepemilikan email sebagai autentikasi yang tahan terhadap phishing, dan jangan menganggap rekomendasi pengaturan ulang kata sandi menyetujui setiap penerapan OTP. Dalam persyaratan identitas digitalnya, NIST melarang email sebagai pengautentikasi out-of-band sambil membedakan kode konfirmasi alamat dan pemulihan dari larangan tersebut. NIST SP 800-63B-4 bagian 3.1.3 dan 3.1.3.1.
Kerjakan anggaran validitas
Garis waktu hipotetis menetapkan pembuatan token pada 09:00:00 dan kedaluwarsa pada 09:05:00 . Penerimaan penyedia terjadi pada 09:00:10 , penerimaan penerima pada 09:04:40 dan ilustrasi tindakan pengguna pada 09:05:20 . Hanya tersisa 20 detik pada penerimaan penerima; tindakan terjadi 20 detik setelah kedaluwarsa.
Berdasarkan kebijakan yang dinyatakan bahwa token tidak valid pada atau setelah masa berlakunya habis, token valid yang belum digunakan dan disajikan pada detik 299 akan tetap berada dalam jangka waktu lima menit ini, sedangkan presentasi pada detik 300 atau 301 tidak akan berlaku. Token yang sudah ditukarkan tidak boleh digunakan kembali hanya karena masih ada waktu. Ini adalah hasil yang diharapkan berdasarkan kebijakan yang dibuat, bukan pemeriksaan token yang dilaksanakan atau masa hidup universal yang direkomendasikan.
Pertanyaan yang bisa ditindaklanjuti adalah ke mana perginya 280 detik antara pembuatan dan penerimaan penerima. Penerimaan penyedia pada 10 detik tidak membuktikan bahwa 270 detik berikutnya dihabiskan seluruhnya di dalam satu penyedia; mendapatkan bukti antrian dan respons sebelum menugaskan tanggung jawab. Visibilitas kotak masuk masih belum diketahui. Tidak ada token nyata, akun produksi, atau pengiriman yang diuji.
Perbaiki tahap yang gagal
Jika aplikasi mengantri terlalu lambat, prioritaskan beban kerja akses akun dan hilangkan penundaan batch yang dapat dihindari. Jika penyedia melaporkan kegagalan sementara, periksa respons lengkap dan dukungan penanganan percobaan ulang. Jika token tidak valid karena permintaan yang lebih baru, buatlah perilaku tersebut dapat dimengerti tanpa memperlihatkan apakah suatu akun ada kepada peminta yang tidak diautentikasi.
Gunakan batas kapasitas dan respons permintaan umum yang jelas untuk mencegah klik berulang menjadi banjir email. Rekonsiliasi percobaan ulang dengan kebijakan token aplikasi. Mengirim ulang pesan lama secara membabi buta dapat mengirimkan token yang sudah tidak valid, sementara menerbitkan token baru tanpa batas dapat meningkatkan risiko penyalahgunaan.
Verifikasi tanpa mencatat rahasia
Uji akun terkontrol yang disetujui di seluruh tujuan yang relevan dan catat latensi tahap, hasil kedaluwarsa, dan penanganan duplikat. Setiap perubahan pada masa berlaku, pembuatan token, atau pemulihan akun memerlukan tinjauan keamanan; memperpanjang masa pakai bukanlah pengganti untuk memperbaiki antrian.
Tutup insiden dengan penyebab spesifik tahapan, cakupan remediasi, dan perjalanan pelanggan yang terukur. Jaga agar kesenjangan visibilitas yang tersisa tetap jelas. Dukungan harus dapat menjelaskan “diterima oleh penerima, masa validitas telah habis” tanpa mengklaim bahwa pelanggan telah membaca pesan atau mengungkapkan kredensial mereka.
Pilih pemilik dari tahap gagal
Keterlambatan antrian menjadi tanggung jawab aplikasi atau operator pengirim; penolakan penerimaan yang jelas termasuk dalam penyelidikan rute; hasil yang kedaluwarsa atau sudah digunakan termasuk dalam kebijakan token dan status aplikasi. Simpan satu catatan korelasi yang telah disunting dan mintalah pemilik terkait menentukan pengujian ulang yang disetujui.