Temu Duga Backend: Mereka Bentuk Aliran Penetapan Semula Kata Laluan yang Selamat

Gesaan dan Konteks Berkenaan

Reka bentuk aliran penetapan semula kata laluan pautan e-mel layan diri untuk aplikasi web pengguna. API permintaan menerima alamat e-mel dan, apabila akaun sepadan, menghantar pautan HTTPS yang mengandungi token legap. Token tamat tempoh 30 minit selepas penciptaan. Pangkalan data tidak boleh sesekali menyimpan token pembawa mentah.

Reka bentuk ini mesti menghalang pemanggil yang tidak disahkan daripada mengetahui sama ada sesuatu e-mel telah didaftarkan, membanjiri satu peti masuk, memainkan semula pautan yang telah digunakan, menukar kata laluan pengguna lain, atau memenangi perlumbaan dengan penghantaran penetapan semula yang kedua. Penetapan semula yang berjaya akan menukar kata laluan, membatalkan setiap token penetapan semula yang masih aktif untuk akaun tersebut, membatalkan sesi sedia ada yang telah disahkan, dan mengeluarkan pemberitahuan keselamatan. Penetapan semula kata laluan tidak membuang atau menggantikan pengesah MFA yang telah didaftarkan.

Ini terutamanya soalan keselamatan dan ketekalan backend. Jawapan yang mantap menghubungkan model ancaman kepada kontrak API, kitaran hayat token, transaksi pangkalan data, penghantaran e-mel, model sesi, dan bukti operasi. Menyebut token rawak dan masa tamat tempoh hanyalah permulaan; bahagian yang sukar ialah memastikan setiap laluan yang boleh diperhatikan dan serentak mematuhi kontrak keselamatan yang sama.

Perkara yang Dinilai oleh Penemu Duga

Isyarat pertama ialah pemodelan ancaman. Calon harus mengenal pasti penghitungan akaun, pengeboman e-mel penetapan semula (reset-email bombing), suntikan pengepala Host, kebocoran URL, tekaan token, pendedahan pangkalan data, serangan ulang pautan, pengubahsuaian klien, penggunaan serentak, sesi yang dicuri, dan pintasan MFA. Setiap ancaman harus dipetakan kepada kawalan khusus dan bukannya dakwaan generik bahawa titik akhir tersebut adalah selamat.

Isyarat kedua ialah perbezaan antara token mentah dan pengesah (verifier) yang disimpan. E-mel tersebut mengandungi rahsia pembawa berentropi tinggi. Pangkalan data hanya menyimpan ringkasan (digest) sehala, jadi membaca jadual token tidak mendedahkan pautan yang boleh digunakan secara langsung. Calon juga harus membezakan token rawak ini daripada kata laluan manusia: kata laluan yang dipilih oleh pengguna memerlukan cincangan kata laluan yang perlahan, manakala token rawak 256-bit yang seragam boleh diindeks oleh ringkasan kriptografi yang pantas tanpa menjadikannya mudah diteka.

Isyarat ketiga ialah reka bentuk transaksi. Menyemak used_at dalam kod aplikasi dan mengemas kininya kemudian mewujudkan perlumbaan serangan ulang. Dua token sah yang berbeza untuk pengguna yang sama mewujudkan satu lagi perlumbaan melainkan akaun tersebut menjadi titik penyirikan (serialization point). Jawapan yang kukuh mengunci baris pengguna, menggunakan token yang diberikan secara bersyarat, menukar kata laluan, membatalkan token dan sesi saudara (sibling), serta merekodkan peristiwa outbox di dalam satu transaksi pendek.

Isyarat keempat ialah pertimbangan sempadan pemulihan. Menetapkan semula kata laluan yang terlupa bukanlah kebenaran untuk menyahdayakan MFA atau menggantikan faktor kedua yang hilang. Pemulihan akaun dengan jaminan lebih tinggi memerlukan laluan pembuktian yang direka secara berasingan. Jawapan tersebut juga harus menolak soalan keselamatan sebagai mekanisme pemulihan tunggal dan mengelakkan penghantaran kata laluan lama atau kata laluan yang baru dijana melalui e-mel.

