Γεννήτρια UUID

• UUID v1 συνδυάζει μια χρονική σήμανση με τη διεύθυνση MAC του μηχανήματος — εγγυημένα μοναδικό αλλά αποκαλύπτει τον χρόνο δημιουργίας και την ταυτότητα του υλικού, δημιουργώντας ζητήματα απορρήτου.
• UUID v3 και v5 είναι ντετερμινιστικά κατακερματισμού (hashes): η v3 χρησιμοποιεί MD5, η v5 χρησιμοποιεί SHA-1. Με δεδομένο τον ίδιο χώρο ονομάτων και όνομα, παράγουν πάντα το ίδιο UUID — χρήσιμο για τη δημιουργία συνεπών αναγνωριστικών από φυσικά κλειδιά (π.χ., μετατροπή διευθύνσεων email σε αναγνωριστικά χρηστών).
• UUID v4 χρησιμοποιεί 122 bits τυχαίων δεδομένων, παρέχοντας την ισχυρότερη εγγύηση μοναδικότητας χωρίς διαρροή πληροφοριών.
• UUID v7 (RFC 9562, 2024) ενσωματώνει μια χρονική σήμανση Unix στα πρώτα 48 bits διατηρώντας παράλληλα 74 τυχαία bits — ταξινομήσιμο κατά χρόνο δημιουργίας, καθιστώντας το ιδανικό για πρωτεύοντα κλειδιά βάσης δεδομένων όπου η απόδοση ευρετηρίου έχει σημασία.

Για τις περισσότερες εφαρμογές, το v4 είναι η προεπιλεγμένη επιλογή· μεταβείτε στο v7 για πρωτεύοντα κλειδιά βάσης δεδομένων όπου η σειρά εισαγωγής έχει σημασία.

UUID v4 χρησιμοποιεί 122 τυχαία bits, αποδίδοντας 5,3 × 10^36 πιθανές τιμές. Το πρόβλημα των γενεθλίων καθορίζει την πιθανότητα σύγκρουσης: μετά τη δημιουργία 2,7 × 10^18 (2,7 τρισεκατομμυρίων) UUID, υπάρχει 50% πιθανότητα μίας σύγκρουσης.

Με πρακτικούς όρους, η δημιουργία 1 δισεκατομμυρίου UUID ανά δευτερόλεπτο για 85 χρόνια φτάνει σε αυτό το όριο. Σε πιο ρεαλιστικές κλίμακες — ένα σύστημα που δημιουργεί 1 εκατομμύριο UUID την ημέρα — η πιθανότητα οποιασδήποτε σύγκρουσης σε 100 χρόνια είναι περίπου 1 στα 10^24.

Αυτό προϋποθέτει μια κατάλληλη γεννήτρια τυχαίων αριθμών (CSPRNG)· η χρήση του Math.random() στη JavaScript (το οποίο δεν είναι κρυπτογραφικά ασφαλές) μειώνει την εντροπία και αυξάνει τον κίνδυνο σύγκρουσης. Χρησιμοποιείτε πάντα crypto.randomUUID(), βιβλιοθήκες uuid v4 ή εγγενείς συναρτήσεις UUID βάσης δεδομένων για συστήματα παραγωγής.

Τα UUID ως πρωτεύοντα κλειδιά επιτρέπουν αποκεντρωμένη δημιουργία ID (οι εφαρμογές δημιουργούν ID χωρίς επικοινωνία με τη βάση δεδομένων) και αποτρέπουν επιθέσεις απαρίθμησης (οι χρήστες δεν μπορούν να μαντέψουν τα ID άλλων εγγραφών).

Ωστόσο, οι τυχαίες τιμές UUID v4 βλάπτουν την απόδοση του ευρετηρίου B-tree — οι τυχαίες εισαγωγές προκαλούν διασπάσεις σελίδων και κατακερματισμό, αυξάνοντας την ενίσχυση εγγραφών κατά 2-5x σε comparaison με διαδοχικά ακέραια κλειδιά. Το UUID v7 το λύνει αυτό με τυχαιότητα με πρόθεμα χρονικής σήμανσης, παρέχοντας τόσο μοναδικότητα όσο και διαδοχική σειρά.

