Hashing Data Entropi Rendah & Kartu Kredit di APAC

Fakta yang tidak nyaman: hashing bukan sama dengan melindungi. Anda bisa menyimpan hash SHA-256 dari nomor kartu kredit, sepenuhnya patuh PCI DSS, dan tetap praktis tanpa perlindungan sama sekali, karena nilai yang Anda hash tidak mengandung entropi yang cukup untuk menahan brute force.

Ini menjatuhkan tim engineering yang sebenarnya teliti, karena hashing terasa aman. Hash itu satu arah, asalnya tak bisa dipulihkan dengan membalik fungsi, jadi tentu saja datanya terlindungi. Cacatnya bukan pada hash. Cacatnya pada apa yang Anda masukkan ke dalamnya.

Masalah entropi, dalam angka nyata #

Nomor kartu 16 digit bukan angka acak. Strukturnya publik dan tetap:

• 4 hingga 6 digit pertama adalah Issuer Identification Number (IIN): prefiks bank, sepenuhnya publik.
• Digit terakhir adalah checksum, dihitung dengan algoritma Luhn, rumus yang dipublikasikan tahun 1954. Ia bukan rahasia; ia deteksi kesalahan.

Sekarang mask PAN seperti yang lazim diizinkan PCI DSS: 4 hingga 6 digit pertama dan 4 digit terakhir terlihat, 6 hingga 8 digit tengah tersembunyi:

4532 AAXX XXXX 1234

Dengan hanya 4 digit IIN yang diketahui, yang tak diketahui tersisa 8 digit, atau paling banyak 100.000.000 kemungkinan nilai. Terapkan checksum Luhn dan hanya 1 dari 10 yang bertahan. Ruang pencarian Anda yang sesungguhnya: 10 juta nilai. Itu bukan password. Itu daftar yang sangat pendek.

Seberapa cepat 10 juta hash bisa diuji? #

Di sini keadaannya makin buruk. SHA-256 cepat memang by design. Ia dibangun untuk pemeriksaan integritas pada kecepatan gigabit, bukan untuk menyimpan rahasia. Benchmark cracking GPU modern bersifat publik dan reproducible:

Sepuluh juta tebakan dibagi 8,5 miliar per detik kira-kira seperseribu detik. Pada satu GPU konsumen. Bahkan komputer ber-GPU tunggal bisa memakai rainbow table untuk ‘membalik’ hash kartu kredit dalam sekejap mata.

Kesimpulannya tumpul: Patuh bukan berarti aman. Pada field entropi rendah, bahkan SHA-2 (atau SHA-3) tidak aman, bahkan saat patuh. Fungsinya memang satu arah; ia hanya mudah dihabiskan ketika ruang input kecil. Mengganti SHA-256 dengan SHA-512 atau SHA-3 tidak menyelesaikan ini, karena sama cepatnya.

Apa yang benar-benar diizinkan oleh “patuh” #

PCI DSS sebenarnya tidak memerintahkan Anda meng-hash PAN dengan SHA-256. Requirement 3.5 menyatakan Anda harus membuat PAN tak terbaca menggunakan strong cryptography, yang secara eksplisit menyebut keyed hash dan enkripsi, serta mencatat bahwa indeks hashed and salted dapat diterima bila salt dirahasiakan dan hash tidak praktis dibalikkan. Masalahnya: SHA-256 polos tanpa salt atas ruang 10 juta nilai itu, dalam praktik, bisa dibalikkan lewat kehabisan-coba, sehingga ia gagal pada niat persyaratan meskipun kotak centang lolos.

Masking (menampilkan 4-6 digit pertama dan/atau 4 terakhir) adalah kontrol terpisah: ia melindungi apa yang dilihat operator, bukan apa yang Anda simpan. Keduanya mudah tertukar, dan kekeliruan itulah cara PAN termasked-tapi-hash-polos berakhir di produksi.

Cara melindungi data semacam ini dengan benar #

Solusinya: perlakukan field entropi rendah dengan penghormatan yang sama seperti password, karena secara matematis mereka sama lemahnya. Opsinya, urut dari yang terbaik:

1. Jangan simpan sama sekali. Tokenisasikan PAN dan simpan nomor aslinya di vault atau HSM terpisah. Bila Anda tak pernah menyimpan nilainya, tak ada yang bisa di-brute force.
2. Keyed hashing (HMAC) dengan pepper rahasia. Bila Anda harus mengindeks berdasarkan PAN, gunakan HMAC dengan kunci entropi tinggi yang disimpan di luar database. Tanpa kuncinya, brute force tidak feasible secara komputasional apa pun entropi inputnya.
3. Password hashing memory-hard. Saat Anda hanya bisa melindungi nilai dengan nilai itu sendiri, gunakan Argon2id (RFC 9106) atau scrypt dengan salt acak per nilai dan parameter yang dituning agar setiap tebakan memakan waktu dan memori sungguhan. Argon2id dengan biaya memori misalnya 64 MB mengubah pencarian habis-coba 0,001 detik itu menjadi berbulan-bulan waktu GPU.
4. Salt dan pepper di mana-mana. Salt acak per nilai menaklukkan rainbow table pra-komputasi; pepper rahasia menaklukkan serangan offline sepenuhnya selama tetap rahasia.

OWASP Password Storage Cheat Sheet dan NIST SP 800-63B keduanya merekomendasikan fungsi memory-hard untuk rahasia entropi rendah justru karena alasan ini.

Pelajaran di luar kartu #

Ini berlaku untuk setiap pengenal berformat tetap dengan entropi terbatas: nomor identitas nasional, nomor telepon, tanggal lahir, bahkan API key dengan generasi yang buruk. Jika ruang input kecil, kecepatan fungsi hash adalah musuh Anda, dan “patuh” bukan sinonim “aman”.

API & Application Security Review kami memeriksa bagaimana kode Anda benar-benar menyimpan dan mengirim nilai sensitif, dan kami akan berkata lugas di titik mana kelulusan checklist masih membiarkan data nyata terekspos.