- An ninh toàn diện, triển khai với trách nhiệm rõ ràng/
- Phân tích & Cảnh báo an ninh/
- Hash dữ liệu entropy thấp & thẻ tín dụng tại APAC/
Hash dữ liệu entropy thấp & thẻ tín dụng tại APAC
Mục lục
Một sự thật không dễ chịu: hash không đồng nghĩa với bảo vệ. Bạn có thể lưu hash SHA-256 của số thẻ tín dụng, hoàn toàn tuân thủ PCI DSS, và vẫn thực tế không có bất kỳ sự bảo vệ nào, vì giá trị bạn hash đơn giản không chứa đủ entropy để cưỡng lại brute force.
Điều này khiến cả những đội engineering cẩn trọng vấp ngã, vì hash cảm giác an toàn. Hash là một chiều, không thể khôi phục bản gốc bằng cách đảo ngược hàm, vậy chắc chắn dữ liệu được bảo vệ rồi. Lỗi không nằm ở hàm hash. Lỗi nằm ở thứ bạn nạp vào nó.
Bài toán entropy, bằng con số thực #
Số thẻ 16 chữ số không phải ngẫu nhiên. Cấu trúc của nó công khai và cố định:
- 4 đến 6 chữ số đầu là Issuer Identification Number (IIN): tiền tố ngân hàng, hoàn toàn công khai.
- Chữ số cuối là checksum, tính bằng thuật toán Luhn, công thức công bố từ 1954. Nó không phải bí mật; chỉ là phát hiện lỗi.
Bây giờ che PAN theo cách PCI DSS thường cho phép: 4-6 chữ số đầu và 4 chữ số cuối hiển thị, 6-8 chữ số giữa bị giấu:
4532 AAXX XXXX 1234
Khi chỉ biết 4 chữ số IIN, phần chưa biết còn 8 chữ số, tức nhiều nhất 100.000.000 giá trị khả dĩ. Áp checksum Luhn thì chỉ 1 trên 10 sống sót. Không gian tìm kiếm thật của bạn là 10 triệu giá trị. Đó không phải mật khẩu. Đó là một danh sách rất ngắn.
Kiểm thử 10 triệu hash mất bao lâu? #
Ở đây tình hình tệ hơn nữa. SHA-256 nhanh ngay trong thiết kế. Nó sinh ra cho kiểm tra toàn vẹn tốc độ gigabit chứ không phải lưu bí mật. Benchmark bẻ khóa GPU hiện đại công khai và tái lập được:
| Phần cứng | Thông lượng SHA-256 xấp xỉ |
|---|---|
| 1× GPU RTX 4090 | ~8,5 tỷ hash/giây |
| Cụm 4× RTX 4090 | ~34 tỷ hash/giây |
| Cụm 8× RTX 4090 | ~68 tỷ hash/giây |
Mười triệu phỏng đoán chia 8,5 tỷ mỗi giây khoảng một phần nghìn giây. Trên một GPU tiêu dùng thôi. Thậm chí một máy tính GPU đơn lẻ cũng dùng rainbow table ‘giải ngược’ số thẻ tín dụng trong chớp mắt.
Kết luận thẳng thắn: Tuân thủ không phải an toàn. Với trường entropi thấp, kể cả SHA-2 (hay SHA-3) cũng không an toàn, dù nó tuân thủ. Hàm vốn một chiều; chỉ là nó dễ dàng bị vét cạn khi không gian input nhỏ. Đổi SHA-256 sang SHA-512 hay SHA-3 không sửa được, vì chúng equally nhanh.
“Tuân thủ” thực ra cho phép gì #
PCI DSS thật ra không yêu cầu bạn hash PAN bằng SHA-256. Requirement 3.5 nói bạn phải làm PAN không đọc được bằng strong cryptography, rõ ràng nêu keyed hash và mã hóa, đồng thời ghi chú rằng index hashed and salted chấp nhận được nếu salt được giữ bí mật và hash không thể đảo ngược thực tế. Vấn đề: SHA-256 trần không salt trên không gian 10 triệu giá trị, trong thực tế, đảo ngược được bằng cách vét cạn, nên nó thất bại ý định của yêu cầu dù ô kiểm vẫn được tick.
Masking (hiện 4-6 chữ số đầu và/hoặc 4 cuối) là kiểm soát riêng: nó bảo vệ điều operator nhìn thấy, không phải thứ bạn lưu. Hai thứ này dễ nhầm lẫn, và chính sự nhầm lẫn đưa những PAN masked-nhưng-hash-trần vào production.
Cách bảo vệ loại dữ liệu này đúng đắn #
Cách sửa: đối xử với trường entropi thấp như với password, vì về mặt toán học chúng yếu như nhau. Các lựa chọn, theo thứ tự ưu tiên:
- Đừng lưu nó luôn. Tokenise PAN và giữ số thật trong vault hay HSM riêng. Nếu bạn chưa bao giờ lưu giá trị, không có gì để brute force.
- Keyed hashing (HMAC) với pepper bí mật. Nếu bắt buộc phải đánh chỉ mục theo PAN, dùng HMAC với khóa entropi cao đặt ngoài database. Không có khóa, brute force không khả thi về mặt tính toán bất kể entropy đầu vào.
- Password hashing memory-hard. Khi bạn chỉ có thể bảo vệ giá trị bằng chính giá trị đó, dùng Argon2id (RFC 9106) hay scrypt với salt ngẫu nhiên từng giá trị và tham số tinh chỉnh để mỗi phỏng đoán tốn thời gian và bộ nhớ thật. Argon2id với chi phí bộ nhớ chẳng hạn 64 MB biến cuộc vét cạn 0,001 giây kia thành hàng tháng thời gian GPU.
- Salt và pepper ở khắp nơi. Salt ngẫu nhiên từng giá trị đánh bại rainbow table tính trước; pepper bí mật đánh bại hoàn toàn tấn công offline miễn là giữ kín.
OWASP Password Storage Cheat Sheet và NIST SP 800-63B đều khuyến nghị hàm memory-hard cho bí mật entropi thấp đúng vì lý do này.
Bài học ngoài các thẻ #
Nguyên tắc này áp cho mọi định danh định dạng cố định có entropy hạn chế: số căn cước, số điện thoại, ngày sinh, thậm chí API key sinh kém. Nếu không gian input nhỏ, tốc độ hàm hash là kẻ thù của bạn, và “tuân thủ” không đồng nghĩa “an toàn”.
API & Application Security Review của chúng tôi soi cách mã bạn thật sự lưu và truyền giá trị nhạy cảm, và chúng tôi sẽ nói thẳng chỗ nào vượt checklist mà vẫn để lộ dữ liệu thật.