The Copenhagen Book: Panduan Implementasi Autentikasi Aplikasi Web
(thecopenhagenbook.com)- Berfungsi sebagai panduan dasar yang dapat dirujuk saat merancang implementasi autentikasi di aplikasi web, dengan tujuan mengisi celah dalam materi autentikasi online
- Merupakan materi gratis dan open source, serta disediakan dengan model pemeliharaan oleh komunitas
- Sebagian isinya mungkin mencerminkan opini atau belum lengkap, sehingga lebih tepat digunakan sebagai materi pendukung daripada sebagai satu-satunya acuan
- Disarankan digunakan bersama OWASP Cheat Sheet Series, materi referensi keamanan autentikasi
- Saran atau kekhawatiran dapat disampaikan dengan membuka issue baru, sehingga Anda dapat berpartisipasi dalam peningkatan dokumen
Tujuan dan karakter dokumen
- The Copenhagen Book menyediakan panduan umum yang dapat dirujuk saat mengimplementasikan autentikasi (auth) di aplikasi web
- Cara operasinya adalah sebagai berikut
- Disediakan secara gratis
- Bersifat open source
- Dipelihara oleh komunitas
- Isinya terkadang mungkin mencerminkan opini atau belum lengkap
Materi rujukan pendamping dan cara berpartisipasi
- Saat mengimplementasikan autentikasi, disarankan untuk merujuknya bersama OWASP Cheat Sheet Series
- Jika ada saran atau kekhawatiran, Anda dapat membuka issue baru
1 komentar
Komentar Hacker News
Kalau saya tidak salah, sepertinya tulisan ini dibuat oleh penulis Lucia, pustaka autentikasi populer untuk TypeScript
Baru-baru ini ia mengumumkan bahwa pustaka Lucia bukan lagi cara yang ergonomis untuk mengimplementasikan autentikasi, lalu memutuskan menghentikan pustaka itu dan menggantinya dengan seri panduan berbentuk tulisan
Pratinjau panduan awalnya enak dibaca dan juga sangat selaras dengan The Copenhagen Book
https://github.com/lucia-auth/lucia
https://github.com/lucia-auth/lucia/discussions/1707
https://lucia-next.pages.dev/
Jarang ada orang yang melihat tanda-tanda kompleksitas akan meledak, mengakui bahwa pustaka itu sudah tidak lagi berguna bahkan bagi dirinya sendiri, lalu dengan rendah hati keluar dari jalur standar pembengkakan pustaka
Faktanya, 99% orang hanya butuh login/logout, dan itu sangat berguna bila disediakan sebagai pustaka
Kalau Anda memang harus menyediakan passkey Web 8.0 lewat soket kurva eliptik WASM, silakan buat sendiri atau pakai Auth0, tetapi aneh kalau orang yang membuat aplikasi resep CRUD diberi spesifikasi OAuth dan daftar jebakannya lalu disuruh membangun autentikasi sendiri
Orang seperti itu seharusnya fokus pada ide utamanya alih-alih menciptakan ulang plumbing, dan banyak orang pada akhirnya akan mengimplementasikannya dengan salah sehingga secara praktis sama saja dengan tidak punya autentikasi
Bagian ini salah: “alamat email tidak peka huruf besar-kecil”
https://thecopenhagenbook.com/email-verification
Menurut standar email, alamat email peka terhadap huruf besar-kecil
Kalau alamat email diubah menjadi huruf kecil saat pengiriman, email bisa terkirim ke orang yang salah, dan itu berbahaya dalam autentikasi
Banyak penyedia email besar memilih untuk tidak membedakan huruf besar-kecil, tetapi situs yang membahas autentikasi umum seharusnya merekomendasikan kasus yang umum berlaku
https://stackoverflow.com/questions/9807909/are-email-addres...
Tambahan lagi, tidak selalu jelas apa pasangan huruf besar-kecil dari suatu karakter, dan itu pun bisa berubah seiring waktu. Misalnya, huruf kapital Jerman ß baru ditambahkan ke Unicode pada 2008, jadi dalam pemrograman umum sebaiknya sebisa mungkin menghindari pembedaan huruf besar-kecil
Standarnya mengatakan satu hal, tetapi implementasinya bekerja berbeda, dan dalam kasus ini mengikuti teks standar saja malah menimbulkan masalah di dunia nyata
Dengan begitu, email dikirim ke alamat dengan kapitalisasi seperti saat pertama kali dimasukkan, dan login tetap bisa dilakukan tanpa memedulikan huruf besar-kecil
Kekurangannya, dua pengguna dengan email yang hanya berbeda kapitalisasi tidak bisa dipisahkan sebagai dua akun berbeda, tetapi menurut saya itu tidak masalah
Emailnya sendiri tidak membedakan huruf besar-kecil, tetapi nama pengguna yang dibuat dari email itu justru peka huruf besar-kecil, sehingga jika akun dibuat dengan email berhuruf kapital, Anda harus memasukkan kapitalisasi yang sama persis untuk bisa login, dan login dengan email yang mengabaikan huruf besar-kecil tidak berhasil
Setelah itu hapus juga perbedaan bahasa dan budaya, maka miliaran baris kode akan lenyap, sampai-sampai saya seperti bisa mendengar ukuran repositori sudah mengecil
Misalnya satu entri pengguna berisi JohnDoe@example.com, entri lain berisi johndoe@example.com, padahal jelas orangnya sama
Lebih repot lagi karena nilainya datang dari sistem yang berbeda-beda
Menurut saya, matriks risiko email yang tidak peka huruf besar-kecil jauh lebih baik daripada email yang peka huruf besar-kecil. Jadi mengubah semua email menjadi huruf kecil adalah pilihan yang benar, dan The Copenhagen Book juga benar dalam hal ini
Sangat bagus. Saya selalu kesal karena 90% materi keamanan terasa dibuat agar mustahil dipahami kalau Anda bukan pakar keamanan. Terutama materi kriptografi
Namun hampir semua halaman di sini jelas, ringkas, langsung ke inti, dan bisa segera diterapkan, jadi saya sangat suka
Hanya saja halaman tentang kurva eliptik sama sulit dipahaminya dengan materi kriptografi lain
Cara kerjanya sendiri adalah matematika, jadi menurut saya pada dasarnya memang tidak transparan
Setelah memahami medan hingga atau kurva eliptik, pada dasarnya grup bilangan bulat, saya jadi bisa memahami banyak hal dalam kriptografi, dan biasanya itu dalam satu atau lain bentuk merupakan masalah logaritma diskret
Akan bagus jika ada juga dokumen alternatif untuk topik serupa. Misalnya sesuatu seperti OWASP Cheatsheet, tetapi berupa dokumen dengan sudut pandang yang lebih praktis
Saya menghargainya, tetapi agak skeptis terhadap dokumen ini
Namanya cukup bombastis. Menyebut dokumen ini seolah-olah ditulis oleh para peneliti universitas di Copenhagen adalah trik pemasaran yang hebat
Memang benar Lucia adalah library yang relatif populer, tetapi itu tidak berarti ia mempromosikan best practice atau bahwa penulisnya harus dipandang sebagai otoritas di bidang penting ini
Ada juga bagian dari desain Lucia yang tidak saya sukai. Ia menyarankan untuk memperpanjang masa berlaku token yang ada ketika token pengguna hampir kedaluwarsa, alih-alih membuat token keamanan baru
Karena token pada praktiknya hidup selamanya dan bisa terus disalahgunakan, ini terlihat seperti perilaku yang sangat tidak aman, dan melanggar best practice keamanan berupa masa hidup token yang terbatas
Baik Lucia maupun “Copenhagen Book” merekomendasikan pendekatan ini: https://thecopenhagenbook.com/sessions#session-lifetime
Ini adalah pendekatan yang umum dan biasanya disebut rolling session
Token itu sendiri pada dasarnya harus immutable, sehingga masa berlakunya tidak boleh bisa diubah; karena itu, pembaruan token seharusnya dilakukan dengan memberikan token baru, bukan mengubah token asli
Dalam kasus pertama, penyerang mencuri token dan menggunakannya selamanya. Dalam kasus kedua, penyerang juga bisa terus menyamar sebagai pengguna jika setelah mencuri token ia menerima token baru tepat sebelum masa berlakunya habis
Jika pengguna terlempar keluar, mereka mungkin menyadari ada sesuatu yang salah, tetapi kemungkinannya kecil, dan demi pengalaman pengguna yang baik tetap dibutuhkan masa tenggang. Kalau tidak, pengguna yang sah juga akan mengalami masalah pada permintaan paralel
Anda bisa memakai token kedua, yaitu refresh token, tetapi itu hanya memindahkan risikonya ke token tersebut. Sekarang yang harus dikhawatirkan adalah refresh token dicuri dan disalahgunakan selamanya
Refresh token berguna karena Anda tidak perlu menyentuh database pada setiap permintaan. Biasanya token sesi berumur pendek dapat diverifikasi tanpa database, misalnya signed JWT
Namun, saat dicuri token itu tidak bisa dibatalkan dan tetap valid sampai kedaluwarsa, jadi untuk mengurangi dampaknya Anda perlu membuat waktu kedaluwarsanya singkat
Sebaliknya, refresh token melakukan lookup ke database. Bukan token kedua itu sendiri yang menambah keamanan, melainkan lookup ke database yang menambah keamanan. Karena token bisa dibatalkan dengan menghapusnya dari database
Lucia, setidaknya berdasarkan contohnya, selalu melakukan lookup ke database sehingga token dapat dibatalkan kapan saja
Untuk mengurangi risiko, pengguna sebaiknya bisa melihat sesi aktif dan mengakhirinya. Kalau memungkinkan, akan bagus juga menampilkan informasi waktu, lokasi, dan perangkat. Misalnya: “Login kemarin pukul 12 pagi dari iPhone di Copenhagen”
Anda juga bisa memberi tahu pengguna saat ada login dari lokasi atau perangkat baru
Pada akhirnya, tidak ada cara untuk mengimplementasikan sesi jangka panjang yang sepenuhnya aman
Menurut saya ini poin yang bagus, tetapi saya tidak bisa mengklaim diri sebagai ahli
Ada dua hal dalam OAuth yang sering terlewat oleh semua orang, dan keduanya tidak terlalu terlihat
Senang ada yang menyoroti salah satunya. Saat menggunakan token, transaksi harus dipakai sebagai mekanisme distributed lock
Pada refresh token, pentingnya menjadi dua kali, bahkan empat kali lipat. Jika token yang sama dipakai lebih dari sekali, pengguna itu akan logout
Tidak peduli apakah sistem berjalan di satu mesin atau N mesin. Jika ada dua atau lebih permintaan dengan refresh token yang diproses secara bersamaan — hal yang sangat umum terjadi — pengguna akan logout dan sering kali berakhir dengan 500
Refresh token itu sekali pakai
Hal lain yang sering terlewat oleh developer dan framework autentikasi adalah parameter “state”
Jika melihat arah perkembangan autentikasi belakangan ini secara umum, rasanya bukan menuju keamanan melalui ambiguitas, melainkan lebih ke ketidakstabilan akibat ambiguitas
Begitu status aplikasi ikut terlibat, logika aplikasi harus disesuaikan dengan autentikasi, dan aplikasi harus memeriksa apakah seseorang telah mencuri refresh token
Transaksi saja tidak cukup untuk menyelesaikannya. Misalnya, jika dua tab dibuka cepat, server akan dihantam dua kali dengan refresh token asli
Dokumen itu memang lebih memilih refresh token rotation, tetapi juga membahas kesulitan yang jelas di lingkungan cluster: https://datatracker.ietf.org/doc/html/rfc6819#section-5.2.2....
Banyak permintaan selalu terjadi secara bersamaan. Misalnya browser dibuka dengan beberapa tab, atau aplikasi ponsel mulai berjalan dan langsung mengirim beberapa permintaan sekaligus
Akan lebih baik jika lebih banyak situs web memberi opsi seperti, “jangan biarkan sesi berakhir sampai saya logout, saya paham risikonya”
Belakangan ini tombol “remember me” tidak ada efeknya sama sekali
Karena sesi terus kedaluwarsa, hari saya jadi terus terputus-putus. Saya особенно benci GitHub; karena saya memakainya kira-kira seminggu sekali, sesinya selalu habis, lalu saya dipaksa lewat autentikasi dua faktor juga, jadi setiap kali harus mengeluarkan ponsel dan memasukkan angka
Pengalaman penggunanya buruk sekali, tetapi bahkan tanpa bukti pun saya rasa kalau pengguna terus-menerus dipaksa login seperti ini, mereka akan lelah dan jadi kurang waspada
Jika seseorang login ke satu situs beberapa kali setiap minggu, maka sekitar login ke-60 akan lebih mudah bagi situs phishing untuk menyelinap. Sebaliknya, jika akun yang hampir tak pernah meminta login tiba-tiba meminta kata sandi, itu terasa aneh dan justru meningkatkan kewaspadaan
Pada akhirnya perusahaan harus belajar bahwa setiap orang punya toleransi risiko dan postur keamanan yang berbeda, lalu menyediakan pilihan
Tambahan lagi, karena sangat kesal dengan sesi GitHub yang sering berakhir dan autentikasi dua faktornya, saya akhirnya pindah ke Gitea dan mematikan kedaluwarsa. Itu 90% alasan saya pindah
Karena hanya bisa diakses dari jaringan saya, saya malah merasa keamanannya lebih baik. Sangat mungkin perusahaan kehilangan pelanggan karena model keamanan yang tidak fleksibel
Kurang lebih jika dipakai dalam 30 hari, sesi diperpanjang 30 hari lagi
https://thecopenhagenbook.com/sessions#session-lifetime
Yang lebih buruk, sesinya tampak bertahan sekitar 1-2 menit lebih lama dari seminggu, jadi minggu ini saya diusir tepat setelah mulai melanjutkan pekerjaan minggu lalu
Beberapa minggu lalu saya login untuk mencatat sebelum rapat berulang, lalu selama beberapa minggu berturut-turut saya dipaksa login lagi di tengah rapat itu
Ada sangat banyak pengaturan yang bisa menonaktifkan tombol “remember me” seperti itu
Secara pribadi saya tidak pernah punya masalah tetap login di situs web, termasuk GitHub
Saya baru mengenal protokol SRP, dan saya heran kenapa ini tidak lebih luas dipakai atau dibahas
Ini protokol yang relatif sederhana untuk melakukan pembuktian tanpa pengetahuan dan sekaligus membuat token sesi antara server dan klien
https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
Saya suka materi ini. Banyak nasihat keamanan terasa rumit dan kadang bahkan tidak masuk akal. Rasanya seperti pengacara yang menyarankan agar tidak melakukan apa pun
Panduan ini menyegarkan karena ringkas, mudah diikuti, mudah dipahami, dan memberi saran yang lugas
Saya akan terus membaca komentar untuk melihat apakah ada pendapat berlawanan atau hal yang perlu diwaspadai, tetapi sepertinya saya akan meninjaunya sambil membandingkannya dengan proyek autentikasi saya
Satu hal yang saya harapkan adalah adanya bagian tentang JWT. Kalau pendapat penulis adalah “jangan pakai”, bahkan mengatakan itu saja sudah cukup
Salah satu kritik saya yang sering terhadap tim keamanan adalah mereka menghabiskan banyak waktu untuk memberi tahu apa yang tidak boleh dilakukan, alih-alih secara proaktif menyediakan alat atau cara agar orang bisa melakukan hal yang mereka inginkan dengan efisien
Email bisa dianggap sebagai sistem yang lebih aman, artinya belum tentu bisa diakses segera atau dari mana saja
Saya penasaran, apakah “auth” di sini berarti authn, atau authz
Dari tampilannya sepertinya berarti autentikasi, tetapi akan lebih baik kalau diperjelas
Sedikit keluhan singkat yang agak terkait: browser bawaan aplikasi sedang merusak web
Browser bawaan membuat penggunaan OAuth sosial menjadi mustahil. Dalam beberapa kasus benar-benar mustahil, dalam kasus lain praktis mustahil
Jika Anda menekan tautan di Instagram, secara default itu dibuka di browser Instagram, dan jika tautan itu punya “Sign in with Google”, maka itu tidak akan bekerja karena Google memblokir “browser tidak aman” seperti Instagram
Bahkan “Sign in with Facebook” pun bermasalah, padahal Meta memiliki Instagram dan Facebook sekaligus. Browser bawaan Facebook juga punya masalah serupa
Pernah klik tautan di tempat seperti Slack, lalu membalas pesan, kemudian kembali ke browser sambil berharap halaman itu masih ada, tetapi ternyata Slack menelannya ke dalam browsernya sendiri hingga tak ada di mana-mana; itu hampir selalu tidak berguna
Untungnya, barusan saya cek, di Slack ada cara untuk mematikan browser bawaan