Tạo một cách an toàn một UNIQUEIDENTIFIER trong SQL Server

Tôi dự định sẽ sử dụng một UNIQUEIDENTIFIER làm khóa truy cập mà người dùng có thể sử dụng để truy cập dữ liệu nhất định. Khóa sẽ hoạt động như một mật khẩu theo nghĩa đó.

Tôi cần tạo nhiều định danh như vậy như là một phần của INSERT...SELECT câu lệnh. Vì lý do kiến trúc, tôi muốn tạo phía máy chủ định danh trong trường hợp này.

Làm thế nào tôi có thể tạo ngẫu nhiên an toàn UNIQUEIDENTIFIER? Lưu ý, điều đó NEWIDsẽ không đủ ngẫu nhiên vì nó không hứa hẹn bất kỳ thuộc tính bảo mật nào cả. Tôi đang tìm SQL Server tương đương với System.Security.Cryptography.RandomNumberGenerator vì tôi cần ID không thể truy cập được. Bất cứ điều gì dựa trên CHECKSUM, RANDhoặc GETUTCDATEcũng sẽ không đủ điều kiện.

— sử dụng
nguồn

@AaronBertrand ít nhất, một nếu các chữ số luôn luôn 4. Nhưng thực tế là tôi không có bằng chứng mạnh mẽ rằng họ có thể đoán được không có nghĩa là họ không có. Tôi không thể dựa trên quyết định bảo mật này.

— usr

Có lẽ NEWID chỉ là ngẫu nhiên như "các khóa SSH yếu của Debian": en.wikinews.org/wiki/iêu Họ chắc chắn trông ngẫu nhiên đối với nhà phát triển đã thử nghiệm chúng ...

— usr

Đó là 4 cho bạn biết thuật toán nào được sử dụng trong việc tạo GUID. vi.wikipedia.org/wiki/Globally_unique_identifier#Alacticm

— Mr.Mindor

Bạn có hiểu rằng yếu tố quyết định duy nhất trong mức độ bảo mật của bạn là entropy bit không? Ý tưởng rằng NEWID không đủ ngẫu nhiên cho nhu cầu của bạn sẽ ngụ ý rằng bạn có một số ý tưởng về lượng entropy bit được yêu cầu là "an toàn" cho trường hợp sử dụng của bạn. Con số đó là gì?

— Cade Roux

@usr - "được cung cấp kiến thức đầy đủ về trạng thái nội bộ", người ta có thể bẻ khóa mọi cách tiếp cận.

Câu trả lời:

SELECT CAST(CRYPT_GEN_RANDOM(16) AS UNIQUEIDENTIFIER)

Nên làm thủ thuật tôi sẽ nghĩ.

CRYPT_GEN_RANDOM

Trả về số ngẫu nhiên mã hóa được tạo bởi API Crypto (CAPI).

— Martin Smith
nguồn

Chỉ hai xu của tôi, nhưng đây có thể không phải là một ý tưởng tốt. Để diễn giải loạt bài xuất sắc của Eric Lippert trên GUID ( phần 1 , phần 2 , phần 3 ), từ viết tắt là GUID, không phải GSUID - Mã định danh duy nhất toàn cầu, không phải Định danh duy nhất bảo mật toàn cầu.

Vấn đề nằm ở chỗ khi GUID được tạo trong phạm vi không thù địch, chẳng hạn như mọi người sử dụng NEWID (), tất cả các giá trị đều được đảm bảo là duy nhất (tốt, sắp xếp, xem bài viết của Eric, phần 3). Nhưng nếu một thực thể thù địch xâm nhập vào phạm vi đó, cả hai đều có thể dự đoán GUID được tạo tiếp theo, cũng như tự gây ra va chạm.

Bằng cách tạo phương thức riêng của bạn để tạo ra một giá trị mà bạn lưu trữ bên trong một cấu trúc trông giống như GUID, về cơ bản bạn đã trở thành một thực thể thù địch. Bạn đã thay đổi hợp đồng của GUID từ duy nhất thành ngẫu nhiên . Trong khi ai đó giỏi toán hơn tôi có thể chứng minh bạn vẫn là duy nhất, điều đó chỉ nằm trong giới hạn của phương pháp thế hệ của bạn. Nếu bạn trộn các GUID giả này với GUID NEWID (), tất cả các cược sẽ bị tắt.

