City Courier

Hampir setiap aplikasi modern memakai JSON Web Token untuk menjaga sesi login, dan sebagian besar tutorial mengajarkannya dengan cara yang sama: satu kunci rahasia, algoritma HS256, selesai. Cara itu berhasil — sampai tidak lagi. JWT punya sejumlah celah yang sudah lama terdokumentasi: serangan `alg: none` yang membuat token tanpa tanda tangan diterima, kebingungan algoritma yang menipu server memverifikasi dengan cara yang salah, dan penyuntikan `kid` yang mengarahkan verifikasi ke kunci milik penyerang. Yang mengganggu saya bukan keberadaan celah itu, melainkan satu pertanyaan yang tidak terjawab tuntas di materi berbahasa Indonesia yang saya temukan: kalau saya menerapkan pengamanan yang katanya benar, apakah ia benar-benar bertahan saat diserang? Sebagian besar tulisan berhenti pada "gunakan RS256". Nyaris tidak ada yang menunjukkan buktinya.

Langsung: pengguna sistem kurir — pengirim, kurir, admin — yang sesi loginnya bergantung pada mekanisme ini. Mereka tidak akan pernah tahu ia ada, dan memang begitu seharusnya. Keamanan yang bekerja itu tidak terlihat. Sesungguhnya: pengembang lain yang menghadapi pertanyaan yang sama. Itulah sebabnya hasilnya saya terbitkan, bukan saya simpan.

Alih-alih satu kunci rahasia bersama, sistem ini memakai kriptografi asimetris RS256 dan mendistribusikan kunci publiknya lewat JWKS sesuai RFC 7517. Perbedaannya bisa dijelaskan tanpa istilah teknis sama sekali:

Menurut artikel yang terbit, pengujian mencakup sepuluh skenario serangan kritis, termasuk kebingungan algoritma dan penyuntikan kunci. Sistem yang diuji menerapkan:

• Rotasi kunci JWKS dinamis
• Distribusi kunci publik sesuai RFC 7517
• Penyimpanan kunci privat terenkripsi
• Pembatasan algoritma secara eksplisit
• Identifikasi kunci berbasis UUID
• Pencatatan menyeluruh

Hasilnya: sistem bertahan terhadap seluruh skenario yang diuji, dengan dampak performa minimal — dan bagian terakhir ini penting, karena keamanan yang membuat aplikasi lambat akan dimatikan orang.

Artikel itu menceritakan bagian yang berhasil. Bagian ini menceritakan yang tidak. Sistemnya berhasil. Kodenya tidak. Riset saya lolos sidang dan terbit di jurnal terakreditasi. Tapi basis kodenya tumbuh cepat, dari lebih dari satu tangan, tanpa peninjauan kode, tanpa perlindungan branch, tanpa pemeriksaan otomatis, dan tanpa kesepakatan arsitektur tertulis. Akibatnya bisa diduga: peringatan menumpuk sampai ratusan, dan satu berkas antarmuka membengkak hingga hampir empat ribu baris. Di sebelahnya tersimpan salinan cadangan berkas itu, lebih besar lagi — pengakuan yang tidak saya sadari sedang saya tulis: saya sudah tidak percaya pada kode saya sendiri sampai harus menyalinnya sebelum berani mengubah apa pun. Saya sempat menyalahkan keadaan. Belakangan saya sadar diagnosis itu tidak menyelesaikan apa pun. Sebagai orang yang memulai proyek ini, sayalah yang seharusnya memasang pagar pengamannya sejak awal. Tidak ada peninjauan kode karena tidak ada yang mensyaratkannya. Tidak ada standar arsitektur karena tidak ada yang menuliskannya. Ada dua pilihan waktu itu: terus menambal, atau berhenti dan mengakui fondasinya salah sejak awal. Saya memilih berhenti dan menulis ulang dari nol. Keputusan itu mahal, dan saya yakin itu benar. Menulis kode yang berfungsi bisa dipelajari siapa saja. Mengenali kapan kode yang berfungsi tetap harus dibuang adalah keterampilan yang berbeda, dan jauh lebih sulit. Pelajaran yang saya bawa: kualitas kode bukan hasil dari orang yang disiplin, melainkan hasil dari sistem yang membuat ketidakdisiplinan sulit dilakukan. Dan ada ironi yang tidak bisa saya hindari: beberapa bulan kemudian saya merancang kurikulum yang mengajarkan peninjauan sejawat kepada murid kelas 5 — praktik yang absennya justru menghancurkan proyek saya sendiri.

Dampak terkuatnya bukan angka:

Satu trade-off yang saya kalah: