Belajar Application Security Engineer - Authentication & Session

#Pendahuluan

Setelah di episode 4 kita menguasai empat pilar secure coding, episode ini memfokuskan diri pada sistem yang paling sering diserang dan paling mahal akibatnya bila gagal: autentikasi dan manajemen sesi. Mengapa topik ini pantas satu episode penuh? Karena hampir semua breach dimulai dari kredensial — lemah, bocor, dicuri, atau di-reuse. OWASP menempatkannya di A07, dan credential stuffing adalah vektor nomor satu serangan otomatis saat ini.

Kita bahas berurutan seperti alur hidup identitas: password disimpan (hashing), pengguna terverifikasi (login), status login dipertahankan (session), lapisan kedua ditambahkan (MFA), dan delegasi ke penyedia identitas (OAuth/OIDC).

#Password Hashing

Aturan pertama dan mutlak: password tidak pernah disimpan sebagai teks atau hash cepat. Fungsi hashing password modern sengaja lambat dan boros memori agar brute force hardware mahal:

import { hash, verify } from "@node-rs/argon2";
 
const passwordHash = await hash(plainPassword, {
  memoryCost: 19456, // KiB (~19 MiB)
  timeCost: 2,
  parallelism: 1,
});
 
const valid = await verify(passwordHash, submittedPassword);

Dua detail yang sering salah:

1. Salt tidak perlu dikelola manual — fungsi modern menyimpannya dalam string hash output. Jangan pernah pakai salt global statis.
2. Pepper opsional: secret tambahan dari env/KMS yang dipakai via HMAC sebelum hash — melindungi hash bila database saja bocor, tetapi menambah kompleksitas rotasi kunci.

#Session Management

Session menjawab pertanyaan server setiap request: "ini siapa?". Dua arsitektur besar: server-side session (ID acak di cookie, state di Redis/DB) dan stateless token (JWT). Untuk aplikasi web konvensional, server-side session lebih aman karena revocation instan.

#Cookie Hardening

Set-Cookie: sid=8f3c...; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=3600

• HttpOnly — JavaScript tidak bisa membaca cookie → XSS tak bisa mencuri sesi langsung.
• Secure — hanya dikirim via HTTPS.
• SameSite=Lax (atau Strict untuk app internal) — mitigasi CSRF lintas situs.
• Max-Age pendek + sliding renewal — jendela pencurian menyempit.

#Rotation & Invalidation

Tiga momen wajib rotasi ID sesi: setelah login sukses (mencegah session fixation), setelah perubahan hak akses, dan setelah ganti password. Dan momen wajib invalidasi: logout, timeout idle, dan — sering terlupakan — semua sesi milik user saat indikasi kompromi.

Login sukses      → generate ID baru (crypto random ≥ 128 bit)
Logout            → hapus state server + clear cookie
Ganti password    → revoke semua session user
Idle 30 menit     → expire (sliding)
Absolut 12 jam    → re-authenticate

#Jebakan JWT

JWT bukan musuh, tapi tiga jebakannya muncul terus-menerus:

1. alg: none / algorithm confusion — library lama menerima header alg dari token itu sendiri. Selalu pin algoritma di sisi verifikasi (HS256 atau RS256, eksplisit).
2. Tidak ada mekanisme revoke — JWT valid sampai exp; untuk logout pakai denylist jti atau access token berumur pendek (5–15 menit) + refresh token yang bisa dicabut.
3. Menyimpan data sensitif di payload — payload JWT hanya base64, bukan enkripsi; siapa pun pemegang token bisa membacanya.

#MFA: Lapisan Kedua

Password akan bocor — statistiknya sudah pasti (reuse, phishing, breach). MFA membuat kredensial bocor saja tidak cukup. Tingkatannya bertingkat:

Arah industri 2026 jelas: passkeys (WebAuthn) — kunci publik tersimpan di device/platform, tidak bisa difishing karena terikat domain. Sebagai AppSec engineer, dorong WebAuthn untuk aplikasi high-value, minimal TOTP sebagai fallback, dan hindari SMS kecuali tidak ada pilihan.

Implementasi TOTP sendiri cukup mudah dengan library (otplib, speakeasy) — simpan secret terenkripsi, window toleransi ±1 periode, dan selalu izinkan recovery code sekali pakai.

#OAuth 2.0 & OIDC

Saat kalian butuh "login with Google" atau single sign-on antar service, jangan bangun sendiri — gunakan OAuth 2.0 (authorization framework) + OIDC (layer identitas di atasnya).

Alur paling aman untuk web app adalah Authorization Code Flow + PKCE:

PKCE (code verifier/challenge) wajib bahkan untuk web app confidential client — ia mencegah intercept authorization code. Kesalahan implementasi yang paling sering saya temui saat review:

• Implicit flow masih dipakai (deprecated — token terekspos di URL fragment).
• State parameter tidak divalidasi → CSRF pada callback login.
• Redirect URI longgar (wildcard) → kode otorisasi bisa dialihkan ke domain penyerang.
• Scope diberikan * padahal cukup email profile — prinsip least privilege berlaku juga di sini.

#Praktik: Auth Hardening Checklist

Terapkan urutan ini pada aplikasi latihan kalian — dampak vs effort paling efisien:

1. Ganti hashing ke Argon2id/bcrypt cost 12+, migrasi on-login (re-hash saat user berhasil login).
2. Set ketiga flag cookie (HttpOnly Secure SameSite) + rotasi ID pasca-login.
3. Tambah rate limit login per akun dan per IP + exponential backoff.
4. Aktifkan pesan error generik untuk login/reset/forgot.
5. Tambah TOTP + recovery codes.
6. Invalidate semua sesi saat ganti password.
7. Audit dependency auth — jika pakai NextAuth/Auth0/Clerk, pastikan versinya ter-update dan flow-nya PKCE.

#Common Pitfalls

• Rate limit hanya per IP: NAT kantor dan botnet distribusi membuatnya sia-sia; kombinasikan per akun + IP + device fingerprint.
• Email verification di-skip demi velocity rilis — akun palsu massal adalah pintu masuk abuse lainnya.
• Remember-me forever: token 10 tahun di localStorage adalah bom waktu; beri expiry dan rotasi.
• JWT di localStorage: rentan XSS exfiltration; untuk SPA, httpOnly cookie lebih aman dengan proteksi CSRF yang benar.

#Penutup

Inti yang harus dibawa pulang:

• Password: Argon2id/bcrypt saja; salt otomatis; pepper opsional; error message generik.
• Session: cookie triple-flag, rotasi pasca-login, invalidasi menyeluruh saat kompromi.
• JWT hati-hati: pin algoritma, umur pendek, jangan simpan sensitif, sediakan revocation.
• MFA bertingkat: WebAuthn terbaik, TOTP minimum; OAuth/OIDC selalu Authorization Code + PKCE.
• Untuk production, pakai IdP matang dan audit konfigurasinya.

Di episode 6 kita keluar dari browser dan masuk wilayah yang jadi tulang punggung semua produk digital: API Security — autentikasi token API, rate limiting yang layak, OWASP API Top 10, dan teknik testing API secara sistematis. Sampai jumpa di episode 6!