สร้าง UNIQUEIDENTIFIER อย่างปลอดภัยใน SQL Server

ฉันตั้งใจจะใช้UNIQUEIDENTIFIERเป็นคีย์การเข้าถึงที่ผู้ใช้สามารถใช้เพื่อเข้าถึงข้อมูลบางอย่าง กุญแจจะทำหน้าที่เป็นรหัสผ่านในแง่นั้น

ฉันจำเป็นต้องสร้างตัวระบุหลายตัวเป็นส่วนหนึ่งของINSERT...SELECTคำสั่ง ด้วยเหตุผลทางสถาปัตยกรรมฉันต้องการสร้างตัวระบุฝั่งเซิร์ฟเวอร์ในกรณีนี้

ฉันจะสร้างแบบสุ่มที่ปลอดภัยได้UNIQUEIDENTIFIERอย่างไร โปรดทราบว่าNEWIDจะไม่สามารถสุ่มได้มากพอเนื่องจากไม่ได้รับประกันคุณสมบัติความปลอดภัยใด ๆ เลย ฉันกำลังมองหา SQL Server ที่เทียบเท่ากับSystem.Security.Cryptography.RandomNumberGeneratorเพราะฉันต้องการ ID ที่ไม่สามารถคาดเดาได้ สิ่งใดขึ้นอยู่กับCHECKSUM, RANDหรือGETUTCDATEยังจะได้มีสิทธิ์

— usr
แหล่งที่มา

@AaronBertrand 4อย่างน้อยที่สุดหนึ่งถ้าตัวเลขอยู่เสมอ แต่ความจริงที่ว่าฉันไม่มีหลักฐานแน่ชัดว่าพวกเขาอาจจะคาดเดาได้ไม่ได้หมายความว่าพวกเขาไม่ได้ ฉันไม่สามารถตัดสินใจเรื่องความปลอดภัยนี้ได้จากการสังเกตนี้

— usr

บางที NEWID จะสุ่มเพียงแค่เป็น "คีย์ SSH ที่อ่อนแอ Debian": en.wikinews.org/wiki/ …พวกเขาดูสุ่มจากนักพัฒนาที่ทดสอบพวกเขา ...

— usr

นั่นคือ 4 บอกคุณว่าอัลกอริทึมที่ใช้ในการสร้าง GUID en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm

— Mr.Mindor

คุณเข้าใจหรือไม่ว่าปัจจัยในการกำหนดระดับความปลอดภัยของคุณคือบิตเอนโทรปี? ความคิดที่ว่า NEWID นั้นไม่สุ่มพอสำหรับความต้องการของคุณนั่นก็หมายความว่าคุณมีความคิดเกี่ยวกับปริมาณของบิตเอนโทรปีซึ่งจำเป็นต้อง "ปลอดภัย" สำหรับกรณีการใช้งานของคุณ หมายเลขนั้นคืออะไร?

— เคด Roux

@usr - "ได้รับความรู้เต็มรูปแบบของสถานะภายใน" สามารถแตกวิธีใดก็ได้

คำตอบ:

SELECT CAST(CRYPT_GEN_RANDOM(16) AS UNIQUEIDENTIFIER)

ควรทำเคล็ดลับที่ฉันคิด

CRYPT_GEN_RANDOM

ส่งคืนตัวเลขสุ่มเข้ารหัสที่สร้างโดย Crypto API (CAPI)

— Martin Smith
แหล่งที่มา

แค่สองเซ็นต์ของฉัน แต่นี่อาจไม่ใช่ความคิดที่ดี เพื่อถ่ายซีรีส์ยอดเยี่ยมเอริค Lippert ใน GUID ของ ( ตอนที่ 1 , ตอนที่ 2 , ส่วน 3 ) ตัวย่อคือ GUID ไม่ GSUID - ทั่วโลก Unique Identifier ไม่ปลอดภัยทั่วโลก Unique Identifier

ปัญหาอยู่ที่ว่าเมื่อสร้าง GUID ภายในขอบเขตที่ไม่เป็นมิตรเช่นทุกคนที่ใช้ NEWID () ค่าทั้งหมดจะได้รับการรับประกันว่าจะไม่ซ้ำกัน (ดูได้จากบทความของ Eric ตอนที่ 3) แต่ถ้าเอนทิตีที่เป็นศัตรูเข้ามาในขอบเขตนั้นพวกเขาทั้งคู่สามารถทำนาย GUID ที่สร้างขึ้นครั้งถัดไปรวมทั้งทำให้เกิดการชนกันได้ด้วยตนเอง

ด้วยการสร้างวิธีการของคุณเองในการสร้างมูลค่าที่คุณเก็บไว้ในโครงสร้างที่ดูเหมือน GUID คุณได้กลายเป็นเอนทิตีที่เป็นมิตร คุณมีการเปลี่ยนแปลงสัญญา GUID ที่จากการที่ไม่ซ้ำกันที่จะเป็นแบบสุ่ม ในขณะที่บางคนเก่งเรื่องคณิตศาสตร์มากกว่าฉันอาจพิสูจน์ได้ว่าคุณยังคงมีเอกลักษณ์เฉพาะภายในขอบเขตของวิธีการสร้างของคุณ หากคุณผสม guid-guid ของเหล่านี้เข้ากับ NEWID () GUIDs การเดิมพันทั้งหมดจะปิด