Tôi nói điều này có thể không phải là một ý tưởng tốt chỉ vì tôi không biết toàn bộ phạm vi về cách bạn đang sử dụng các giá trị. Nếu bạn là thực thể duy nhất tạo ra các giá trị (không trộn lẫn và khớp) và / hoặc bạn không duy trì các giá trị và / hoặc bạn không quan tâm đến xung đột, điều này có thể không thành vấn đề. Nếu bất kỳ mục nào trong số đó không đúng, bạn có thể muốn đánh giá lại.

— Dave Simione
nguồn

Điểm thú vị. Sự lựa chọn kiểu dữ liệu của tôi UNIQUEIDENTIFIERchủ yếu là một sự trùng hợp. Nó chỉ thuận tiện để xử lý số lượng 16 byte bằng cách sử dụng loại đó. Tôi nghĩ về nó như một mật khẩu. Nó phải là duy nhất, mặc dù. Tôi tự tin rằng tôi sẽ không bao giờ thấy va chạm (và ngay cả khi có ứng dụng sẽ bị sập - vì vậy cũng an toàn).

— usr

Tôi không đồng ý, điều này phụ thuộc vào 'cách bạn' mã hóa nó nếu nó trở nên ngẫu nhiên thay vì duy nhất. Nó có thể dễ dàng giống nhau.

— Dawesi

Theo https://blogs.msdn.microsoft.com/sqlprogrammability/2006/03/23/newsequentialid-histrorybenefits-and-implementation/ , các NEWID () chức năng chỉ kết thúc tốt đẹp các chức năng của Windows CoCreateGuid, mà trả về một v4 kiểu GUID . Và theo https://msdn.microsoft.com/en-us/l Library / bb417a2c-7a58-404f-84dd-6b494ecf0d13#id11 , kể từ Windows 2000 trở lại năm 1999,

"các bit ngẫu nhiên cho tất cả các GUID phiên bản 4 được xây dựng trong Windows được lấy thông qua API mã hóa Windows CryptGenRandom hoặc tương đương, cùng một nguồn được sử dụng để tạo khóa mật mã"

Vì vậy, tôi muốn nói rằng bạn có thể xem xét NEWID () bảo mật bằng mật mã - ít nhất là trong phạm vi 122 bit của entropy mà nó cung cấp.

— Jordan Rieger
nguồn

Nó thật thú vị. Cá nhân tôi sẽ không tin tưởng điều này vì mục đích bảo mật. Cả Windows và SQL Server đều không đảm bảo về điều này.

— usr

@usr Tôi không chắc bảo đảm sẽ như thế nào. Nó không sử dụng từ "đảm bảo", nhưng dường như là tài liệu SDK Windows MSDN tiêu chuẩn. Sẽ rất khó để MS hạ cấp tính ngẫu nhiên về mật mã của GUID trong một số phiên bản Windows trong tương lai. Sẽ không có gì để đạt được.

— Jordan Rieger

Trang MSDN đó chỉ đơn thuần ghi lại các lựa chọn lịch sử nhưng nó không nói rằng điều này sẽ được giữ trong tương lai. Tương tự cho SQL Server. Tôi không thể tưởng tượng hoàn cảnh mà theo đó điều này sẽ bị phá vỡ. Nhưng đã có nhiều sự kiện RNG thảm khốc. Các giả định như thế này thường bị sai. Đó là một cuộc tranh luận heuristic.

— usr

@usr Nhưng làm thế nào bất kỳ tài liệu MSDN nào có thể đảm bảo hành vi trong tương lai của Windows? Hầu hết chúng ta có thể hy vọng trong những trường hợp này là tài liệu về hành vi hiện tại. Nếu hành vi từng thay đổi, thì họ sẽ cập nhật tài liệu. Đó là lý do tại sao các Q & As Stack Overflow này có thẻ phiên bản và được cập nhật theo thời gian.

— Jordan Rieger

Họ đảm bảo về những điều họ sẽ không thay đổi. Họ có thể thay đổi sản phẩm nhưng họ sẽ không làm thế nếu họ nói "đây là một chức năng quan trọng về bảo mật với các đặc tính này". Tôi giải thích tài liệu đó trong câu hỏi giống như một quan điểm lịch sử hơn là một tuyên bố về tương lai.

— usr