Topik wawancara representatif

Bagaimana Anda merancang login magic-link yang aman?

BackendSulit
Tim Redaksi Offer.ccDipublikasikan Diperbarui

Pertanyaan

Rancang alur backend untuk login magic-link email pada SaaS berisiko rendah. Jelaskan pembuatan dan penyimpanan token, pertahanan terhadap replay dan enumerasi, serta mengapa alur ini tidak secara otomatis memberikan autentikasi berjaminan tinggi (high-assurance) atau tahan phishing.

Petunjuk dan konteks

Sebuah SaaS berisiko rendah ingin agar pengguna memasukkan alamat email dan menerima tautan login sekali pakai. Rancang alur permintaan, pengiriman, verifikasi, pembentukan sesi, pencabutan, dan audit. Tangani skenario kotak surat yang disusupi, tautan yang diteruskan, prefetch email, replay, penyalahgunaan batas laju (rate abuse), dan tindakan berisiko tinggi.

Apa yang sedang diuji oleh pewawancara

  • Apakah Anda menggunakan token sekali pakai yang tidak dapat diprediksi dan berumur pendek.
  • Apakah Anda mencegah enumerasi akun, kebocoran log, dan verifikasi brute-force.
  • Apakah Anda membedakan kemudahan dari jaminan (assurance) dan ketahanan terhadap phishing.
  • Apakah sesi, pencabutan, notifikasi, audit, dan fallback dirancang secara lengkap.

Pertanyaan klarifikasi sebelum menjawab

Konfirmasikan risiko bisnis, status email terverifikasi, perilaku multiberangkat, masa berlaku tautan, penyedia email, MFA, dan operasi berisiko tinggi. Pembayaran, perubahan hak istimewa, dan data sensitif memerlukan autentikasi yang tahan phishing atau autentikasi tambahan, bukan email sebagai satu-satunya faktor berjaminan tinggi.

Kerangka jawaban 30 detik

Hasilkan token acak berentropi tinggi dan simpan hanya hash, tujuan, pengguna, masa kedaluwarsa, dan status penggunaannya. Kembalikan respons yang sama untuk alamat yang ada maupun yang tidak dikenal serta batasi laju permintaan (rate-limit). Verifikasi melalui HTTPS, gunakan token secara atomik, kemudian buat sesi berumur pendek dan rotasi pengidentifikasinya. Izinkan satu kali penggunaan, audit kegagalan dan perangkat yang tidak biasa, serta lakukan pencabutan jika diperlukan. Keamanan magic link mewarisi risiko kotak surat dan saluran peramban, sehingga tautan ini tidak secara otomatis tahan phishing atau cocok untuk setiap tingkat jaminan NIST.

Pembahasan mendalam langkah demi langkah

1. Pembuatan dan penyimpanan

Gunakan nilai acak yang aman secara kriptografis sebagai parameter URL sekali pakai; simpan nilai hash-nya, bukan teks biasa (plaintext). Catat tujuan, pengguna, waktu pembuatan dan kedaluwarsa, waktu penggunaan, serta konteks permintaan. Bandingkan hash dalam waktu konstan (constant time) dan batasi percobaan.

2. Permintaan dan verifikasi

Kembalikan pesan, batas waktu respons (timing envelope), dan status yang sama untuk setiap email guna menghindari enumerasi. Terapkan pembatasan laju (rate-limit) berdasarkan IP, alamat, perangkat, dan anggaran global, beserta kuota pengiriman email. Verifikasi harus menandai token telah digunakan dalam transaksi atau pembaruan kondisional atomik, untuk mencegah dua klik bersamaan memutar ulang (replay) token tersebut.

3. Kontrol sesi dan risiko

Setelah token digunakan, rotasi pengidentifikasi sesi, tetapkan cookie yang aman, dan beri tahu pengguna mengenai perangkat serta lokasi. Pengambil awal email (mail prefetcher) dan pemindai keamanan mungkin mengunjungi tautan terlebih dahulu; gunakan halaman konfirmasi perantara dan tindakan pengguna yang eksplisit. Wajibkan autentikasi ulang, MFA, atau WebAuthn untuk operasi sensitif daripada mengubah tautan menjadi kredensial berhak istimewa yang berumur panjang.

Contoh jawaban berkualitas tinggi

Saya mendefinisikan magic link sebagai faktor yang praktis untuk akses berisiko rendah, bukan sebagai autentikator universal yang tahan phishing. Setelah permintaan dibuat, layanan menggunakan CSPRNG, hanya menyimpan hash, tujuan, masa kedaluwarsa, dan status penggunaan, serta mengembalikan hasil yang sama untuk setiap alamat. Pemverifikasi mencari hash melalui HTTPS, secara atomik menandainya telah digunakan, merotasi ID sesi, menetapkan cookie yang aman, dan mencatat peristiwa audit. Tautan berumur pendek dan dapat dicabut; URL-nya harus dijauhkan dari log dan analitik. Untuk menangani prefetch, tampilkan halaman konfirmasi dan wajibkan klik yang disengaja. Untuk penerusan email dan banyak perangkat, tentukan apakah hanya satu kali penggunaan yang diizinkan dan bagaimana cara memberi tahu pemilik akun. Pembayaran dan perubahan hak akses menggunakan MFA atau WebAuthn. Pengujian mencakup replay, klik bersamaan, enumerasi, batas laju, kebocoran email, perangkat anomali, dan pencabutan.

Kesalahan umum

  • Menyimpan token teks biasa di basis data atau log.
  • Gagal mengonsumsi token secara atomik, sehingga memungkinkan replay bersamaan.
  • Mengembalikan pesan kesalahan yang berbeda untuk alamat yang tidak dikenal sehingga memungkinkan enumerasi.
  • Menyebut magic link secara inheren tahan phishing atau setara dengan kunci perangkat keras (hardware key).
  • Menukar tautan kedaluwarsa dengan sesi berumur panjang atau mengabaikan notifikasi dan pencabutan.

Pertanyaan lanjutan dan jawabannya

Bagaimana dengan prefetching pada klien email?

Jangan menyelesaikan login pada permintaan GET. Tampilkan halaman konfirmasi, gunakan token hanya setelah tindakan pengguna yang eksplisit, dan bedakan telemetri prefetch dari klik nyata.

Berapa lama token harus aktif?

Pilih rentang waktu singkat berdasarkan toleransi risiko dan estimasi keterlambatan email, lalu pantau tingkat replay dan tautan yang tidak digunakan. Setelah kedaluwarsa, terbitkan token baru daripada memperpanjang token yang lama.

Mengapa tidak menggunakannya untuk administrator atau persetujuan pembayaran?

Saluran kotak surat dapat diteruskan, dibajak, atau di-phishing, dan NIST membedakan beberapa penggunaan konfirmasi email dari autentikasi berjaminan tinggi. Tindakan berisiko tinggi memerlukan autentikasi yang tahan phishing, pengikatan transaksi (transaction binding), dan notifikasi independen.

Sumber publik

Pertanyaan terkait