Dari sisi klien, ini tampak seperti pemutusan acak satu jam setelah sesi berjalan. Ikon baki menghilang, terowongan dibangun ulang, dan log menunjukkan kegagalan autentikasi alih-alih kesalahan jaringan. Yang sebenarnya terjadi adalah sesi melakukan negosiasi ulang dan jabat tangan kedua membutuhkan kredensial yang salinan validnya sudah tidak dimiliki klien. Kode sekali pakai yang berhasil saat masuk tidak dapat berhasil lagi, sehingga pembaruan kunci gagal persis seperti yang dirancang.

Perbaikannya adalah keputusan tentang apa yang harus disajikan jabat tangan kedua, bukan pengatur waktu percobaan ulang yang lebih lama.

Ikuti pertukaran dari sudut pandang klien

Saat masuk, klien mengirim nama pengguna, kata sandi, dan kode dari perangkat token, dan server menerima kombinasi itu. Sesi lalu berjalan sampai pemicu negosiasi ulang aktif, yang memulai jabat tangan TLS baru di dalam terowongan yang ada. Jabat tangan itu meminta autentikasi lagi. Jika jalur autentikasi server mengharapkan kata sandi plus kode sekali pakai yang berlaku, klien tidak punya kode baru untuk ditawarkan kecuali pengguna hadir untuk mengetikkannya.

Sebagian besar klien tidak membuka permintaan di tengah sesi, sehingga jabat tangan habis waktu dan terowongan jatuh. Pengguna melihat penyambungan ulang, bukan permintaan autentikasi, dan itulah sebabnya laporan pertama biasanya menyalahkan jaringan.

auth-gen-token mengubah siapa yang menjawab pertanyaan kedua

auth-gen-token adalah opsi yang memungkinkan server menerbitkan token setelah login berhasil, dan negosiasi ulang berikutnya menyajikan token itu alih-alih mengulang kata sandi dan kode. Panduan mendokumentasikan masa hidup dan perilaku pembaruannya, dan token harus diperlakukan sebagai kredensial dengan kedaluwarsanya sendiri. Pada jalur bawaan, server memvalidasi token itu sendiri alih-alih memanggil lagi pengautentikasi kata sandi eksternal.

Dengan integrasi autentikasi eksternal, pembagian itu berubah. Plugin harus memahami status token dan menerapkan pemeriksaannya sendiri, karena server bukan lagi satu-satunya komponen yang memutuskan apakah sesi berlanjut. Memperlakukan token sebagai kode numerik sekali pakai lain bukanlah implementasi fitur ini.

Putuskan apa yang terjadi pada status akun

Token yang bertahan lebih lama daripada akses akun adalah lubang kebijakan. Putuskan bagaimana akun yang dinonaktifkan, keanggotaan grup yang dicabut, atau perangkat yang dicabut berlaku saat token masih valid. Masa hidup token yang pendek memperkecil jendela; jalur pencabutan eksplisit membuatnya disengaja. Tuliskan jawabannya sebelum mengaktifkan opsi, karena jalur bawaan tidak menghubungi pengautentikasi eksternal pada setiap negosiasi ulang.

Dalam penyebaran multi-server, rahasia penandatanganan token harus dibagi, atau klien dapat dikirim ke node yang tidak dapat memvalidasi tokennya.

Uji kedaluwarsa dan penyambungan ulang, bukan hanya login

Turunkan interval negosiasi ulang pada profil uji agar jabat tangan kedua terjadi saat Anda mengamati, lalu ikuti kedua log. Pastikan token diterbitkan saat login, disajikan saat pembaruan kunci, dan disegarkan atau diterbitkan ulang sesuai masa hidup yang dikonfigurasi. Lalu paksa kedaluwarsa token dan penyambungan ulang penuh, karena klien yang menyambung ulang dengan bersih tetap bisa gagal pada jalur pembaruan kunci.

Uji penghapusan akun terakhir. Kasus itu memberi tahu Anda apakah kebijakan yang Anda tulis ditegakkan atau hanya didokumentasikan.

Jangan perbaiki dengan menonaktifkan pembaruan

Menyetel interval negosiasi ulang ke nol di kedua sisi menghapus gejalanya dan rotasi kunci bersamanya. Itu menyembunyikan masalah penggunaan ulang kredensial di balik perubahan kebijakan yang tidak ditinjau siapa pun. Pertahankan pembaruan, dan pilih antara token yang diterbitkan server dan tantangan interaktif baru berdasarkan ada tidaknya pengguna.

Pengatur waktu percobaan ulang yang lebih lama tidak membuat kode yang sudah terpakai menjadi valid lagi. Itu hanya menunda pemutusan dan membuat log lebih sulit dibaca.

Artikel terkait