2FA-Tool Logo
2FA-Tool.com Ασφαλής γεννήτρια κωδικών 2FA στο πρόγραμμα περιήγησης
⏱️ Κρυπτογραφία & Πρωτόκολλα RFC ✓ Ανάλυση Προτύπων IETF

Επεξήγηση TOTP έναντι HOTP: Βασικές διαφορές, ασφάλεια και αρχές λειτουργίας

Εκατομμύρια προγραμματιστές και μηχανικοί ασφαλείας βλέπουν κυλιόμενους 6-ψήφιους κωδικούς επαλήθευσης καθημερινά, αλλά λίγοι κατανοούν τον κομψό μαθηματικό μηχανισμό που λειτουργεί πίσω από την οθόνη. Από τους καθοδηγούμενους από συμβάντα μετρητές του RFC 4226 (HOTP) το 2005 έως τα διακριτά χρονικά βήματα του RFC 6238 (TOTP) το 2011, αυτός ο οδηγός εξετάζει τον αλγόριθμο Dynamic Truncation σε επίπεδο byte, τα τρωτά σημεία αποσυγχρονισμού μετρητή, τις ανοχές απόκλισης ρολογιού (clock drift) και τον λόγο για τον οποίο το TOTP κατέκτησε τον σύγχρονο ιστό.

2FA
Ομάδα Ασφαλείας 2FA-Tool
Ενημερώθηκε τον Οκτώβριο του 2026
Εκτιμώμενος χρόνος ανάγνωσης: 14 λεπτά (2.600+ λέξεις)
RFC 6238 RFC 4226 Dynamic Truncation
💡 Κρυπτογραφικά Συμπεράσματα (TL;DR)
  • Η Θεμελιώδης Διαφορά Εισόδου: Το HOTP υπολογίζει hashes από έναν μονοτονικά αυξανόμενο μετρητή C, ενώ το TOTP αντικαθιστά το C με ένα χρονικό βήμα εποχής T (CurrentUnixTime / 30).
  • Άμεση Κληρονομικότητα: Το TOTP είναι μαθηματικά μια εξειδίκευση του HOTP: TOTP(K, Time) = HOTP(K, T). Και οι δύο αλγόριθμοι χρησιμοποιούν ακριβώς την ίδια συνάρτηση Dynamic Truncation.
  • Αρχιτεκτονικός Καθοριστικός Παράγοντας: Το HOTP διατηρεί κατάσταση (οι διακομιστές πρέπει να κλειδώνουν και να αποθηκεύουν τους μετρητές στον δίσκο σε κάθε επικύρωση). Το TOTP είναι stateless (χωρίς κατάσταση), επιτρέποντας στα σύγχρονα cloud microservices να επικυρώνουν tokens σε κατανεμημένα clusters με εξισορρόπηση φορτίου (load-balancing) χωρίς κεντρικές λειτουργίες εγγραφής στη βάση δεδομένων.
01

Ιστορικές Ρίζες: Από τα Ιδιοταγή Hardware Tokens στα Ανοιχτά Πρότυπα Ιστού

Στις αρχές της δεκαετίας του 2000, ο εταιρικός έλεγχος ταυτότητας δύο παραγόντων κυριαρχούνταν από ιδιοταγή key fobs όπως το RSA SecurID. Αυτές οι κλειστές, δαπανηρές συσκευές περιείχαν εσωτερικούς κρυστάλλους χαλαζία συγχρονισμένους με ιδιόκτητους εταιρικούς διακομιστές. Εάν ένας οργανισμός επιθυμούσε να παράσχει ασφάλεια πολλαπλών παραγόντων σε χιλιάδες υπαλλήλους, το κόστος προμήθειας υλικού και οι άδειες χρήσης ήταν υπέρογκα.

Για την απελευθέρωση του ελέγχου ταυτότητας από ιδιοταγείς παρόχους, η κοινοπραξία OATH (Initiative for Open Authentication) ιδρύθηκε από ηγέτες του κλάδου με σκοπό τη δημιουργία ανοιχτών, απαλλαγμένων από δικαιώματα προτύπων IETF, τα οποία κάθε μηχανικός λογισμικού θα μπορούσε ελεύθερα να επιθεωρήσει, να υλοποιήσει και να ελέγξει:

📜 2005: RFC 4226 (HOTP)

HMAC-Based One-Time Password Algorithm. Σχεδιασμένο για μικροελεγκτές χαμηλής κατανάλωσης με φυσικά πλήκτρα πίεσης. Το πάτημα του κουμπιού αυξάνει έναν εσωτερικό μετρητή και εμφανίζει ένα 6-ψήφιο token σε οθόνη LCD.

📜 2011: RFC 6238 (TOTP)