Isyarat terakhir ialah pemikiran operasi. Respons generik tidak berkesan jika masa, tingkah laku had kadar (rate-limit), log, analitis, atau alatan sokongan masih mendedahkan kewujudan akaun atau token mentah. Penghantaran e-mel mesti dapat bertahan daripada kegagalan pembekal tanpa mengubah akaun secara pramatang, dan pemantauan mesti mengesan penyalahgunaan tanpa menyimpan rahsia pembawa di dalam log.

Soalan untuk Dijelaskan Sebelum Menjawab

• Adakah ini penggantian kata laluan atau pemulihan akaun sepenuhnya? Jika pengguna masih mempunyai e-mel yang disahkan

tetapi hanya kehilangan kata laluan, pautan tersebut boleh menggantikan kata laluan itu. Kehilangan akses e-mel, MFA, dan kod pemulihan memerlukan proses pemulihan yang lebih kukuh dan berasingan.

• Adakah akaun tersebut menggunakan MFA? Penetapan semula kata laluan harus membiarkan faktor yang didaftarkan kekal utuh. Jika produk

mahu satu aliran untuk memulihkan kedua-duanya, keperluan jaminan dan semakan penyalahgunaannya akan berubah secara ketara.

• Sesi manakah yang mesti dibatalkan? Gesaan ini membatalkan semua sesi. Mengekalkan peranti yang memulakan proses untuk kekal

didaftarkan masuk memerlukan bukti bahawa ia telah pun dipercayai berserta pengecualian yang didokumentasikan dengan jelas.

• Bolehkah beberapa pautan aktif serentak? Membenarkan bilangan terhad yang kecil mengelakkan pembatalan e-mel

yang sah semata-mata kerana mesej yang dihantar kemudian tiba terlebih dahulu. Mana-mana pautan yang berjaya mesti membatalkan setiap pautan lain untuk pengguna tersebut.

• Apakah saluran risiko dan penghantaran yang terpakai? E-mel mungkin boleh diterima untuk akaun pengguna berisiko rendah tetapi

tidak mencukupi untuk akses kewangan atau terkawal. SMS, kod pemulihan, pembuktian sokongan, dan tempoh menunggu mempunyai risiko pengambilalihan dan ketersediaan yang berbeza.

• Apakah dasar kata laluan sedia ada yang mentadbir log masuk? Penetapan semula mesti menggunakan dasar panjang, senarai sekatan, dan

cincangan yang sama. Dasar khusus penetapan semula yang lebih lemah menjadi pintasan pengesahan.

• Apakah bajet penyalahgunaan dan had pembekal e-mel yang wujud? Had kadar memerlukan dimensi seperti akaun,

IP, peranti, dan kapasiti pembekal global. Kuncian tegar berasaskan akaun sahaja membolehkan penyerang menafikan pemulihan kepada mangsa yang diketahui.

Rangka Kerja Jawapan 30 Saat

“Saya akan mengembalikan respons 202 dan mesej yang sama untuk setiap e-mel, kemudian melakukan carian dan penghantaran secara tak segerak (asynchronously) di sebalik had kadar berlapis. Untuk akaun sebenar, saya akan menjana 32 bait rawak, menghantar e-mel token base64url dalam pautan yang dibina daripada asal (origin) HTTPS yang dikonfigurasikan, dan hanya menyimpan ringkasannya bersama pengguna dan masa tamat tempoh 30 minit. Halaman GET tidak pernah menggunakan token tersebut. Pada POST terakhir, saya mengesahkannya semula, mencincang kata laluan baharu, mengunci baris pengguna, menandakan token digunakan secara atomik, mengemas kini kata laluan, membatalkan semua token penetapan semula dan sesi lain, serta menulis peristiwa outbox untuk pemberitahuan dan audit. Permintaan serentak atau serangan ulang kemudiannya gagal pada penggunaan bersyarat. Pemulihan MFA kekal sebagai aliran berasingan.”

