UUID-specifikationen beskriver flera "versioner" som är metoder för att skapa UUID. De flesta syftar till att säkerställa unikhet (det är UUID: s huvudpunkt) genom att använda t.ex. det aktuella datumet. Detta är effektivt men innebär att även om den genererade UUID är unik är de också förutsägbara vilket gör dem otillräckliga för vissa säkerhetsanvändningar.

"version 4" UUID-genereringsmetod (i avsnitt 4.4) ska dock använda en kryptografiskt stark slumptalsgenerator. 6 av de 128 bitarna är fixerade till ett konventionellt värde (för att indikera att detta är en version 4 UUID, nämligen), så detta lämnar 122 bitar från RNG.

Om underliggande RNG är säkert (t.ex. / dev / urandom på ett Linux / MacOS / * BSD-system eller CryptGenRandom () på Windows) då ges många genererade UUID, en angripare är inte tänkt att kunna förutsäga nästa med framgångssannolikhet högre än 2 ^-122 , vilket är tillräckligt litet för de flesta ändamål, inklusive startkoder för kärnmissiler. bitar garanterar unikhet med hög sannolikhet. Om du genererar många UUID av version 4 och ackumulerar dem kan du förvänta dig att stöta på din första kollision efter cirka 2 ⁶¹ UUID - det är ungefär 2 miljarder miljarder; att bara lagra det antalet UUID skulle använda mer än 30 miljoner terabyte. Om du bara "10" tänker 10 ¹² sådana UUID (tusen miljarder, som kan lagras över 16 terabyte), är riskerna med att ha två identiska UUID bland dessa ungefär 9,4 * 10 ^{-14 sup>, dvs cirka 700 tusen gånger mindre sannolikt än att vinna miljoner dollar i lotteriet.}

Därför är UUID lämpliga för säkerhetsändamål om ( och bara om) de är "version 4" UUID genererade med en säker RNG.

Är de tillräckligt säkra för de ändamål som du beskrev? Enligt min mening generellt ja. Är de tillräckligt säkra i applikationer där säkerhet är ett viktigt problem? Nej. De genereras med en icke-slumpmässig algoritm, så de är inte på något sätt kryptografiskt slumpmässiga eller säkra.

Så för en avregistrerings- eller prenumerationsverifieringsfunktion ser jag verkligen inget säkerhetsproblem. För att identifiera en användare av en webbbankapplikation å andra sidan (eller egentligen till och med en lösenordsåterställning av en webbplats där identitet är värdefull) är GUID: er definitivt otillräckliga.

För mer information kanske du vill kolla in avsnitt 6 (Säkerhetsöverväganden) i RFC 4122 för GUID (eller universellt unika identifierare).

De är säkra i Windows 2000 eller senare. Din sårbarhet & risk beror på hur GUID genereras. Windows 2000 eller senare använder version 4 av GUID som är kryptografiskt säker.

För mer information se den här MSDN-länken och den här stack-overflow-frågan. (Tack till Jordan Rieger i kommentarerna)

Om du använder ett gemensamt utvecklingsspråk är det inte så svårt att skapa en enhetsgenerator med unika slumpmässiga nummer med en korrekt kryptofunktion (vi pratar om 10 rader kod som finns tillgängliga som exempel på de vanligaste språken helt enkelt med Google) och så med en enkel ny guide är det i grund och botten latskap från utvecklarens synvinkel.

I det beskrivna scenariot är de "tillräckligt säkra", om guiden som skickas i glömt lösenordsfunktion har några grundläggande funktioner:

1) Det är verkligen ett one shot-värde som inte har något samband med användar-id, så när lösenordet har återställts kan det inte användas längre

2) Det har ett definierat tidsfönster för dess giltighet (du kan återställa lösenordet under de närmaste 30 minuterna eller något liknande)

Om du använder samma Guid kan du återställa lösenordet mer än en gång eller gissa guid och reset-lösenordet av användare som inte bad om lösenordsåterställning eller, som Avid beskriver i kommentaren, försöker få tillgång till återställningslösenord med s ome typ av omspelning bifogas då är det applikationsdesignen som är felaktig och att använda eller inte använda en Guid inte är det verkliga problemet.

Så om du inte har att göra med mycket känslig information kan en guide kanske fungera, men varför gör du inte saker på rätt sätt första gången och använder en ordentlig krypto-api för att skapa en säker slumpmässig sträng?

RegardsMassimo

Falska "GUID", som inte genereras av någon GUID-genereringsalgoritm, men som istället bara är 128 bitar (16 byte) som genereras av en kryptografiskt säker PRNG och som bara representeras konventionell GUID-kodning med hex-med bindestreck, är mestadels säkra för engångsmärken.

Du stöter dock på födelsedagsproblemet, eftersom förekomsten av en kollision är cirka 2 ^ -64 för 128- bit-tokens.

Bättre att använda 256-bitars eller 512-bitars tokens, där förekomsten av en kollision är runt 2 ^ -128 eller 2 ^ -256.