Have I Been Pwned 2.0

• Layanan pemeriksaan kebocoran data Have I Been Pwned telah diperbarui sepenuhnya dengan tampilan baru
• Bersamaan dengan desain baru, fitur halaman web utama diubah dan ditingkatkan secara besar-besaran
• Fitur pencarian kini lebih intuitif, dan panduan tentang cara memeriksa akun serta berbagai kasus data breach diperkuat
• Beragam fitur baru dan yang ditingkatkan seperti dasbor pengguna, pencarian domain, dan dokumentasi API telah ditambahkan
• Performa dan keamanan web dibangun di atas infrastruktur cloud modern, menghadirkan pengalaman pengguna yang cepat dan aman

---

Pengenalan dan latar belakang

• Have I Been Pwned (selanjutnya disebut HIBP) 2.0 dirilis ulang sepenuhnya setelah pengembangan dalam waktu lama
• Commit pertama dibuat pada Februari 2023, lalu setelah soft launch pada Maret 2024 dan proses open source, situs ini dibuka sebagai hasil rekonstruksi penuh dengan identitas merek baru
• Struktur dan fungsi seluruh situs dirombak, dan bersama fitur-fitur baru, toko merchandise juga resmi dibuka

Fitur pencarian

• Kolom pencarian utama, fitur paling khas HIBP, ditingkatkan agar lebih intuitif dengan presentasi yang lebih segar (animasi confetti)
• Untuk menghindari pengalaman yang terasa membebani, pendekatan yang berat dan bernuansa negatif dihindari, dan fokus diberikan pada penyediaan informasi praktis berbasis fakta bagi pengguna
• Pencarian username dan nomor telepon dihapus dari situs web (namun tetap dipertahankan di API seperti sebelumnya)
  • Pencarian berbasis alamat email lebih cocok dari sisi parsing, notifikasi, dan konsistensi layanan
  • Nomor telepon dan username membebani pemrosesan data serta nyaris tidak digunakan dalam praktik, sehingga dikeluarkan untuk mengurangi kebingungan

Halaman kasus data breach

• Setiap insiden breach (kebocoran) kini memiliki halaman detail khusus
• Dengan tata letak yang lebih intuitif dan enak dilihat dibanding sebelumnya, halaman ini memberikan panduan yang spesifik dan dapat langsung dijalankan tentang dampak yang dialami serta langkah penanganannya
• Informasi tambahan seperti panduan yang disesuaikan per wilayah direncanakan akan ditambahkan melalui kerja sama dengan lembaga lain (misalnya NCSC)
• Ke depannya, detail seperti dukungan 2FA, passkey, dan panduan yang disesuaikan untuk pengguna juga akan ditambahkan

Dasbor

• Berbagai fitur yang sebelumnya terpisah (pemeriksaan breach sensitif, pengelolaan domain, pengelolaan langganan, dll.) kini disatukan dalam dasbor terpadu
• Dasbor diakses berbasis verifikasi email, dan metode autentikasi baru seperti passkey juga direncanakan akan ditambahkan ke depan
• Ini juga membuka kemungkinan berkembang menjadi platform yang dapat diperluas, misalnya untuk notifikasi akun keluarga

Fitur pencarian domain

• Fitur verifikasi/pencarian domain dirancang ulang sepenuhnya, dengan UI yang lebih rapi dan dukungan berbagai filter (misalnya hanya melihat kebocoran terbaru)
• Dibangun dengan struktur single-page application (SPA) penuh, dan hasil pencarian disajikan cepat dalam format JSON melalui API
• Proses verifikasi kepemilikan domain juga disederhanakan dari awal
• Peningkatan untuk metode autentikasi selain email akan dilakukan secara terpisah

API

• Dalam pembaruan kali ini, tidak ada perubahan maupun penghentian apa pun pada API itu sendiri
• Dokumentasi API sedang dipersiapkan untuk mengadopsi alat Scalar berbasis OpenAPI, tetapi untuk saat ini dokumentasi lama tetap dipertahankan sambil diseragamkan ke gaya baru
• Nantinya akan beralih ke dokumentasi terbaru berbasis Scalar

Merchandise dan stiker

• Toko merchandise resmi dengan branding HIBP telah dibuka, dan penjualan produk seperti kaus sudah dimulai (berbasis Teespring, tanpa margin)
• Stiker tetap dijual melalui toko Sticker Mule, dan artwork-nya tersedia sebagai open source untuk digunakan secara bebas

Teknologi dan infrastruktur