Perbincangan Terperinci Langkah demi Langkah

Mulakan dengan dua titik akhir awam dan kontrak respons yang sengaja dikecilkan:

POST /password-reset-requests
{ "email": "person@example.com" }

202 Accepted
{ "message": "If an account matches, reset instructions will be sent." }

POST /password-resets
{ "token": "opaque-base64url-value", "new_password": "..." }

Titik akhir permintaan mengembalikan status, bentuk mesej, dan dasar cache yang sama tanpa mengira sama ada akaun tersebut wujud. Ia harus menyerahkan tugas kepada baris gilir yang terhad sebelum kembali supaya laluan keluar pantas pangkalan data atau panggilan SMTP yang ketara tidak mewujudkan orakel masa (timing oracle). Jangan tambahkan jeda waktu tidur (sleep) tetap dan menganggap masalah selesai: ketepuan baris gilir, pendikitan (throttles) khusus akaun, dan laluan ralat yang berbeza masih boleh mendedahkan tingkah laku atau menjadi alat penafian perkhidmatan (DoS).

Normalkan e-mel hanya mengikut peraturan identiti yang disahkan bagi produk tersebut. Menukar domain kepada huruf kecil mungkin sah; menggunakan peraturan khusus pembekal seperti membuang titik atau teg tambah pada setiap domain boleh menggabungkan dua akaun yang berbeza. Lapiskan had kadar merentas kunci akaun yang dinormalkan, IP atau rangkaian sumber, isyarat peranti atau risiko, dan bajet global pembekal e-mel. Tingkatkan trafik yang mencurigakan kepada cabaran (challenge). Respons awam kekal generik, dan permintaan lupa kata laluan tidak sekali-kali mengunci akaun atau menukar kata laluannya.

Bagi akaun sedia ada, jana 32 bait dengan penjana rawak selamat secara kriptografi. Itu bersamaan dengan 256 bit; base64url tanpa pad mewakilinya dalam 43 aksara. Ini adalah pilihan reka bentuk, bukan peraturan tamat tempoh atau pengekodan sejagat. Simpan SHA-256(raw_token) dan hantar nilai mentah hanya melalui pautan e-mel. Disebabkan input adalah rawak seragam dan berentropi tinggi, ringkasan sehala yang pantas menyokong carian berindeks; menggunakan ringkasan itu sendiri sebagai nilai pembawa yang dihantar akan gagal kerana pelayan mencincang input itu sekali lagi. Kata laluan ialah rahsia manusia berentropi rendah dan oleh itu memerlukan cincangan kata laluan bergaram (salted) yang perlahan.

Jadual PostgreSQL ilustrasi adalah:

CREATE TABLE password_reset_tokens (
  id uuid PRIMARY KEY,
  user_id uuid NOT NULL REFERENCES users(id),
  token_digest bytea NOT NULL UNIQUE,
  created_at timestamptz NOT NULL,
  expires_at timestamptz NOT NULL,
  used_at timestamptz,
  revoked_at timestamptz
);

CREATE INDEX password_reset_tokens_active_user_idx
  ON password_reset_tokens (user_id, expires_at)
  WHERE used_at IS NULL AND revoked_at IS NULL;

URL e-mel mesti menggunakan asal yang dikonfigurasikan atau disenaraiputihkan berbanding pengepala Host yang tidak dipercayai. Gunakan HTTPS, padamkan (redact) token daripada log aplikasi, proksi, analitis, dan ralat, serta elakkan aset pihak ketiga daripada berada pada halaman penetapan semula. Tetapkan dasar no-referrer supaya navigasi tidak mendedahkan token pertanyaan (query token). Tindakan GET boleh menunjukkan borang atau melaporkan bahawa pautan tidak sah, tetapi ia tidak boleh menggunakan token tersebut: pengimbas keselamatan mel dan pratonton pautan secara rutin melawat pautan sebelum pengguna berbuat demikian.

