Hashing Low Entropy Data & Credit Cards sa APAC

Narito ang hindi komportableng katotohanan: hindi pareho ang hashing at pagprotekta. Maaari kang mag-imbak ng SHA-256 hash ng credit card number, fully PCI DSS compliant, at walang epektibong proteksyon pa rin, dahil walang sapat na entropy ang value na ni-hash mo para labanan ang brute force.

Napapadapa rito ang mga maingat na engineering teams dahil feels na safe ang hashing. One-way ang hash, hindi mababawi ang original sa pagbaliktad ng function, kaya siguradong protected ang data, di ba? Ang depekto ay wala sa hash. Nasa pinakain mo dito.

Ang problema sa entropy, sa totoong numero #

Hindi random ang 16-digit card number. Pampubliko at fixed ang structure nito:

• Ang unang 4 hanggang 6 digits ang Issuer Identification Number (IIN): bank prefix, pampublikong-publiko.
• Ang huling digit ay checksum, kinukwenta ng Luhn algorithm, formula na nailabas noong 1954. Hindi ito sikreto; error detection ito.

Ngayon i-mask ang PAN sa karaniwang pinahihintulutan ng PCI DSS: unang 4-6 digits at huling 4 visible, gitnang 6-8 nakatago:

4532 AAXX XXXX 1234

Sa 4 digits lang ang alam sa IIN, natitirang unknown ay 8 digits, o pinakamarami 100,000,000 posibleng values. I-apply ang Luhn checksum at 1 sa 10 lang ang makakaligtas. Totoong search space mo ay 10 milyon values. Hindi iyan password. Napakaikling listahan iyan.

Gaano kabilis maitest ang 10 milyong hashes? #

Dito lalalim pa. Mabilis by design ang SHA-256. Ginawa para sa integrity checking sa gigabit speed, hindi para sa pag-iimbak ng mga sikreto. Publiko at reproducible ang modern GPU cracking benchmarks:

Sampung milyong hula hinati sa 8.5 bilyon kada segundo ay humigit kumulang isang libong bahagi ng isang segundo. Sa iisang consumer GPU. Kahit isang GPU computer lang ay kayang gumamit ng rainbow table para ‘i-un-hash’ ang credit card number sa kisap-mata.

Tumpol ang konklusyon: hindi secure ang compliant. Sa low-entropy fields, kahit SHA-2 (o SHA-3) ay hindi secure, kahit compliant pa ito. One-way nga ang function; napakadali lang nitong maubos kapag maliit ang input space. Hindi aayos ng problemang ito ang pagpapalit ng SHA-256 sa SHA-512 o SHA-3, dahil kasing bilis nila.

Ano talagang pinapayagan ng “compliant” #

Hindi talaga sinasabi ng PCI DSS na i-hash mo ang PANs gamit ang SHA-256. Sinasabi ng Requirement 3.5 na gawin mong unreadable ang PAN gamit ang strong cryptography, na eksplisitong bumanggit sa keyed hashes at encryption, at nagtatala na acceptable ang hashed and salted index kung lihim ang salt at hindi praktikal na nababaliktarin ang hash. Ang problema: ang hubad, unsalted SHA-256 ng 10-milyong-value space ay sa praktika ay reversible sa pamamagitan ng exhaustion, kaya nabibigo ito sa intent ng requirement kahit pasado ang checklist tick.

Ang masking (pagpapakita ng unang 4-6 at/o huling 4) ay hiwalay na control: pinoprotektahan nito ang nakikita ng operator, hindi ang iniimbak mo. Madaling magkamali sa dalawa, at sa kamalian ding iyon napupunta sa production ang masked-pero-bare-hashed na PANs.

Paano tamang iprotekta ang ganitong uri ng data #

Ang solusyon: tratuhin ang low-entropy fields gaya ng pagtrato mo sa password, dahil sa matematika, kasinghina sila. Ang mga opsyon, ayon sa preference:

1. Huwag talagang i-store. I-tokenise ang PAN at ilagay ang totoong numero sa hiwalay na vault o HSM. Kung hindi mo kailanman iniimbak ang value, walang pwedeng i-brute force.
2. Keyed hashing (HMAC) na may secret pepper. Kung kailangan mong mag-index base sa PAN, gumamit ng HMAC na may high-entropy key na nakalagay sa labas ng database. Walang key, computationally infeasible ang brute force anuman ang input entropy.
3. Memory-hard password hashing. Kapag kailangan mong iprotekta ang value gamit ang mismong value, gumamit ng Argon2id (RFC 9106) o scrypt na may per-value random salt at parameters na tinuning upang kada hula ay may tunay na gastos sa oras at memorya. Argon2id sa halimbawang 64 MB memory cost ay ginagawang buwan ng GPU time ang 0.001-segundong exhaustive search na iyon.
4. Salts at peppers sa lahat ng dako. Ang random salt kada value ay tatalo sa precomputed rainbow tables; secret pepper ang tuluyang tatalo sa offline attacks habang liham ito.

Inirerekomenda ng OWASP Password Storage Cheat Sheet at NIST SP 800-63B ang memory-hard functions para sa low-entropy secrets dahil eksaktong dahilang ito.

Aralin lampas sa mga card #

Umaabot ito sa bawat fixed-format identifier na limitado ang entropy: national ID numbers, phone numbers, dates of birth, at kahit API keys na mahina ang generation. Kung maliit ang input space, kalaban mo ang bilis ng hash function, at hindi synonym ng “safe” ang “compliant.”

Sinusuri ng API & Application Security Review amin kung paano talaga nag-iimbak at nagtutransmit ng sensitibong values ang code mo, at sasabihin namin nang tuwiran kung saan nag-iiwan ng exposed na totoong data ang pagpasa sa checklist.