Time-Based One-Time Password Algorithm. Σχεδιάστηκε καθώς αυξανόταν ραγδαία η υιοθέτηση των smartphones. Αξιοποιώντας τον συγχρονισμό ώρας δικτύου NTP μέσω κινητής τηλεφωνίας, το TOTP εξάλειψε πλήρως τις αποκλίσεις κατάστασης των φυσικών κουμπιών.

02

Αρχιτεκτονική HOTP (RFC 4226) & Μηχανισμός Bytes Dynamic Truncation

Ο βασικός μαθηματικός ορισμός του HOTP είναι απατηλά συνοπτικός:

HOTP(K, C) = Truncate(HMAC-SHA-1(K, C)) mod 10DigitCount

Ανάλυση Παραμέτρων:

  • K: Κοινόχρηστο συμμετρικό μυστικό κλειδί (τυπικά μια αποκωδικοποιημένη από Base32 δυαδική ακολουθία 160-bit / 20-byte).
  • C: Μετρητής ακεραίου 8-byte (64-bit) big-endian.
  • HMAC-SHA-1: Κωδικός ελέγχου ταυτότητας μηνύματος με κλειδί που παράγει κρυπτογραφικό digest 20 byte (160 bit).

🔍 Πώς το Dynamic Truncation (DT) Μετατρέπει 20 Bytes σε 6 Ψηφία:

Ένα digest HMAC-SHA1 περιέχει 160 bits (20 bytes). Η εξαγωγή 6 ομοιόμορφων δεκαδικών ψηφίων απαιτεί έναν ντετερμινιστικό μηχανισμό επιλογής με αντοχή σε συγκρούσεις, όπως ορίζεται στην Ενότητα 5.3 του RFC 4226:

// Βήμα 1: Υπολογισμός δυναμικής μετατόπισης (Dynamic Offset)
Offset = HS[19] & 0x0F
Λαμβάνουμε το τελευταίο byte (δείκτης 19) του digest των 20 byte. Η εφαρμογή μάσκας με το 0x0F απομονώνει τα 4 bits χαμηλής τάξης, δίνοντας έναν ακέραιο αυστηρά μεταξύ 0 και 15 (0x0 έως 0xF). Αυτό διασφαλίζει ότι η επακόλουθη εξαγωγή 4 byte δεν θα υπερβεί ποτέ το buffer των 20 byte (καθώς 15 + 4 = 19).
// Βήμα 2: Εξαγωγή 4 διαδοχικών Bytes με μάσκα
P = ( (HS[Offset] & 0x7F) << 24 ) | ( (HS[Offset+1] & 0xFF) << 16 ) | ( (HS[Offset+2] & 0xFF) << 8 ) | ( HS[Offset+3] & 0xFF )
Εξάγονται 4 bytes ξεκινώντας από το Offset. Η μάσκα 0x7F μηδενίζει το πιο σημαντικό bit (MSB) για να αποφευχθεί υπερχείλιση προσημασμένου ακεραίου σε διαφορετικές αρχιτεκτονικές CPU (διασφαλίζοντας έναν καθαρό θετικό ακέραιο 31-bit).
// Βήμα 3: Αριθμητική Modulo για τα τελικά ψηφία
OTP = P mod 106 = P mod 1000000
Η εφαρμογή του modulo 1.000.000 απομονώνει τα τελικά 6 δεκαδικά ψηφία, συμπληρώνοντας με μηδενικά στην αρχή εάν απαιτείται (π.χ. το 748 γίνεται "000748").
🧪 Συγκεκριμένο διάνυσμα δοκιμής από το Παράρτημα D του RFC 4226:

Έστω ότι το μυστικό κλειδί είναι σε ASCII "12345678901234567890" και ο Μετρητής C = 0. Το προκύπτον digest HMAC-SHA1 σε δεκαεξαδική μορφή είναι:

cc 93 cf 18 50 8d 94 93 4c 64 b6 6d 8b fb 87 fb 23 cb 4b 71

1. Το τελικό byte είναι 0x71. 0x71 & 0x0F = 0x01, άρα Offset = 1.
2. Τα Bytes 1 έως 4 είναι: 93 cf 18 50. Ο μηδενισμός του MSB δίνει 0x13cf1850, το οποίο σε δεκαδική μορφή ισούται με 332.339.280.
3. 332339280 mod 1000000 = 339280. Το τελικό 6-ψήφιο OTP είναι 339280!

03

Εξέλιξη TOTP (RFC 6238): Η Μαγεία του Χρονικού Βήματος

Το HOTP απαιτούσε τη διατήρηση του μετρητή στον πελάτη σε συγχρονισμό με τον διακομιστή. Σε συσκευές λογισμικού, η καταμέτρηση των πατημάτων πλήκτρων ή κουμπιών εισάγει διαρκώς ανθρώπινο λάθος.

