Penghasilan Data Entropi Rendah & Kad Kredit di APAC

Berikut fakta yang tidak selesa: menghasilkan hash bukan sama dengan melindungi. Anda boleh menyimpan hash SHA-256 bagi nombor kad kredit, patuh sepenuhnya PCI DSS, dan tetap tiada perlindungan berkesan langsung, kerana nilai yang anda hasilkan hash tidak mengandungi entropi yang mencukupi untuk menahan serangan brute force.

Ini menjatuhkan pasukan kejuruteraan yang teliti kerana hash terasa selamat. Hash itu sehala, asal tidak boleh dipulihkan dengan membalikkan fungsi, jadi tentunya data dilindungi. Kelemahannya bukan pada hash. Kelemahannya pada apa yang anda suapkan kepadanya.

Masalah entropi, dalam angka sebenar #

Nombor kad 16 digit bukan rawak. Strukturnya awam dan tetap:

• 4 hingga 6 digit pertama ialah Nombor Identifikasi Penerbit (IIN): awalan bank, sepenuhnya awam.
• Digit terakhir ialah checksum, dikira oleh algoritma Luhn, formula yang diterbitkan pada 1954. Ia bukan rahsia; ia pengesanan ralat.

Sekarang topengkan PAN seperti yang lazim dibenarkan PCI DSS: 4 hingga 6 digit pertama dan 4 digit terakhir kelihatan, 6 hingga 8 digit tengah tersembunyi:

4532 AAXX XXXX 1234

Dengan hanya 4 digit IIN diketahui, yang tidak diketahui ialah 8 digit, atau paling banyak 100,000,000 nilai mungkin. Guna checksum Luhn dan hanya 1 daripada 10 yang terselamat. Ruang carian sebenar anda ialah 10 juta nilai. Itu bukan kata laluan. Itu senarai yang sangat pendek.

Berapa pantas 10 juta hash boleh diuji? #

Di sinilah keadaan bertambah buruk. SHA-256 laju secara reka bentuk. Ia dibina untuk semakan integriti pada kelajuan gigabit, bukan untuk menyimpan rahsia. Penanda aras pemecah GPU moden adalah awam dan boleh direproduksi:

Sepuluh juta tekaan dibahagi 8.5 bilion sesaat kira-kira satu per seribu saat. Pada satu GPU pengguna sahaja. Malah komputer satu GPU boleh guna rainbow table untuk ’nyah-hash’ nombor kad kredit dalam sekejap mata.

Kesimpulannya tumpul: Patuh bukan selamat. Pada medan entropi rendah, walaupun SHA-2 (atau SHA-3) tidak selamat, walaupun ia patuh. Fungsi itu sehala; ia cuma mudah habis dicuba apabila ruang input kecil. Menukar SHA-256 kepada SHA-512 atau SHA-3 tidak membaiki ini, kerana mereka sama lajunya.

Apa yang “patuh” benar-benar benarkan #

PCI DSS sebenarnya tidak meminta anda menghasilkan hash PAN dengan SHA-256. Keperluan 3.5 menyatakan anda mesti menjadikan PAN tidak boleh dibaca menggunakan kriptografi kukuh, yang secara eksplisit menyebut hash berkunci dan penyulitan, serta memaklumkan bahawa indeks hash dan salt adalah boleh diterima di mana salt dirahsiakan dan hash tidak praktikal boleh dibalikkan. Masalahnya: SHA-256 kosong tanpa salt atas ruang 10 juta nilai itu, secara praktikal, boleh dibalikkan melalui kehabisan-cubaan, jadi ia gagal niyat keperluan walaupun tanda semak senarai lepas.

Penopengan (memaparkan 4-6 pertama dan/atau 4 terakhir) ialah kawalan berasingan: ia melindungi apa yang dilihat oleh pengendali, bukan apa yang anda simpan. Kedua-duanya mudah dikelirukan, dan kekeliruan itulah cara PAN bertopeng-tetapi-hash-kosong berakhir di produksi.

Cara melindungi data jenis ini dengan betul #

Pembaikannya: rawat medan entropi rendah dengan penghormatan yang sama seperti kata laluan, kerana dari segi matematik ia sama lemahnya. Pilihan, mengikut keutamaan:

1. Jangan simpan langsung. Tokenisasikan PAN dan simpan nombor sebenar dalam vault atau HSM berasingan. Jika anda tidak pernah menyimpan nilainya, tiada apa untuk dipecahkan secara brute force.
2. Hash berkunci (HMAC) dengan pepper rahsia. Jika anda mesti mengindeks mengikut PAN, guna HMAC dengan kunci entropi tinggi yang disimpan di luar pangkalan data. Tanpa kunci itu, brute force tidak feasil secara komputasi tanpa kira entropi input.
3. Hash kata laluan memory-hard. Di mana anda perlu melindungi nilai dengan nilai itu sendiri, guna Argon2id (RFC 9106) atau scrypt dengan salt rawak setiap nilai dan parameter yang ditala supaya setiap tekaan memakan masa dan memori sebenar. Argon2id pada kos memori 64 MB menukar carian habis-cubaan 0.001 saat itu kepada bulan masa GPU.
4. Salt dan pepper di merata tempat. Salt rawak setiap nilai menewaskan rainbow table pra-pengiraan; pepper rahsia menewaskan serangan luar talian sepenuhnya selagi ia kekal rahsia.

OWASP Password Storage Cheat Sheet dan NIST SP 800-63B kedua-duanya mengesyorkan fungsi memory-hard bagi rahsia entropi rendah atas sebab yang sama.

Pelajaran melangkaui kad #

Ia terpakai kepada setiap pengecam format tetap dengan entropi terhad: nombor kad pengenalan negara, nombor telefon, tarikh lahir, malah kunci API dengan penjanaan lemah. Jika ruang input kecil, kelajuan fungsi hash ialah musuh anda, dan “patuh” bukan sinonim “selamat”.

Semakan Keselamatan API & Aplikasi kami mengkaji bagaimana kod anda sebenarnya menyimpan dan menghantar nilai sensitif, dan kami akan memberitahu anda dengan jelas di mana lulus senarai semak masih mendedahkan data sebenar.