Encoding, hashing và encryption là ba việc khác nhau
Hầu như mọi hiểu lầm trên trang này đều bắt nguồn từ việc coi ba thứ này là một, nên đáng để phân biệt cho rõ.
Encoding (mã hóa ký tự) đảo ngược được và không chứa bí mật nào. Base64 sinh ra để chuyển dữ liệu nhị phân qua những kênh chỉ nhận văn bản — file đính kèm email, data URI, chuỗi JSON — bằng cách biểu diễn mỗi ba byte thành bốn ký tự, nên kết quả luôn lớn hơn khoảng một phần ba. Không có khóa nào cả. Ai nhìn thấy chuỗi đó cũng giải mã được chỉ trong một bước, kể cả trên trang này. Base64 không phải là bảo mật, không đáng gọi là làm rối mã, và không che giấu được gì trước bất kỳ ai chịu nhìn. Mã hóa phần trăm (percent-encoding) là thứ tương tự dành cho URL, và đó là nơi có một lỗi phổ biến khác: mã hóa một giá trị đưa vào query string là thao tác khác với làm sạch cả một URL đã ghép xong, vì chỉ thao tác đầu mới escape các ký tự &, =, ? và / vốn tạo nên cấu trúc của URL. Làm sai thì “Smith & Sons” sẽ tới máy chủ dưới dạng hai tham số thay vì một giá trị.
Hashing (băm) là một chiều và cũng không có khóa. Hàm băm nhận bất kỳ đầu vào nào và tạo ra một dấu vân tay có độ dài cố định, và không có cách nào đảo ngược — không phải vì nó được mã hóa, mà vì thông tin đã mất. Điều bạn có thể làm là đoán đầu vào rồi so sánh, và chính điều đó khiến MD5, SHA-1 và SHA-256 không phù hợp để lưu mật khẩu: chúng rất nhanh, một card đồ họa tính được hàng tỷ mã mỗi giây, và một bảng mã hash bị đánh cắp sẽ bị bẻ với tốc độ đó. Mật khẩu cần một hàm cố tình chậm và có salt — bcrypt, scrypt hoặc Argon2. Ngoài ra, MD5 và SHA-1 bị phá vì một lý do khác: giờ đây người ta có thể cố ý tạo ra hai file khác nhau có cùng mã hash, nên không thuật toán nào trong hai có thể chứng minh một file đúng là file bạn mong đợi, dù cả hai vẫn ổn để phát hiện một file tải về bị hỏng do vô tình.
Encryption (mã hóa bảo mật) là thứ duy nhất có khóa, và không công cụ nào ở đây làm việc đó. Đây không phải thiếu sót. Mã hóa đúng cách đòi hỏi quản lý khóa, và một trang web không phải nơi để giữ khóa.
JWT được ký chứ không được mã hóa, và điều này khiến rất nhiều người nhầm. Phần header và payload của token là Base64URL — ai giữ token cũng đọc được, không cần khóa. Chữ ký ngăn người khác sửa token; nó không hề ngăn họ đọc, nên không có gì bí mật nên nằm trong payload. Từ đó suy ra việc giải mã một token hoàn toàn không chứng minh được gì về nó: ai cũng có thể viết bất kỳ claim nào họ muốn rồi mã hóa Base64. Xác minh nghĩa là tính lại chữ ký bằng khóa của bên phát hành, và đó là việc máy chủ của bạn làm, một website không bao giờ được hỏi bạn thứ đó. Vì vậy công cụ giải mã của chúng tôi không ngụ ý là đã xác minh, và đánh dấu những dạng cho thấy có vấn đề — token đã hết hạn, token không có thời hạn nào, và thuật toán “none”, vốn là một cách vượt qua xác thực đã được ghi nhận chứ không phải chuyện lạ cho vui.
JSON có giới hạn độ chính xác của số mà phần lớn công cụ định dạng lặng lẽ vấp phải. Bản thân JSON không giới hạn độ lớn của số, nhưng số trong JavaScript là số thực 64-bit, nên số nguyên chỉ giữ chính xác đến 9.007.199.254.740.991. ID bài đăng Twitter, snowflake của Discord, khóa cơ sở dữ liệu 64-bit hay số tài khoản ngân hàng đều lớn hơn thế, và đưa nó qua công cụ định dạng một dòng thông thường — parse rồi stringify — sẽ làm đổi mấy chữ số cuối. Kết quả vẫn trông như một con số hợp lý, và chính điều đó mới nguy hiểm: 7205759403792793600 lặng lẽ thành 7205759403792793000. Các công cụ JSON của chúng tôi ghi lại đúng các chữ số bạn đã dán và cho biết đã phải bảo vệ bao nhiêu con số.
Phiên bản UUID cho biết nó được tạo ra thế nào, không phải nó đảm bảo điều gì. Không có gì đăng ký UUID hay bắt buộc tính duy nhất; tính duy nhất chỉ là xác suất, và phiên bản cho biết các bit đến từ đâu. Phiên bản 4 gồm 122 bit ngẫu nhiên từ bộ sinh số mật mã của trình duyệt, nên không đoán được và vì thế phù hợp cho link đặt lại mật khẩu, mã mời và mọi thứ cần bí mật — nhưng không phù hợp làm khóa cơ sở dữ liệu, vì khóa ngẫu nhiên nằm rải rác trong chỉ mục đã sắp xếp và làm nó bị phân mảnh. Phiên bản 7 đặt dấu thời gian 48 bit tính theo mili giây lên đầu, nên khóa được thêm vào cuối chỉ mục giống số nguyên tự tăng mà vẫn duy nhất toàn cục. Đổi lại, UUID v7 cho bất kỳ ai có nó biết rõ thời điểm nó được tạo, chính xác đến từng mili giây.
Khi nào trình duyệt thực sự không phải công cụ phù hợp
Không công cụ nào trong mười ba công cụ này gửi gì đi đâu cả. Không có yêu cầu mạng nào, không ghi log gì, và các trang vẫn hoạt động khi đã ngắt mạng — đó chính là lý do bạn có thể dùng chúng với một phản hồi API đầy dữ liệu khách hàng hay một token mà bạn sẽ không gửi email cho ai. Đó là lý lẽ thật lòng ủng hộ chúng. Còn đây là lý lẽ thật lòng phản đối.
Dán một secret đang dùng trên môi trường production vào một trang web là thói quen không nên có — kể cả trang này. Cam kết về quyền riêng tư của chúng tôi là thật, nhưng thứ bảo vệ bạn không phải lời cam kết mà là cách mã nguồn hoạt động, và thái độ hợp lý duy nhất với bất kỳ trang web nào là kiểm tra thay vì tin. Việc kiểm tra không tốn gì: ngắt kết nối internet sau khi trang đã tải xong và xem các công cụ này vẫn tiếp tục chạy. Một công cụ cần máy chủ sẽ ngừng hoạt động. Và nếu một thông tin xác thực vẫn còn hiệu lực mà bạn đã lỡ dán vào nơi không kiểm chứng được, việc đúng là thay mới nó, chứ không phải ngồi suy đoán. Với một token đang có hiệu lực ngay lúc này, giải mã tại máy — bằng hàm Base64 có sẵn trong ngôn ngữ lập trình của bạn, hoặc hai dòng lệnh trong shell — là cách làm tốt hơn mọi website, kể cả của chúng tôi.
Kiểm tra theo schema. Các công cụ JSON và XML của chúng tôi kiểm tra tài liệu có đúng cú pháp hay không, đó là câu hỏi khác với việc nó có khớp với một schema hay không. Kiểm tra theo JSON Schema hoặc XSD nghĩa là phải tải về và áp dụng một file schema, tức là một yêu cầu mạng mà các trang này cố ý không bao giờ thực hiện. Hãy dùng ajv cho JSON Schema và xmllint cho XSD và DTD; cả hai đều miễn phí và đều làm việc này tốt hơn một trang web có thể làm.
Bất cứ thứ gì thực sự lớn, hoặc cần xử lý theo luồng. Tài liệu được giữ nguyên vẹn trong bộ nhớ, đôi khi là hai bản khi đang định dạng, nên giới hạn là tab trình duyệt. Vài megabyte thì xong ngay, vài trăm megabyte thì không. jq xử lý theo luồng một file JSON nhiều gigabyte mà không trình duyệt nào mở nổi, và ripgrep tìm trong cả một repository nhanh hơn thời gian bạn dán một file. Việc tạo mã hash gặp phiên bản khắt khe hơn của cùng giới hạn này: mật mã của trình duyệt không hỗ trợ tính digest từng phần, nên cả file phải nằm vừa trong bộ nhớ cùng lúc — một file ảnh đĩa DVD sẽ thất bại, trong khi sha256sum, shasum hay certutil xử lý theo luồng mà chẳng hề hấn gì.
Tự động hóa và CI. Các công cụ này chạy khi có người bấm. Định dạng mọi file trong một repository, tạo mười nghìn UUID cho dữ liệu mẫu, hay kiểm tra JSON trong pipeline là việc của script: jq, xmllint, uuidgen, openssl và lệnh base64 đã có sẵn trên hầu hết các máy.
Xác minh bất cứ thứ gì có chữ ký. Xác minh chữ ký, chuỗi chứng chỉ và mọi thứ cần khóa bí mật nên được thực hiện trên máy chủ của bạn, bằng một thư viện được bảo trì. Trang này sẽ cho bạn biết token tuyên bố điều gì; nó sẽ không bao giờ nói với bạn rằng token là thật, và bạn nên nghi ngờ bất kỳ trang nào nói làm được điều đó mà không cần khóa của bạn.
Chọn giữa những công cụ nghe na ná nhau
Định dạng JSON hay Kiểm tra JSON. Cùng một bộ phân tích, khác câu hỏi. Định dạng JSON dùng để đọc và định hình lại một tài liệu đã phân tích được — thụt lề, thu gọn, giữ nguyên các số lớn. Kiểm tra JSON dành cho tài liệu không phân tích được, và kết quả là dòng, cột, ký tự gây lỗi với dấu mũ bên dưới, và nguyên nhân nào trong bốn nguyên nhân thường gặp. Nếu bạn đang nhìn chằm chằm vào “Unexpected token”, thứ bạn cần là Kiểm tra JSON. Cách phân chia tương tự áp dụng cho Định dạng XML và Kiểm tra XML.
Giải mã Base64 hay Giải mã JWT. JWT gồm ba phần Base64URL, nên công cụ giải mã chung sẽ cho bạn thấy từng phần. Trang JWT tách chúng ra giúp bạn, định dạng JSON, đổi các claim hết hạn, thời điểm phát hành và thời điểm bắt đầu hiệu lực từ dấu thời gian Unix thành ngày giờ thực theo múi giờ của bạn, ghi nhãn các claim đã đăng ký, và cảnh báo về việc hết hạn và thuật toán “none”. Dùng công cụ giải mã chung cho một khối Base64, và trang JWT cho token.
Mã hóa Base64 hay Mã hóa URL. Hai việc khác nhau cùng tạo ra văn bản “an toàn”. Base64 biến byte bất kỳ thành văn bản với cái giá là tăng 33 phần trăm dung lượng, và Base64 chuẩn hoàn toàn không an toàn trong URL — các ký tự +, / và = của nó đều mang nghĩa riêng ở đó, vì vậy mới có Base64URL. Mã hóa phần trăm để nguyên văn bản dễ đọc và chỉ escape những gì sẽ làm hỏng URL, đó là thứ bạn cần cho từ khóa tìm kiếm, địa chỉ email hay đích chuyển hướng. Mã hóa cả một file để đưa vào query string thường là dấu hiệu lẽ ra nó phải nằm trong phần thân yêu cầu.
Tạo mã hash hay Tạo UUID. Mã hash được suy ra từ đầu vào, nên cùng một đầu vào luôn cho cùng một giá trị — đó là điều biến nó thành dấu vân tay, phù hợp để xác minh file tải về hoặc loại bỏ nội dung trùng lặp. UUID là giá trị ngẫu nhiên mới, không liên quan đến thứ gì, nên không bao giờ lặp lại. Nếu bạn muốn cùng một mã định danh cho cùng một nội dung, hãy băm nó. Nếu bạn muốn một mã định danh mới, hãy tạo UUID.
Tạo mã QR hay Tạo mã vạch. QR là một lưới hai chiều chứa văn bản tùy ý — một URL, thông tin Wi-Fi, một số điện thoại — và được đọc bằng camera điện thoại. Trang mã vạch tạo các mã một chiều dùng trong bán lẻ và logistics: EAN-13, EAN-8, UPC-A, ITF-14, Code 128 và Code 39, có tính chữ số kiểm tra cho mã bán lẻ, và một dãy số sai hoặc thiếu sẽ bị từ chối thay vì lặng lẽ được đệm thêm thành một mã vạch hợp lệ của một sản phẩm khác.