Công cụ dành cho nhà phát triển · Trình tạo UUID
UUID ngẫu nhiên có an toàn khi đặt lại mật khẩu hoặc mã thông báo phiên không?
· Tại sao nó quan trọng
uuid mật mã browser-apis
Phiên bản v4 UUID từ CSPRNG có nhiều entropy, vậy tại sao những người đánh giá bảo mật vẫn cau mày với mã thông báo UUID? Bài đăng này tách câu hỏi entropy khỏi câu hỏi thiết kế.
Liên kết đặt lại sử dụng UUID của hàng — một phím tắt phổ biến và hai lý do rất khác nhau có thể khiến nó không an toàn
Một lối tắt phổ biến: sử dụng mã định danh hàng UUID của người dùng làm mã thông báo đặt lại mật khẩu. Bảng có cột uuid; nó là duy nhất; thật khó đoán (nếu là v4). URL là /reset? mã thông báo=550e8400-e29b-41d4-a716-446655440000. Người đánh giá bảo mật ngay lập tức từ chối nó, không phải vì UUID yếu mà vì nó kết hợp hai mối quan tâm lẽ ra phải độc lập. Hàng UUID ổn định và thường hiển thị công khai (trong URL, API, nhật ký). Mã thông báo đặt lại phải được sử dụng một lần và bí mật. Việc sử dụng lại hàng UUID làm mã thông báo có nghĩa là danh tính của người dùng và thông tin xác thực được đặt lại của họ có cùng giá trị và thông tin xác thực sẽ tồn tại vĩnh viễn thay vì hết hạn. Kẻ tấn công biết ID người dùng có thể thực hiện thiết lập lại. Người dùng đã sao chép và dán liên kết đặt lại cách đây 5 năm vẫn có thể sử dụng liên kết đó. Đây là những lỗi thiết kế, không phải lỗi entropy.
Kiểm tra entropy: 122 bit ngẫu nhiên - tại sao v4 do CSPRNG tạo ra không thể đoán được bằng vũ lực
Việc kiểm tra tính ngẫu nhiên là cần thiết nhưng chưa đủ. Phiên bản 4 dự trữ bốn bit phiên bản và hai bit biến thể, để lại 128 - 4 - 2 = 122 vị trí ngẫu nhiên khi quá trình triển khai điền ngẫu nhiên vào các trường khác. Đạo hàm đó không nói gì về thời hạn sử dụng, lưu trữ hoặc ủy quyền. Quá trình kiểm tra trình tạo sẽ hỏi xem các trường đó có đến từ CSPRNG thay vì Math.random hay dấu thời gian hay không. ToolAcre thỏa mãn ranh giới của trình tạo đó. Việc kiểm tra thiết kế vẫn dành riêng cho từng ứng dụng: thông tin xác thực đặt lại cần có vòng đời riêng, bản trình bày được lưu trữ một chiều, tính vô hiệu sau khi sử dụng thành công và thời hạn hết hạn được chọn theo chính sách rủi ro của dịch vụ. Việc sử dụng lại ID bản ghi vĩnh viễn của người dùng sẽ không thực hiện được việc phân tách đó ngay cả khi ID được tạo một cách an toàn.
Kiểm tra trình tạo: trong đó mã thông báo UUID thực sự không thành công — thế hệ dựa trên Math.random, dấu thời gian v1 và địa chỉ MAC cũng như các hạt giống có thể dự đoán được
Một ví dụ hoạt động: kế hoạch đặt lại mật khẩu không thành công, sau đó vượt qua ba lần kiểm tra. Kiểm tra entropy không thành công: máy chủ cấp mã thông báo đặt lại thông qua Math.random(), được đóng gói dưới dạng v4 UUID. Kẻ tấn công quan sát ba mã thông báo và dự đoán mã thông báo thứ tư. Kiểm tra trình tạo không thành công: máy chủ sử dụng v1 UUID làm mã thông báo đặt lại, bao gồm dấu thời gian tạo và địa chỉ MAC trong giá trị. Kẻ tấn công đọc dấu thời gian, biết thời điểm thiết lập lại được thực hiện và thu hẹp cửa sổ tìm kiếm. Vượt qua kiểm tra entropy nhưng không vượt qua kiểm tra thiết kế: máy chủ sử dụng v4 UUID từ crypto.getRandomValues nhưng lưu trữ nó ở dạng văn bản thuần túy trong cơ sở dữ liệu và không đặt thời hạn. Kẻ tấn công vi phạm cơ sở dữ liệu sẽ đọc mã thông báo đặt lại và sử dụng chúng để đặt lại tài khoản vài tuần sau đó. Ba lần kiểm tra này là độc lập; bạn phải vượt qua cả ba.
Kiểm tra thiết kế: mã định danh so với thông tin xác thực — tại sao việc sử dụng lại khóa chính của bản ghi làm khóa bí mật lại kết hợp hai thứ cần xoay vòng độc lập
Lược đồ mã thông báo đặt lại vượt qua kiểm tra entropy và trình tạo nhưng không vượt qua kiểm tra thiết kế (không băm, không hết hạn, không vô hiệu hóa mỗi lần sử dụng) vẫn dễ bị tấn công. Xử lý mã thông báo phía máy chủ: khi người dùng yêu cầu đặt lại mật khẩu, hãy tạo mã thông báo ngẫu nhiên mới (không phải hàng UUID) từ crypto.getRandomValues. Lưu trữ biểu diễn một chiều thay vì giá trị được trình bày, đặt thời hạn dành riêng cho chính sách và vô hiệu hóa bản ghi sau khi sử dụng thành công. Khi người dùng nhấp vào liên kết, tra cứu người dùng qua email, tìm nạp hàm băm được lưu trữ, so sánh mã thông báo được cung cấp với hàm băm, kiểm tra thời hạn sử dụng và chỉ thực hiện đặt lại nếu mã thông báo hợp lệ và chưa hết hạn. Ngay lập tức vô hiệu hóa mã thông báo (xóa hoặc đánh dấu là đã sử dụng) để không thể sử dụng lại. Không bao giờ đăng nhập mã thông báo thô; chỉ đăng nhập ID người dùng và hành động.
Xử lý phía máy chủ mã thông báo - lưu trữ hàm băm, đặt thời hạn sử dụng, vô hiệu hóa khi sử dụng và không bao giờ ghi lại giá trị thô
Mã thông báo sẽ không bao giờ xuất hiện trong thông báo lỗi hoặc trong cơ sở dữ liệu trừ khi được băm. Thiết kế xác thực đầy đủ nằm ngoài phạm vi của một UUID bài viết, nhưng các nguyên tắc giữ: a 122Mã thông báo ngẫu nhiên -bit vốn không phải là mã thông báo truy cập. Tính ngẫu nhiên là phần dễ dàng; cái ToolAcre trình tạo mang đến cho bạn CSPRNGUUID được hỗ trợ. Phần khó khăn là thiết kế: băm trước khi lưu trữ, đặt thời gian hết hạn, vô hiệu hóa việc sử dụng, ngăn chặn việc sử dụng lại ID vĩnh viễn làm bí mật tạm thời, kiểm tra xem ai truy cập cái gì và khi nào. Người đánh giá bảo mật phê duyệt sơ đồ liên kết lại chỉ dựa trên entropy của mã thông báo sẽ bỏ qua phần còn lại của phân tích. Một nhà phát triển nghĩ rằng CSPRNG-được hỗ trợ UUID là đủ cho một liên kết đặt lại mật khẩu mà không cần băm, hết hạn và vô hiệu hóa là đánh giá thấp mối đe dọa. Tính ngẫu nhiên ngăn chặn việc đoán mò; thiết kế bảo vệ chống lại việc sử dụng lại, hết hạn và sử dụng sai mục đích.
Ví dụ đã hoạt động - xem xét sơ đồ liên kết lại đối với mỗi lần kiểm tra và viết lại các phần yếu
Trình tạo ToolAcre thực hiện đúng phần ngẫu nhiên; ứng dụng phải thực hiện đúng phần thiết kế. Kiểm tra mã liên kết đặt lại của riêng bạn dựa trên cả ba bước kiểm tra: nó có sử dụng CSPRNG (crypto.getRandomValues, crypto.randomUUID hoặc thư viện mật mã) không phải Math.random không? Token có thời gian hết hạn không? Mã thông báo có được băm trước khi lưu trữ không? Mã thông báo có bị vô hiệu sau khi sử dụng không? Mã có tránh sử dụng lại ID cố định của người dùng làm mã thông báo tạm thời không? Nếu bạn trả lời có cho tất cả những điều này thì thiết kế liên kết đặt lại của bạn là hợp lý. Trình tạo ToolAcre là phần CSPRNG; phần còn lại là mã ứng dụng mà bạn phải xem xét kỹ. Hiểu ba lớp bảo mật giúp bạn kiểm tra các thư viện và khung UUID của bên thứ ba. Khi bạn đánh giá một thư viện, hãy kiểm tra xem thư viện đó có sử dụng CSPRNG (kiểm tra entropy) không phải nguồn ngẫu nhiên yếu. Kiểm tra xem nó có ghi lại nguồn nào nó sử dụng không và tại sao (kiểm tra trình tạo).
Điều này không bao gồm những gì — thiết kế xác thực đầy đủ, MFA và giới hạn tốc độ, những vấn đề này cũng quan trọng như entropy của mã thông báo
Kiểm tra mã ví dụ và tài liệu nhấn mạnh các nguyên tắc thiết kế: băm, hết hạn, vô hiệu (kiểm tra thiết kế). Các thư viện vượt qua được cả ba bước kiểm tra này rất hiếm; hầu hết chỉ tập trung vào entropy. Trình tạo ToolAcre vượt qua quá trình kiểm tra entropy và trình tạo bằng cách sử dụng crypto.getRandomValues. Việc kiểm tra thiết kế là trách nhiệm của bạn; thư viện không thể biết yêu cầu hết hạn hoặc chiến lược băm của bạn. Việc gỡ lỗi hệ thống liên kết đặt lại bị hỏng thường phát hiện một trong ba lỗi. Nếu người dùng báo cáo việc nhận được các liên kết đặt lại không còn hoạt động thì vấn đề có thể là hết hạn: mã thông báo đã được phát hành nhưng đã hết hạn trước khi người dùng nhấp vào liên kết. Nếu mã thông báo được sử dụng lại nhiều lần, tính năng vô hiệu sẽ bị phá vỡ. Nếu mã thông báo xuất hiện trong thông báo lỗi hoặc đầu ra gỡ lỗi thì việc ghi nhật ký sẽ làm rò rỉ chúng. Nếu liên kết đặt lại hoạt động với một người dùng nhưng không hoạt động với người dùng khác thì có thể có độ trễ sao chép cơ sở dữ liệu hoặc vấn đề về múi giờ khi tính toán hết hạn. Nếu các yêu cầu đặt lại hợp pháp ngẫu nhiên không thành công thì CSPRNG có thể bị hỏng (hiếm).
Bài học rút ra: tính ngẫu nhiên là phần dễ dàng — trình tạo ToolAcre cung cấp cho bạn các UUID được hỗ trợ bởi CSPRNG; phần còn lại là kỷ luật thiết kế
Bắt đầu bằng việc ghi nhật ký: bật nhật ký kiểm tra chi tiết để tạo và xác minh liên kết đặt lại, sau đó tái tạo sự cố và theo dõi quy trình. Trình tạo ToolAcre đảm bảo hai lần kiểm tra đầu tiên đều vượt qua; xử lý sự cố liên kết đặt lại hầu như luôn rơi vào danh mục thiết kế. Các phương pháp hay nhất cho hệ thống liên kết đặt lại sản xuất bao gồm: tạo mã thông báo ngẫu nhiên mới cho mỗi yêu cầu đặt lại, không sử dụng lại mã thông báo cũ. Lưu trữ bản trình bày một chiều cùng với siêu dữ liệu về tài khoản và quá trình tạo, sau đó chọn thời hạn hết hạn theo chính sách rủi ro được ghi lại của dịch vụ. Vô hiệu hóa mã thông báo ngay sau khi xác minh thành công. Đăng nhập yêu cầu đặt lại và thành công để kiểm tra. Thực hiện giới hạn tỷ lệ để ngăn chặn các cuộc tấn công vũ phu. Chỉ gửi liên kết đặt lại qua email chứ không phải SMS hoặc các kênh không được mã hóa. Thông báo cho người dùng về các lần thử đặt lại mật khẩu (để họ có thể phát hiện các lần đặt lại trái phép). Trình tạo ToolAcre mang lại cho bạn tính ngẫu nhiên; làm theo những thực hành này mang lại cho bạn sự an toàn.