Το κόστος αποθήκευσης είναι επίσης υψηλότερο: 16 bytes έναντι 4-8 bytes για ακέραιους, σημαντικό σε πίνακες με δισεκατομμύρια γραμμές και πολλαπλά ευρετήρια.

Ένα κοινό μοτίβο συνδυάζει τα UUID ως αναγνωριστικά προς τα έξω με εσωτερικά κλειδιά αυτόματης αύξησης ακεραίων, κάνοντας join στους πίνακες με βάση τον αποδοτικό ακέραιο ενώ εκθέτει μόνο το ασφαλές UUID σε API και URL.

Ένα UUID (Universally Unique Identifier) είναι μια τιμή 128-bit σχεδιασμένη να είναι μοναδική στον χώρο και τον χρόνο χωρίς κεντρική αρχή καταχώρισης, όπως ορίζεται από το IETF RFC 9562 (το οποίο αντικαθιστά το παλαιότερο RFC 4122).

Τα 128 bits του γράφονται ως 32 δεκαεξαδικοί χαρακτήρες ομαδοποιημένοι σε μοτίβο 8-4-4-4-12, όπως το 550e8400-e29b-41d4-a716-446655440000. Συγκεκριμένα bits είναι δεσμευμένα: το 13ο δεκαεξαδικό ψηφίο κωδικοποιεί την έκδοση και τα ανώτερα bits του 17ου δεκαεξαδικού ψηφίου κωδικοποιούν την παραλλαγή.

Τα υπόλοιπα bits μεταφέρουν τυχαία δεδομένα, μια χρονική σήμανση ή ένα όνομα με κατακερματισμό ανάλογα με την έκδοση. Επειδή ο προσπελάσιμος χώρος είναι 2^122, ανεξάρτητες γεννήτριες μπορούν να παράγουν με ασφάλεια αναγνωριστικά χωρίς να συντονίζονται ποτέ.

Ο απλούστερος τρόπος για να δημιουργήσετε ένα UUID είναι μια ενσωματωμένη συνάρτηση γλώσσας που καλεί μια κρυπτογραφικά ασφαλή πηγή τυχαίων αριθμών.

• Στην JavaScript, η crypto.randomUUID() επιστρέφει ένα UUID v4 και τεκμηριώνεται στα MDN Web Docs ως μέρος του Web Crypto API, το οποίο είναι διαθέσιμο σε σύγχρονα προγράμματα περιήγησης και στο Node.js 14.17+.
• Στην Python, η τυπική βιβλιοθήκη uuid παρέχει την uuid.uuid4() για τυχαίες τιμές και την uuid.uuid1() για τιμές που βασίζονται σε χρονική σήμανση.
• Στην PostgreSQL, η gen_random_uuid() παράγει ένα UUID v4, ενώ η MySQL 8 προσφέρει την UUID() για μια τιμή στυλ v1.

Όλες αυτές εκπέμπουν συμβολοσειρές συμβατές με το RFC 9562, επομένως τα αναγνωριστικά που δημιουργούνται σε μία γλώσσα συνεργάζονται άψογα με μια άλλη.

Ναι, ένα GUID και ένα UUID είναι το ίδιο αναγνωριστικό 128-bit· το GUID (Globally Unique Identifier) είναι απλώς η ορολογία της Microsoft για το τυπικό UUID που ορίζεται από το IETF RFC 9562. Είναι συμβατά σε επίπεδο δυαδικών δεδομένων, επομένως μια τιμή που δημιουργείται από τα Windows ή το .NET μπορεί να χρησιμοποιηθεί από οποιοδήποτε σύστημα συμβατό με το RFC και το αντίστροφο.

