ΜΕΡΟΣ Ι: Πώς να συνδεθείτε

Θα υποθέσουμε ότι γνωρίζετε ήδη πώς να κατασκευάσετε μια φόρμα HTML σύνδεσης + κωδικού πρόσβασης η οποία POSTάρει τις τιμές σε ένα σενάριο στην πλευρά του διακομιστή για έλεγχο ταυτότητας. Οι παρακάτω ενότητες θα ασχοληθούν με πρότυπα για υγιή πρακτικά auth, και πώς να αποφύγετε τις πιο συνηθισμένες παγίδες ασφαλείας. Για HTTPS ή όχι για HTTPS; Αν η σύνδεση δεν είναι ήδη ασφαλής (δηλαδή, διοχετευμένη μέσω HTTPS με χρήση SSL/TLS), οι τιμές της φόρμας σύνδεσης θα αποστέλλονται σε καθαρό κείμενο, γεγονός που επιτρέπει σε οποιονδήποτε κρυφακούει τη γραμμή μεταξύ του προγράμματος περιήγησης και του διακομιστή ιστού να μπορεί να διαβάσει τις συνδέσεις καθώς περνούν. Αυτός ο τύπος υποκλοπής γίνεται συνήθως από τις κυβερνήσεις, αλλά γενικά, δεν θα ασχοληθούμε με τα 'ιδιόκτητα' καλώδια παρά μόνο για να πούμε το εξής: Απλά χρησιμοποιήστε το HTTPS. Στην ουσία, ο μόνος πρακτικός τρόπος για να προστατευτείτε από την υποκλοπή/παρακολούθηση πακέτων κατά τη διάρκεια της σύνδεσης είναι η χρήση του HTTPS ή ενός άλλου σχήματος κρυπτογράφησης που βασίζεται σε πιστοποιητικά (για παράδειγμα, TLS) ή ενός δοκιμασμένου σχήματος πρόκλησης-απάντησης (για παράδειγμα, το SRP που βασίζεται στο Diffie-Hellman). Οποιαδήποτε άλλη μέθοδος μπορεί εύκολα να παρακαμφθεί από έναν εισβολέα που κρυφακούει. Φυσικά, αν είστε πρόθυμοι να γίνετε λίγο ανεφάρμοστοι, θα μπορούσατε επίσης να χρησιμοποιήσετε κάποια μορφή σχήματος ελέγχου ταυτότητας δύο παραγόντων (π.χ. την εφαρμογή Google Authenticator, ένα φυσικό 'cold war style' codebook, ή ένα RSA key generator dongle). Εάν εφαρμοστεί σωστά, αυτό θα μπορούσε να λειτουργήσει ακόμη και με μια μη ασφαλή σύνδεση, αλλά είναι δύσκολο να φανταστεί κανείς ότι ένας προγραμματιστής θα ήταν πρόθυμος να εφαρμόσει το two-factor auth αλλά όχι το SSL. (Μην) Κρυπτογράφηση JavaScript από το δικό σας ρολό (Roll-your-own) / κρυπτογράφηση/κρυπτογράφηση με κρυπτογράφηση σε μορφή κατακερματισμού Δεδομένου του αντιληπτού (αν και πλέον αποφεύξιμου) κόστους και της τεχνικής δυσκολίας της εγκατάστασης ενός πιστοποιητικού SSL στον ιστότοπό σας, ορισμένοι προγραμματιστές μπαίνουν στον πειρασμό να αναπτύξουν τα δικά τους συστήματα κατακερματισμού ή κρυπτογράφησης εντός του προγράμματος περιήγησης, προκειμένου να αποφύγουν τη διαβίβαση συνδέσεων καθαρού κειμένου μέσω ενός μη ασφαλούς καλωδίου. Αν και αυτή είναι μια ευγενική σκέψη, είναι ουσιαστικά άχρηστη (και μπορεί να αποτελέσει ελάττωμα ασφαλείας), εκτός αν συνδυαστεί με ένα από τα παραπάνω - δηλαδή είτε με την εξασφάλιση της γραμμής με ισχυρή κρυπτογράφηση είτε με τη χρήση ενός δοκιμασμένου μηχανισμού πρόκλησης-απόκρισης (αν δεν ξέρετε τι είναι αυτό, απλά να ξέρετε ότι είναι μια από τις πιο δύσκολα αποδείξιμες, πιο δύσκολα σχεδιάσιμες και πιο δύσκολα υλοποιήσιμες έννοιες στην ψηφιακή ασφάλεια). Ενώ είναι αλήθεια ότι ο κατακερματισμός του κωδικού πρόσβασης μπορεί να είναι αποτελεσματικός κατά της αποκάλυψης κωδικού πρόσβασης, είναι ευάλωτος σε επιθέσεις επανάληψης, επιθέσεις Man-In-The-Middle / αεροπειρατεία (αν ένας εισβολέας μπορεί να εισάγει μερικά bytes στην ανασφάλιστη σελίδα HTML πριν φτάσει στο πρόγραμμα περιήγησής σας, μπορεί απλά να σχολιάσει τον κατακερματισμό στην JavaScript), ή επιθέσεις brute-force (αφού δίνετε στον εισβολέα τόσο το όνομα χρήστη, το αλάτι όσο και τον κατακερματισμένο κωδικό πρόσβασης). CAPTCHAS κατά της ανθρωπότητας Το CAPTCHA προορίζεται να ανατρέψει μια συγκεκριμένη κατηγορία επιθέσεων: αυτοματοποιημένη δοκιμασία και σφάλμα λεξικού/brute force χωρίς ανθρώπινο χειριστή. Δεν υπάρχει καμία αμφιβολία ότι αυτή είναι μια πραγματική απειλή, ωστόσο, υπάρχουν τρόποι απρόσκοπτης αντιμετώπισής της που δεν απαιτούν CAPTCHA, συγκεκριμένα κατάλληλα σχεδιασμένα συστήματα στραγγαλισμού σύνδεσης από την πλευρά του διακομιστή - θα τα συζητήσουμε αργότερα. Γνωρίζετε ότι οι υλοποιήσεις CAPTCHA δεν είναι ίδιες- συχνά δεν είναι επιλύσιμες από τον άνθρωπο, οι περισσότερες από αυτές είναι στην πραγματικότητα αναποτελεσματικές έναντι των bots, όλες είναι αναποτελεσματικές έναντι της φτηνής εργασίας του τρίτου κόσμου (σύμφωνα με το OWASP, η τρέχουσα τιμή του sweatshop είναι 12 δολάρια ανά 500 δοκιμές) και ορισμένες υλοποιήσεις μπορεί να είναι τεχνικά παράνομες σε ορισμένες χώρες (βλ. OWASP Authentication Cheat Sheet). Αν πρέπει να χρησιμοποιήσετε ένα CAPTCHA, χρησιμοποιήστε το reCAPTCHA της Google, καθώς είναι εξ ορισμού OCR-σκληρό (αφού χρησιμοποιεί ήδη OCR-ανεπιθύμητες σαρώσεις βιβλίων) και προσπαθεί πολύ σκληρά να είναι φιλικό προς τον χρήστη. Προσωπικά, τείνω να βρίσκω τα CAPTCHAS ενοχλητικά και τα χρησιμοποιώ μόνο ως έσχατη λύση όταν ένας χρήστης έχει αποτύχει να συνδεθεί αρκετές φορές και οι καθυστερήσεις στραγγαλισμού έχουν εξαντληθεί. Αυτό θα συμβεί αρκετά σπάνια ώστε να είναι αποδεκτό και ενισχύει το σύστημα στο σύνολό του. Αποθήκευση κωδικών πρόσβασης / επαλήθευση συνδέσεων Αυτό μπορεί τελικά να είναι κοινή γνώση μετά από όλες τις πολύ-δημοσιευμένες παραβιάσεις και διαρροές δεδομένων χρηστών που είδαμε τα τελευταία χρόνια, αλλά πρέπει να ειπωθεί: Μην αποθηκεύετε κωδικούς πρόσβασης σε καθαρό κείμενο στη βάση δεδομένων σας. Οι βάσεις δεδομένων των χρηστών παραβιάζονται, διαρρέουν ή συλλέγονται τακτικά μέσω SQL injection, και αν αποθηκεύετε ακατέργαστους κωδικούς πρόσβασης σε απλό κείμενο, αυτό σημαίνει ότι το παιχνίδι τελείωσε αμέσως για την ασφάλεια της σύνδεσής σας. Έτσι, αν δεν μπορείτε να αποθηκεύσετε τον κωδικό πρόσβασης, πώς ελέγχετε ότι ο συνδυασμός login+password που αποστέλλεται από τη φόρμα σύνδεσης είναι σωστός; Η απάντηση είναι ο κατακερματισμός με χρήση μιας συνάρτησης εξαγωγής κλειδιού. Κάθε φορά που δημιουργείται ένας νέος χρήστης ή αλλάζει ένας κωδικός πρόσβασης, παίρνετε τον κωδικό πρόσβασης και τον περνάτε από ένα KDF, όπως το Argon2, το bcrypt, το scrypt ή το PBKDF2, μετατρέποντας τον κωδικό πρόσβασης καθαρού κειμένου ("correcthorsebatterystaple") σε ένα μακρύ, τυχαίο αλφαριθμητικό, το οποίο είναι πολύ πιο ασφαλές να αποθηκεύσετε στη βάση δεδομένων σας. Για να επαληθεύσετε μια σύνδεση, εκτελείτε την ίδια συνάρτηση κατακερματισμού στον εισαγόμενο κωδικό πρόσβασης, αυτή τη φορά περνώντας το salt και συγκρίνετε την προκύπτουσα συμβολοσειρά κατακερματισμού με την τιμή που είναι αποθηκευμένη στη βάση δεδομένων σας. Τα Argon2, bcrypt και scrypt αποθηκεύουν ήδη το salt μαζί με το hash. Ανατρέξτε σε αυτό το άρθρο στο sec.stackexchange για πιο λεπτομερείς πληροφορίες. Ο λόγος που χρησιμοποιείται ένα salt είναι ότι ο κατακερματισμός από μόνος του δεν είναι επαρκής -- θα θέλετε να προσθέσετε ένα λεγόμενο 'salt' για να προστατεύσετε το hash από rainbow tables. Ένα salt ουσιαστικά εμποδίζει δύο κωδικούς πρόσβασης που ταιριάζουν ακριβώς να αποθηκευτούν ως η ίδια τιμή κατακερματισμού, αποτρέποντας έτσι τη σάρωση ολόκληρης της βάσης δεδομένων σε μία εκτέλεση, εάν ένας επιτιθέμενος εκτελεί επίθεση μαντείας κωδικού πρόσβασης. Ένας κρυπτογραφικός κατακερματισμός δεν πρέπει να χρησιμοποιείται για την αποθήκευση κωδικών πρόσβασης, επειδή οι επιλεγμένοι από τον χρήστη κωδικοί πρόσβασης δεν είναι αρκετά ισχυροί (δηλαδή συνήθως δεν περιέχουν αρκετή εντροπία) και μια επίθεση μαντεψιάς κωδικών πρόσβασης θα μπορούσε να ολοκληρωθεί σε σχετικά σύντομο χρονικό διάστημα από έναν επιτιθέμενο με πρόσβαση στους κατακερματισμούς. Για το λόγο αυτό χρησιμοποιούνται τα KDFs - αυτά ουσιαστικά "τεντώνουν το κλειδί", πράγμα που σημαίνει ότι κάθε μαντεψιά κωδικού πρόσβασης που κάνει ένας επιτιθέμενος προκαλεί πολλαπλές επαναλήψεις του αλγορίθμου κατακερματισμού, για παράδειγμα 10.000 φορές, γεγονός που αναγκάζει τον επιτιθέμενο να μαντέψει τον κωδικό πρόσβασης 10.000 φορές πιο αργά. Τα δεδομένα συνεδρίας - "Έχετε συνδεθεί ως Spiderman69" Αφού ο διακομιστής επαληθεύσει τη σύνδεση και τον κωδικό πρόσβασης με τη βάση δεδομένων των χρηστών σας και βρει μια αντιστοιχία, το σύστημα χρειάζεται έναν τρόπο για να θυμάται ότι το πρόγραμμα περιήγησης έχει πιστοποιηθεί. Αυτό το γεγονός θα πρέπει να αποθηκεύεται πάντα μόνο από την πλευρά του διακομιστή στα δεδομένα συνόδου. Εάν δεν είστε εξοικειωμένοι με τα δεδομένα συνόδου, δείτε πώς λειτουργούν: Μια μοναδική συμβολοσειρά που δημιουργείται τυχαία αποθηκεύεται σε ένα cookie που λήγει και χρησιμοποιείται για να παραπέμπει σε μια συλλογή δεδομένων - τα δεδομένα συνόδου - τα οποία αποθηκεύονται στον διακομιστή. Εάν χρησιμοποιείτε ένα πλαίσιο MVC, αυτό αναμφίβολα έχει ήδη αντιμετωπιστεί. Εάν είναι δυνατόν, βεβαιωθείτε ότι το cookie συνεδρίας έχει τις σημαίες secure και HTTP Only (Μόνο HTTP) ρυθμισμένες κατά την αποστολή του στο πρόγραμμα περιήγησης. Η σημαία HttpOnly παρέχει κάποια προστασία από την ανάγνωση του cookie μέσω επίθεσης XSS. Η σημαία secure διασφαλίζει ότι το cookie αποστέλλεται πίσω μόνο μέσω HTTPS και, επομένως, προστατεύει από επιθέσεις κατασκοπείας δικτύου. Η τιμή του cookie δεν πρέπει να είναι προβλέψιμη. Όταν παρουσιάζεται ένα cookie που παραπέμπει σε ανύπαρκτη σύνοδο, η τιμή του πρέπει να αντικαθίσταται αμέσως για την αποφυγή session fixation.

