MFA σε portals και CRM: TOTP, recovery codes και ασφαλής ανάκτηση λογαριασμού
Ένα ισχυρό password μειώνει τον κίνδυνο, αλλά δεν προστατεύει όταν κλαπεί μέσω phishing, credential stuffing ή malware. Το multi-factor authentication προσθέτει δεύτερη απόδειξη, όπως authenticator app ή security key. Η ασφάλεια όμως μπορεί να ακυρωθεί αν η διαδικασία ανάκτησης επιτρέπει σε κάποιον να παρακάμψει εύκολα το δεύτερο factor.
Η σωστή υλοποίηση καλύπτει ολόκληρο τον κύκλο ζωής: enrollment, login, αλλαγή συσκευής, recovery, ειδοποιήσεις και αφαίρεση authenticator. Δεν είναι απλώς ένα πεδίο έξι ψηφίων μετά το password.
Επιλογή δεύτερου factor
Οι συνηθισμένες επιλογές είναι TOTP authenticator app, passkeys ή hardware security keys, push approval και SMS/voice OTP. Δεν έχουν όλες την ίδια αντοχή στο phishing. Τα passkeys και security keys μπορούν να προσφέρουν phishing-resistant authentication, ενώ ένα TOTP code μπορεί να υποκλαπεί από ψεύτικη σελίδα σε πραγματικό χρόνο.
Το κατάλληλο επίπεδο εξαρτάται από το ρίσκο. Ένα admin panel με πρόσβαση σε οικονομικά ή προσωπικά δεδομένα χρειάζεται ισχυρότερη απαίτηση από ένα απλό customer account. Για ευαίσθητους ρόλους μπορεί να επιτρέπονται μόνο συγκεκριμένοι authenticator types.
Η NIST SP 800-63B περιγράφει authentication assurance levels και τον συνδυασμό ανεξάρτητων factors. Η εφαρμογή πρέπει να κάνει δική της risk assessment και να μη θεωρεί κάθε μέθοδο ισοδύναμη.
Ασφαλές enrollment
Η προσθήκη νέου authenticator απαιτεί πρόσφατη ισχυρή authentication. Ένας εισβολέας που βρήκε ξεκλείδωτο session δεν πρέπει να μπορεί να δεσμεύσει τη δική του συσκευή χωρίς reauthentication.
Για TOTP, ο server δημιουργεί secret με ασφαλή random generator και εμφανίζει QR code μόνο μέσα σε προστατευμένη ροή. Το enrollment ολοκληρώνεται αφού ο χρήστης υποβάλει έγκυρο code, αποδεικνύοντας ότι το authenticator ρυθμίστηκε. Το secret αποθηκεύεται κρυπτογραφημένο και η πρόσβαση περιορίζεται.
Για WebAuthn/passkeys, το backend ελέγχει challenge, origin, RP ID και credential uniqueness. Το authenticator παίρνει φιλικό όνομα ώστε ο χρήστης να αναγνωρίζει τις συσκευές του.
TOTP validation χωρίς replay
Τα TOTP codes ισχύουν για μικρό χρονικό παράθυρο. Ο server μπορεί να δεχτεί περιορισμένο clock skew, αλλά δεν ανοίγει υπερβολικά το window. Εφαρμόζει rate limiting ανά account, IP και device signal χωρίς να δημιουργεί denial of service με εύκολο account lock.
Ένα code που χρησιμοποιήθηκε επιτυχώς δεν πρέπει να γίνεται δεκτό ξανά στο ίδιο time step όπου το threat model απαιτεί replay protection. Το validation γίνεται server-side με constant-time comparison και τα secrets δεν γράφονται σε logs.
Τα errors δεν αποκαλύπτουν αν απέτυχε το password ή ο δεύτερος factor περισσότερο από όσο χρειάζεται. Τα security events καταγράφουν timestamp, authenticator type και outcome, όχι το OTP.
Recovery codes
Ο χρήστης μπορεί να χάσει τη συσκευή. Τα recovery codes είναι one-time secrets που αποθηκεύονται offline. Η τρέχουσα NIST καθοδήγηση αναφέρει ότι saved recovery code πρέπει να έχει επαρκή τυχαιότητα, να αποθηκεύεται hashed και να ακυρώνεται μετά τη χρήση, με έκδοση νέου.
Η εφαρμογή εμφανίζει τους codes μία φορά και επιτρέπει download ή print, όχι email σε απλό κείμενο. Στη βάση κρατά hashes, όπως για passwords, ώστε database leak να μην αποκαλύψει usable codes.
Κάθε χρήση ενεργοποιεί ειδοποίηση και αφαιρεί τον code. Η αναγέννηση ακυρώνει το προηγούμενο set και απαιτεί reauthentication. Το UI δείχνει πόσοι απομένουν χωρίς να τους ξαναεμφανίζει.
Δεύτερος authenticator αντί για εύκολη recovery
Η NIST συνιστά να ενθαρρύνονται τουλάχιστον δύο ξεχωριστά μέσα authentication, ώστε η απώλεια του βασικού να μη οδηγεί σε αδύναμη recovery. Ο χρήστης μπορεί να έχει passkey σε δύο συσκευές ή authenticator app μαζί με recovery code.
Η προσθήκη δεύτερου authenticator είναι πιο ασφαλής όταν γίνεται πριν χαθεί ο πρώτος. Το onboarding πρέπει να εξηγεί την αξία χωρίς να κουράζει τον χρήστη με τεχνική ορολογία.
Για οργανωτικά accounts, μπορεί να υπάρχει admin-assisted recovery, αλλά ο admin δεν πρέπει να βλέπει secrets ή να απενεργοποιεί MFA χωρίς audit, approval και notification.
Account recovery ως υψηλού ρίσκου διαδικασία
Η ανάκτηση παρακάμπτει το κανονικό login, άρα είναι στόχος επιθέσεων. Δεν βασίζεται μόνο σε εύκολες knowledge questions ή πληροφορίες που υπάρχουν στα social media.
Η NIST περιγράφει saved/issued recovery codes, recovery contacts και επανάληψη identity proofing, ανάλογα με το assurance level. Η κατάλληλη διαδικασία εξαρτάται από το αν ο λογαριασμός έχει ταυτοποιηθεί και τι δεδομένα προστατεύει.
Μετά από recovery:
- αποστέλλεται ειδοποίηση σε υπάρχοντα κανάλια
- ανακαλούνται ή επανεξετάζονται ενεργά sessions
- αφαιρούνται ή επαναδεσμεύονται authenticators σύμφωνα με policy
- καταγράφεται actor, μέθοδος και reason
- εφαρμόζεται προσωρινό hold σε ιδιαίτερα ευαίσθητες αλλαγές όπου χρειάζεται
Ο support agent δεν πρέπει να μπορεί με μία ανεξέλεγκτη ενέργεια να παρακάμψει όλα τα factors.
Step-up authentication
Δεν χρειάζεται κάθε page view να ζητά MFA. Για ευαίσθητες ενέργειες, όπως αλλαγή email, δημιουργία API key, export δεδομένων ή refund, η εφαρμογή ζητά πρόσφατη ισχυρή authentication.
Το session κρατά authentication time και achieved assurance level. Αν έχει περάσει το όριο, απαιτείται νέο factor. Το step-up δεσμεύεται στη συγκεκριμένη ενέργεια ή σύντομο παράθυρο και δεν μετατρέπεται σε μόνιμη παράκαμψη.
Remembered devices
Η επιλογή «Μην ξαναρωτήσεις σε αυτή τη συσκευή» χρειάζεται signed, revocable device token με expiry, όχι απλό boolean cookie. Το token συνδέεται με user, device record και version.
Ο χρήστης βλέπει remembered devices και μπορεί να τα ανακαλέσει. Αλλαγή password, recovery ή ύποπτη δραστηριότητα μπορεί να ακυρώνει όλα τα trusted-device tokens. Σε high-risk roles η λειτουργία μπορεί να απαγορεύεται.
Ειδοποιήσεις και audit
Ενημερώνουμε για enrollment νέου authenticator, αφαίρεση, recovery, χρήση recovery code και ύποπτες αποτυχημένες προσπάθειες. Η ειδοποίηση περιλαμβάνει χρόνο, περίπου τοποθεσία ή device information όπου είναι αξιόπιστα και link για άμεση προστασία account.
Το audit log είναι προσβάσιμο μόνο σε κατάλληλους ρόλους και δεν περιέχει secrets. Τα security analytics παρακολουθούν unusual enrollment, πολλές recovery attempts και support overrides.
Πώς το υλοποιεί η Ai Foundry
Στην Ai Foundry σχεδιάζουμε MFA με βάση τους ρόλους και το πραγματικό ρίσκο του portal ή CRM. Υποστηρίζουμε TOTP, passkeys ή security keys όπου ταιριάζουν, με ασφαλές enrollment, reauthentication και step-up για ευαίσθητες ενέργειες.
Αποθηκεύουμε TOTP secrets κρυπτογραφημένα, recovery codes μόνο ως hashes και εφαρμόζουμε rate limits, replay controls και revocable trusted-device tokens. Η recovery διαδικασία έχει audit, ειδοποιήσεις και ελεγχόμενα support permissions. Δοκιμάζουμε απώλεια συσκευής, διπλό code, session theft και αλλαγή authenticator ώστε η ασφάλεια να παραμένει λειτουργική και στην πραγματική ζωή.
Checklist
- Ταιριάζει ο authenticator type στο ρίσκο του ρόλου;
- Απαιτείται reauthentication για enrollment και αφαίρεση;
- Ολοκληρώνεται TOTP enrollment μόνο μετά από valid code;
- Υπάρχουν rate limits και replay protection;
- Αποθηκεύονται recovery codes hashed και one-time;
- Ενθαρρύνεται δεύτερος ανεξάρτητος authenticator;
- Είναι αυστηρότερη η recovery από ένα απλό email link;
- Υπάρχει step-up για κρίσιμες ενέργειες;
- Είναι revocable τα remembered devices;
- Στέλνονται notifications για κάθε security change;
Το MFA είναι τόσο ισχυρό όσο η πιο αδύναμη διαδρομή γύρω του. Η καλή υλοποίηση προστατεύει το καθημερινό login χωρίς να μετατρέπει την απώλεια συσκευής σε ανεξέλεγκτο bypass.