• Backend situs dibangun di atas Microsoft Azure, menggunakan App Service, Functions, Hyperscale SQL, Storage, dan lainnya
• Aplikasi web utama ditulis dengan C# dan .NET 9.0, serta ASP.NET MVC (.NET Core)
• Cloudflare digunakan secara efektif untuk WAF, caching, Turnstile (anti-bot), penyimpanan R2, dan lain-lain
• Di sisi frontend, antarmuka modern dibangun dengan Bootstrap terbaru, SASS, dan TypeScript
• Kontribusi anggota inti seperti pengembang asal Islandia, Ingiber, menghasilkan tingkat penyelesaian yang tinggi dan UI yang indah
• Ukuran halaman web dan jumlah request masing-masing dikurangi sekitar 28% dan 31%, sehingga optimisasinya lebih efektif dibanding 11 tahun lalu
• Pelacakan, data iklan, dan elemen tidak perlu lainnya sepenuhnya dihilangkan, dengan penekanan kuat pada privasi pengguna

Pemanfaatan AI

• Dalam proses rebuild situs kali ini, Chat GPT dimanfaatkan secara aktif untuk menyelesaikan berbagai masalah pengembangan seperti CSS, rekomendasi ikon, pengaturan Cloudflare, dan kekhasan .NET Core
• Dengan saran cepat dari AI dan otomatisasi kode, produktivitas meningkat sangat besar
• Akurasi dan kegunaannya juga terbukti tinggi untuk migrasi cepat dan otomatisasi pekerjaan

Perjalanan pengembangan dan kesimpulan

• Berbagai pekerjaan yang tidak terlihat, seperti pembaruan dokumen hukum, memerlukan waktu dan biaya yang besar
• Menjelang dan setelah peluncuran, sejumlah perbaikan darurat dan rilis berulang dilakukan untuk menyelesaikan masalah dengan cepat
• Tanpa kehilangan semangat awal, peluncuran ulang ini berhasil menjaga profesionalisme layanan, skalabilitas, dan kenyamanan penggunaan
• HIBP adalah hasil dari gairah yang dicurahkan sejak 2013 selama seperempat perjalanan hidup, dan melalui versi 2.0 ini diharapkan melangkah naik lagi sebagai layanan komunitas

[GN⁺]

Opini Hacker News

• Ada yang membayangkan kalau bermitra dengan firma hukum, lalu membagikan ajakan untuk mendorong class action atas semua kebocoran data akibat kelalaian—yang pada praktiknya berarti hampir semua kasus—serta menghubungkannya dengan layanan perbankan pembayaran agar dana penyelesaian bisa langsung ditransfer ke jutaan orang, maka ini bisa menjadi tindakan seorang pahlawan modern. Ditekankan juga pentingnya bekerja sama dengan pengacara yang benar-benar mampu menjatuhkan putusan menyakitkan bagi perusahaan yang lalai; penyelesaian kecil semata berisiko membuat manajemen tidak bertanggung jawab terus berlanjut. Secara opsional, disebut juga kemungkinan menjual data terkait gugatan yang akan segera diajukan kepada perusahaan investasi. Pada akhirnya, diharapkan tercipta suasana sosial di mana berita kebocoran data saja sudah cukup untuk memukul harga saham perusahaan tersebut.
  • Ada harapan bahwa jika setiap kali dana penyelesaian cair, sebagian kecilnya bisa langsung didonasikan ke tempat yang baik, maka orang akan lebih termotivasi untuk ikut class action.
  • Soal layanan perbankan itu, ada gurauan cemas tentang berapa lama sampai data yang disimpan dalam sistem seperti itu juga ikut bocor.
  • Ada kekhawatiran sistem seperti ini justru bisa menjadi bumerang. Dalam situasi saat perusahaan saja sudah sulit untuk mengungkapkan fakta kebocoran, struktur semacam ini hanya akan memperbesar risiko dan membuat mereka makin menghindari pengungkapan. Menurut pendapat ini, lebih baik saya tahu informasi saya bocor dan bisa segera mengganti kata sandi.
  • Ada keluhan bahwa sampai sekarang masih menunggu hari ketika bisa mendapat kompensasi dari Blue Shield karena data pribadi dijual ke Google, sambil menyatakan minat untuk memakai layanan seperti ini.