Το RFC 6238 αντικατέστησε τον μετρητή C με ένα διακριτό χρονικό βήμα T που προέρχεται απευθείας από το ρολόι εποχής Unix (Unix epoch clock):

T = ⌊ (CurrentUnixTime - T0) / X ⌋
  • CurrentUnixTime: Δευτερόλεπτα που έχουν παρέλθει από τις 1970-01-01 00:00:00 UTC.
  • T0: Αναφορά αρχικοποίησης εποχής (με προεπιλογή το 0 σε όλες τις σύγχρονες υλοποιήσεις).
  • X (Παράθυρο Χρονικού Βήματος): Τυπική συνιστώμενη διάρκεια 30 δευτερολέπτων.
  • Συνάρτηση Floor ⌊ ⌋: Για οποιαδήποτε χρονική σήμανση εντός ενός παραθύρου 30 δευτερολέπτων, το T παραμένει αμετάβλητο. Για παράδειγμα, μεταξύ των δευτερολέπτων εποχής 1728211200 και 1728211229, το T αποτιμάται στον ακριβώς ίδιο ακέραιο 64-bit.

Δυαδική Σειριοποίηση: Μόλις υπολογιστεί το T, συσκευάζεται σε ένα buffer δυαδικών bytes 8-byte big-endian (πανομοιότυπο σε δομή μνήμης με τον μετρητή C στο HOTP). Κατά συνέπεια, ο ενοποιημένος τύπος απλοποιείται σε:
TOTP(K, Time) = HOTP(K, T) Αυτή η μαθηματική κομψότητα εξηγεί γιατί οι εφαρμογές authenticator ανανεώνουν τα tokens συγχρονισμένα κάθε 30 δευτερόλεπτα χωρίς να απαιτείται επίμονος συγχρονισμός κατάστασης.

Υποστήριξη RFC 6238 για SHA-256 και SHA-512: Ενώ το RFC 4226 όριζε αυστηρά το HMAC-SHA-1, το RFC 6238 επέκτεινε την υποστήριξη για HMAC-SHA-256 και HMAC-SHA-512. Στο SHA-256 (digest 32-byte), η μετατόπιση λαμβάνεται από το byte 31 (HS[31] & 0x0F)· στο SHA-512 (digest 64-byte), η μετατόπιση λαμβάνεται από το byte 63 (HS[63] & 0x0F). Ωστόσο, στο 99,9% των εμπορικών ιστότοπων (Google, Microsoft, GitHub, AWS), το SHA-1 παραμένει η πανταχού παρούσα προεπιλογή λόγω συμβατότητας με παλαιότερες εφαρμογές κινητών.
04

Ολοκληρωμένος Πίνακας Άμεσης Σύγκρισης (HOTP έναντι TOTP)

Διάσταση HOTP (RFC 4226) TOTP (RFC 6238)
Μεταβλητή Εισόδου Μετρητής Συμβάντων C (μονοτονικά αυξανόμενος) Χρονικό Βήμα T (παράθυρο εποχής Unix 30 δευτερολέπτων)
Διάρκεια Ζωής Token Αόριστη (έγκυρο μέχρι να καταναλωθεί στην επόμενη σύνδεση) Αυστηρά 30 δευτερόλεπτα (αυτόματη ακύρωση)
Αρχιτεκτονική Διακομιστή Με κατάσταση (απαιτεί ατομικές εγγραφές στη βάση δεδομένων ανά σύνδεση) Χωρίς κατάσταση (ανεξάρτητη επαλήθευση μέσω NTP)
Έκθεση σε Επιθέσεις Replay Μέτρια (το υποκλαπέν token παραμένει έγκυρο μέχρι να χρησιμοποιηθεί) Ελάχιστη (περιορίζεται στα εναπομείναντα δευτερόλεπτα του τρέχοντος παραθύρου)
Κύριος Τρόπος Αποτυχίας Αποσυγχρονισμός Μετρητή (κατά λάθος πατήματα πλήκτρων) Απόκλιση Ρολογιού (απόκλιση ώρας στο τηλέφωνο του χρήστη)
Υποστηριζόμενα Cryptographic Hashes Αποκλειστικά HMAC-SHA-1 HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-512
Υιοθέτηση στον Κλάδο Παλαιά τραπεζικά fobs, εξειδικευμένες φυσικές πύλες 99,9% των σύγχρονων authenticators ιστού
05

Αποσυγχρονισμός έναντι Απόκλισης Χρόνου: Τεχνικές Λύσεις

Σε κατανεμημένα περιβάλλοντα παραγωγής, οι πελάτες και οι διακομιστές αναπόφευκτα αποκλίνουν. Οι κρυπτογράφοι σχεδίασαν ρητά παράθυρα αντιστάθμισης για τη διατήρηση της αξιοπιστίας:

⚙️ Μετριασμός HOTP: Παράθυρο Επαλήθευσης Look-Ahead (s)

