Verifikasi Masuk 2 Langkah via Kode Email
Lapisan keamanan ekstra yang mengirimkan kode rahasia 6 digit ke email setiap kali ada yang mencoba masuk, memastikan hanya pemilik akun asli yang bisa mengakses data keuangan.
Lapisan keamanan ekstra yang mengirimkan kode rahasia 6 digit ke email setiap kali ada yang mencoba masuk, memastikan hanya pemilik akun asli yang bisa mengakses data keuangan.
Tantangan & Kebutuhan Pengguna
Mengamankan akun finansial dengan autentikasi dua faktor (2FA) via email OTP sering kali menimbulkan celah pada pengelolaan state transisi: bagaimana sistem mengizinkan pengguna membuka halaman verifikasi OTP setelah password cocok, namun secara ketat mencegah mereka memotong kompas langsung ke `/dashboard` sebelum kode OTP dimasukkan?
Jangan berikan kunci penuh sebelum langkah verifikasi kedua tuntas; cukup berikan tiket tunggu berstatus 'pending' yang hanya diakui di ruang verifikasi.
Solusi & Cara Kerja
Saat pengguna memasukkan email dan password di endpoint login, sistem terlebih dahulu memeriksa batas percobaan login (rate limiter), memvalidasi hash password menggunakan `bcryptjs`, lalu membangkitkan kode OTP 6 digit dengan masa berlaku 10 menit yang dikirim melalui `nodemailer`. Alih-alih langsung memberikan sesi penuh, server menerbitkan JWT sementara dengan klaim `role: 'pending'`. Di tingkat jaringan, `src/proxy.ts` membedakan antara keberadaan token (`user`) dan status login penuh (`user.role !== 'pending'`), sehingga pengguna dengan token `pending` akan selalu ditolak jika mencoba mengakses halaman internal sebelum menuntaskan verifikasi OTP.
Berikut adalah koordinasi antara penerbitan token sementara berstatus `pending` saat login dan pencegahan akses di lapisan `proxy.ts`:
Detail & Hal yang Diperhatikan
- Penanganan Registrasi Ganda pada Akun Belum Aktif: Jika pengguna mendaftar ulang dengan email yang sudah ada namun `isactive` masih `0`, sistem tidak melempar error duplikat melainkan memperbarui hash password dan mengirim ulang OTP baru.
- Invaliasi OTP Sekali Pakai: Begitu OTP berhasil diverifikasi, kolom `otp` dan `otpexpired` langsung di-reset menjadi `NULL` pada transaksi yang sama agar kode tidak dapat digunakan ulang.
- Kompatibilitas Edge Runtime: Penandatanganan dan verifikasi JWT menggunakan pustaka `jose` berbasis Web Crypto API (`HS256`) agar dapat dieksekusi dengan ringan di dalam lapisan Proxy Next.js.
Seluruh respons yang melewati lapisan proxy juga disuntikkan header keamanan standar (X-Content-Type-Options: nosniff, X-Frame-Options: DENY, dan Referrer-Policy) untuk memitigasi serangan clickjacking dan MIME sniffing.