ΜΕΡΟΣ ΙΙ: Πώς να παραμείνετε συνδεδεμένοι - Το διαβόητο πλαίσιο ελέγχου "Να με θυμάστε"

Τα Cookies μόνιμης σύνδεσης ("θυμηθείτε με" λειτουργικότητα) αποτελούν μια επικίνδυνη ζώνη: από τη μία πλευρά, είναι απολύτως εξίσου ασφαλή με τις συμβατικές συνδέσεις όταν οι χρήστες κατανοούν πώς να τα χειρίζονται, και από την άλλη πλευρά, αποτελούν τεράστιο κίνδυνο για την ασφάλεια στα χέρια απρόσεκτων χρηστών, οι οποίοι μπορεί να τα χρησιμοποιούν σε δημόσιους υπολογιστές και να ξεχνούν να αποσυνδεθούν, και οι οποίοι μπορεί να μην γνωρίζουν τι είναι τα cookies του προγράμματος περιήγησης ή πώς να τα διαγράψουν. Προσωπικά, μου αρέσουν τα μόνιμα logins για τους ιστότοπους που επισκέπτομαι τακτικά, αλλά ξέρω πώς να τα χειρίζομαι με ασφάλεια. Αν είστε βέβαιοι ότι οι χρήστες σας γνωρίζουν το ίδιο, μπορείτε να χρησιμοποιείτε μόνιμα logins με καθαρή συνείδηση. Αν όχι - λοιπόν, τότε μπορείτε να υιοθετήσετε τη φιλοσοφία ότι οι χρήστες που είναι απρόσεκτοι με τα διαπιστευτήρια σύνδεσής τους το έφεραν πάνω τους αν τους παραβιάσουν. Δεν είναι σαν να πηγαίνουμε στα σπίτια των χρηστών μας και να ξεριζώνουμε όλα αυτά τα Post-It σημειώματα με τους κωδικούς πρόσβασης που έχουν τοποθετήσει στην άκρη των οθονών τους. Φυσικά, ορισμένα συστήματα δεν έχουν την πολυτέλεια να χακάρουν οποιουσδήποτε λογαριασμούς- για τέτοια συστήματα, δεν υπάρχει κανένας τρόπος να δικαιολογήσετε την ύπαρξη μόνιμων συνδέσεων. Αν αποφασίσετε να εφαρμόσετε μόνιμα cookies σύνδεσης, να πώς θα το κάνετε:

