Gesaan dan konteks
Pengguna yang telah log masuk menghantar alamat e-mel baharu. Perkhidmatan mesti membuktikan kawalan ke atas alamat baharu sambil mengurangkan risiko pengambilalihan akaun akibat sesi yang dicuri, pengenalpastian e-mel (enumeration), klik berulang, dan permintaan serentak. Terangkan model data, kitaran hayat token, pemberitahuan, dasar sesi, had kadar, peristiwa audit, dan laluan pemulihan.
Andaikan bahawa menukar e-mel mempengaruhi log masuk, pemulihan kata laluan, dan notis keselamatan, menjadikannya tindakan akaun berisiko tinggi. Sesi semasa mungkin dicuri, salah satu alamat mungkin tidak dapat diakses buat sementara waktu, dan hanya satu permintaan pertukaran boleh aktif untuk satu akaun.
Perkara yang diuji oleh penemu duga
Penemu duga ingin mendengar perbezaan antara sesi aktif dan identiti yang baru disahkan semula. Jawapan yang kukuh memerlukan pengesahan semula atau kaedah pelbagai faktor sedia ada untuk akaun berisiko tinggi. Mereka mengekalkan alamat yang dicadangkan secara berasingan sehingga pembuktian berjaya.
Mereka juga mencari token rawak sekali guna, jangka hayat pendek, cincangan (digest) token bahagian pelayan, pencegahan ulangan (replay), pemberitahuan ke alamat lama, ralat seragam, dan peristiwa audit. Jawapan yang cemerlang merangkumi pembatalan sesi, pemulihan, dan tak varian untuk kemas kini serentak.
Jawapan 30 saat
“Saya akan mewajibkan pengesahan semula baru-baru ini, dan kaedah MFA sedia ada untuk akaun berisiko lebih tinggi. Saya akan menyimpan alamat yang dicadangkan dalam rekod tertangguh yang berasingan dan bukannya menggantikan alamat semasa. Token rawak sekali guna yang selamat secara kriptografi akan dihantar melalui e-mel ke alamat baharu; pangkalan data hanya menyimpan digest, tujuan, luput, dan status penggunaannya. Transaksi pengesahan mengunci akaun, menyemak digest, tarikh luput, dan versi, kemudian menukar alamat secara atomik dan menghabiskan permintaan tersebut. Alamat lama menerima notis keselamatan dan pilihan pembatalan. Sesi dibatalkan atau dinaikkan tahap pengesahan (stepped up) mengikut risiko. Respons adalah selamat daripada enumerasi, permintaan dihadkan kadar, dan peristiwa audit tidak sekali-kali mengandungi token.”
Analisis mendalam langkah demi langkah
Langkah 1: Modelkan akaun dan permintaan tertangguh
Kekalkan current_email pada akaun dan simpan rekod pending_email_change yang berasingan yang mengandungi ID akaun, alamat cadangan yang dinormalkan, digest token, tujuan, luput, status, versi, masa penciptaan, dan konteks risiko sesi yang memulakannya. Sehingga pembuktian berjaya, nilai yang dicadangkan tidak boleh menjejaskan log masuk atau pemulihan.
Langkah 2: Sahkan semula dan tetapkan sempadan risiko
Log masuk yang aktif hanya membuktikan bahawa sesi tersebut diterima. Wajibkan semakan kata laluan terkini atau faktor MFA sedia ada, dan pertimbangkan isyarat peranti, IP, dan anomali. Mengetahui alamat baharu tidak membuktikan identiti semasa. Hasil peningkatan pengesahan (step-up) mestilah berjangka hayat pendek dan bertujuan tunggal, bukan kelayakan universal yang kekal.
Langkah 3: Jana dan hantar token sekali guna
Gunakan penjana rawak yang selamat secara kriptografi, TTL yang pendek, dan satu tujuan. Simpan hanya digest satu hala dalam pangkalan data; pautan e-mel membawa token mentah. Mesej tersebut tidak boleh mendedahkan sama ada akaun wujud atau tidak. Penghantaran semula dihadkan kadar dan membatalkan token yang lebih lama. Token yang telah digunakan, tamat tempoh, atau digantikan tidak boleh digunakan semula.
Langkah 4: Sahkan dan lakukan komit secara atomik
Semasa pengesahan, lakukan pemeriksaan format dan kadar, kemudian kunci akaun dan baris tertangguh dalam satu transaksi. Bandingkan digest dalam masa malar (constant time) dan periksa status, TTL, tujuan, dan versi. Kuatkuasakan keunikan alamat baharu dalam transaksi yang sama, kemas kini e-mel semasa secara atomik, gunakan (consume) permintaan tersebut, dan tambahkan peristiwa audit. Klik pendua mengembalikan hasil idempoten atau hasil selamat yang telah diproses tanpa mengulangi kesan sampingan.
Langkah 5: Kendalikan alamat lama, sesi, dan notis
Hantar notis keselamatan ke alamat lama dan benarkan pembatalan sementara permintaan masih dalam status tertangguh. Jika berjaya, batalkan token penyegar (refresh token) yang berjangka hayat panjang atau wajibkan sesi lain untuk mengesahkan semula; akaun berisiko tinggi mungkin memerlukan pembatalan global serta-merta. Alamat baharu tidak boleh menjadi satu-satunya bukti pemulihan serta-merta.
Langkah 6: Kawal enumerasi, penyalahgunaan, dan keadaan perlumbaan
Gunakan masa pemprosesan dan mesej yang seragam untuk titik akhir permintaan dan pengesahan, supaya penyerang tidak dapat mengetahui sama ada alamat telah didaftarkan. Hadkan kadar mengikut akaun, alamat sasaran, peranti, dan rangkaian. Kekangan keunikan serta penguncian baris atau kemas kini versi bersyarat menghalang dua permintaan daripada berjaya serentak; semakan kependudukan dan penulisan berkongsi satu sempadan transaksi.
Langkah 7: Reka bentuk pemulihan dan kes tidak tersedia
Benarkan penghantaran semula terhad untuk kelewatan penghantaran sambil membatalkan token lama. Jika alamat lama hilang, jangan terima alamat baharu yang belum disahkan sebagai bukti pengambilalihan yang mencukupi; gunakan proses pemulihan akaun yang lebih kukuh. Kegagalan penghantaran, alamat yang telah digunakan, dan penolakan dasar harus memaparkan mesej yang selamat sambil mengekalkan kod sebab dalaman dalam rekod audit.
Langkah 8: Uji ancaman dan ukur hasil
Uji sesi yang dicuri, ulangan dan luput token, pengesahan serentak, pembatalan melalui alamat lama, pembatalan refresh token, pemilikan alamat merentas akaun, dan enumerasi titik akhir. Ukur kegagalan pengesahan lanjutan, percubaan ulangan, kependaman dari pengesahan ke pembatalan, penghantaran pemberitahuan, dan volum pemulihan manual. Ujian kebocoran pangkalan data harus menunjukkan bahawa digest yang disimpan tidak boleh digunakan sebagai token.
Pertukaran (Trade-offs), sempadan, dan perolehan maklumat
TTL yang pendek mengurangkan pendedahan risiko tetapi meningkatkan tekanan penghantaran semula apabila mel tertangguh; penghantaran semula yang terhad dan status yang jelas mengimbangi kedua-duanya. Membatalkan setiap sesi adalah lebih selamat tetapi mengganggu pelbagai peranti, jadi tahap risiko boleh memilih skopnya. Tempoh pembatalan alamat lama meningkatkan pemulihan tetapi tidak boleh membatalkan pertukaran berisiko tinggi yang telah selesai.
Penyimpanan digest sahaja melindungi daripada pendedahan pangkalan data, tetapi token mentah masih boleh bocor melalui pautan, sejarah pelayar, log, penjejakan, dan analitik. Tapis laluan tersebut dan lakukan pengalihan selepas penggunaan ke URL yang bersih. Kekangan keunikan memudahkan pemilikan identiti, tetapi produk mesti mentakrifkan sama ada satu alamat boleh dimiliki oleh beberapa akaun.
Contoh jawapan berkualiti tinggi
“Saya akan menganggap pertukaran e-mel sebagai mesin keadaan (state machine) berisiko tinggi. Pengguna melengkapkan pengesahan semula baru-baru ini dan, apabila diperlukan, semakan MFA sedia ada. Alamat yang dicadangkan dimasukkan ke dalam rekod tertangguh; alamat semasa kekal berwibawa untuk log masuk dan pemulihan. CSPRNG menghasilkan token sekali guna dengan TTL pendek, manakala pangkalan data hanya menyimpan digest, tujuan, versi, dan statusnya.
Transaksi pengesahan mengunci akaun dan permintaan, menyemak digest, tarikh luput, versi, dan kekangan keunikan, kemudian mengemas kini alamat secara atomik, menghabiskan permintaan, dan merekodkan peristiwa audit. Alamat lama menerima notis keselamatan dan boleh membatalkan permintaan yang masih tertangguh. Selepas berjaya, refresh token dibatalkan dan sesi lain dinaikkan semula tahap pengesahan mengikut risiko.
Semua titik akhir menggunakan ralat seragam dan had kadar mengikut akaun, sasaran, dan rangkaian. Log mengandungi kod sebab dan bukannya token. Ulangan, keadaan perlumbaan, kehilangan peti mel lama, dan kegagalan penghantaran masing-masing mempunyai laluan pemulihan yang ditetapkan, dan ujian mengukur kelupaan token, kependaman pembatalan, serta ketahanan terhadap enumerasi.”
Kesilapan biasa
- Menggantikan alamat semasa penyerahan borang. Alamat yang belum terbukti boleh menyekat pengguna sebenar atau membiarkan sesi yang dicuri mengambil alih.
- Mempercayai sesi sedia ada semata-mata. Pencuri sesi boleh menyelesaikan tindakan berisiko tinggi.
- Menyimpan token mentah dalam pangkalan data atau log. Sistem tersebut menjadi laluan pengambilalihan akaun.
- Membenarkan penggunaan semula token. Serangan ulangan boleh mengulangi pemberitahuan atau menulis ganti alamat.
- Mendedahkan kewujudan alamat. Respons pengesahan dan permintaan menjadi orakel enumerasi.
- Mengabaikan perlumbaan keunikan. Dua akaun atau permintaan mungkin menuntut alamat yang sama.
- Mengekalkan semua sesi jangka panjang selepas berjaya. Refresh token yang dicuri kekal boleh digunakan.
- Mempercayai alamat baharu apabila alamat lama hilang. Ini memintas jaminan pemulihan akaun.
Soalan susulan dan jawapan
Mengapa tidak menulis alamat baharu dahulu dan mengesahkannya secara tak segerak (asynchronously)?
Log masuk, pemulihan, dan notis mungkin menggunakannya serta-merta, manakala pembalikan (rollback) memperkenalkan keadaan perlumbaan. Nilai tertangguh yang berasingan mengekalkan input yang belum disahkan di luar sempadan identiti.
Berapa lamakah jangka hayat token sepatutnya?
Tiada angka yang bebas daripada risiko. Pilih tempoh masa yang singkat berdasarkan taburan penghantaran dan matlamat ancaman, tambahkan penghantaran semula yang terhad, dan ukur tingkah laku pengeluaran-hingga-luput yang sebenar.
Bolehkah notis alamat lama menggantikan MFA?
Tidak. Notis dan pembatalan adalah pertahanan mendalam (defense-in-depth) dan isyarat pemulihan, bukan bukti identiti dengan jaminan tinggi. Akaun berisiko tinggi masih memerlukan kaedah MFA sedia ada atau pemulihan yang lebih kukuh.
Bagaimana jika dua tab mengesahkan secara serentak?
Gunakan versi, keadaan sekali guna, dan kunci transaksi supaya hanya satu permintaan bertukar daripada tertangguh kepada digunakan. Permintaan kedua mengembalikan hasil idempoten dan tidak melakukan kesan sampingan pendua.
Bagaimanakah anda menghalang token daripada masuk ke dalam analitik?
Gunakan laluan sekali guna, tapis parameter pertanyaan pada lapisan pinggir (edge) dan aplikasi, lakukan pengalihan selepas penggunaan ke URL yang bersih, dan nyahdayakan pengesahan caching untuk respons sensitif.