ฉันบอกว่านี่อาจไม่ใช่ความคิดที่ดีเพียงเพราะฉันไม่ทราบขอบเขตทั้งหมดของวิธีที่คุณใช้ค่าต่างๆ หากคุณเป็นเอนทิตีเพียงคนเดียวที่สร้างค่า (ไม่มิกซ์แอนด์แมตช์) และ / หรือคุณยังไม่ยืนยันค่าและ / หรือคุณไม่สนใจเรื่องการชนกันนี่อาจไม่ใช่ปัญหา หากรายการเหล่านั้นไม่เป็นจริงคุณอาจต้องการประเมินอีกครั้ง

— Dave Simione
แหล่งที่มา

จุดที่น่าสนใจ ตัวเลือกประเภทข้อมูลของฉันUNIQUEIDENTIFIERส่วนใหญ่เป็นเรื่องบังเอิญ มันสะดวกที่จะจัดการปริมาณ 16 ไบต์โดยใช้ชนิดนั้น ฉันคิดว่ามันเป็นรหัสผ่าน มันจะต้องไม่ซ้ำกันแม้ว่า ฉันมั่นใจว่าฉันจะไม่เห็นการชนกัน (และแม้ว่าจะมีแอพที่จะเกิดความผิดพลาด - ดังนั้นมันจึงปลอดภัยเช่นกัน)

— usr

ฉันไม่เห็นด้วยมันขึ้นอยู่กับ 'วิธี' คุณเข้ารหัสมันหากมันกลายเป็นสุ่มมากกว่าที่ไม่ซ้ำกัน มันสามารถเหมือนกันได้อย่างง่ายดาย

— Dawesi

ตามhttps://blogs.msdn.microsoft.com/sqlprogrammability/2006/03/23/newsequentialidid-histrorybenefits-and-implementation/ฟังก์ชัน NEWID () เพิ่งตัดฟังก์ชัน Windows CoCreateGuid ซึ่งจะคืนค่าสไตล์ v4 . และเป็นไปตามhttps://msdn.microsoft.com/en-us/library/bb417a2c-7a58-404f-84dd-6b494ecf0d13#id11ตั้งแต่ Windows 2000 ย้อนกลับไปในปี 1999

"บิตสุ่มสำหรับ GUID ทั้งหมด 4 รุ่นที่สร้างขึ้นใน Windows ได้มาจาก Windows CryptGenRandom API การเข้ารหัสลับหรือเทียบเท่าแหล่งที่มาเดียวกันที่ใช้สำหรับการสร้างคีย์เข้ารหัส"

ดังนั้นฉันจะบอกว่าคุณสามารถพิจารณา NEWID () การเข้ารหัสที่ปลอดภัย - อย่างน้อยก็เท่ากับขนาดของบิตเอนโทรปี 122 ที่ให้ไว้

— Jordan Rieger
แหล่งที่มา

นั่นดูน่าสนใจ. ฉันเองจะไม่เชื่อใจสิ่งนี้เพื่อความปลอดภัย ทั้ง Windows และ SQL Server ไม่รับประกันเกี่ยวกับสิ่งนี้

— usr

@usr ฉันไม่แน่ใจว่าการรับประกันจะเป็นอย่างไร ไม่ได้ใช้คำว่า "รับประกัน" แต่ดูเหมือนจะเป็นเอกสาร MSDN Windows SDK มาตรฐาน มันไม่น่าเป็นไปได้อย่างยิ่งที่ MS จะลดระดับการสุ่มรหัสลับของ GUID ใน Windows บางรุ่นในอนาคต จะไม่มีอะไรจะได้รับ

— Jordan Rieger

หน้า MSDN นั้นเป็นเพียงเอกสารทางเลือกทางประวัติศาสตร์ แต่ไม่ได้บอกว่าสิ่งนี้จะถูกเก็บไว้ในอนาคต เหมือนกันสำหรับ SQL Server ฉันไม่สามารถจินตนาการถึงสถานการณ์ที่สิ่งนี้จะพังทลายลง แต่มีการทำลาย RNG หลายครั้ง สมมติฐานเช่นนี้มักจะกลายเป็นเท็จ มันเป็นอาร์กิวเมนต์ฮิวริสติก

— usr

@usr แต่เอกสาร MSDN ใดที่รับประกันการทำงานในอนาคตของ Windows ได้อย่างไร สิ่งที่เราคาดหวังมากที่สุดในกรณีนี้คือเอกสารเกี่ยวกับพฤติกรรมปัจจุบัน หากพฤติกรรมนั้นเปลี่ยนแปลงไปพวกเขาก็จะอัพเดตเอกสาร นั่นเป็นเหตุผลที่ Q & As Stack Overflow เหล่านี้มีแท็กเวอร์ชันและรับการปรับปรุงเป็นครั้งคราว

— Jordan Rieger

พวกเขารับประกันเกี่ยวกับสิ่งที่พวกเขาจะไม่เปลี่ยนแปลง พวกเขาสามารถเปลี่ยนผลิตภัณฑ์ แต่พวกเขาจะไม่ถ้าพวกเขาพูดว่า "นี่คือฟังก์ชั่นที่สำคัญด้านความปลอดภัยที่มีคุณสมบัติเหล่านี้" ฉันตีความเอกสารที่เป็นปัญหาเช่นมุมมองประวัติศาสตร์มากกว่าข้อความเกี่ยวกับอนาคต

— usr