Γιατί ένας έγκυρος κωδικός μιας χρήσης αποτυγχάνει ακόμη και στην είσοδο VPN

Ανοίγετε τον πελάτη VPN, πληκτρολογείτε τον κωδικό πρόσβασης και τα έξι ψηφία από την εφαρμογή ελέγχου ταυτότητας επιστρέφουν ως άκυρα — δύο φορές, μετά και τρίτη. Τίποτα δεν άλλαξε στον λογαριασμό από χθες, οπότε το ένστικτο είναι να διαγράψετε την καταχώριση στην εφαρμογή και να τη σαρώσετε ξανά — συνήθως η λάθος επισκευή. Ένας κωδικός μιας χρήσης δεν είναι δεύτερος κωδικός πρόσβασης: η πύλη πρέπει να τον ζητήσει σε συγκεκριμένο βήμα, από συγκεκριμένη καταχωρισμένη εγγραφή, μέσα σε συγκεκριμένο παράθυρο, και οι περισσότερες απορρίψεις συμβαίνουν πριν συγκριθούν τα ψηφία. Βρείτε σε ποιο βήμα βρίσκεστε πριν αγγίξετε την εγγραφή.

Η σειρά των αιτημάτων δείχνει σε ποια ροή βρίσκεστε

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

Το λάθος σχήμα μοιάζει με κακό κωδικό. Επικολλήστε έναν φρέσκο κωδικό σε πεδίο μόνο για κωδικό πρόσβασης και ο διακομιστής θα τον διαβάσει ως μέρος του κωδικού. Στην πλευρά του πελάτη, το OpenVPN 2.4 και νεότερο κάνουν τη διαφορά ορατή: ένας διακομιστής που απαντά με AUTH_FAILED,CRV1: περιμένει απάντηση σε πρόκληση, άρα το προφίλ χρειάζεται static-challenge ή αρχείο κωδικού σε μορφή SCRV1:. Ένα παλαιότερο προφίλ που φέρει μόνο auth-user-pass επικυρώνει τον κωδικό πρόσβασης και μετά κολλάει, κάτι που στο αρχείο καταγραφής μοιάζει με αποτυχία OTP αν και δεν στάλθηκε κωδικός.

Το WireGuard αξίζει να αναφερθεί ως εξαίρεση: επαληθεύει ζεύγη κλειδιών και όχι ανθρώπους, άρα δεν υπάρχει πεδίο για κωδικό. Αν ένας πάροχος διαφημίζει κάποιον, κάτι έξω από τη σήραγγα τον δέχεται.

Τι κάνει ο διακομιστής με τα έξι ψηφία

Οι κωδικοί βάσει χρόνου ακολουθούν το RFC 6238, που τυλίγει την παλαιότερη κατασκευή βάσει μετρητή από το RFC 4226: HMAC πάνω σε κινούμενο παράγοντα, περικομμένο σε έξι ψηφία από προεπιλογή. Στο TOTP ο κινούμενος παράγοντας είναι η τρέχουσα ώρα Unix διαιρεμένη με ένα βήμα, 30 δευτερόλεπτα εκτός αν ο διαχειριστής την άλλαξε. Ο επαληθευτής δεν συγκρίνει ποτέ τα ψηφία σας με αποθηκευμένη τιμή· επαναϋπολογίζει τον αναμενόμενο κωδικό από τον κοινό σπόρο και συνήθως δέχεται και τα γειτονικά βήματα, ώστε μια αργή διαδρομή να μην αποτυγχάνει την είσοδο.

Δύο συνέπειες χάνονται. Η ζώνη ώρας του τηλεφώνου είναι άσχετη, γιατί ο σπόρος δεν βλέπει ποτέ τοπικό ρολόι — μετρά μόνο η απόκλιση από την πραγματική UTC, και μια συσκευή που τρέχει δύο λεπτά μπροστά αποτυγχάνει σε κάθε κωδικό ενώ δείχνει καθαρή αντίστροφη μέτρηση. Και ένας κωδικός είναι μίας χρήσης εξ ορισμού: ο επαληθευτής θυμάται την τελευταία τιμή μετρητή που δέχτηκε για αυτόν τον σπόρο, άρα τα ίδια ψηφία που υποβάλλονται ξανά απορρίπτονται ακόμη και μέσα στο ίδιο παράθυρο. Ένας πελάτης που επαναλαμβάνει μετά από λήξη χρόνου μπορεί να κάψει τον κωδικό που μόλις έστειλε.

Τα διακριτικά βάσει μετρητή μετακινούν τον μετρητή σε κάθε πάτημα, άρα χάνουν τον συγχρονισμό αφού δημιουργηθούν κωδικοί αλλά δεν σταλούν ποτέ· η συνήθης επισκευή είναι ένα παράθυρο επανασυγχρονισμού που δέχεται λίγες τιμές μπροστά. Αν ο διαχειριστής έχει εγγράψει HOTP και η εφαρμογή σας δείχνει TOTP, κάθε τιμή είναι λάθος με τρόπο που μοιάζει με πρόβλημα ρολογιού. Το URI παροχής πίσω από τον κωδικό QR ονομάζει τον τύπο, τα ψηφία, την περίοδο και το hash.