1. Πρώτον, αφιερώστε λίγο χρόνο για να διαβάσετε το άρθρο Paragon Initiative's άρθρο σχετικά με το θέμα. Θα πρέπει να λάβετε ένα σωρό στοιχεία σωστά, και το άρθρο κάνει εξαιρετική δουλειά εξηγώντας το καθένα από αυτά.
2. Και για να επαναλάβω μία από τις πιο συνηθισμένες παγίδες, ΜΗΝ αποθηκεύετε το PERSISTENT LOGIN COOKIE (TOKEN) ΣΤΗ ΒΑΣΗ ΔΕΔΟΜΕΝΩΝ ΣΑΣ, ΜΟΝΟ ΕΝΑ HASH ΤΟΥ! Το login token είναι ισοδύναμο κωδικού πρόσβασης, οπότε αν ένας επιτιθέμενος έπαιρνε στα χέρια του τη βάση δεδομένων σας, θα μπορούσε να χρησιμοποιήσει τα tokens για να συνδεθεί σε οποιονδήποτε λογαριασμό, ακριβώς σαν να ήταν συνδυασμοί login-password καθαρού κειμένου. Επομένως, χρησιμοποιήστε κατακερματισμό (σύμφωνα με το https://security.stackexchange.com/a/63438/5002, ένας αδύναμος κατακερματισμός αρκεί για το σκοπό αυτό) όταν αποθηκεύετε μόνιμα διακριτικά σύνδεσης.

   ΜΕΡΟΣ ΙΙΙ: Χρήση μυστικών ερωτήσεων

   Μην εφαρμόζετε 'μυστικές ερωτήσεις'. Το χαρακτηριστικό 'μυστικές ερωτήσεις' είναι ένα αντι-πρότυπο ασφάλειας. Διαβάστε το έγγραφο από τον σύνδεσμο νούμερο 4 της λίστας MUST-READ. Μπορείτε να ρωτήσετε τη Σάρα Πέιλιν γι' αυτό, αφού ο λογαριασμός ηλεκτρονικού ταχυδρομείου της Yahoo! παραβιάστηκε κατά τη διάρκεια μιας προηγούμενης προεδρικής εκστρατείας επειδή η απάντηση στην ερώτηση ασφαλείας της ήταν... "Wasilla High School"! Ακόμη και με ερωτήσεις που καθορίζονται από τον χρήστη, είναι πολύ πιθανό οι περισσότεροι χρήστες να επιλέξουν ένα από τα δύο:

• Μια 'τυπική' μυστική ερώτηση, όπως το πατρικό όνομα της μητέρας ή το αγαπημένο κατοικίδιο ζώο.
• Ένα απλό κομμάτι ασήμαντης πληροφορίας που ο καθένας θα μπορούσε να πάρει από το blog του, το προφίλ του στο LinkedIn, ή κάτι παρόμοιο
• Οποιαδήποτε ερώτηση που είναι πιο εύκολο να απαντηθεί από το να μαντέψουν τον κωδικό πρόσβασής τους. Το οποίο, για κάθε αξιοπρεπή κωδικό πρόσβασης, είναι κάθε ερώτηση που μπορείτε να φανταστείτε Συμπερασματικά, οι ερωτήσεις ασφαλείας είναι εγγενώς ανασφαλείς σε όλες σχεδόν τις μορφές και παραλλαγές τους και δεν πρέπει να χρησιμοποιούνται σε ένα σύστημα ελέγχου ταυτότητας για κανέναν λόγο. Ο πραγματικός λόγος για τον οποίο οι ερωτήσεις ασφαλείας υπάρχουν ακόμη και στην άγρια φύση είναι ότι με βολικό τρόπο εξοικονομούν το κόστος μερικών κλήσεων υποστήριξης από χρήστες που δεν μπορούν να έχουν πρόσβαση στο email τους για να φτάσουν σε έναν κωδικό επανενεργοποίησης. Αυτό γίνεται εις βάρος της ασφάλειας και της φήμης της Sarah Palin's. Αξίζει τον κόπο; Μάλλον όχι.

  ΜΕΡΟΣ IV: Λειτουργικότητα ξεχασμένου κωδικού πρόσβασης

  Έχω ήδη αναφέρει γιατί δεν πρέπει ποτέ να χρησιμοποιείτε ερωτήσεις ασφαλείας για τη διαχείριση ξεχασμένων/χαμένων κωδικών πρόσβασης χρηστών- είναι επίσης αυτονόητο ότι δεν πρέπει ποτέ να στέλνετε στους χρήστες τους πραγματικούς κωδικούς πρόσβασης με e-mail. Υπάρχουν τουλάχιστον δύο ακόμη πολύ συνηθισμένες παγίδες που πρέπει να αποφύγετε σε αυτόν τον τομέα:

1. Μην επαναφέρετε έναν ξεχασμένο κωδικό πρόσβασης σε έναν αυτοπαραγόμενο ισχυρό κωδικό πρόσβασης - τέτοιοι κωδικοί πρόσβασης είναι γνωστό ότι είναι δύσκολο να τους θυμάται κανείς, πράγμα που σημαίνει ότι ο χρήστης πρέπει είτε να τον αλλάξει είτε να τον γράψει - ας πούμε, σε ένα φωτεινό κίτρινο Post-It στην άκρη της οθόνης του. Αντί να ορίσετε έναν νέο κωδικό πρόσβασης, αφήστε τους χρήστες να επιλέξουν αμέσως έναν νέο κωδικό πρόσβασης - κάτι που έτσι κι αλλιώς θέλουν να κάνουν. (Εξαίρεση σε αυτό θα μπορούσε να αποτελέσει η περίπτωση που οι χρήστες χρησιμοποιούν καθολικά έναν διαχειριστή κωδικών πρόσβασης για την αποθήκευση/διαχείριση κωδικών πρόσβασης που κανονικά θα ήταν αδύνατο να θυμηθούν χωρίς να τους γράψουν).
2. Κατακερματίζετε πάντα τον κωδικό/το κωδικό πρόσβασης που χάθηκε στη βάση δεδομένων. AGAIN, αυτός ο κωδικός είναι ένα άλλο παράδειγμα ισοδύναμου κωδικού πρόσβασης, οπότε ΠΡΕΠΕΙ να κατακερματιστεί σε περίπτωση που κάποιος εισβολέας πάρει στα χέρια του τη βάση δεδομένων σας. Όταν ζητείται ένας κωδικός χαμένου κωδικού πρόσβασης, στείλτε τον κωδικό απλού κειμένου στη διεύθυνση ηλεκτρονικού ταχυδρομείου του χρήστη, στη συνέχεια κατακερματισμός, αποθηκεύστε τον κατακερματισμό στη βάση δεδομένων σας -- και πετάξτε το πρωτότυπο. Ακριβώς όπως ένας κωδικός πρόσβασης ή ένα μόνιμο διακριτικό σύνδεσης. Μια τελευταία σημείωση: βεβαιωθείτε πάντα ότι η διεπαφή σας για την εισαγωγή του 'χαμένου κωδικού πρόσβασης' είναι τουλάχιστον εξίσου ασφαλής με την ίδια τη φόρμα σύνδεσης, αλλιώς ένας εισβολέας θα χρησιμοποιήσει απλώς αυτή για να αποκτήσει πρόσβαση. Το να βεβαιωθείτε ότι δημιουργείτε πολύ μεγάλους 'κωδικούς χαμένου κωδικού πρόσβασης' (για παράδειγμα, 16 αλφαριθμητικούς χαρακτήρες με ευαισθησία στην πεζότητα) είναι μια καλή αρχή, αλλά εξετάστε το ενδεχόμενο να προσθέσετε το ίδιο σύστημα περιορισμού που κάνετε για την ίδια τη φόρμα σύνδεσης.

   ΜΕΡΟΣ V: Έλεγχος της ισχύος του κωδικού πρόσβασης

   Αρχικά, θα'θελήσετε να διαβάσετε αυτό το μικρό άρθρο για έναν έλεγχο της πραγματικότητας: Οι 500 πιο συνηθισμένοι κωδικοί πρόσβασης Εντάξει, ίσως η λίστα να μην είναι'η κανονική λίστα με τους πιο συνηθισμένους κωδικούς πρόσβασης σε οποιοδήποτε σύστημα οπουδήποτε ποτέ, αλλά είναι'μια καλή ένδειξη για το πόσο κακώς επιλέγουν οι άνθρωποι τους κωδικούς πρόσβασης όταν δεν υπάρχει επιβαλλόμενη πολιτική. Επιπλέον, η λίστα φαίνεται τρομακτικά κοντά στο σπίτι σας όταν τη συγκρίνετε με τις δημόσια διαθέσιμες αναλύσεις των πρόσφατα κλεμμένων κωδικών πρόσβασης. Έτσι: Χωρίς ελάχιστες απαιτήσεις για την ισχύ του κωδικού πρόσβασης, το 2% των χρηστών χρησιμοποιεί έναν από τους 20 πιο συνηθισμένους κωδικούς πρόσβασης. Που σημαίνει: Αν ένας εισβολέας έχει μόλις 20 προσπάθειες, 1 στους 50 λογαριασμούς στον ιστότοπό σας θα είναι δυνατό να σπάσει. Για την ανατροπή αυτού του γεγονότος απαιτείται ο υπολογισμός της εντροπίας ενός κωδικού πρόσβασης και στη συνέχεια η εφαρμογή ενός κατωφλίου. Το Εθνικό Ινστιτούτο Προτύπων και Τεχνολογίας (NIST) Special Publication 800-63 έχει μια σειρά από πολύ καλές προτάσεις. Αυτό, όταν συνδυάζεται με ανάλυση λεξικού και διάταξης πληκτρολογίου (για παράδειγμα, το 'qwertyuiop' είναι κακός κωδικός πρόσβασης), μπορεί να απορρίψει το 99% όλων των κακώς επιλεγμένων κωδικών πρόσβασης σε επίπεδο 18 bit εντροπίας. Ο απλός υπολογισμός της ισχύος του κωδικού πρόσβασης και η επίδειξη ενός οπτικού μετρητή ισχύος στον χρήστη είναι καλή, αλλά ανεπαρκής. Αν δεν επιβληθεί, πολλοί χρήστες πιθανότατα θα το αγνοήσουν. Και για μια αναζωογονητική άποψη σχετικά με τη φιλικότητα προς τον χρήστη των κωδικών πρόσβασης υψηλής εντροπίας, συνιστάται ανεπιφύλακτα το Password Strength xkcd του Randall Munroe's. Χρησιμοποιήστε το Have I Been Pwned API του Troy Hunt's για να ελέγξετε τους κωδικούς πρόσβασης των χρηστών σε σχέση με τους κωδικούς πρόσβασης που έχουν παραβιαστεί σε δημόσιες παραβιάσεις δεδομένων.

   ΜΕΡΟΣ VI: Πολλά περισσότερα - ή: Αποτροπή προσπαθειών σύνδεσης με ταχείες πυρκαγιές

   Πρώτον, ρίξτε μια ματιά στους αριθμούς: Password Recovery Speeds - How long will your password stand up Αν δεν έχετε το χρόνο να κοιτάξετε τους πίνακες σε αυτόν τον σύνδεσμο, εδώ'είναι η λίστα τους:

3. Δεν χρειάζεται σχεδόν καθόλου χρόνο για να σπάσετε έναν αδύναμο κωδικό πρόσβασης, ακόμη και αν τον σπάτε με άβακα.
4. Χρειάζεται σχεδόν καθόλου χρόνο για να σπάσετε έναν αλφαριθμητικό κωδικό πρόσβασης 9 χαρακτήρων, αν είναι ανεπηρέαστος από την πεζότητα.
5. Δεν χρειάζεται σχεδόν κανένας χρόνος για να σπάσετε έναν περίπλοκο κωδικό πρόσβασης, με σύμβολα και γράμματα και αριθμούς, κεφαλαία και πεζά γράμματα, αν είναι μικρότερος από 8 χαρακτήρες (ένας επιτραπέζιος υπολογιστής μπορεί να ψάξει ολόκληρο το χώρο των πλήκτρων μέχρι 7 χαρακτήρες σε λίγες μέρες ή και ώρες)
6. Θα χρειαζόταν, ωστόσο, υπερβολικά πολύς χρόνος για να σπάσετε ακόμη και έναν κωδικό πρόσβασης 6 χαρακτήρων, αν περιορίζεστε σε μία προσπάθεια ανά δευτερόλεπτο! Τι μπορούμε να μάθουμε λοιπόν από αυτούς τους αριθμούς; Λοιπόν, πολλά, αλλά μπορούμε να επικεντρωθούμε στο πιο σημαντικό μέρος: το γεγονός ότι η αποτροπή μεγάλου αριθμού ταχέως διαδοχικών προσπαθειών σύνδεσης (δηλαδή η επίθεση brute force) δεν είναι πραγματικά τόσο δύσκολη. Αλλά η αποτροπή της σωστής δεν είναι τόσο εύκολη όσο φαίνεται. Σε γενικές γραμμές, έχετε τρεις επιλογές που είναι όλες αποτελεσματικές κατά των επιθέσεων brute-force (και των επιθέσεων λεξικού, αλλά εφόσον ήδη εφαρμόζετε μια πολιτική ισχυρών κωδικών πρόσβασης, δεν θα πρέπει να αποτελούν πρόβλημα):

• Παρουσιάστε ένα CAPTCHA μετά από N αποτυχημένες προσπάθειες (πολύ ενοχλητικό και συχνά αναποτελεσματικό -- αλλά επαναλαμβάνομαι εδώ)
• Κλείδωμα λογαριασμών και απαίτηση επαλήθευσης email μετά από N αποτυχημένες προσπάθειες (αυτό είναι μια επίθεση DoS που περιμένει να συμβεί)
• Και τέλος, login throttling: δηλαδή, ο καθορισμός μιας χρονικής καθυστέρησης μεταξύ των προσπαθειών μετά από N αποτυχημένες προσπάθειες (ναι, οι επιθέσεις DoS είναι ακόμα πιθανές, αλλά τουλάχιστον είναι πολύ λιγότερο πιθανές και πολύ πιο περίπλοκες να πραγματοποιηθούν). Καλύτερη πρακτική #1: Μια μικρή χρονική καθυστέρηση που αυξάνεται με τον αριθμό των αποτυχημένων προσπαθειών, όπως:
• 1 αποτυχημένη προσπάθεια = καμία καθυστέρηση
• 2 αποτυχημένες προσπάθειες = καθυστέρηση 2 δευτερολέπτων
• 3 αποτυχημένες προσπάθειες = καθυστέρηση 4 δευτερολέπτων
• 4 αποτυχημένες προσπάθειες = καθυστέρηση 8 δευτερολέπτων
• 5 αποτυχημένες προσπάθειες = καθυστέρηση 16 δευτερολέπτων
• κ.λπ. Η επίθεση DoS σε αυτό το σύστημα θα ήταν πολύ ανεφάρμοστη, καθώς ο χρόνος κλειδώματος που προκύπτει είναι ελαφρώς μεγαλύτερος από το άθροισμα των προηγούμενων χρόνων κλειδώματος. Για να διευκρινιστεί: Η καθυστέρηση δεν είναι καθυστέρηση πριν από την επιστροφή της απάντησης στο πρόγραμμα περιήγησης. Είναι περισσότερο σαν ένα χρονικό όριο ή μια περίοδος αναμονής κατά την οποία οι προσπάθειες σύνδεσης σε έναν συγκεκριμένο λογαριασμό ή από μια συγκεκριμένη διεύθυνση IP δεν θα γίνονται αποδεκτές ή δεν θα αξιολογούνται καθόλου. Δηλαδή, τα σωστά διαπιστευτήρια δεν θα επιστρέψουν σε επιτυχή σύνδεση και τα λανθασμένα διαπιστευτήρια δεν θα προκαλέσουν αύξηση της καθυστέρησης. Καλύτερη πρακτική #2: Μια χρονική καθυστέρηση μεσαίου μήκους που τίθεται σε ισχύ μετά από N αποτυχημένες προσπάθειες, όπως:
• 1-4 αποτυχημένες προσπάθειες = καμία καθυστέρηση
• 5 αποτυχημένες προσπάθειες = 15-30 λεπτά καθυστέρηση Η επίθεση DoS σε αυτό το σύστημα θα ήταν αρκετά ανέφικτη, αλλά σίγουρα εφικτή. Επίσης, ίσως είναι σημαντικό να σημειωθεί ότι μια τόσο μεγάλη καθυστέρηση μπορεί να είναι πολύ ενοχλητική για έναν νόμιμο χρήστη. Οι ξεχασιάρηδες χρήστες θα σας αντιπαθήσουν. Καλύτερη πρακτική #3: Συνδυάζοντας τις δύο προσεγγίσεις - είτε μια σταθερή, σύντομη χρονική καθυστέρηση που τίθεται σε ισχύ μετά από N αποτυχημένες προσπάθειες, όπως:
• 1-4 αποτυχημένες προσπάθειες = καμία καθυστέρηση
• 5+ αποτυχημένες προσπάθειες = καθυστέρηση 20 δευτερολέπτων Ή, μια αυξανόμενη καθυστέρηση με σταθερό άνω όριο, όπως:
• 5 δευτερόλεπτα καθυστέρηση
• 2 αποτυχημένες προσπάθειες = 15 δευτερόλεπτα καθυστέρηση
• 3+ αποτυχημένες προσπάθειες = 45 δευτερόλεπτα καθυστέρηση Αυτό το τελικό σχήμα προέρχεται από τις προτάσεις βέλτιστων πρακτικών του OWASP (σύνδεσμος 1 από τη λίστα MUST-READ) και θα πρέπει να θεωρείται βέλτιστη πρακτική, ακόμη και αν είναι ομολογουμένως περιοριστικό.

  ως κανόνας, ωστόσο, θα έλεγα: όσο πιο αυστηρή είναι η πολιτική κωδικών πρόσβασης, τόσο λιγότερο πρέπει να ενοχλείτε τους χρήστες με καθυστερήσεις. Εάν απαιτείτε ισχυρούς (αλφαριθμητικά με ευαισθησία στην πεζότητα + απαιτούμενοι αριθμοί και σύμβολα) κωδικούς πρόσβασης 9+ χαρακτήρων, θα μπορούσατε να δώσετε στους χρήστες 2-4 προσπάθειες κωδικού πρόσβασης χωρίς καθυστέρηση πριν ενεργοποιήσετε το throttling. Η επίθεση DoS σε αυτό το τελικό σύστημα στραγγαλισμού σύνδεσης θα ήταν πολύ ανέφικτη. Και ως τελική πινελιά, επιτρέπετε πάντα τη διέλευση μόνιμων (cookie) συνδέσεων (ή/και μιας μορφής σύνδεσης με CAPTCHA), ώστε οι νόμιμοι χρήστες να μην καθυστερούν καν ενώ η επίθεση βρίσκεται σε εξέλιξη. Με αυτόν τον τρόπο, η πολύ ανέφικτη επίθεση DoS γίνεται μια εξαιρετικά ανέφικτη επίθεση. Επιπλέον, είναι λογικό να κάνουμε πιο επιθετικό throttling στους λογαριασμούς διαχειριστών, αφού αυτοί είναι τα πιο ελκυστικά σημεία εισόδου.

  ΜΕΡΟΣ VII: Κατανεμημένες επιθέσεις ωμής βίας

  Παρεμπιπτόντως, οι πιο προχωρημένοι επιτιθέμενοι θα προσπαθήσουν να παρακάμψουν τον περιορισμό σύνδεσης με 'την εξάπλωση των δραστηριοτήτων τους':

• Διανέμοντας τις απόπειρες σε ένα botnet για να αποτρέψουν τη σήμανση των διευθύνσεων IP
• Αντί να διαλέξουν έναν χρήστη και να δοκιμάσουν τους 50.000 πιο κοινούς κωδικούς πρόσβασης (κάτι που δεν μπορούν να κάνουν, εξαιτίας του throttling μας), θα διαλέξουν ΤΟΝ πιο κοινό κωδικό πρόσβασης και θα τον δοκιμάσουν εναντίον 50.000 χρηστών. Με αυτόν τον τρόπο, όχι μόνο παρακάμπτουν τα μέτρα μέγιστων προσπαθειών, όπως τα CAPTCHAs και ο περιορισμός σύνδεσης, αλλά αυξάνεται και η πιθανότητα επιτυχίας τους, αφού ο νούμερο 1 πιο κοινός κωδικός πρόσβασης είναι πολύ πιο πιθανός από τον νούμερο 49.995.
• Διαστήματα μεταξύ των αιτήσεων σύνδεσης για κάθε λογαριασμό χρήστη, π.χ. 30 δευτερόλεπτα μεταξύ τους, για να ξεγλιστρήσετε κάτω από το ραντάρ. Εδώ, η καλύτερη πρακτική θα ήταν να καταγράφετε τον αριθμό των αποτυχημένων συνδέσεων, σε όλο το σύστημα, και να χρησιμοποιείτε έναν τρέχοντα μέσο όρο της συχνότητας των κακών συνδέσεων στον ιστότοπό σας ως βάση για ένα ανώτατο όριο που θα επιβάλλετε σε όλους τους χρήστες. Πολύ αφηρημένο; Επιτρέψτε μου να επαναδιατυπώσω: Ας πούμε ότι ο ιστότοπός σας είχε κατά μέσο όρο 120 κακές συνδέσεις ανά ημέρα τους τελευταίους 3 μήνες. Χρησιμοποιώντας αυτόν τον (τρέχοντα μέσο όρο), το σύστημά σας θα μπορούσε να θέσει το συνολικό όριο στο τριπλάσιο - δηλαδή 360 αποτυχημένες προσπάθειες σε μια περίοδο 24 ωρών. Στη συνέχεια, εάν ο συνολικός αριθμός των αποτυχημένων προσπαθειών σε όλους τους λογαριασμούς υπερβεί αυτόν τον αριθμό μέσα σε μία ημέρα (ή ακόμα καλύτερα, παρακολουθείτε τον ρυθμό επιτάχυνσης και ενεργοποιείτε ένα υπολογισμένο όριο), ενεργοποιεί τον περιορισμό σύνδεσης σε όλο το σύστημα - δηλαδή μικρές καθυστερήσεις για ΟΛΟΥΣ τους χρήστες (ακόμα, με εξαίρεση τις συνδέσεις cookie ή/και τις εφεδρικές συνδέσεις CAPTCHA). Έχω επίσης δημοσιεύσει μια ερώτηση με περισσότερες λεπτομέρειες και μια πραγματικά καλή συζήτηση για το πώς να αποφύγετε τις δύσκολες παγίδες στην απόκρουση κατανεμημένων επιθέσεων ωμής βίας

  ΜΕΡΟΣ VIII: Αυθεντικοποίηση δύο παραγόντων και πάροχοι αυθεντικοποίησης

  Τα διαπιστευτήρια μπορούν να παραβιαστούν, είτε από exploits, είτε από κωδικούς πρόσβασης που έχουν καταγραφεί και χαθεί, είτε από φορητούς υπολογιστές με κλειδιά που έχουν κλαπεί, είτε από χρήστες που εισάγουν συνδέσεις σε ιστότοπους phishing. Οι συνδέσεις μπορούν να προστατευθούν περαιτέρω με τον έλεγχο ταυτότητας δύο παραγόντων, ο οποίος χρησιμοποιεί παράγοντες εκτός ζώνης, όπως κωδικούς μίας χρήσης που λαμβάνονται από μια τηλεφωνική κλήση, ένα μήνυμα SMS, μια εφαρμογή ή ένα dongle. Αρκετοί πάροχοι προσφέρουν υπηρεσίες ελέγχου ταυτότητας δύο παραγόντων. Ο έλεγχος ταυτότητας μπορεί να ανατεθεί πλήρως σε μια υπηρεσία ενιαίας σύνδεσης, όπου ένας άλλος πάροχος χειρίζεται τη συλλογή διαπιστευτηρίων. Αυτό μεταθέτει το πρόβλημα σε ένα αξιόπιστο τρίτο μέρος. Τόσο η Google όσο και το Twitter παρέχουν υπηρεσίες SSO βασισμένες σε πρότυπα, ενώ το Facebook παρέχει μια παρόμοια ιδιόκτητη λύση.

  ΑΠΑΡΑΙΤΗΤΟΙ ΣΥΝΔΕΣΜΟΙ σχετικά με τον έλεγχο ταυτότητας στον ιστό

1. OWASP Guide To Authentication / OWASP Authentication Cheat Sheet
2. Dos and Don'ts of Client Authentication on the Web (πολύ ευανάγνωστη ερευνητική εργασία του MIT)
3. Wikipedia: HTTP cookie
4. Ερωτήσεις προσωπικής γνώσης για εφεδρικό έλεγχο ταυτότητας: (πολύ ευανάγνωστη ερευνητική εργασία του Berkeley).

Οριστικό άρθρο

Αποστολή διαπιστευτηρίων

Ο μόνος πρακτικός τρόπος για την 100% ασφαλή αποστολή διαπιστευτηρίων είναι η χρήση [SSL][1]. Η χρήση JavaScript για την κατακερματισμό του κωδικού πρόσβασης δεν είναι ασφαλής. Συνήθεις παγίδες για τον κατακερματισμό κωδικού πρόσβασης από την πλευρά του πελάτη:

• Εάν η σύνδεση μεταξύ του πελάτη και του διακομιστή δεν είναι κρυπτογραφημένη, ό,τι κάνετε είναι [ευάλωτο σε επιθέσεις man-in-the-middle][2]. Ένας επιτιθέμενος θα μπορούσε να αντικαταστήσει το εισερχόμενο javascript για να σπάσει τον κατακερματισμό ή να στείλει όλα τα διαπιστευτήρια στον διακομιστή του, θα μπορούσε να ακούσει τις απαντήσεις του πελάτη και να υποδυθεί τέλεια τους χρήστες, κ.λπ. κ.λπ. Το SSL με αξιόπιστες Αρχές Πιστοποιητικών έχει σχεδιαστεί για να αποτρέπει τις επιθέσεις MitM.
• Ο κατακερματισμένος κωδικός πρόσβασης που λαμβάνει ο διακομιστής είναι [λιγότερο ασφαλής][3] αν δεν κάνετε πρόσθετη, περιττή εργασία στον διακομιστή. Υπάρχει μια άλλη ασφαλής μέθοδος που ονομάζεται SRP, αλλά είναι κατοχυρωμένη με δίπλωμα ευρεσιτεχνίας (αν και έχει [ελεύθερη άδεια χρήσης][4]) και υπάρχουν λίγες καλές διαθέσιμες υλοποιήσεις.

  Αποθήκευση κωδικών πρόσβασης

  Μην αποθηκεύετε ποτέ τους κωδικούς πρόσβασης ως απλό κείμενο στη βάση δεδομένων. Ούτε καν αν δεν σας ενδιαφέρει η ασφάλεια του δικού σας ιστότοπου. Υποθέστε ότι κάποιοι από τους χρήστες σας θα επαναχρησιμοποιήσουν τον κωδικό πρόσβασης του online τραπεζικού τους λογαριασμού. Έτσι, αποθηκεύστε τον κατακερματισμένο κωδικό πρόσβασης και πετάξτε τον αρχικό. Και βεβαιωθείτε ότι ο κωδικός πρόσβασης δεν εμφανίζεται στα αρχεία καταγραφής πρόσβασης ή στα αρχεία καταγραφής εφαρμογών. Το OWASP συνιστά τη χρήση του Argon2 ως πρώτη επιλογή για νέες εφαρμογές. Εάν αυτό δεν είναι διαθέσιμο, θα πρέπει να χρησιμοποιείται αντ' αυτού το PBKDF2 ή το scrypt. Και τέλος, αν κανένα από τα παραπάνω δεν είναι διαθέσιμο, χρησιμοποιήστε το bcrypt. Οι κατακερματισμοί από μόνοι τους είναι επίσης ανασφαλείς. Για παράδειγμα, πανομοιότυποι κωδικοί πρόσβασης σημαίνουν πανομοιότυπους κατακερματισμούς - αυτό καθιστά τους πίνακες αναζήτησης κατακερματισμών έναν αποτελεσματικό τρόπο για την ταυτόχρονη παραβίαση πολλών κωδικών πρόσβασης. Αντ' αυτού, αποθηκεύστε τον αλατισμένο κατακερματισμό. Το salt είναι μια συμβολοσειρά που προστίθεται στον κωδικό πρόσβασης πριν από τον κατακερματισμό - χρησιμοποιήστε διαφορετικό (τυχαίο) salt ανά χρήστη. Το salt είναι μια δημόσια τιμή, οπότε μπορείτε να το αποθηκεύσετε μαζί με το hash στη βάση δεδομένων. Δείτε εδώ για περισσότερες πληροφορίες σχετικά με αυτό. Αυτό σημαίνει ότι δεν μπορείτε'να στείλετε στους χρήστες τους ξεχασμένους κωδικούς τους (επειδή έχετε μόνο το hash). Μην επαναφέρετε τον κωδικό πρόσβασης του χρήστη'αν δεν έχετε πιστοποιήσει τον χρήστη (οι χρήστες πρέπει να αποδείξουν ότι είναι σε θέση να διαβάζουν τα μηνύματα ηλεκτρονικού ταχυδρομείου που αποστέλλονται στην αποθηκευμένη (και επικυρωμένη) διεύθυνση ηλεκτρονικού ταχυδρομείου).

  Ερωτήσεις ασφαλείας

  Οι ερωτήσεις ασφαλείας είναι ανασφαλείς - αποφύγετε τη χρήση τους. Γιατί; Οτιδήποτε κάνει μια ερώτηση ασφαλείας, το κάνει καλύτερα ένας κωδικός πρόσβασης. Διαβάστε το PART III: Χρήση μυστικών ερωτήσεων στην [απάντηση του @Jens Roland][6] εδώ σε αυτό το wiki.

  Cookies συνόδου

  Αφού συνδεθεί ο χρήστης, ο διακομιστής στέλνει στο χρήστη ένα cookie συνεδρίας. Ο διακομιστής μπορεί να ανακτήσει το όνομα χρήστη ή το id από το cookie, αλλά κανείς άλλος δεν μπορεί να δημιουργήσει ένα τέτοιο cookie (TODO εξήγηση μηχανισμών). [Τα cookies μπορούν να υποκλαπούν][7]: είναι τόσο ασφαλή όσο το υπόλοιπο μηχάνημα του πελάτη και οι άλλες επικοινωνίες. Μπορούν να διαβαστούν από το δίσκο, να ανιχνευθούν στην κυκλοφορία του δικτύου, να αφαιρεθούν από μια επίθεση cross-site scripting, να διαρρηχθούν από ένα δηλητηριασμένο DNS, ώστε ο πελάτης να στέλνει τα cookies του σε λάθος διακομιστές. Μην στέλνετε μόνιμα cookies. Τα cookies θα πρέπει να λήγουν στο τέλος της συνεδρίας του πελάτη (κλείσιμο του προγράμματος περιήγησης ή αποχώρηση από τον τομέα σας). Εάν θέλετε να κάνετε autologin στους χρήστες σας, μπορείτε να ορίσετε ένα μόνιμο cookie, αλλά θα πρέπει να διαφέρει από ένα cookie πλήρους συνεδρίας. Μπορείτε να ορίσετε μια πρόσθετη σημαία ότι ο χρήστης έχει συνδεθεί αυτόματα και ότι πρέπει να συνδεθεί πραγματικά για ευαίσθητες λειτουργίες. Αυτό είναι δημοφιλές στους ιστότοπους αγορών που θέλουν να σας παρέχουν μια απρόσκοπτη, εξατομικευμένη εμπειρία αγορών, αλλά εξακολουθούν να προστατεύουν τα οικονομικά σας στοιχεία. Για παράδειγμα, όταν επιστρέφετε για να επισκεφθείτε το Amazon, σας εμφανίζει μια σελίδα που μοιάζει σαν να έχετε συνδεθεί, αλλά όταν πηγαίνετε να κάνετε μια παραγγελία (ή να αλλάξετε τη διεύθυνση αποστολής, την πιστωτική σας κάρτα κ.λπ.), σας ζητούν να επιβεβαιώσετε τον κωδικό πρόσβασής σας. Από την άλλη πλευρά, οι οικονομικοί ιστότοποι, όπως οι τράπεζες και οι πιστωτικές κάρτες, έχουν μόνο ευαίσθητα δεδομένα και δεν θα πρέπει να επιτρέπουν την αυτόματη είσοδο ή μια λειτουργία χαμηλής ασφάλειας.

  Κατάλογος εξωτερικών πόρων

• Dos and Don'ts of Client Authentication on the Web (PDF) Ακαδημαϊκό άρθρο 21 σελίδων με πολλές εξαιρετικές συμβουλές.
• Ask YC: Best Practices for User Authentication Συζήτηση στο φόρουμ για το θέμα
• You're Probably Storing Passwords Incorrectly Εισαγωγικό άρθρο σχετικά με την αποθήκευση κωδικών πρόσβασης
• Συζήτηση: Coding Horror: Συζήτηση στο φόρουμ σχετικά με ένα άρθρο του Coding Horror.
• [Ποτέ μην αποθηκεύετε κωδικούς πρόσβασης σε βάση δεδομένων!](

Πρώτον, μια ισχυρή προειδοποίηση ότι αυτή η απάντηση δεν είναι η καλύτερη δυνατή για αυτή ακριβώς την ερώτηση. Σίγουρα δεν πρέπει να είναι η κορυφαία απάντηση!

Θα προχωρήσω και θα αναφέρω το προτεινόμενο BrowserID της Mozilla (ή ίσως ακριβέστερα, το Verified Email Protocol) στο πνεύμα της εύρεσης ενός μονοπατιού αναβάθμισης προς καλύτερες προσεγγίσεις για τον έλεγχο ταυτότητας στο μέλλον.

Θα το συνοψίσω ως εξής:

1. Η Mozilla είναι ένας μη κερδοσκοπικός οργανισμός με αξίες που ευθυγραμμίζονται καλά με την εξεύρεση καλών λύσεων σε αυτό το πρόβλημα.
2. Η πραγματικότητα σήμερα είναι ότι οι περισσότεροι ιστότοποι χρησιμοποιούν έλεγχο ταυτότητας βάσει φόρμας
3. Ο έλεγχος ταυτότητας βάσει φόρμας έχει ένα μεγάλο μειονέκτημα, το οποίο είναι ο αυξημένος κίνδυνος phishing. Οι χρήστες καλούνται να εισάγουν ευαίσθητες πληροφορίες σε μια περιοχή που ελέγχεται από μια απομακρυσμένη οντότητα και όχι σε μια περιοχή που ελέγχεται από τον πράκτορα χρήστη (πρόγραμμα περιήγησης).
4. Δεδομένου ότι τα προγράμματα περιήγησης είναι έμμεσα αξιόπιστα (η όλη ιδέα ενός πράκτορα χρήστη είναι να ενεργεί εκ μέρους του χρήστη), μπορούν να συμβάλουν στη βελτίωση αυτής της κατάστασης.
5. Η πρωταρχική δύναμη που εμποδίζει την πρόοδο εδώ είναι το αδιέξοδο ανάπτυξης. Οι λύσεις πρέπει να αποσυντίθενται σε βήματα που παρέχουν από μόνα τους κάποιο σταδιακό όφελος.
6. Η απλούστερη αποκεντρωμένη μέθοδος έκφρασης μιας ταυτότητας που είναι ενσωματωμένη στην υποδομή του διαδικτύου είναι το όνομα τομέα.
7. Ως δεύτερο επίπεδο έκφρασης ταυτότητας, κάθε τομέας διαχειρίζεται το δικό του σύνολο λογαριασμών.
8. Η μορφή "account@domain" είναι συνοπτική και υποστηρίζεται από ένα ευρύ φάσμα πρωτοκόλλων και σχημάτων URI. Ένα τέτοιο αναγνωριστικό είναι, βέβαια, το πιο παγκοσμίως αναγνωρισμένο ως διεύθυνση ηλεκτρονικού ταχυδρομείου.
9. Οι πάροχοι ηλεκτρονικού ταχυδρομείου είναι ήδη οι de facto πρωταρχικοί πάροχοι ταυτότητας στο διαδίκτυο. Οι τρέχουσες ροές επαναφοράς κωδικού πρόσβασης συνήθως σας επιτρέπουν να αναλάβετε τον έλεγχο ενός λογαριασμού εάν μπορείτε να αποδείξετε ότι ελέγχετε τη σχετική διεύθυνση ηλεκτρονικού ταχυδρομείου του λογαριασμού αυτού.
10. Το πρωτόκολλο Verified Email Protocol προτάθηκε για να παρέχει μια ασφαλή μέθοδο, βασισμένη στην κρυπτογραφία δημόσιου κλειδιού, για τον εξορθολογισμό της διαδικασίας απόδειξης στον τομέα B ότι έχετε λογαριασμό στον τομέα A.
11. Για τα προγράμματα περιήγησης που δεν υποστηρίζουν το Πρωτόκολλο Επαληθευμένου Ηλεκτρονικού Ταχυδρομείου (επί του παρόντος όλα), η Mozilla παρέχει ένα shim που υλοποιεί το πρωτόκολλο σε κώδικα JavaScript από την πλευρά του πελάτη.
12. Για τις υπηρεσίες ηλεκτρονικού ταχυδρομείου που δεν υποστηρίζουν το Πρωτόκολλο Επαληθευμένου Ηλεκτρονικού Ταχυδρομείου, το πρωτόκολλο επιτρέπει σε τρίτους να ενεργούν ως έμπιστοι μεσάζοντες, βεβαιώνοντας ότι έχουν επαληθεύσει την κυριότητα ενός λογαριασμού από έναν χρήστη. Δεν είναι επιθυμητό να υπάρχει μεγάλος αριθμός τέτοιων τρίτων μερών- αυτή η δυνατότητα προορίζεται μόνο για να επιτρέψει μια διαδρομή αναβάθμισης και είναι πολύ προτιμότερο οι υπηρεσίες ηλεκτρονικού ταχυδρομείου να παρέχουν οι ίδιες αυτές τις βεβαιώσεις.
13. Η Mozilla προσφέρει τη δική της υπηρεσία για να ενεργεί ως ένα τέτοιο αξιόπιστο τρίτο μέρος. Οι πάροχοι υπηρεσιών (δηλαδή, τα αξιόπιστα μέρη) που εφαρμόζουν το Πρωτόκολλο Επαληθευμένου Ηλεκτρονικού Ταχυδρομείου μπορούν να επιλέξουν να εμπιστεύονται ή όχι τους ισχυρισμούς της Mozilla. Η υπηρεσία της Mozilla επαληθεύει την κυριότητα του λογαριασμού των χρηστών χρησιμοποιώντας το συμβατικό μέσο της αποστολής ενός ηλεκτρονικού ταχυδρομείου με έναν σύνδεσμο επιβεβαίωσης.
14. Οι πάροχοι υπηρεσιών μπορούν, φυσικά, να προσφέρουν αυτό το πρωτόκολλο ως επιλογή επιπλέον οποιασδήποτε άλλης(-ων) μεθόδου(-ων) ελέγχου ταυτότητας που επιθυμούν να προσφέρουν.
15. Ένα μεγάλο όφελος της διεπαφής χρήστη που επιδιώκεται εδώ είναι ο "επιλογέας ταυτότητας". Όταν ένας χρήστης επισκέπτεται έναν ιστότοπο και επιλέγει να πιστοποιηθεί, το πρόγραμμα περιήγησής του του εμφανίζει μια επιλογή διευθύνσεων ηλεκτρονικού ταχυδρομείου ("προσωπικές", "εργασίας", "πολιτικού ακτιβισμού" κ.λπ.) που μπορεί να χρησιμοποιήσει για να ταυτοποιηθεί στον ιστότοπο.
16. Ένα άλλο μεγάλο πλεονέκτημα της διεπαφής χρήστη που επιδιώκεται στο πλαίσιο αυτής της προσπάθειας είναι να βοηθηθεί το πρόγραμμα περιήγησης να γνωρίζει περισσότερα για τη σύνοδο του χρήστη - ως ποιος έχει συνδεθεί επί του παρόντος, κατά κύριο λόγο - ώστε να μπορεί να το εμφανίζει αυτό στο χρώμιο του προγράμματος περιήγησης.
17. Λόγω της κατανεμημένης φύσης αυτού του συστήματος, αποφεύγεται ο εγκλωβισμός σε μεγάλους ιστότοπους όπως το Facebook, το Twitter, το Google κ.λπ. Κάθε άτομο μπορεί να κατέχει το δικό του τομέα και, ως εκ τούτου, να ενεργεί ως ο δικός του πάροχος ταυτότητας.

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