Công cụ dành cho nhà phát triển · Trình tạo UUID
UUID dựa trên tên (v3 và v5): ID xác định từ không gian tên
· Lý lịch
uuid mật mã browser-apis
Khi cùng một bản ghi bên ngoài phải luôn có cùng một mã định danh thì UUID ngẫu nhiên sẽ không hoạt động. Phiên bản 3 và 5 UUID băm một vùng tên và tên thành một ID ổn định; bài đăng này giải thích cách thức và thời điểm sử dụng chúng.
Nhập lại cùng một khách hàng hai lần — vấn đề trùng lặp mà ID xác định có thể giải quyết
Quy trình nhập dữ liệu nhận hồ sơ khách hàng từ hệ thống bên ngoài có ID bên ngoài ổn định trong hệ thống đó. Nếu bạn tạo UUID ngẫu nhiên mới cho mỗi lần nhập, việc nhập cùng một khách hàng hai lần sẽ tạo ra hai số nhận dạng khác nhau và các bản ghi trùng lặp. Sự trùng lặp này chảy xuống các hệ thống báo cáo, thanh toán và hỗ trợ. Nếu bạn lấy UUID từ ID bên ngoài của khách hàng và vùng tên ổn định đại diện cho nguồn nhập của bạn thì mỗi lần nhập đều tạo ra UUID giống nhau cho cùng một khách hàng, cho phép bạn xác định và cập nhật các bản ghi hiện có. Tính xác định này là đặc điểm xác định của UUID v3 và v5: chúng không được tạo độc lập mà xuất phát từ đầu vào và cùng một đầu vào luôn tạo ra UUID giống hệt nhau.
Không gian tên cộng với tên - cách nối và băm dữ liệu đầu vào cũng như lý do tại sao không gian tên ngăn chặn xung đột giữa các nguồn khác nhau
v3 hoặc v5 UUID có nguồn gốc từ ba thành phần: vùng tên UUID (thường được xác định trước), tên (chuỗi byte bất kỳ) và thuật toán băm (MD5 cho v3, SHA-1 cho v5). Ghép nối 16 bytes của không gian tên UUID với UTF-8 byte của tên, băm phép nối, lấy 16 bytes đầu tiên của kết quả băm và hiểu các byte đó là UUID với phiên bản nibble được đặt thành 3 hoặc 5. Không gian tên phân vùng không gian ID: các UUID v5 từ không gian tên DNS không bao giờ xung đột với các UUID v5 từ không gian tên URL. RFC 9562 xác định bốn không gian tên được xác định trước: theo DNS tên, bởi URL, bởi OID và theo X.500 tên phân biệt. Các tổ chức có thể tạo ra không gian tên của riêng mình bằng cách tạo v4 UUID.
MD5 trong v3 và SHA-1 trong v5 — tại sao hàm băm yếu lại được chấp nhận ở đây vì ID không phải là biện pháp kiểm soát bảo mật
Phiên bản 3 sử dụng MD5 và phiên bản 5 sử dụng SHA-1, các lựa chọn kể từ ngày đặc tả và các triển khai có sẵn. Đối với UUID dựa trên tên, sự khác biệt này không quan trọng vì hàm băm không phải là ranh giới bảo mật hoặc kiểm soát mật mã. UUID không chứng minh được tính xác thực hoặc tính toàn vẹn; nó chỉ đơn giản là chuyển đổi một chuỗi có độ dài thay đổi thành giá trị 128-bit cố định. Mô hình tấn công không liên quan vì UUID được lưu trữ và so sánh dưới dạng các giá trị không rõ ràng, không phải dưới dạng bằng chứng hoặc biện pháp kiểm soát bảo mật. Việc triển khai mới nên sử dụng v5 (SHA-1) thay vì v3 (MD5), không phải vì lý do bảo mật thuyết phục mà vì v5 là tiêu chuẩn hiện đại và được cung cấp rộng rãi.
Các không gian tên được xác định trước — DNS, URL, OID và X.500 và thời điểm tạo ra không gian tên của riêng bạn
RFC 9562 chỉ định chính xác bốn UUID không gian tên được xác định trước với các biểu diễn byte cụ thể: 6ba7b810-9dad-11d1-80b4-00c04fd430c8 cho DNS, 6ba7b811-9dad-11d1-80b4-00c04fd430c8 cho URL, 6ba7b812-9dad-11d1-80b4-00c04fd430c8 cho OID và 6ba7b814-9dad-11d1-80b4-00c04fd430c8 cho X.500 tên phân biệt. v5 UUID bắt nguồn từ vùng tên DNS và tên www.example.com sẽ luôn giống hệt nhau và sẽ không bao giờ xung đột với v5 UUID từ vùng tên URL. Việc sử dụng không gian tên được xác định trước sẽ đảm bảo khả năng tương tác: nếu nhiều nhóm sử dụng v5 độc lập với không gian tên DNS, thì họ sẽ tạo các UUID giống hệt nhau cho cùng tên DNS. Việc chọn hoặc tạo ra một không gian tên là một phần của thiết kế lược đồ.
Ví dụ đã hoạt động — lấy khái niệm v5 UUID từ không gian tên URL và bản ghi URL, từng bước một
Rút ra v5 UUID về mặt khái niệm từ không gian tên URL và tên https://example.com/api/users/42. Không gian tên UUID là 16 bytes là 6b a7 b8 11 9d ad 11 d1 80 b4 00 c0 4f d4 30 c8. Tên là chuỗi UTF-8 https://example.com/api/users/42, là 30 bytes. Ghép các byte không gian tên (16) và byte tên (30) để có tổng số 46 bytes. Tính toán hàm băm SHA-1, tạo ra hàm băm 20 byte. Lấy 16 bytes đầu tiên và hiểu chúng là UUID với phiên bản nibble được đặt thành 5 và các bit biến thể được đặt thành tiêu chuẩn RFC. Tính toán lại với đầu vào giống hệt nhau sẽ tạo ra kết quả giống hệt nhau. Hầu hết các nhà phát triển sử dụng thư viện ngôn ngữ UUID của họ để tính toán v5.
Trường hợp mẫu bị phá vỡ - khi tên thay đổi, khi không gian tên không nhất quán giữa các nhóm và khi thông tin đầu vào là bí mật
UUID dựa trên tên giả định rằng tên này ổn định và nhất quán trên các hệ thống và các lần nhập. Nếu cùng một bản ghi bên ngoài có các tên khác nhau trong các hệ thống khác nhau, việc tạo v5 từ mỗi tên sẽ tạo ra các UUID khác nhau và không thể xác định được cùng một người. Nếu một không gian tên không được các nhóm thống nhất (mỗi nhóm tạo ra không gian tên riêng cho cùng một nguồn), họ sẽ tạo ra các UUID khác nhau và không khớp với các bản ghi. Nếu đầu vào là dữ liệu nhạy cảm, việc tạo v5 UUID có nghĩa là UUID là giá trị công khai, xác định mà bất kỳ ai cũng có thể tra cứu nếu họ biết đầu vào. Tính xác định bị phá vỡ khi đầu vào thay đổi hoặc định nghĩa vùng tên không nhất quán.
Điều này không bao gồm những gì — trình tạo ToolAcre lấy từ CSPRNG, vì vậy ID dựa trên tên cần có thư viện UUID trong ngôn ngữ của bạn
ToolAcre chỉ tạo UUID v4, được lấy từ trình tạo bảo mật bằng mật mã của trình duyệt để đảm bảo tính độc lập. Dẫn xuất UUID dựa trên tên yêu cầu thư viện UUID ngôn ngữ của bạn hoặc triển khai tính toán SHA-1 và định dạng kết quả chính xác. Bài đăng này giải thích khái niệm và trường hợp sử dụng; Việc triển khai thế hệ v5 rất đơn giản bằng bất kỳ ngôn ngữ nào có quyền truy cập vào các thư viện mật mã tiêu chuẩn. Cơ chế đạo hàm v5 rất đơn giản; thách thức là tích hợp nó vào một lược đồ hệ thống trong đó không gian tên ổn định, tên nhất quán và cách tiếp cận được ghi lại rõ ràng cho nhóm của bạn. Nhóm phát triển nên ghi lại các lựa chọn không gian tên.
Bài học rút ra: mang tính quyết định khi bạn cần, nếu không thì ngẫu nhiên - sử dụng v5 để ánh xạ ổn định và trình tạo ToolAcre cho mọi thứ không thể đoán được
Sử dụng v5 để ánh xạ ổn định giữa số nhận dạng bên ngoài và bản ghi nội bộ của bạn. Tính xác định ngăn chặn việc nhập trùng lặp và làm cho các bản ghi trùng khớp trên các hệ thống trở nên đơn giản và đáng tin cậy. Không sử dụng UUID dựa trên tên cho các số nhận dạng không thể đoán được hoặc cho các tình huống yêu cầu tính bảo mật và bí mật cao. ToolAcre tạo UUID v4 ngẫu nhiên cho các số nhận dạng phải độc lập và khác biệt mà không có khả năng dự đoán. Khi hệ thống của bạn cần ID xác định để ánh xạ đầu vào tới số nhận dạng cố định, thư viện ngôn ngữ UUID của bạn có thể tính toán chúng. Tính quyết định là một tính năng mạnh mẽ khi bạn kiểm soát đầu vào..