Εάν ένας χρήστης πατήσει το κουμπί του token 5 φορές χωρίς υποβολή, ο μετρητής του πελάτη φτάνει στο C+5 ενώ ο διακομιστής παραμένει στο C.
Το RFC 4226 καθορίζει ότι κατά τον έλεγχο ταυτότητας, ο διακομιστής υπολογίζει ένα παράθυρο look-ahead που εκτείνεται στο [C+1, C+s] (συνήθως s=20). Εάν υπάρξει αντιστοίχιση, ο διακομιστής μεταβαίνει μπροστά και συγχρονίζει αμέσως τον μετρητή C.

⏱️ Μετριασμός TOTP: Ανοχή Απόκλισης Χρόνου (Time Skew Tolerance ±1 Παράθυρο)

Λόγω καθυστέρησης δικτύου ή απόκλισης ρολογιού της συσκευής πελάτη (π.χ. το ρολόι ενός τηλεφώνου λειτουργεί 10 δευτερόλεπτα πίσω), τα tokens ενδέχεται να φτάσουν σε παρακείμενα χρονικά βήματα.
Οι διακομιστές παραγωγής αξιολογούν έναν πίνακα 3 παραθύρων: [T-1, T, T+1], επεκτείνοντας ουσιαστικά το παράθυρο αποδοχής στα 90 δευτερόλεπτα.

Υποχρεωτικός Κανόνας Anti-Replay: Για να αποτραπούν επιθέσεις replay εντός του παραθύρου απόκλισης των 90 δευτερολέπτων, οι διακομιστές πρέπει να αποθηκεύουν στην προσωρινή μνήμη (cache) και να κλειδώνουν τα αναλωμένα tokens στη μνήμη (π.χ. Redis) για 90 δευτερόλεπτα, απορρίπτοντας διπλότυπες υποβολές.
🛡️ Σύγκριση Συμβολοσειρών Σταθερού Χρόνου (Άμυνα κατά Timing Attacks):

Όταν οι διακομιστές επαληθεύουν εάν ο κωδικός που υπέβαλε ο χρήστης ταιριάζει με τον υπολογισμένο κωδικό, οι απλοί έλεγχοι ισότητας συμβολοσειρών (όπως userOtp === serverOtp) τερματίζονται στον πρώτο μη συμβατό χαρακτήρα. Ένας εισβολέας που μετρά μικροσκοπικούς χρόνους απόκρισης δικτύου μπορεί να ανακατασκευάσει τα ψηφία επαναληπτικά. Τα εταιρικά backends επιβάλλουν συγκρίσεις ισότητας σταθερού χρόνου (π.χ. crypto.timingSafeEqual στο Node.js) για να αποτρέψουν αναλύσεις χρονισμού μέσω πλευρικών καναλιών.

06

Γιατί το TOTP Επικράτησε στο Σύγχρονο Διαδίκτυο

Ο αποφασιστικός θρίαμβος του TOTP έναντι του HOTP σε όλο τον ιστό οδηγήθηκε από τρεις αρχιτεκτονικές επιταγές:

☁️ Stateless Επεκτασιμότητα στο Cloud

Σε κατανεμημένα microservices πολλαπλών περιοχών, οποιοδήποτε instance διακομιστή με ρολόι συγχρονισμένο μέσω NTP μπορεί να επικυρώσει tokens TOTP χωρίς να κάνει ερωτήματα ή να κλειδώνει κάποια κεντρική εγγραφή στη βάση δεδομένων.

📱 Συνέργεια με το Οικοσύστημα Κινητών

Τα smartphones βαθμονομούν συνεχώς τα ρολόγια του συστήματός τους μέσω σταθμών βάσης κινητής τηλεφωνίας και GPS, εξαλείφοντας την απόκλιση ρολογιού χωρίς να απαιτείται συντήρηση φυσικού υλικού.

🛡️ Στενό Παράθυρο Επίθεσης 30 Δευτερολέπτων

Τα tokens HOTP παραμένουν έγκυρα επ' αόριστον μέχρι να χρησιμοποιηθούν. Τα tokens TOTP λήγουν εντός 30 δευτερολέπτων, εξουδετερώνοντας αυτόματα παραβιασμένα αρχεία καταγραφής και παθητικές υποκλοπές πακέτων.

🧮 Μηχανή RFC 6238 Αμιγώς στην Πλευρά του Πελάτη

Ζήστε τους Υπολογισμούς TOTP σε Πραγματικό Χρόνο στο 2FA-Tool

Δείτε πώς η συμβολοσειρά του μυστικού Base32 μετατρέπεται σε δυναμικούς 6-ψήφιους κωδικούς μέσω του dynamic truncation HMAC-SHA1. 100% εκτός σύνδεσης στο πρόγραμμα περιήγησής σας.

Άνοιγμα Online Γεννήτριας