Αποτυχίες που μοιάζουν με λάθος κωδικό

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

Δεύτερο είναι ένα σύνολο παραμέτρων που δεν ταιριάζει. Ένας σπόρος εγγεγραμμένος με οκτώ ψηφία, περίοδο 60 δευτερολέπτων ή SHA-256 παράγει κωδικούς που ένας επαληθευτής που περιμένει έξι ψηφία, 30 δευτερόλεπτα και SHA-1 απορρίπτει, και στον πελάτη αυτό δεν ξεχωρίζει από λάθος κωδικό. Εμφανίζεται μετά από μεταναστεύσεις όπου η εγγραφή προστέθηκε ξανά από φωτογραφία του κωδικού QR ή όπου η εγγραφή του διακριτικού ξαναχτίστηκε με προεπιλογές.

Τρίτο δεν αφορά τον κωδικό. Οι πύλες συνήθως επιστρέφουν μία γενική αποτυχία ελέγχου ταυτότητας για λάθος κωδικό πρόσβασης, ληγμένο κωδικό και απενεργοποιημένο λογαριασμό, σκόπιμα, ώστε κανείς να μην μπορεί να ανιχνεύσει ποιος παράγοντας απέτυχε. Διαβάστε το αρχείο καταγραφής της πύλης ή του RADIUS αντί για το μήνυμα του πελάτη: μια πρόκληση που δεν εκδόθηκε ποτέ, μια άρνηση πρόσβασης χωρίς χαρακτηριστικό OTP και μια άρνηση πολιτικής εμφανίζονται ίδια στην οθόνη και οδηγούν σε διαφορετικά επόμενα βήματα.

Μια σύντομη ακολουθία που το περιορίζει

Ξεκινήστε από τον φθηνότερο έλεγχο και σταματήστε στο πρώτο βήμα που δεν στέκει.

1. Περιμένετε έναν φρέσκο κωδικό, υποβάλετέ τον μία φορά και σημειώστε αν η πρόκληση εμφανίζεται πριν ή αφού γίνει δεκτός ο κωδικός πρόσβασης.
2. Ταιριάξτε την ετικέτα στην εφαρμογή με το όνομα χρήστη που αποθηκεύει ο διακομιστής.
3. Επιβεβαιώστε ότι το προφίλ μπορεί να απαντήσει καθόλου σε πρόκληση, όπως στην περίπτωση CRV1 παραπάνω.
4. Συγκρίνετε το ρολόι της συσκευής με γνωστή πηγή χρόνου· απόκλιση πάνω από λίγες δεκάδες δευτερόλεπτα σπάει το TOTP από μόνη της.
5. Ρωτήστε τον διαχειριστή αν το διακριτικό είναι TOTP ή HOTP και ποια ψηφία, περίοδος και hash εγγράφηκαν.

Δύο κανόνες εμποδίζουν να χειροτερέψουν τα πράγματα. Μην επαναλαμβάνετε πολλές φορές: πολλές πύλες μετρούν αποτυχίες ανά λογαριασμό και είτε τον κλειδώνουν είτε αρχίζουν να καθυστερούν τις απαντήσεις, ώστε μια ριπή μετατρέπει μια μικρή λάθος ρύθμιση σε αίτημα υποστήριξης. Και μην επανεγγράφετε το διακριτικό ως διαγνωστικό, γιατί αυτό ακυρώνει τον παλιό σπόρο· αν η πραγματική βλάβη ήταν μια πρόκληση που ο πελάτης δεν έστειλε ποτέ, τώρα έχετε δύο αλλαγές να εξηγήσετε αντί για μία.

Κρατήστε τον σπόρο και τους κωδικούς ανάκτησης έξω από τη διαδικασία

Τα έξι ψηφία και το μυστικό πίσω τους δεν είναι ανταλλάξιμα. Ένας κωδικός QR παροχής ή ένας σπόρος Base32 δημιουργεί κάθε μελλοντικό κωδικό για τον λογαριασμό, άρα ανήκει στην ίδια κατηγορία με τον κωδικό πρόσβασης: όχι σε στιγμιότυπο οθόνης, όχι σε σχόλιο αιτήματος, όχι σε συνομιλία με κάποιον που επικοινώνησε πρώτος μαζί σας. Οι κωδικοί ανάκτησης είναι ξεχωριστός μηχανισμός — μίας χρήσης, συχνά παρακάμπτουν εντελώς το αίτημα κωδικού, και αν ξοδέψετε έναν για να δοκιμάσετε τον λογαριασμό, αφαιρείτε μια εφεδρική διαδρομή που μπορεί να χρειαστείτε αργότερα.

Ένας κωδικός δεν κάνει ούτε μια σελίδα εισόδου αξιόπιστη: ένα αίτημα OTP σε παρόμοιο τομέα συλλέγει έναν έγκυρο κωδικό και τον αναπαράγει μέσα στο παράθυρο, και το πιστοποιητικό εξακολουθεί να είναι αυτό που σας λέει πού πληκτρολογείτε.

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