Jangan percaya pengesahan yang dilakukan semasa GET tersebut. Klien yang diubah suai boleh memanggil titik akhir akhir secara terus, jadi POST penukaran kata laluan mesti menerima dan mengesahkan semula token. Sebelum membuka transaksi, hasilkan ringkasan token, cari calon yang belum tamat tempoh, sahkan kata laluan baharu, dan kira cincangan kata laluan perlahan. Ini mengekalkan kerja pencincangan kata laluan yang mahal dan kebanyakan permintaan tidak sah di luar kuncian akaun. Kenakan had kadar pada titik akhir ini juga.

Perubahan keadaan akhir menggunakan baris pengguna sebagai titik penyirikan:

candidate = find token by SHA-256(raw_token)
reject publicly if candidate is missing, expired, used, or revoked
new_hash = Argon2id(new_password, fresh_salt, tuned_parameters)

BEGIN
  SELECT id FROM users WHERE id = candidate.user_id FOR UPDATE

  UPDATE password_reset_tokens
  SET used_at = now()
  WHERE id = candidate.id
    AND used_at IS NULL
    AND revoked_at IS NULL
    AND expires_at > now()
  RETURNING user_id

  if no row returned: ROLLBACK and reject

  UPDATE users
  SET password_hash = new_hash,
      password_changed_at = now(),
      auth_version = auth_version + 1
  WHERE id = candidate.user_id

  UPDATE password_reset_tokens
  SET revoked_at = now()
  WHERE user_id = candidate.user_id
    AND id <> candidate.id
    AND used_at IS NULL
    AND revoked_at IS NULL

  DELETE FROM sessions WHERE user_id = candidate.user_id

  INSERT security_outbox(password_reset_succeeded, user_id, occurred_at)
COMMIT

Kira cincangan sebelum BEGIN, tetapi jangan sesekali lakukannya (commit) melainkan kemas kini token bersyarat berjaya. Bagi penggunaan baharu, OWASP kini menyenaraikan Argon2id dengan memori 19 MiB, dua lelaran, dan satu darjah keselarian sebagai satu konfigurasi minimum; lakukan penanda aras dan tingkatkan kos sambil memastikan kapasiti pengesahan yang sah kekal selamat. Simpan algoritma dan parameter bersama cincangan kata laluan supaya ia boleh berkembang. Bcrypt ialah sandaran legasi dengan kekangan panjang input, bukan sinonim gantian terus.

Kuncian baris mengendalikan dua kelas perlumbaan. Jika dua permintaan mengemukakan token yang sama, hanya kemas kini bersyarat yang pertama boleh menetapkan used_at. Jika mereka mengemukakan dua token sah yang berbeza untuk seorang pengguna, kedua-duanya mungkin melepasi pembacaan awal dan kerja pencincangan, tetapi hanya satu yang memegang kuncian pengguna. Transaksi tersebut membatalkan token yang satu lagi; selepas permintaan kedua memperoleh kuncian, kemas kini bersyaratnya tidak mengembalikan sebarang baris. Oleh itu, kata laluan mempunyai satu nilai yang menang, dan setiap permintaan yang kalah melihat keadaan token terminal.

Pemadaman sesi sebelah pelayan memberikan pembatalan serta-merta untuk sesi yang disokong pangkalan data. Dengan token penyegaran (refresh tokens), batalkan rekod pelayannya. Untuk token akses yang stateless, meningkatkan auth_version atau menyemak password_changed_at hanya berfungsi jika setiap permintaan yang dilindungi membandingkan keadaan pelayan tersebut; tanpa semakan sedemikian, pembatalan ditangguhkan sehingga token tamat tempoh. Nyatakan batasan tersebut secara eksplisit dan bukannya mendakwa bahawa memadam kuki penyemak imbas membatalkan penyerang di tempat lain.

