Menghasilkan UNIQUEIDENTIFIER dengan aman di SQL Server

Saya bermaksud menggunakan UNIQUEIDENTIFIERsebagai kunci akses yang dapat digunakan pengguna untuk mengakses data tertentu. Kuncinya akan bertindak sebagai kata sandi dalam arti itu.

Saya perlu membuat beberapa pengidentifikasi seperti itu sebagai bagian dari INSERT...SELECTpernyataan. Untuk alasan arsitektur saya ingin membuat pengidentifikasi sisi server dalam kasus ini.

Bagaimana saya bisa menghasilkan acak yang aman UNIQUEIDENTIFIER? Catatan, itu NEWIDtidak akan cukup acak karena tidak menjanjikan properti keamanan sama sekali. Saya mencari SQL Server yang setara dengan System.Security.Cryptography.RandomNumberGenerator karena saya memerlukan ID yang tidak dapat diucapkan. Apa pun berdasarkan CHECKSUM, RANDatau GETUTCDATEjuga tidak memenuhi syarat.

— usr
sumber

@ AaronBertrand setidaknya, satu jika angka selalu 4. Tetapi fakta bahwa saya tidak memiliki bukti kuat bahwa mereka mungkin dapat ditebak bukan berarti tidak. Saya tidak bisa mendasarkan keputusan keamanan ini pada pengamatan ini.

— usr

Mungkin NEWID sama acaknya dengan "kunci SSH Debian lemah": en.wikinews.org/wiki/…. Mereka tentu saja terlihat acak bagi pengembang yang mengujinya ...

— usr

Itu 4 memberitahu Anda apa algoritma yang digunakan dalam menghasilkan GUID. en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm

— Mr.Mindor

Anda mengerti bahwa satu-satunya faktor penentu dalam tingkat keamanan Anda adalah bit entropy? Gagasan bahwa NEWID tidak cukup acak untuk kebutuhan Anda akan menyiratkan bahwa Anda memiliki beberapa gagasan tentang jumlah entropi bit yang diperlukan untuk "aman" untuk kasus penggunaan Anda. Berapa angka itu?

— Cade Roux

@ Usr - "diberi pengetahuan penuh tentang keadaan internal", orang dapat memecahkan pendekatan apa pun .

Jawaban:

SELECT CAST(CRYPT_GEN_RANDOM(16) AS UNIQUEIDENTIFIER)

Seharusnya melakukan trik yang saya pikir.

CRYPT_GEN_RANDOM

Mengembalikan nomor acak kriptografis yang dihasilkan oleh API Crypto (CAPI).

— Martin Smith
sumber

Hanya dua sen saya, tetapi ini mungkin bukan ide yang baik. Mengutip seri Eric Lippert yang luar biasa pada GUID ( bagian 1 , bagian 2 , bagian 3 ), akronimnya adalah GUID, bukan GSUID - Pengidentifikasi Unik Global, bukan Pengidentifikasi Unik Global Aman.

Masalahnya terletak pada ketika GUID dihasilkan dalam lingkup non-bermusuhan, seperti semua orang yang menggunakan NEWID (), semua nilai dijamin unik (well, semacam, lihat artikel Eric, bagian 3). Tetapi jika entitas bermusuhan memasuki ruang lingkup itu, mereka dapat memprediksi GUID yang dihasilkan berikutnya, serta menyebabkan tabrakan sendiri.

Dengan membuat metode Anda sendiri menghasilkan nilai yang Anda simpan di dalam struktur yang terlihat seperti GUID, pada dasarnya Anda telah menjadi entitas yang bermusuhan. Anda telah mengubah kontrak GUID dari menjadi unik menjadi acak . Sementara seseorang yang lebih baik dalam matematika daripada saya mungkin bisa membuktikan Anda masih unik, itu hanya dalam batas-batas metode generasi Anda. Jika Anda mencampur GUID semu ini dengan GUID NEWID (), semua taruhan dimatikan.