• Ada yang terkejut bahwa bahkan dalam 10 tahun terakhir, situs sebesar LinkedIn pernah menyimpan kata sandi tanpa salt, dan mempertanyakan bagaimana kesalahan seperti itu masih bisa terjadi di zaman modern.
  • Dijelaskan bahwa hal seperti ini sebenarnya bisa terjadi jauh lebih mudah daripada yang dibayangkan. Dari sudut pandang middleware perantara, field password di dalam data JSON bisa saja terlihat hanya sebagai satu field biasa, dan jika API atau sistem logging mencatat seluruh request body, masalah nyata bisa muncul. Menyimpan kata sandi tanpa salt langsung di penyimpanan kata sandi memang jarang, tetapi misalnya pada API gateway aplikasi Android, jika alur seperti "lupa kata sandi" tidak ditandai sebagai informasi sensitif, masalah serupa bisa terjadi; ini dibagikan sebagai pengalaman pribadi.
  • Ada komentar bercanda bahwa kesalahan seperti ini terjadi karena dalam wawancara engineering tidak cukup banyak diberikan soal Leetcode Hard.
  • Banyak orang membicarakan AI Slop, tetapi ditunjukkan bahwa masalah Outsourced Slop juga sudah lama sangat serius. Berdasarkan pengalaman, sangat mungkin hasil kerja programmer outsourcing menjadi penyebab utama dalam kasus seperti LinkedIn juga. Ditegaskan bahwa hanya manajer yang kuat dan kompeten yang bisa menetapkan standar kualitas dan memverifikasinya agar tidak lahir produk yang dari luar tampak rapi tetapi di dalam rapuh.
  • Ada dugaan bahwa kesalahan seperti ini terjadi karena sistem lama yang dibangun di masa lalu—seperti legacy mainframe—dibiarkan begitu saja karena tidak ada yang bisa meluangkan waktu atau anggaran untuk pemeliharaan maupun migrasi. Makin besar perusahaan, makin kuat pula inersia atau pembekuan sistem pentingnya, sampai-sampai downtime sekitar satu jam saja dianggap sebagai "kerugian" bernilai jutaan won atau lebih, sehingga perbaikan justru makin mustahil; ini ditunjukkan sebagai masalah struktural.
• Banyak pengguna umum ternyata sering memakai Have I Been Pwned, dan menganggap arus masuk ke 1Password sebagai salah satu pilihan terbaik. Disebutkan bahwa promosi dengan 1Password memang kolaborasi yang sangat cocok. Ada saran agar teks banner itu diubah menjadi sesuatu seperti "sangat direkomendasikan" agar lebih menonjol. Ditekankan bahwa sebagian besar peretasan akun sosial terjadi karena penggunaan ulang kata sandi, dan dari pengalaman seperti itu, edukasi penggunaan kata sandi aman serta dorongan ke password manager sangat positif. Sambil mengucapkan selamat atas pembaruan ini, dibagikan juga pengalaman telah membantu menyelesaikan lebih dari sekitar 20 kasus nyata dalam setahun terakhir.
• Ada kekaguman pada fitur yang menampilkan seluruh riwayat kebocoran data dalam bentuk scroll vertikal lengkap dengan logo dan kalimat pengantar; terasa menyeramkan tetapi juga mengesankan.
  • Saat melihat daftar kebocoran data, ada rasa tak berdaya dan sinisme bahwa hampir tidak ada tindakan yang bisa diambil selain pembekuan kredit.
• Ada rasa penasaran siapa pemegang rekor riwayat kebocoran data terbanyak. Seseorang berbagi bahwa email utamanya sudah muncul dalam 40 kebocoran sejauh ini; yang paling lama dari Juni 2011 (HackForums, bahkan sudah tidak ingat), dan yang terbaru dari September 2024 (FrenchCitizens, tidak ada hubungannya dengan Prancis).
  • Ada balasan bahwa seseorang mengungguli rekor itu hanya selisih 1.
  • Dibagikan juga rekor mengejutkan bahwa email [e-mail] tercatat dalam 322 kebocoran.
• Bagi yang menginginkan privasi lebih, ada tips bahwa layanan ini memiliki fitur opt-out untuk menyembunyikan hasil pencarian email di dalam layanan tersebut.
• Karena memakai beberapa alias email, ada harapan agar tersedia fitur pencarian berdasarkan domain supaya tidak perlu mencari satu per satu.
  • Dijelaskan bahwa di bawah panduan "The Domain Search Feature", setelah memverifikasi kepemilikan domain, hasil bisa dilihat sekaligus.
• Ada kesan bahwa ini benar-benar situs yang hebat, sekaligus harapan agar pemerintah menanggapi masalah seperti ini dengan lebih serius. Pencurian identitas, pengambilalihan akun, dan masalah serupa pada akhirnya bermula dari kebocoran data, dan di zaman sekarang pembobolan akun digital adalah bencana yang lebih serius daripada pencurian ke rumah secara fisik. Jika terjadi penyusupan fisik, ada 911 dan prosedur pelaporan serta pelacakan yang jelas, tetapi untuk pelanggaran digital tidak ada kontak yang jelas dan hampir tidak ada proses penyelesaian; karena itu didorong agar respons sosial berubah.
• Desain pembaruan ini dinilai sangat positif, dan mengikuti update dari Troy juga menyenangkan, meski kadang terasa seperti black humor yang menarik. Ada pengalaman kebingungan karena timeline tampaknya diurutkan dari kebocoran paling lama ke yang terbaru, tetapi penanggalannya ternyata merujuk bukan pada saat data bocor melainkan saat kebocoran itu diungkap ke publik. Sebagai solusi, disarankan agar pengurutan dan penandaan sama-sama berbasis "tanggal pengungkapan", sementara di dalam kartu tetap dicantumkan tanggal kebocoran sebenarnya dalam format standar agar lebih jelas.