Tulis pemberitahuan kejayaan dan peristiwa audit keselamatan melalui outbox dalam transaksi yang sama, kemudian hantar selepas commit. Pemberitahuan tersebut mengandungi masa, panduan pemulihan akaun, dan cara untuk melaporkan penipuan, bukannya kata laluan lama atau baharu. Gangguan pembekal pemberitahuan harus mencetuskan percubaan semula dan amaran; ia tidak seharusnya mengundurkan (rollback) kata laluan yang telah pun diubah. Di bahagian permintaan, token dan tugas e-mel harus dihubungkan secara tahan lama supaya pangkalan data commit yang diikuti oleh kegagalan baris gilir tidak menyebabkan permintaan tergantung secara senyap. Outbox atau satu stor kerja berasaskan transaksi menyelesaikan sempadan tersebut.

Benarkan bilangan pautan aktif yang terhad dan bukannya membatalkan pautan sebelumnya pada setiap permintaan. Penggantian serta-merta membolehkan penyerang meminta penetapan semula berulang kali dan membatalkan e-mel mangsa sebelum ia dibuka. Hadkan baris yang belum selesai, batalkan atau tamatkan tempoh baris yang paling lama apabila had dicapai, dan batalkan semua baris yang tinggal selepas berjaya. Padamkan baris terminal dan tamat tempoh secara berkala mengikut dasar pengekalan audit.

Token tersimpan yang legap biasanya lebih mudah daripada pautan penetapan semula JWT serba lengkap. JWT yang ditandatangani masih memerlukan keadaan pelayan untuk kegunaan sekali sahaja serta-merta, pembatalan seluruh pengguna, dan perlumbaan penukaran kata laluan; sebaik sahaja keadaan itu wujud, token rawak berserta ringkasan mempunyai tuntutan (claims) dan laluan penghuraian yang lebih sedikit. PIN pendek berguna untuk kemasukan manual tetapi mempunyai entropi yang jauh lebih rendah, jadi ia memerlukan pendikitan percubaan yang ketat dan sesi penetapan semula yang terhad selepas pengesahan.

Pemantauan harus menjejaki kadar permintaan mengikut dimensi risiko, kelewatan baris gilir, ralat pembekal, hasil penghantaran, kegagalan pengesahan token, usia token semasa kejayaan, percubaan serangan ulang, dan kegagalan pembatalan sesi. Jauhkan e-mel mentah, token, kata laluan baharu, dan URL penetapan semula penuh daripada metrik dan log. Amaran harus mengesan kedua-dua kempen global dan pembanjiran satu akaun tanpa mendedahkan kewujudan akaun dalam respons awam.

Uji aliran sebagai mesin keadaan (state machine), bukan hanya sebagai titik akhir laluan gembira (happy-path). Hantar POST selari dengan token yang sama dan dengan dua token berbeza untuk seorang pengguna; tepat satu sahaja yang boleh berjaya. Sahkan tamat tempoh pada sempadan, penggunaan semula selepas kejayaan, pembatalan token saudara, akaun yang tidak wujud, gangguan baris gilir dan e-mel, manipulasi pengepala Host, kebocoran Referer, pemadaman log, dimensi had kadar, penolakan sesi pada peranti lain, percubaan semula pemberitahuan, dan akaun dengan MFA. Pengimbas keselamatan seharusnya boleh melakukan GET pada pautan tanpa menggunakannya.

Contoh Jawapan Berkualiti Tinggi

“Saya akan mentakrifkan token penetapan semula sebagai pengesah sementara dan mereka bentuk sekeliling keseluruhan kitaran hayatnya. Titik akhir permintaan sentiasa mengembalikan respons 202 yang sama. Ia membariskan carian dan penghantaran di sebalik kawalan penyalahgunaan peringkat akaun, rangkaian, peranti, dan pembekal, tetapi ia tidak sekali-kali mengunci atau menukar akaun hanya kerana seseorang menaip alamat e-mel.

Bagi akaun yang sepadan, saya menjana 32 bait rawak, menghantar nilai base64url dalam pautan HTTPS, dan hanya menyimpan ringkasan SHA-256, ID pengguna, dan tempoh luput 30 minit. Asal penetapan semula dikonfigurasikan dan bukannya diterbitkan daripada Host; halaman tersebut tidak mempunyai sumber pihak ketiga, menggunakan dasar no-referrer, dan semua talian paip log memadamkan token tersebut. GET hanya memaparkan borang kerana pengimbas e-mel mungkin membuka pautan tersebut.