Saya mengatakan ini mungkin bukan ide yang baik hanya karena saya tidak tahu seluruh ruang lingkup bagaimana Anda menggunakan nilai-nilai tersebut. Jika Anda adalah satu-satunya entitas yang menghasilkan nilai (tidak ada campuran dan kecocokan), dan / atau Anda tidak mempertahankan nilai, dan / atau Anda tidak peduli dengan tabrakan, ini mungkin bukan masalah. Jika salah satu dari item itu tidak benar, Anda mungkin ingin mengevaluasi kembali.

— Dave Simione
sumber

Poin menarik. Pilihan tipe data saya UNIQUEIDENTIFIERkebanyakan kebetulan. Lebih mudah untuk menangani kuantitas 16 byte menggunakan tipe itu. Saya menganggapnya sebagai kata sandi. Itu harus unik. Saya yakin bahwa saya tidak akan pernah melihat tabrakan (dan bahkan jika ada aplikasi hanya akan crash - jadi itu aman juga).

— usr

Saya tidak setuju, itu tergantung 'bagaimana' Anda mengenkripsi itu menjadi acak daripada unik. Dengan mudah bisa sama.

— Dawesi

Menurut https://blogs.msdn.microsoft.com/sqlprogrammability/2006/03/23/newafterentialid-histrorybenefits-and-implementation/ , fungsi NEWID () hanya membungkus fungsi Windows CoCreateGuid, yang mengembalikan GUID gaya v4, yang mengembalikan GUID gaya-v4 . Dan menurut https://msdn.microsoft.com/en-us/library/bb417a2c-7a58-404f-84dd-6b494ecf0d13#id11 , sejak Windows 2000 kembali pada tahun 1999,

"bit acak untuk semua GUID versi 4 yang dibangun di Windows diperoleh melalui API kriptografi Windows CryptGenRandom atau yang setara, sumber yang sama yang digunakan untuk pembuatan kunci kriptografi"

Jadi saya katakan Anda dapat mempertimbangkan NEWID () aman secara kriptografis - setidaknya sejauh 122 bit entropi yang disediakannya.

— Jordan Rieger
sumber

Itu menarik. Saya pribadi tidak akan mempercayai ini untuk tujuan keamanan. Baik Windows maupun SQL Server tidak membuat jaminan tentang hal ini.

— usr

@ Usr Saya tidak yakin akan seperti apa jaminan itu. Itu tidak menggunakan kata "jaminan", tetapi tampaknya dokumentasi standar MSDN Windows SDK. Akan sangat tidak mungkin bagi MS untuk menurunkan versi keacakan kriptografis GUID di beberapa versi Windows mendatang. Tidak akan ada untungnya.

— Jordan Rieger

Halaman MSDN itu hanya mendokumentasikan pilihan bersejarah tetapi tidak mengatakan bahwa ini akan disimpan di masa depan. Sama untuk SQL Server. Saya tidak bisa membayangkan keadaan di mana ini akan rusak. Tetapi ada banyak bencana RNG bencana. Asumsi seperti ini seringkali ternyata salah. Itu argumen heuristik.

— usr

@ Usr Tapi bagaimana dokumentasi MSDN bisa menjamin perilaku Windows di masa depan? Yang paling bisa kita harapkan dalam kasus-kasus ini adalah dokumentasi perilaku saat ini. Jika perilakunya berubah, maka mereka memperbarui dokumentasinya. Itulah sebabnya Tanya Jawab Stack Overflow ini memiliki tag versi dan diperbarui dari waktu ke waktu.

— Jordan Rieger

Mereka membuat jaminan tentang hal-hal yang tidak akan mereka ubah. Mereka dapat mengubah produk tetapi mereka tidak akan melakukannya jika mereka mengatakan "inilah fungsi penting keamanan dengan properti ini". Saya menafsirkan bahwa dokumentasi yang dipertanyakan lebih seperti pandangan historis daripada pernyataan tentang masa depan.

— usr