Η μόνη συνηθισμένη διαφορά είναι η παρουσίαση: τα εργαλεία της Microsoft συχνά περικλείουν την τιμή σε αγκύλες, για παράδειγμα {550e8400-e29b-41d4-a716-446655440000}, και ορισμένα API του COM ιστορικά μετέτρεπαν τα δεκαεξαδικά σε κεφαλαία.

Μια λεπτή επιφύλαξη είναι η σειρά των byte — το δυαδικό GUID της Microsoft αποθηκεύει τα τρία πρώτα πεδία σε μορφή little-endian, κάτι που έχει σημασία μόνο κατά την ανάλυση ακατέργαστων byte και όχι στην κανονική μορφή συμβολοσειράς με παύλες.

Ένα UUID δεν είναι μυστικό και δεν πρέπει ποτέ να αντιμετωπίζεται ως τέτοιο, ακόμη και όταν τα τυχαία bits του προέρχονται από μια κρυπτογραφικά ασφαλή γεννήτρια. Το RFC 9562 προειδοποιεί ρητά ότι τα UUID δεν προσφέρουν ενσωματωμένη ασφάλεια και δεν πρέπει να θεωρούνται δύσκολο να μαντευτούν· ομοίως, το OWASP προειδοποιεί κατά της χρήσης αναγνωριστικών ως διακριτικών εξουσιοδότησης.

Η έκδοση 4 αντλεί 122 bits από μια γεννήτρια CSPRNG, οπότε είναι μη πρακτικό να προβλεφθεί, αλλά οι εκδόσεις 1 και 7 ενσωματώνουν χρονικές σήμανσεις που διαρρέουν τον χρόνο δημιουργίας, ενώ οι εκδόσεις 3 και 5 είναι ντετερμινιστικά hashes ενός γνωστού χώρου ονομάτων και ονόματος.

Για διακριτικά συνεδρίας, επαναφορά κωδικού πρόσβασης ή κλειδιά API, δημιουργήστε αποκλειστικά μυστικά υψηλής εντροπίας αντί να βασίζεστε στη δομή ενός UUID για προστασία.

Τα πεδία έκδοσης και παραλλαγής είναι σταθερά πρότυπα bits ενσωματωμένα σε κάθε UUID του RFC 9562 που υποδεικνύουν στους αναλύτες πώς δημιουργήθηκε η τιμή.

Η έκδοση καταλαμβάνει τα τέσσερα πιο σημαντικά bits του έβδομου byte (το 13ο δεκαεξαδικό ψηφίο), επομένως ένα UUID v4 δείχνει πάντα 4 σε αυτό το σημείο και ένα v7 δείχνει πάντα 7. Η παραλλαγή βρίσκεται στα δύο ή τρία πιο σημαντικά bits του ένατου byte (το 17ο δεκαεξαδικό ψηφίο), το οποίο για την τυπική παραλλαγή IETF κάνει αυτό το ψηφίο ένα από τα 8, 9, a ή b.

Γι' αυτόν τον λόγο, ένα έγκυρο UUID v4 ταιριάζει με το πρότυπο xxxxxxxx-xxxx-4xxx-[89ab]xxx-xxxxxxxxxxxx. Ο έλεγχος αυτών των σταθερών θέσεων είναι ο σωστός τρόπος επικύρωσης ή ταξινόμησης ενός UUID αντί για έναν απλό έλεγχο μήκους.

Η μαζική δημιουργία UUID είναι χρήσιμη για την αρχικοποίηση βάσεων δεδομένων, τη δημιουργία δοκιμαστικών δεδομένων, δοκιμές φόρτου και συμπλήρωση εικονικών API, και αυτό το εργαλείο μπορεί να εξάγει πολλά έγκυρα αναγνωριστικά με ένα μόνο κλικ. Επειδή κάθε UUID δημιουργείται ανεξάρτητα από μια πηγή τυχαίων αριθμών ή χρονικής σήμανσης ανά RFC 9562, η δημιουργία μιας παρτίδας δεν φέρει κανένα ουσιαστικό κίνδυνο σύγκρουσης ακόμη και σε μεγάλους αριθμούς.