POST terakhir mengesahkan token sekali lagi dan mencincang kata laluan baharu sebelum memulakan transaksi pendek. Di dalam transaksi tersebut, saya mengunci baris pengguna, menandakan token tersebut digunakan secara bersyarat, mengemas kini kata laluan dan versi pengesahan, membatalkan setiap token penetapan semula saudara dan sesi sebelah pelayan, serta memasukkan peristiwa outbox. Kemas kini bersyarat menggagalkan serangan ulang token yang sama; kuncian pengguna berserta pembatalan saudara menjadikan dua token berbeza disirikan kepada satu pemenang.

Selepas commit, pekerja (workers) menghantar pemberitahuan keselamatan dan mencuba semula secara bebas. Saya akan menguji respons generik dan pemasaan, kebocoran token dan URL, penggunaan serentak, tamat tempoh, kegagalan pembekal, penolakan sesi jauh, dan akaun MFA. Menetapkan semula kata laluan membiarkan MFA utuh; kehilangan semua pengesah akan melalui proses pemulihan berasingan dengan jaminan yang lebih tinggi.”

Kesilapan Biasa

• Mengembalikan “e-mel tidak ditemui” → penyerang boleh menghitung akaun yang didaftarkan → **kembalikan status

dan mesej awam yang sama serta elakkan laluan pemasaan keluar pantas.**

• Menyimpan token mentah → pembaca pangkalan data memperoleh pautan penetapan semula yang berfungsi → **simpan ringkasan sehala dan

padamkan nilai mentah di mana-mana kecuali penghantaran dan penyerahan pengguna.**

• Menggunakan ID pengguna daripada borang akhir → klien boleh menukar akaun sasaran → **peroleh pengguna hanya

daripada rekod token sebelah pelayan.**

• Menggunakan pautan semasa GET → pengimbas e-mel boleh membatalkannya sebelum pengguna tiba → **gunakan

hanya semasa POST penukaran kata laluan.**

• Mengesahkan semasa GET tetapi tidak pada POST → klien yang dipalsukan memintas borang yang dipaparkan → **sahkan semula tamat tempoh

dan keadaan terminal dalam transaksi sebelah pelayan yang terakhir.**

• Menyemak kemudian mengemas kini tanpa syarat → permintaan selari kedua-duanya boleh melepasi semakan → **gunakan

kemas kini bersyarat di dalam transaksi dan sirikan token berbeza pada baris pengguna.**

• Membatalkan pautan sebelumnya pada setiap permintaan → penyerang boleh memastikan e-mel terbaharu mangsa sentiasa

lapuk → benarkan set yang terhad dan batalkan semua saudara hanya selepas satu berjaya.

• Membina URL daripada Host → permintaan yang diracuni boleh menghantar domain penetapan semula yang dikawal penyerang →

gunakan asal HTTPS yang dikonfigurasikan atau disenaraiputihkan.

• Meletakkan token dalam log atau analitis → sistem kebolehlihatan menjadi stor kelayakan → **padamkan

rentetan pertanyaan dan larang sumber pihak ketiga pada halaman penetapan semula.**

• Log masuk automatik selepas penetapan semula tanpa dasar sesi → penetapan sesi (session fixation) dan tingkah laku sesi yang dicuri

menjadi tidak jelas → wajibkan log masuk biasa dan batalkan sesi sebelah pelayan secara eksplisit.

• Menetapkan semula MFA bersama kata laluan → kawalan ke atas satu e-mel boleh mengalahkan faktor yang lebih kuat → **kekalkan pemulihan

MFA sebagai aliran berasingan berasaskan risiko.**

• Menghantar kata laluan baharu melalui e-mel → kata laluan kekal dalam saluran yang tidak selamat dan penyerang boleh

mengunci mangsa → hantar pautan terhad masa dan jangan ubah apa-apa sehingga bukti yang sah diserahkan.

Soalan Susulan dan Respons

Susulan 1: Apakah yang berubah jika produk menggunakan token akses JWT tanpa keadaan (stateless)?

Batalkan token penyegaran pada pelayan. Untuk pembatalan token akses serta-merta, sertakan versi pengesahan atau nilai dikeluarkan-pada (issued-at) dan bandingkannya dengan keadaan pelayan semasa pada setiap permintaan yang dilindungi. Jika senibina menolak carian tersebut atau cache pembatalan, token akses lama kekal sah sehingga tamat tempoh; nyatakan pendedahan maksimum dan bukannya menjanjikan log keluar serta-merta.

Susulan 2: Patutkah permintaan baharu membatalkan setiap pautan penetapan semula sebelumnya?

Biasanya tidak sebelum kejayaan dicapai. E-mel boleh tertangguh atau susunannya bertukar, dan penyerang yang mengetahui alamat tersebut boleh terus membatalkan pautan terkini mangsa. Simpan set kecil token terhad yang belum tamat tempoh, kawal volum permintaan, dan batalkan setiap saudara dalam transaksi penukaran kata laluan yang berjaya. Produk berisiko tinggi mungkin memilih penggantian yang lebih ketat, tetapi ia mesti menerima pertukaran (trade-off) ketersediaan tersebut.

Susulan 3: Bagaimanakah anda menyokong kod enam digit dan bukannya token URL?

Kod enam digit mempunyai entropi yang jauh lebih rendah daripada token 256-bit. Ikatkan ia pada akaun dan percubaan penetapan semula yang berskop sempit, kenakan pendikitan percubaan dan tamat tempoh di sebelah pelayan, serta cipta sesi penetapan semula jangka pendek hanya selepas pengesahan berjaya. Jangan biarkan kod yang disahkan menjadi sesi disahkan umum atau membenarkan klien memilih ID pengguna.

Susulan 4: Peraturan kata laluan baharu manakah yang akan anda gunakan?

Gunakan dasar pengesah yang sama seperti log masuk. Jika produk menerima pakai panduan NIST semasa, kata laluan yang digunakan sebagai faktor tunggal mempunyai minimum 15 aksara; kata laluan yang digunakan hanya dalam MFA mungkin mempunyai minimum 8 aksara. Benarkan sekurang-kurangnya 64 aksara, tolak nilai biasa atau terkompromi dengan senarai sekatan, dan jangan tambah peraturan komposisi sewenang-wenangnya atau putaran berkala. Laraskan kos cincangan kata laluan secara berasingan daripada peraturan input ini.

Susulan 5: Bagaimana jika pengguna juga kehilangan akses kepada e-mel dan MFA?

Itu adalah pemulihan akaun sepenuhnya, bukan titik akhir penetapan semula kata laluan ini. Gunakan kod pemulihan atau kenalan yang didaftarkan terlebih dahulu, pengesah yang tinggal, pembuktian identiti berulang, tempoh menunggu, dan semakan manual mengikut risiko akaun. Perubahan pada alamat pemulihan itu sendiri memerlukan pengesahan dan pemberitahuan bebas. Jangan sekali-kali bergantung pada soalan keselamatan yang mudah diselidik sebagai bukti tunggal.

Susulan 6: Bagaimanakah anda mengesahkan bahawa penghitungan akaun benar-benar dikawal?

Bandingkan akaun sedia ada dan tidak wujud merentas status, badan, pengepala, tingkah laku cache, taburan kependaman, peralihan had kadar, dan kesan sampingan hiliran. Uji di bawah ketepuan baris gilir dan kegagalan pembekal, bukan hanya larian setempat yang tenang. Semak log CDN, proksi, aplikasi, analitis, dan sokongan untuk pengecam dan URL penuh, dan sahkan bahawa papan pemuka penyalahgunaan mendedahkan isyarat agregat tanpa menjadi perkhidmatan carian untuk kewujudan akaun.