Για επαναλήψιμα δεδομένα δοκιμών, προτιμήστε τα ντετερμινιστικά UUID έκδοσης 5 που προέρχονται από έναν σταθερό χώρο ονομάτων και όνομα, ώστε η ίδια είσοδος να αποδίδει πάντα το ίδιο αναγνωριστικό σε όλες τις εκτελέσεις.

Κατά την αρχικοποίηση πινάκων κλίμακας παραγωγής, εξετάστε την έκδοση 7, ώστε οι μαζικά εισαγόμενες σειρές να καταλήγουν σε περίπου διαδοχική σειρά ευρετηρίου, κάτι που διατηρεί τις σελίδες B-tree συμπαγείς και μειώνει την ενίσχυση εγγραφής κατά την εισαγωγή.

Αποθηκεύστε τα UUID σε έναν εγγενή δυαδικό τύπο 16-byte όποτε η βάση δεδομένων σας υποστηρίζει έναν, επειδή η διατήρησή τους ως κείμενο 36 χαρακτήρων σπαταλάει περισσότερο από διπλάσιο χώρο και επιβραδύνει τις συγκρίσεις ευρετηρίου. Η PostgreSQL παρέχει ειδικό τύπο στήλης uuid, ενώ η MySQL και ο SQL Server χρησιμοποιούν συνήθως το BINARY(16) με συναρτήσεις μετατροπής προς και από τη συμβολοσειρά με παύλες.

Όπως σημειώνει το RFC 9562, τα UUID δεν διακρίνουν πεζά-κεφαλαία και πρέπει να κανονικοποιούνται — συνήθως σε πεζά — πριν από την αποθήκευση, ώστε οι αναζητήσεις να παραμένουν συνεπείς.

Εάν χρησιμοποιείτε UUID ως πρωτεύοντα κλειδιά, προτιμήστε την έκδοση 7 για να διατηρήσετε την τοπικότητα εισαγωγής· εάν πρέπει να χρησιμοποιήσετε την έκδοση 4, ορισμένες μηχανές σάς επιτρέπουν να αναδιατάξετε τα bytes χρονικής σήμανσης, αν και η έκδοση 7 είναι η τυποποιημένη λύση στο ίδιο πρόβλημα κατακερματισμού.

Το πιο κοινό λάθος με τα UUID είναι η χρήση μιας μη κρυπτογραφικής τυχαίας πηγής, όπως η συνάρτηση Math.random() της JavaScript, η οποία δεν είναι CSPRNG και μπορεί να παράγει μεροληπτικές ή προβλέψιμες τιμές· το MDN συνιστά αντίθετα τη crypto.randomUUID() ή το Web Crypto API.

Άλλα συχνά σφάλματα περιλαμβάνουν:

• αντιμετώπιση του μηδενικού UUID (όλα μηδενικά) ως πραγματικού αναγνωριστικού
• υπόθεση ότι τα UUID είναι αρκετά μυστικά για την εξουσιοδότηση πρόσβασης
• αποθήκευσή τους ως κείμενο όταν μια δυαδική στήλη 16-byte θα ήταν πολύ πιο αποδοτική

Οι προγραμματιστές αναμιγνύουν επίσης εκδόσεις ασυνεπώς ή βασίζονται στην έκδοση 1 σε περιβάλλοντα ευαίσθητα στο απόρρητο όπου η ενσωματωμένη χρονική σήμανση και η ιστορική διεύθυνση MAC διαρρέουν πληροφορίες. Τέλος, η σύγκριση UUID με διάκριση πεζών-κεφαλαίων προκαλεί ψευδείς αναντιστοιχίες, καθώς το RFC 9562 τα ορίζει ως μη ευαίσθητα στα πεζά-κεφαλαία.