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

ψήφοι
4k

Φόρμα έλεγχο ταυτότητας που βασίζεται για ιστοσελίδες

Πιστεύουμε ότι η υπερχείλιση στοίβας δεν πρέπει μόνο να είναι ένας πόρος για πολύ συγκεκριμένα τεχνικά ζητήματα, αλλά και για τις γενικές κατευθυντήριες γραμμές για τον τρόπο επίλυσης παραλλαγές σε κοινά προβλήματα. «Μορφή βάση πιστοποίησης για ιστοσελίδες» θα πρέπει να είναι ένα καλό θέμα για ένα τέτοιο πείραμα.

Θα πρέπει να περιλαμβάνει θέματα όπως:

  • Πως να συνδεθείτε
  • Πώς να αποσυνδεθείτε
  • Πώς να παραμείνετε συνδεδεμένοι
  • Διαχείριση των cookies (συμπεριλαμβανομένων των προτεινόμενων ρυθμίσεων)
  • SSL / HTTPS κρυπτογράφησης
  • Πώς να αποθηκεύσετε τους κωδικούς πρόσβασης
  • Χρησιμοποιώντας μυστικές ερωτήσεις
  • Ξεχάσατε το όνομα χρήστη λειτουργικότητα / κωδικό
  • Χρήση nonces για την πρόληψη cross-site πλαστά αίτησης (CSRF)
  • OpenID
  • πλαίσιο ελέγχου «Να με θυμάσαι»
  • Browser αυτόματη συμπλήρωση των ονομάτων χρηστών και κωδικών πρόσβασης
  • Μυστική διευθύνσεις URL (δημόσια διεύθυνση URL που προστατεύονται από πέψη)
  • Έλεγχος ισχύος κωδικού πρόσβασης
  • επικύρωση E-mail
  • και πολύ περισσότερο για τον έλεγχο ταυτότητας που βασίζεται μορφή ...

Δεν θα πρέπει να περιλαμβάνουν τα πράγματα όπως:

  • Ρόλοι και άδεια
  • HTTP βασικό έλεγχο ταυτότητας

Παρακαλώ βοηθήστε μας:

  1. Γεγονός που υποδηλώνει υποκατηγορίες
  2. Υποβολή καλά άρθρα για αυτό το θέμα
  3. Επεξεργασία του επίσημη απάντηση
Δημοσιεύθηκε 02/08/2008 στις 20:51
πηγή χρήστη
Σε άλλες γλώσσες...                            


12 απαντήσεις

ψήφοι
3k

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

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

Για να HTTPS ή όχι HTTPS;

Εκτός αν η σύνδεση είναι ήδη ασφαλείς (δηλαδή, σήραγγα μέσω HTTPS χρησιμοποιώντας SSL / TLS), οι τιμές φόρμα σύνδεσης σας θα σταλεί σε απλό κείμενο, το οποίο επιτρέπει σε οποιονδήποτε υποκλοπές στη γραμμή μεταξύ του browser και web server θα είναι σε θέση να διαβάσει συνδέσεις καθώς περνούν διά μέσου. Αυτό το είδος των υποκλοπών γίνεται συνήθως από τις κυβερνήσεις, αλλά σε γενικές γραμμές δεν θα αντιμετωπίσει «ανήκουν» τα καλώδια εκτός από το να πω το εξής: Αν η προστασία κάτι σημαντικό, χρησιμοποιούν HTTPS.

Στην ουσία, ο μόνος πρακτικός τρόπος για την προστασία από υποκλοπές / πακέτων sniffing κατά τη διάρκεια σύνδεσής είναι με τη χρήση HTTPS ή άλλο σχήμα κρυπτογράφησης βάσει πιστοποιητικού (για παράδειγμα, TLS ) ή ένας αποδεδειγμένος & δοκιμάστηκαν σύστημα πρόκλησης-απόκρισης (για παράδειγμα, το Diffie-Hellman που βασίζονται σε SRP). Οποιαδήποτε άλλη μέθοδος μπορεί εύκολα να παρακαμφθεί από έναν εισβολέα υποκλοπές.

Φυσικά, αν είστε πρόθυμοι να πάρετε λίγο ανέφικτο, θα μπορούσε επίσης να χρησιμοποιήσει κάποια μορφή ελέγχου ταυτότητας δύο παραγόντων (π.χ. την εφαρμογή Επαληθευτής Google, μια φυσική «ψυχρό ύφος πολέμου» βιβλίου, ή ένα RSA κλειδί dongle γεννήτρια). Εάν εφαρμοστεί σωστά, αυτό θα μπορούσε να λειτουργήσει ακόμη και με ένα ακάλυπτο σύνδεση, αλλά είναι δύσκολο να φανταστεί κανείς ότι μια dev θα ήταν πρόθυμοι να εφαρμόσουν δύο παράγοντα ελέγχου ταυτότητας, αλλά όχι SSL.

(Μην) Roll-σας-δικά κρυπτογράφηση JavaScript / κατακερματισμού

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

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

Ενώ είναι αλήθεια ότι κατακερματισμού του κωδικού πρόσβασης μπορεί να είναι αποτελεσματική ενάντια σε αποκάλυψη κωδικό πρόσβασης , είναι ευάλωτα σε επανάληψη επιθέσεις, Man-in-the-middle επιθέσεις / πειρατείες (αν ένας εισβολέας μπορεί να εισφέρει μερικά bytes σε ακάλυπτο HTML σελίδα σας πριν φτάσει σας πρόγραμμα περιήγησης, μπορούν απλά να σχολιάσει το κατακερματισμού στην JavaScript), ή επιθέσεις ωμής βίας (από τη στιγμή που μοιράζουν τον εισβολέα και όνομα χρήστη, το αλάτι και το διαγραμμισμένο password).

Captchas κατά της ανθρωπότητας

CAPTCHAs έχουν ως στόχο να ματαιώσει μια συγκεκριμένη κατηγορία της επίθεσης: αυτόματο λεξικό / ωμής βίας δοκιμής και λάθους χωρίς τον χειριστή. Δεν υπάρχει καμία αμφιβολία ότι αυτό είναι μια πραγματική απειλή, ωστόσο υπάρχουν τρόποι αντιμετώπισής απρόσκοπτα ότι δεν απαιτούν CAPTCHA, ειδικά σχεδιαστεί σωστά συστήματα σύνδεσης στραγγαλισμού serverside - θα συζητήσουμε αυτά αργότερα.

Να ξέρετε ότι CAPTCHA εφαρμογές δεν δημιουργούνται εξίσου? συχνά δεν είναι ανθρώπινα-επιλύσιμο, οι περισσότεροι από αυτούς είναι στην πραγματικότητα αναποτελεσματικά εναντίον bots, όλα αυτά είναι αναποτελεσματικά κατά των φθηνών τρίτου κόσμου της εργασίας (σύμφωνα με το OWASP , το σημερινό ποσοστό κάτεργα είναι $ 12 ανά 500 εξετάσεις), και μερικές εφαρμογές μπορεί να είναι τεχνικά παράνομο σε ορισμένες χώρες (βλ OWASP ταυτότητας εξαπατήσει φύλλο ). Εάν πρέπει να χρησιμοποιήσετε ένα CAPTCHA, χρησιμοποιούν το Google για reCAPTCHA , δεδομένου ότι είναι OCR-δύσκολο εξ ορισμού (αφού χρησιμοποιεί ήδη OCR-ταξινομείται εσφαλμένα σαρώνει το βιβλίο) και προσπαθεί πολύ σκληρά για να είναι φιλικό προς το χρήστη.

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

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

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

Έτσι, αν δεν μπορείτε να αποθηκεύσετε τον κωδικό πρόσβασης, πώς να βεβαιωθείτε ότι ο συνδυασμός login + κωδικό δημοσιεύτηκε από την φόρμα σύνδεσης είναι σωστή; Η απάντηση είναι κατακερματισμού χρησιμοποιώντας ένα πλήκτρο λειτουργίας παραγωγή . Κάθε φορά που ένας νέος χρήστης έχει δημιουργηθεί ή κωδικός πρόσβασης αλλάζει, να πάρετε τον κωδικό πρόσβασης και να τρέξει μέσα από ένα KDF, όπως Argon2, bcrypt, scrypt ή PBKDF2, μετατρέποντας το απλό κείμενο κωδικό πρόσβασης ( «correcthorsebatterystaple») σε μια μακρά, τυχαία εμφάνιση εγχόρδων , το οποίο είναι πολύ πιο ασφαλές για την αποθήκευση στη βάση δεδομένων σας. Για να επαληθεύσετε μια σύνδεση, μπορείτε να εκτελέσετε την ίδια συνάρτηση κατακερματισμού στο μπήκε κωδικό πρόσβασης, αυτή τη φορά περνώντας στο αλάτι και συγκρίνετε το με αποτέλεσμα κορδόνι κατακερματισμού με την τιμή που είναι αποθηκευμένη στη βάση δεδομένων σας. Argon2, bcrypt και κατάστημα scrypt το αλάτι με το hash ήδη. Ελέγξτε έξω αυτό το άρθρο για sec.stackexchange για πιο λεπτομερείς πληροφορίες.

Ο λόγος που χρησιμοποιείται ένα άλας είναι επειδή κατακερματισμού από μόνη της δεν είναι αρκετή - θα θελήσετε να προσθέσετε μια λεγόμενη «αλάτι» για την προστασία του κατακερματισμού κατά τραπέζια ουράνιο τόξο . Ένα άλας αποτρέπει αποτελεσματικά δύο κωδικούς πρόσβασης που ταιριάζουν ακριβώς από το να αποθηκευτούν ως την ίδια τιμή κατακερματισμού, εμποδίζοντας το σύνολο της βάσης δεδομένων που σαρώνεται σε μια επιχείρηση, εάν ένας επιτιθέμενος εκτελεί έναν κωδικό πρόσβασης μαντέψουν επίθεση.

Ένα κρυπτογραφικό hash δεν πρέπει να χρησιμοποιείται για την αποθήκευση κωδικού πρόσβασης επειδή έχει επιλέξει ο χρήστης τους κωδικούς πρόσβασης δεν είναι αρκετά ισχυρή (δηλαδή συνήθως δεν περιέχουν αρκετή εντροπία) και έναν κωδικό πρόσβασης μαντέψουν επίθεση θα μπορούσε να ολοκληρωθεί σε ένα σχετικά σύντομο χρονικό διάστημα από έναν εισβολέα με την πρόσβαση στα hashes. Αυτός είναι ο λόγος που χρησιμοποιείται KDF - αυτά ουσιαστικά «τεντώσει το πλήκτρο» που σημαίνει ότι κάθε κωδικό μαντέψει κάποιος εισβολέας κάνει συνεπάγεται την επανάληψη του αλγορίθμου κατακερματισμού πολλές φορές, για παράδειγμα 10.000 φορές, καθιστώντας τον κωδικό πρόσβασης του εισβολέα μαντέψουν 10.000 φορές πιο αργά.

δεδομένων Συνεδρία - «Έχετε εισέλθει ως Spiderman69»

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

Εάν δεν είστε εξοικειωμένοι με τα δεδομένα συνόδου, εδώ είναι πώς αυτό λειτουργεί: Μια απλή τυχαία που δημιουργείται εγχόρδων αποθηκεύεται σε μια λήγει το cookie και χρησιμοποιείται για την αναφορά συλλογή των δεδομένων - τα δεδομένα περιόδου - που είναι αποθηκευμένα στο διακομιστή. Εάν χρησιμοποιείτε ένα πλαίσιο MVC, αυτό είναι αναμφίβολα ο χειρισμός ήδη.

Αν είναι δυνατόν, βεβαιωθείτε ότι το cookie συνεδρίας έχει τα ασφαλή και HTTP Μόνο σημαίες που όταν αποστέλλονται στο πρόγραμμα περιήγησης. Η σημαία HttpOnly παρέχει κάποια προστασία από το cookie που διαβάζονται από μια επίθεση XSS. Η ασφαλής σημαίας εξασφαλίζει ότι το cookie αποστέλλεται μόνο πίσω μέσω HTTPS, και ως εκ τούτου προστατεύει από τις επιθέσεις του δικτύου sniffing. Η τιμή του cookie δεν θα πρέπει να είναι προβλέψιμη. Όταν παρουσιάζεται ένα cookie που παραπέμπει σε ανύπαρκτη συνεδρίασης, η τιμή του θα πρέπει να αντικατασταθεί αμέσως να αποτρέψει τη σταθεροποίηση συνεδρία .

ΜΕΡΟΣ ΙΙ: Πώς να παραμείνετε συνδεδεμένοι - το περίφημο «Να με θυμάσαι» κουτάκι

Σταθερά Cookies Είσοδος ( «να με θυμάσαι» λειτουργία) είναι μια επικίνδυνη ζώνη? από τη μία πλευρά, είναι απολύτως εξίσου ασφαλή με τα συμβατικά στοιχεία σύνδεσης, όταν οι χρήστες να κατανοήσουν πώς να τα χειριστεί? και από την άλλη πλευρά, είναι ένα τεράστιο κίνδυνο για την ασφάλεια στα χέρια των απρόσεκτους χρήστες, οι οποίοι μπορούν να τα χρησιμοποιούν για δημόσιους υπολογιστές και να ξεχάσετε να αποσυνδεθείτε, και που δεν μπορεί να γνωρίζει ποια τα cookies του προγράμματος περιήγησης είναι ή πώς να τα διαγράψετε.

Προσωπικά, μου αρέσει επίμονες συνδέσεις για τις ιστοσελίδες που επισκέπτονται σε τακτική βάση, αλλά ξέρω πώς να τα χειριστεί με ασφάλεια. Εάν είστε θετικό το γεγονός ότι οι χρήστες σας γνωρίζουν το ίδιο, μπορείτε να χρησιμοποιήσετε επίμονες συνδέσεις με καθαρή συνείδηση. Αν όχι - και, στη συνέχεια, μπορείτε να εγγραφείτε στην φιλοσοφία που οι χρήστες που είναι απρόσεκτοι με τα διαπιστευτήρια σύνδεσής τους έφερε στον εαυτό τους εάν παίρνουν hacked. Δεν είναι όπως πάμε στα σπίτια των χρηστών μας και δάκρυ από όλους εκείνους facepalm που προκαλεί Post-It σημειώνει με τους κωδικούς πρόσβασης που έχουν παραταχθεί στην άκρη των οθονών τους, είτε.

Φυσικά, ορισμένα συστήματα δεν μπορούν να αντέξουν οικονομικά να έχει οποιεσδήποτε λογαριασμούς hacked? για τέτοια συστήματα, δεν υπάρχει κανένας τρόπος που μπορείτε να δικαιολογήσει έχουν ανθεκτικές συνδέσεις.

Αν αποφασίσετε να εφαρμόσουν μόνιμα cookies σύνδεσης, αυτό είναι το πώς μπορείτε να το κάνετε:

  1. Κατ 'αρχάς, να πάρει κάποιο χρόνο για να διαβάσετε το άρθρο Paragon Πρωτοβουλίας για το θέμα. Θα χρειαστεί να πάρετε μια δέσμη των στοιχείων σωστά, και το άρθρο κάνει σπουδαία δουλειά του εξηγώντας το καθένα.

  2. Και μόνο να επαναλάβω μία από τις πιο κοινές παγίδες, ΜΗΝ ΦΥΛΑΣΣΕΤΑΙ ΤΟ μόνιμο cookie ΕΙΣΟΔΟΣ (TOKEN) στη βάση δεδομένων σας, μόνο ένα τμήμα του IT! Η συμβολική σύνδεση είναι Κωδικού Ισοδύναμο, οπότε αν ένας εισβολέας πήρε τα χέρια τους στη βάση δεδομένων σας, θα μπορούσαν να χρησιμοποιήσουν τις μάρκες για να συνδεθείτε σε οποιοδήποτε λογαριασμό, ακριβώς σαν να ήταν απλό κείμενο συνδυασμούς login-password. Ως εκ τούτου, η χρήση κατακερματισμού (σύμφωνα με https://security.stackexchange.com/a/63438/5002 ένα αδύναμο κατακερματισμού θα κάνει μια χαρά για το σκοπό αυτό) κατά την αποθήκευση επίμονη μάρκες σύνδεσης.

ΜΕΡΟΣ III: Χρησιμοποιώντας Secret Ερωτήσεις

Μην εφαρμογή «μυστικές ερωτήσεις» . Χαρακτηριστικό των «μυστικές ερωτήσεις» είναι ένα αντι-πρότυπο ασφαλείας. Διαβάστε το χαρτί από τον αριθμό σύνδεσης 4 από τα MUST-ΔΙΑΒΑΣΤΕ λίστα. Μπορείτε να ζητήσετε Σάρα Πέιλιν για εκείνο το ένα, μετά το Yahoo! της λογαριασμό e-mail πήρε hacked κατά τη διάρκεια της προηγούμενης προεκλογικής εκστρατείας, διότι η απάντηση στην ερώτηση ασφαλείας της ήταν ... «Wasilla High School»!

Ακόμη και με ερωτήσεις που καθορίζεται από το χρήστη, είναι πολύ πιθανό ότι οι περισσότεροι χρήστες θα επιλέγουν είτε:

  • Ένα «πρότυπο» μυστική ερώτηση όπως πατρικό όνομα της μητέρας του ή το αγαπημένο κατοικίδιο ζώο

  • Ένα απλό κομμάτι του trivia που ο καθένας θα μπορούσε να σηκώσει από το blog τους, το προφίλ LinkedIn, ή παρόμοια

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

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

Η αλήθεια λόγος για τον οποίο υπάρχουν ακόμη ζητήματα ασφαλείας στην άγρια ​​φύση είναι ότι εύκολα να αποθηκεύσετε το κόστος των λίγων κλήσεις υποστήριξης από τους χρήστες οι οποίοι δεν μπορούν να έχουν πρόσβαση e-mail τους για να φτάσουμε σε ένα κωδικό ενεργοποίησης. Αυτό το εις βάρος της ασφάλειας και της φήμης Σάρα Πέιλιν. Αξίζει? Πιθανώς όχι.

ΜΕΡΟΣ IV: Ξεχάσατε τον κωδικό Λειτουργικότητα

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

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

  2. Hash πάντα το χαμένο κωδικό πρόσβασης κώδικα / token στη βάση δεδομένων. ΠΑΛΙ , αυτός ο κώδικας είναι ένα άλλο παράδειγμα ενός Ισοδύναμο κωδικό, γι 'αυτό πρέπει να κατακερματίζεται σε περίπτωση που ένας εισβολέας πήρε τα χέρια τους στη βάση δεδομένων σας. Όταν ζητείται ένα χαμένο κωδικό κωδικό πρόσβασης, στείλτε το απλό κείμενο κώδικα στη διεύθυνση ηλεκτρονικού ταχυδρομείου του χρήστη, τότε hash, εκτός από το χασίς στη βάση δεδομένων σας - και πετάξτε το πρωτότυπο . Ακριβώς όπως και έναν κωδικό πρόσβασης ή ένα επίμονο συμβολική σύνδεση.

Μια τελευταία σημείωση: βεβαιωθείτε περιβάλλον σας για την είσοδο στο «χαμένο κωδικό password» είναι τουλάχιστον τόσο ασφαλές όσο φόρμα σύνδεσης σας τον εαυτό, ή ένας εισβολέας θα χρησιμοποιήσει μόνο αυτό για να αποκτήσουν πρόσβαση αντ 'αυτού. Αφού βεβαιωθείτε ότι έχετε δημιουργήσει πολύ μεγάλο «χάσει τους κωδικούς κωδικό πρόσβασης (για παράδειγμα, 16 κεφαλαία γράμματα αλφαριθμητικών χαρακτήρων) είναι μια καλή αρχή, αλλά μπορείτε να προσθέσετε το ίδιο σύστημα επιτάχυνσης που κάνετε για την ίδια τη φόρμα σύνδεσης.

ΜΕΡΟΣ V: Έλεγχος Κωδικός Αντοχή

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

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

Έτσι: Χωρίς ελάχιστες απαιτήσεις αντοχής κωδικό, 2% των χρηστών χρησιμοποιούν ένα από τα κορυφαία 20 πιο συχνές κωδικούς πρόσβασης. Σημασία: εάν ένας επιτιθέμενος παίρνει μόνο 20 απόπειρες, 1 σε 50 λογαριασμούς στην ιστοσελίδα σας θα είναι crackable.

Ματαιώνει αυτό απαιτεί τον υπολογισμό της εντροπίας ενός κωδικού πρόσβασης και, στη συνέχεια, εφαρμόζοντας ένα όριο. Το Εθνικό Ινστιτούτο Προτύπων και Τεχνολογίας (NIST) Ειδική Έκδοση 800-63 έχει μια σειρά από πολύ καλές προτάσεις. Δηλαδή, όταν συνδυάζεται με ένα ανάλυσης λεξικό και πληκτρολόγιο διάταξης (για παράδειγμα, «qwertyuiop» είναι μια κακή κωδικό), μπορεί να απορρίψει το 99% του συνόλου των ανεπαρκώς επιλεγμένων κωδικών πρόσβασης σε επίπεδο 18 bits της εντροπίας. Απλά υπολογισμό αντοχής κωδικό πρόσβασης και δείχνει μια οπτική μετρητή δύναμη για ένα χρήστη είναι καλή, αλλά ανεπαρκής. Εκτός αν επιβάλλεται, πολλοί χρήστες είναι πολύ πιθανό να το αγνοήσει.

Και για ένα δροσιστικό αναλάβει χρηστικότητα του κωδικούς πρόσβασης υψηλής εντροπίας, Randall Munroe του κωδικού δύναμη xkcd συνιστάται ιδιαίτερα.

ΜΕΡΟΣ VI: Πολύ περισσότερο - Ή: Πρόληψη προσπάθειες Rapid-Fire Είσοδος

Κατ 'αρχάς, ρίξτε μια ματιά στους αριθμούς: Ταχύτητες ανάκτηση κωδικού πρόσβασης - Πόσο καιρό θα σταθεί κωδικό σας επάνω

Αν δεν έχετε το χρόνο να κοιτάξουμε μέσα από τους πίνακες του εν λόγω συνδέσμου, εδώ είναι ο κατάλογος των οποίων:

  1. Παίρνει σχεδόν καθόλου χρόνο για να σπάσουμε ένα αδύναμο κωδικό πρόσβασης, ακόμα και αν το σκάσιμο με άβακα

  2. Παίρνει σχεδόν καθόλου χρόνο για να σπάσουμε έναν αλφαριθμητικό κωδικό 9 χαρακτήρων, εάν είναι πεζά ή κεφαλαία

  3. Παίρνει σχεδόν καθόλου χρόνο για να σπάσουμε ένα περίπλοκο, σύμβολα-και-γράμματα-και-αριθμούς, πάνω-και-πεζά κωδικό πρόσβασης, αν είναι μακριά λιγότερο από 8 χαρακτήρες (ένα desktop PC μπορεί να αναζητήσει το σύνολο της keyspace έως 7 χαρακτήρες σε ένα θέμα ημερών ή ακόμα και ώρες)

  4. Θα ήταν, ωστόσο, να λάβει ένα υπερβολικά μεγάλο χρονικό διάστημα για να σπάσει ακόμη και έναν κωδικό πρόσβασης 6 χαρακτήρων, αν περιορίζονταν σε μια προσπάθεια ανά δευτερόλεπτο!

Τι μπορούμε λοιπόν να μάθουμε από αυτούς τους αριθμούς; Λοιπόν, πολλά, αλλά μπορούμε να εστιάσουμε στο πιο σημαντικό κομμάτι: το γεγονός ότι η πρόληψη μεγάλων αριθμών ταχείας φωτιά προσπάθειες διαδοχικών σύνδεσης (δηλαδή το. Brute force επίθεση) δεν είναι και τόσο δύσκολο. Αλλά αποτρέποντας σωστά δεν είναι τόσο εύκολο όσο φαίνεται.

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

  • Παρουσιάστε ένα CAPTCHA μετά Ν αποτυχημένες προσπάθειες (ενοχλητικό ως κόλαση και συχνά αναποτελεσματικές - αλλά είμαι επαναλαμβάνομαι εδώ)

  • Το κλείδωμα των λογαριασμών και απαιτούν επαλήθευση ηλεκτρονικού ταχυδρομείου μετά Ν αποτυχημένες προσπάθειες (αυτό είναι μια DoS επίθεση που περιμένουν να συμβεί)

  • Και, τέλος, την είσοδο επιτάχυνσης : που είναι, θέτοντας ένα χρονικό διάστημα μεταξύ των προσπαθειών μετά από Ν αποτυχημένες προσπάθειες (ναι, DoS επιθέσεις είναι ακόμα εφικτή, αλλά τουλάχιστον θα είναι πολύ λιγότερο πιθανό και πολύ πιο περίπλοκη για να τραβήξει μακριά).

Βέλτιστη πρακτική # 1: Μια μικρή χρονική καθυστέρηση που αυξάνει με τον αριθμό των αποτυχημένων προσπαθειών, όπως:

  • 1 αποτυχημένη απόπειρα = καμία καθυστέρηση
  • 2 αποτυχημένες προσπάθειες = καθυστέρηση 2 sec
  • 3 αποτυχημένες προσπάθειες = καθυστέρηση 4 sec
  • 4 αποτυχημένες προσπάθειες = καθυστέρηση 8 sec
  • 5 αποτυχημένες προσπάθειες = καθυστέρηση 16 δευτ
  • και τα λοιπα.

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

Για να διευκρινίσει: Η καθυστέρηση είναι όχι μια καθυστέρηση πριν επιστρέψει την απάντηση στο πρόγραμμα περιήγησης. Είναι περισσότερο σαν ένα συγκεκριμένο χρονικό διάστημα ή ανερέθιστη περίοδος κατά την οποία προσπαθειών σύνδεσης σε ένα συγκεκριμένο λογαριασμό ή από μια συγκεκριμένη διεύθυνση IP δεν θα γίνει δεκτή ή αξιολογούνται καθόλου. Δηλαδή, σωστά διαπιστευτήρια δεν θα επιστρέψει σε μια επιτυχημένη σύνδεση και εσφαλμένες πιστοποιήσεις δεν θα προκαλέσει μια αύξηση καθυστέρηση.

Βέλτιστη πρακτική # 2: Μια μεσαίου μήκους χρονική καθυστέρηση που πηγαίνει σε ισχύ μετά Ν αποτυχημένες προσπάθειες, όπως:

  • 1-4 αποτυχημένες προσπάθειες = καμία καθυστέρηση
  • 5 αποτυχημένες προσπάθειες = 15-30 min καθυστέρηση

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

Βέλτιστη πρακτική # 3: Ο συνδυασμός των δύο προσεγγίσεων - είτε ένα σταθερό, μικρή χρονική καθυστέρηση που θα τεθεί σε ισχύ μετά το Ν αποτυχημένες προσπάθειες, όπως:

  • 1-4 αποτυχημένες προσπάθειες = καμία καθυστέρηση
  • 5+ αποτυχημένες προσπάθειες = καθυστέρηση 20 sec

Ή, ένας αυξανόμενος καθυστέρηση με σταθερό άνω όριο, όπως:

  • 1 αποτυχημένη προσπάθεια καθυστέρηση = 5 sec
  • 2 αποτυχημένες προσπάθειες = καθυστέρηση 15 sec
  • 3+ αποτυχημένες προσπάθειες = καθυστέρηση 45 sec

Αυτό το τελικό σχέδιο έγινε από τις OWASP βέλτιστες πρακτικές προτάσεις (link 1 από το must-ΔΙΑΒΑΣΤΕ λίστα), και θα πρέπει να θεωρείται βέλτιστη πρακτική, ακόμη και αν είναι ομολογουμένως από την περιοριστική πλευρά.

Ως γενικός κανόνας, ωστόσο, θα ήθελα να πω: η ισχυρότερη πολιτική κωδικό πρόσβασής σας είναι, το λιγότερο που πρέπει να χρηστών bug με τις καθυστερήσεις. Αν χρειάζεστε ισχυρή (case-sensitive αλφαριθμητικά + απαιτείται αριθμούς και σύμβολα) 9+ κωδικούς πρόσβασης χαρακτήρα, θα μπορούσε να δώσει στους χρήστες 2-4 μη καθυστερήσει τις προσπάθειες κωδικό πριν από την ενεργοποίηση της επιτάχυνσης.

DoS επίθεση αυτή τελικό καθεστώς σύνδεσης επιτάχυνσης θα ήταν πολύ πρακτικό. Και ως τελευταία πινελιά, επιτρέπουν πάντα επίμονη (μπισκότο) συνδέσεις (και / ή ένα CAPTCHA-επαληθεύεται φόρμα σύνδεσης) για να περάσει, έτσι ώστε οι νόμιμοι χρήστες δεν θα ακόμη και να καθυστερήσει , ενώ η επίθεση είναι σε εξέλιξη . Με αυτόν τον τρόπο, το πολύ πρακτικό επίθεση DoS γίνεται ένα εξαιρετικά πρακτικό επίθεση.

Επιπλέον, είναι λογικό να κάνει πιο επιθετική επιτάχυνσης σε λογαριασμούς διαχειριστή, δεδομένου ότι αυτά είναι τα πιο ελκυστικά σημεία εισόδου

ΜΕΡΟΣ VII: Κατανεμημένα επιθέσεις Brute Force

Ακριβώς όπως Παρεμπιπτόντως, πιο προηγμένες επιτιθέμενοι θα προσπαθήσουν να παρακάμψουν την είσοδο στραγγαλισμού από την «εξάπλωση των δραστηριοτήτων τους»:

  • Διανομή τις προσπάθειες για ένα botnet για την πρόληψη της διεύθυνσης IP επισήμανσης

  • Αντί να διαλέγετε έναν χρήστη και να δοκιμάσετε τις 50.000 πιο κοινών κωδικών πρόσβασης (τα οποία δεν μπορούν, λόγω του στραγγαλισμού μας), θα επιλέξετε το πιο κοινό κωδικό και να το δοκιμάσετε κατά 50.000 χρήστες αντ 'αυτού. Με αυτόν τον τρόπο, όχι μόνο δεν παίρνουν γύρω από τη μέγιστη-απόπειρες μέτρα όπως CAPTCHAs και σύνδεσης στραγγαλισμό, την ευκαιρία τους αυξάνει τις πιθανότητες επιτυχίας, καθώς, δεδομένου ότι το πιο κοινό κωδικό αριθμό 1 είναι πολύ πιο πιθανό από ό, τι αριθμό 49.995

  • Απόσταση τις αιτήσεις σύνδεσης για κάθε λογαριασμό χρήστη, δηλαδή, εκτός από 30 δευτερόλεπτα, για να γλιστρήσει κάτω από το ραντάρ

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

Πάρα πολύ αφηρημένο; Επιτρέψτε μου να αναδιατυπώσει:

Πείτε το site σας είχε κατά μέσο όρο 120 κακών συνδέσεων ανά ημέρα τους τελευταίους 3 μήνες. Χρησιμοποιώντας αυτό (τρέχει κατά μέσο όρο), το σύστημά σας θα μπορούσε να θέσει το παγκόσμιο όριο έως 3 φορές - δηλαδή. 360 αποτυχημένες προσπάθειες για μια περίοδο 24 ωρών. Στη συνέχεια, αν ο συνολικός αριθμός των αποτυχημένων προσπαθειών σε όλους τους λογαριασμούς υπερβαίνει τον αριθμό μέσα σε μία ημέρα (ή ακόμα καλύτερα, να παρακολουθεί το ρυθμό της επιτάχυνσης και της σκανδάλης σε ένα υπολογισμένο όριο), ενεργοποιεί ολόκληρο το σύστημα σύνδεσης στραγγαλισμού - που σημαίνει μικρή καθυστέρηση για όλους τους χρήστες (και πάλι, με την εξαίρεση των συνδέσεων μπισκότων και / ή δημιουργίας αντιγράφων ασφαλείας συνδέσεις CAPTCHA).

I δημοσιεύτηκε επίσης ένα ζήτημα με περισσότερες λεπτομέρειες και μια πολύ καλή συζήτηση για το πώς να αποφευχθεί η δύσκολη pitfals στην απόκρουση διανέμεται βίαιες επιθέσεις

ΜΕΡΟΣ VIII: Δύο Factor Authentication και ταυτότητας Providers

Διαπιστευτήρια μπορεί να τεθεί σε κίνδυνο, είτε από εκμεταλλεύεται, τους κωδικούς πρόσβασης που καταγράφονται και έχασε, φορητοί υπολογιστές με πλήκτρα που έχουν κλαπεί, ή οι χρήστες που εισέρχονται συνδέσεις σε ιστοσελίδες phishing. Συνδέσεις μπορεί να προστατευθεί περαιτέρω με έλεγχο ταυτότητας δύο παραγόντων, τα οποία χρησιμοποιούν out-of-band παράγοντες, όπως κωδικούς μίας χρήσης που λαμβάνεται από ένα τηλεφώνημα, μήνυμα SMS, την εφαρμογή ή dongle. Αρκετοί πάροχοι προσφέρουν υπηρεσίες ελέγχου ταυτότητας δύο παραγόντων.

Authentication μπορεί να ανατεθεί εξ ολοκλήρου σε ένα ενιαίο sign-on υπηρεσία, όπου ένας άλλος πάροχος χειρίζεται τη συλλογή διαπιστευτήρια. Αυτό ωθεί το πρόβλημα σε ένα έμπιστο τρίτο μέρος. Google και το Twitter και να παρέχουν υπηρεσίες SSO που βασίζονται σε πρότυπα, ενώ το Facebook προσφέρει μια παρόμοια ιδιόκτητο λύση.

Πρέπει να διαβάσει LINKS για το Web ταυτότητας

  1. OWASP οδηγός για την Πιστοποίηση / OWASP ταυτότητας εξαπατήσει Φύλλο
  2. Dos και Don'ts της ταυτότητας πελατών στο Web (ερευνητική εργασία πολύ ευανάγνωστη MIT)
  3. Wikipedia: HTTP μπισκότο
  4. Προσωπικές ερωτήσεις γνώσεων για εναλλακτικές ταυτότητας: ερωτήσεις ασφαλείας στην εποχή του Facebook (πολύ ευανάγνωστη ερευνητική εργασία Berkeley)
Απαντήθηκε 25/01/2009 στις 12:27
πηγή χρήστη

ψήφοι
382

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

Αποστολή διαπιστευτήρια

Ο μόνος πρακτικός τρόπος για να στείλετε διαπιστευτήρια 100% ασφάλεια είναι με τη χρήση SSL . Χρησιμοποιώντας την Javascript για να hash του κωδικού πρόσβασης δεν είναι ασφαλής. Κοινές παγίδες για κατακερματισμού client-side κωδικό:

  • Εάν η σύνδεση μεταξύ του πελάτη και του διακομιστή είναι χωρίς κρυπτογράφηση, όλα όσα κάνουμε είναι ευάλωτο σε άνθρωπο-in-the-middle επιθέσεις . Ένας εισβολέας θα μπορούσε να αντικαταστήσει το εισερχόμενο javascript για να σπάσει το κατακερματισμού ή να στείλετε όλα τα διαπιστευτήρια στον server τους, θα μπορούσαν να ακούσουν τις απαντήσεις των πελατών και να μιμηθεί τους χρήστες τέλεια, κλπ κλπ SSL με αξιόπιστες αρχές πιστοποιητικό έχει σχεδιαστεί για να αποτρέψει τις επιθέσεις MITM.
  • Το διαγραμμισμένο τον κωδικό που έλαβε από το διακομιστή είναι λιγότερο ασφαλείς αν δεν κάνετε επιπλέον, περιττή εργασία στο διακομιστή.

Υπάρχει μια άλλη ασφαλή μέθοδο που ονομάζεται SRP , αλλά είναι κατοχυρωμένη με δίπλωμα ευρεσιτεχνίας (αν και είναι ελεύθερα άδεια ) και υπάρχουν μερικές καλές εφαρμογές διαθέσιμες.

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

Μην ποτέ αποθηκεύετε κωδικούς πρόσβασης ως απλό κείμενο στη βάση δεδομένων. Δεν έχει ακόμη και αν δεν ενδιαφέρονται για την ασφάλεια του δικού σας site. Ας υποθέσουμε ότι κάποιοι από τους χρήστες σας θα χρησιμοποιήσετε ξανά τον κωδικό πρόσβασης του σε απευθείας σύνδεση τραπεζικό τους λογαριασμό. Έτσι, αποθηκεύει τον κωδικό πρόσβασης κατακερματισμένη, και πετάξτε το πρωτότυπο. Και βεβαιωθείτε ότι ο κωδικός πρόσβασης δεν εμφανίζονται στα αρχεία καταγραφής πρόσβασης ή αρχεία καταγραφής εφαρμογής. OWASP συνιστά τη χρήση Argon2 ως η πρώτη σας επιλογή για νέες εφαρμογές. Αν αυτό δεν είναι διαθέσιμο, PBKDF2 ή scrypt θα πρέπει να χρησιμοποιείται αντ 'αυτού. Και τέλος, αν κανένα από τα παραπάνω είναι διαθέσιμα, χρησιμοποιήστε bcrypt.

Hashes από μόνα τους είναι επίσης επισφαλής. Για παράδειγμα, από τους ίδιους κωδικούς πρόσβασης σημαίνει πανομοιότυπο hashes - αυτό κάνει πίνακες αναζήτησης κατακερματισμού έναν αποτελεσματικό τρόπο ρωγμές πολλά κωδικούς πρόσβασης ταυτόχρονα. Αντ 'αυτού, να αποθηκεύσετε το αλατισμένο hash. Ένα άλας είναι μια συμβολοσειρά προσαρτάται στο κωδικό πρόσβασης πριν από τη κατακερματισμού - χρησιμοποιήσετε ένα διαφορετικό (τυχαίο) άλατος ανά χρήστη. Το αλάτι είναι μια δημόσια αξία, ώστε να μπορείτε να αποθηκεύσετε με το hash στη βάση δεδομένων. Δείτε εδώ για περισσότερες πληροφορίες σχετικά με αυτό.

Αυτό σημαίνει ότι δεν μπορείτε να στείλετε στο χρήστη ξεχάσει τους κωδικούς πρόσβασης τους (επειδή έχετε μόνο το hash). Μην επαναφέρετε τον κωδικό πρόσβασης του χρήστη, εκτός αν έχουν πιστοποιηθεί από το χρήστη (χρήστες πρέπει να αποδείξει ότι είναι σε θέση να διαβάσει τα μηνύματα που αποστέλλονται στο αποθηκευμένο (και επικυρωμένα) διεύθυνση ηλεκτρονικού ταχυδρομείου.)

Ερώτηση ασφαλείας

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

cookies συνεδρίας

Αφού ο χρήστης συνδέεται στο, ο server στέλνει ο χρήστης ένα cookie συνεδρίας. Ο διακομιστής μπορεί να ανακτήσει το όνομα χρήστη ή τον κωδικό από το cookie, αλλά κανείς άλλος δεν μπορεί να δημιουργήσει ένα τέτοιο μπισκότο (TODO εξηγήσει τους μηχανισμούς).

Τα cookies μπορεί να ομηρία : είναι μόνο τόσο ασφαλές όσο το υπόλοιπο της μηχανής του πελάτη και άλλες επικοινωνίες. Μπορούν να διαβαστούν από το δίσκο, μύρισε στην κίνηση του δικτύου, σήκωσε από ένα cross-site scripting επιθέσεις, phished από ένα δηλητηριασμένο DNS, ώστε ο πελάτης στέλνει τα cookies τους σε λάθος servers. Μην στέλνετε μόνιμα cookies. Τα cookies πρέπει να λήξει στο τέλος της συνεδρίασης πελάτη (πρόγραμμα περιήγησης κοντά ή εξέρχονται από τον τομέα σας).

Αν θέλετε να AutoLogin χρήστες σας, μπορείτε να ορίσετε ένα μόνιμο cookie, αλλά θα πρέπει να διακρίνεται από ένα μπισκότο πλήρη συνεδρία. Μπορείτε να ορίσετε μια επιπλέον ένδειξη ότι ο χρήστης έχει auto-συνδεδεμένοι, και πρέπει να συνδεθείτε για πραγματικά για τις ευαίσθητες λειτουργίες. Αυτό είναι δημοφιλής με τους δικτυακούς τόπους καταστήματα που θέλουν να σας παρέχει ένα ενιαίο, εξατομικευμένη εμπειρία αγορών, αλλά εξακολουθεί να προστατευθούν τα οικονομικά στοιχεία σας. Για παράδειγμα, όταν επιστρέψετε να επισκεφθείτε το Amazon, θα σας δείξω μια σελίδα που μοιάζει είστε συνδεδεμένοι, αλλά όταν θα πάτε να δώσετε την παραγγελία σας (ή να αλλάξετε τη διεύθυνση αποστολής σας, πιστωτικές κάρτες κλπ), θα σας ζητήσει να επιβεβαιώσετε ο κωδικός σας.

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

Λίστα των εξωτερικών πόρων

Απαντήθηκε 02/08/2008 στις 21:40
πηγή χρήστη

ψήφοι
146

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

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

Θα το συνοψίσω αυτό τον τρόπο:

  1. Mozilla είναι ένας μη κερδοσκοπικός με τιμές που ευθυγραμμίζουν καλά με την εύρεση καλές λύσεις σε αυτό το πρόβλημα.
  2. Η πραγματικότητα σήμερα είναι ότι οι περισσότερες ιστοσελίδες χρησιμοποιούν έλεγχο ταυτότητας μορφή με βάση
  3. Ταυτότητας φόρμα που βασίζεται σε έχει ένα μεγάλο μειονέκτημα, το οποίο είναι αυξημένο κίνδυνο ψαρέματος . Οι χρήστες καλούνται να εισάγετε ευαίσθητες πληροφορίες σε μια περιοχή που ελέγχεται από μία απομακρυσμένη οντότητα, και όχι μια περιοχή που ελέγχεται από τους πράκτορα χρήστη (browser).
  4. Από τα προγράμματα περιήγησης είναι έμμεσα αξιόπιστο (η όλη ιδέα ενός πράκτορα χρήστη είναι να ενεργεί για λογαριασμό του Χρήστη), μπορούν να συμβάλουν στη βελτίωση αυτής της κατάστασης.
  5. Η κύρια δύναμη τροχοπέδη της προόδου εδώ είναι αδιέξοδο ανάπτυξης . Λύσεις πρέπει να αναλυθούν σε βήματα τα οποία παρέχουν κάποια στοιχειώδη όφελος από μόνα τους.
  6. Η απλούστερη αποκεντρωμένη μέθοδος για την έκφραση της ταυτότητας που είναι χτισμένο στην υποδομή στο διαδίκτυο είναι το όνομα τομέα.
  7. Ως δεύτερο επίπεδο έκφρασης της ταυτότητας, κάθε τομέας διαχειρίζεται το δικό του σύνολο των λογαριασμών.
  8. Το έντυπο «λογαριασμό @τομέα» είναι συνοπτική και υποστηρίζεται από ένα ευρύ φάσμα των πρωτοκόλλων και συστημάτων URI. Μια τέτοια αναγνωριστικό είναι, φυσικά, πιο αναγνωρίζεται παγκοσμίως ως μια διεύθυνση ηλεκτρονικού ταχυδρομείου.
  9. πάροχοι υπηρεσιών ηλεκτρονικού ταχυδρομείου είναι ήδη de-facto τους παρόχους πρωτοβάθμιας ταυτότητα στο διαδίκτυο. Οι τρέχουσες ροές επαναφοράς κωδικού πρόσβασης που συνήθως σας επιτρέπουν να πάρετε τον έλεγχο του λογαριασμού, αν μπορείτε να αποδείξετε ότι έχετε τον έλεγχο που σχετίζεται διεύθυνση ηλεκτρονικού ταχυδρομείου αυτού του λογαριασμού.
  10. Το Verified πρωτόκολλο Email προτάθηκε να παρέχει μια ασφαλή μέθοδο, που βασίζεται στην κρυπτογραφία δημόσιου κλειδιού, για τον εξορθολογισμό της διαδικασίας της απόδειξης για την περιοχή Β που έχετε λογαριασμό στο πεδίο Α
  11. Για browsers που δεν υποστηρίζουν το πρωτόκολλο Verified Email (προς το παρόν όλα αυτά), Mozilla παρέχει μια ροδέλα που υλοποιεί το πρωτόκολλο στο client-side κώδικα JavaScript.
  12. Για τις υπηρεσίες ηλεκτρονικού ταχυδρομείου που δεν υποστηρίζουν το πρωτόκολλο Verified Email, το πρωτόκολλο επιτρέπει σε τρίτους να λειτουργήσει ως ένα αξιόπιστο διαμεσολαβητή, υποστηρίζοντας ότι έχουν επαληθεύσει την κατοχή ενός χρήστη του λογαριασμού. Δεν είναι επιθυμητό να έχουμε ένα μεγάλο αριθμό αυτών των τρίτων μερών? αυτή η δυνατότητα προορίζεται μόνο για να επιτρέψει μια πορεία βελτίωσης, και είναι πολύ προτιμάται ότι οι υπηρεσίες ηλεκτρονικού ταχυδρομείου παρέχουν οι ίδιοι αυτούς τους ισχυρισμούς.
  13. Mozilla προσφέρει τη δική τους υπηρεσία να λειτουργεί ως τέτοιο έμπιστο τρίτο μέρος. Οι πάροχοι υπηρεσιών (δηλαδή, οι Τρίτοι Συμβαλλόμενοι) την εφαρμογή του πρωτοκόλλου Verified Email μπορούν να επιλέξουν να εμπιστεύονται τους ισχυρισμούς ή όχι του Mozilla. υπηρεσία του Mozilla επαληθεύει την κυριότητα του λογαριασμού των χρηστών που χρησιμοποιούν τα συμβατικά μέσα της στέλνοντας ένα email με ένα σύνδεσμο επιβεβαίωσης.
  14. Πάροχοι Υπηρεσιών μπορεί, φυσικά, να προσφέρουν αυτό το πρωτόκολλο ως επιλογή πέρα ​​από οποιαδήποτε άλλη μέθοδο (α) της ταυτότητας που μπορεί να επιθυμούν να προσφέρουν.
  15. Μια μεγάλη διεπαφή χρήστη όφελος που επιδιώκεται εδώ είναι η «επιλογέας ταυτότητας». Όταν ένας χρήστης επισκέπτεται μια ιστοσελίδα και να επιλέγει για τον έλεγχο ταυτότητας, ο browser τους, να τους παρουσιάζει μια επιλογή από τις διευθύνσεις ηλεκτρονικού ταχυδρομείου ( «προσωπικά», «εργασία», «πολιτικό ακτιβισμό», κ.λπ.) μπορούν να χρησιμοποιήσουν για να προσδιορίσουν τον εαυτό τους στην ιστοσελίδα.
  16. Ένα άλλο μεγάλο πλεονέκτημα διεπαφή χρήστη που αναζητούνται στο πλαίσιο αυτής της προσπάθειας είναι να βοηθήσει το πρόγραμμα περιήγησης μάθετε περισσότερα σχετικά συνεδρία του χρήστη - που έχουν συνδεθεί ως σήμερα, κατά κύριο λόγο - έτσι ώστε να μπορεί να εμφανίσει ότι το χρώμιο πρόγραμμα περιήγησης.
  17. Λόγω της κατανεμημένης φύσης του εν λόγω συστήματος, αποφεύγει lock-in σε σημαντικά αξιοθέατα όπως το Facebook, Twitter, Google, κλπ Κάθε άτομο μπορεί να έχουν το δικό τους τομέα και, ως εκ τούτου ενεργεί ως δικό τους πάροχο ταυτότητας.

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

Απαντήθηκε 08/08/2011 στις 16:32
πηγή χρήστη

ψήφοι
120

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

Καλώ το ομοίωμα πεδίο (αν και δεν έχω εφεύρει αυτό, έτσι δεν με πίστωση).

Με λίγα λόγια: θα πρέπει απλά να τοποθετήσετε αυτό σε σας <form>και ελέγξτε για να είναι άδειο το πότε επικύρωση:

<input type="text" name="email" style="display:none" />

Το κόλπο είναι να ξεγελάσουν ένα bot να νομίζει ότι πρέπει να εισάγετε δεδομένα σε ένα απαιτούμενο πεδίο, γι 'αυτό ονομάστηκε η είσοδος «e-mail». Αν έχετε ήδη ένα πεδίο που ονομάζεται e-mail που χρησιμοποιείτε θα πρέπει να δοκιμάσετε την ονομασία του ανδρεικέλου κάτι πεδίου άλλο σαν «εταιρεία», «τηλέφωνο» ή «EMAILADDRESS». Απλά επιλέξτε κάτι που ξέρετε ότι δεν χρειάζεται και αυτό ακούγεται σαν κάτι που οι άνθρωποι συνήθως θα βρείτε λογικό να συμπληρώσετε σε μια ηλεκτρονική φόρμα. Τώρα κρύψει το inputπεδίο, χρησιμοποιώντας CSS ή JavaScript / jQuery - ό, τι ταιριάζει καλύτερα - απλά δεν ρυθμίσετε την είσοδο typeσε hiddenή αλλιώς το bot δεν θα πέσει για αυτό.

Όταν επικύρωση της μορφής (είτε πελάτη ή διακομιστή) ελέγξτε αν εικονική τομέα σας έχει γεμίσει για να διαπιστωθεί εάν είχε στείλει από έναν άνθρωπο ή ένα bot.

Παράδειγμα:

Σε περίπτωση ενός ανθρώπου: Ο χρήστης δεν θα δείτε την εικονική πεδίο (στην περίπτωσή μου που ονομάζεται «e-mail») και δεν θα προσπαθήσει να το γεμίσει. Έτσι, η τιμή του ανδρεικέλου τομέα θα πρέπει να εξακολουθεί να είναι άδειο, όταν έχει στείλει το έντυπο.

Σε περίπτωση που ένα bot: Το ρομπότ θα δείτε ένα πεδίο του οποίου ο τύπος είναι textκαι ένα όνομα email(ή ό, τι είναι αυτό που αποκάλεσε) και θα προσπαθήσει λογικά να το γεμίσετε με τα κατάλληλα δεδομένα. Δεν με νοιάζει αν στυλ τη μορφή εισόδου με κάποια φανταχτερή CSS, web-developers το κάνουν όλη την ώρα. Όποια και αν είναι η τιμή στο ομοίωμα πεδίο είναι, δεν με νοιάζει, αρκεί να είναι μεγαλύτερα από ό, τι 0χαρακτήρες.

Χρησιμοποίησα αυτή τη μέθοδο σε ένα βιβλίο επισκεπτών σε συνδυασμό με το CAPTCHA , και δεν έχω δει μια ενιαία θέση ανεπιθύμητα μηνύματα από τότε. Είχα χρησιμοποιήσει ένα CAPTCHA-μόνη λύση πριν, αλλά τελικά οδήγησε σε περίπου πέντε θέσεις ανεπιθύμητα μηνύματα κάθε ώρα. Προσθέτοντας το ομοίωμα τομέα με τη μορφή έχει σταματήσει (τουλάχιστον μέχρι σήμερα) όλα τα ανεπιθύμητα μηνύματα από την εμφάνιση.

Πιστεύω ότι αυτό μπορεί επίσης να χρησιμοποιηθεί μια χαρά με μια φόρμα σύνδεσης / ελέγχου ταυτότητας.

Προειδοποίηση : Φυσικά αυτή η μέθοδος δεν είναι 100% απόδειξη ανόητος. Bots μπορεί να προγραμματιστεί για να αγνοήσει πεδία εισαγωγής με το στυλ display:noneπου εφαρμόζεται σε αυτό. Θα πρέπει επίσης να σκεφτούμε τους ανθρώπους που χρησιμοποιούν κάποια μορφή αυτόματης συμπλήρωσης (όπως και τα περισσότερα προγράμματα περιήγησης έχουν ενσωματωμένο!) Για την αυτόματη συμπληρώσετε όλα τα πεδία της φόρμας τους. Θα μπορούσε κάλλιστα να πάρει μια εικονική τομέα.

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

Να είσαι δημιουργικός!

Απαντήθηκε 22/05/2012 στις 13:11
πηγή χρήστη

ψήφοι
71

Δεν νομίζω ότι η παραπάνω απάντηση είναι «λάθος», αλλά υπάρχουν μεγάλες περιοχές της ταυτότητας που δεν θίγονται (ή μάλλον η έμφαση είναι στο «πώς να εφαρμόσουν συνεδρίες cookie», όχι για «τι επιλογές είναι διαθέσιμες και ποιες είναι οι εμπορικές offs».

προτεινόμενες αλλαγές / απαντήσεις μου είναι

  • Το πρόβλημα έγκειται περισσότερο στη ρύθμιση του λογαριασμού σε σχέση με τον έλεγχο κωδικού πρόσβασης.
  • Η χρήση των δύο παράγοντα authenitication είναι πολύ πιο ασφαλής από ό, τι πιο έξυπνο μέσο για την κρυπτογράφηση των κωδικών πρόσβασης
  • Μην προσπαθήσετε να εφαρμόσει τη δική του μορφή σύνδεσή σας ή την αποθήκευση δεδομένων των κωδικών πρόσβασης, εκτός αν τα δεδομένα που αποθηκεύονται είναι άνευ αξίας κατά τη δημιουργία του λογαριασμού και την αυτο-που παράγονται (δηλαδή, web 2.0 στυλ, όπως το Facebook, το Flickr , κλπ)

    1. Digest Authentication είναι μια προτύπων με βάση την προσέγγιση που υποστηρίζεται σε όλες τις μεγάλες μηχανές αναζήτησης και servers, που δεν θα στείλει έναν κωδικό πρόσβασης, ακόμη και πάνω από ένα ασφαλές κανάλι.

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

Ωστόσο, δεν συνιστούμε αυτό, εκτός από τις δημόσιες υπηρεσίες χαμηλής αξίας. Αυτό είναι ένα θέμα με μερικές από τις άλλες απαντήσεις παραπάνω - μην προσπαθήσετε Μια εκ νέου εφαρμογή μηχανισμών authetication server-side - αυτό το πρόβλημα έχει λυθεί και υποστηρίζεται από τις περισσότερες μεγάλες μηχανές αναζήτησης. Μην χρησιμοποιείτε τα cookies. Μην αποθηκεύετε τίποτα στο δικό στριφτά βάση δεδομένων σας. Απλά ρωτήστε, ανά αίτηση, εάν η σχετική αίτηση autheticated. Οτιδήποτε άλλο θα πρέπει να υποστηρίζονται από τη διαμόρφωση και τρίτων κατασκευαστών αξιόπιστο λογισμικό.

Ετσι ...

Κατ 'αρχάς, εμείς συγχέει την αρχική δημιουργία ενός λογαριασμού (με κωδικό) με τον επανέλεγχο του κωδικού πρόσβασης στη συνέχεια. Αν είμαι Flickr και τη δημιουργία site σας για πρώτη φορά, ο νέος χρήστης έχει πρόσβαση σε μηδενική αξία (κενό χώρο στο διαδίκτυο). Πραγματικά δεν με νοιάζει αν το άτομο τη δημιουργία του λογαριασμού είναι ψέματα σχετικά με το όνομά τους. Αν είμαι δημιουργώντας ένα λογαριασμό του νοσοκομείου intranet / extranet, η αξία έγκειται στο σύνολο των ιατρικών αρχείων, και γι 'αυτό δεν ενδιαφέρονται για την ταυτότητα (*) του δημιουργού λογαριασμό.

Αυτό είναι το πολύ πολύ δύσκολο μέρος. Η μόνη αξιοπρεπής λύση είναι ένα web εμπιστοσύνης. Για παράδειγμα, μπορείτε να συμμετάσχετε στο νοσοκομείο ως γιατρός. Μπορείτε να δημιουργήσετε μια ιστοσελίδα που φιλοξενείται κάπου με τη φωτογραφία σας, τον αριθμό διαβατηρίου σας και ένα δημόσιο κλειδί, και hash τα όλα με το ιδιωτικό κλειδί. Στη συνέχεια, επισκεφτείτε το νοσοκομείο και ο διαχειριστής του συστήματος εξετάζει το διαβατήριό σας, βλέπει αν η φωτογραφία σας ταιριάζει, και στη συνέχεια hashes του κατακερματισμού της ιστοσελίδας / φωτογραφία με το ιδιωτικό κλειδί του νοσοκομείου. Από τώρα και στο εξής μπορούμε να ανταλλάξουμε με ασφάλεια τα κλειδιά και τις μάρκες. Όπως μπορεί ο καθένας που εμπιστεύεται το νοσοκομείο (δεν υπάρχει η μυστική συνταγή BTW). Ο διαχειριστής του συστήματος μπορεί επίσης να σας δώσει μια RSA κλειδί ή άλλο έλεγχο ταυτότητας δύο παραγόντων.

Αλλά αυτό είναι μια μεγάλη ταλαιπωρία, και δεν είναι πολύ web 2.0. Ωστόσο, είναι ο μόνος ασφαλής τρόπος για να δημιουργήσετε νέους λογαριασμούς που έχουν πρόσβαση σε πολύτιμες πληροφορίες που δεν είναι αυτο-δημιουργήθηκε.

  1. Kerberos και SPNEGO - Single Sign On μηχανισμούς με ένα έμπιστο τρίτο μέρος - ουσιαστικά ο χρήστης ελέγχει κατά ένα έμπιστο τρίτο μέρος. (Σημείωση: αυτό δεν είναι σε καμία περίπτωση το να μην εμπιστεύονται το OAuth )

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

  3. SSL πλευρά του πελάτη - να δώσει στους πελάτες ένα δημόσιο κλειδί του πιστοποιητικού (υποστήριξη σε όλες τις μεγάλες μηχανές αναζήτησης - αλλά εγείρει ερωτήματα για την ασφάλεια της μηχανής του πελάτη).

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

Απαντήθηκε 08/08/2011 στις 17:29
πηγή χρήστη

ψήφοι
48

Όταν κατακερματισμού, μην χρησιμοποιείτε γρήγορα αλγορίθμων κατακερματισμού όπως MD5 (υπάρχουν πολλές εφαρμογές hardware). Χρησιμοποιήστε κάτι σαν SHA-512. Για τους κωδικούς πρόσβασης, πιο αργή hashes είναι καλύτερα.

Όσο πιο γρήγορα μπορείτε να δημιουργήσετε hashes, τόσο πιο γρήγορα κάθε ωμής βίας έλεγχος μπορεί να λειτουργήσει. Ως εκ τούτου, πιο αργή hashes θα επιβραδύνει ωμής αναγκάζοντας. Μια αργή αλγόριθμο κατακερματισμού θα κάνει ωμής αναγκάζοντας ανέφικτη για μεγαλύτερο χρονικό διάστημα κωδικούς πρόσβασης (8 ψηφία +)

Απαντήθηκε 09/08/2011 στις 00:07
πηγή χρήστη

ψήφοι
46

Ένα καλό άρθρο για ρεαλιστική εκτίμηση ισχύος κωδικού πρόσβασης είναι:

Dropbox Tech Blog »Blog Archive» zxcvbn: Εκτίμηση αντοχής ρεαλιστική κωδικό

Απαντήθηκε 08/11/2012 στις 12:15
πηγή χρήστη

ψήφοι
41

Το αγαπημένο μου κανόνα σε σχέση με την επαλήθευση ταυτότητας συστήματα: χρήση φράσεων πρόσβασης, δεν τους κωδικούς πρόσβασης. Εύκολο να θυμάστε, είναι δύσκολο να σπάσει. Περισσότερες πληροφορίες: Κωδικοποίηση Τρόμου: Οι κωδικοί πρόσβασης εναντίον πέρασμα Φράσεις

Απαντήθηκε 24/11/2012 στις 22:15
πηγή χρήστη

ψήφοι
20

Θα ήθελα να προσθέσω μια πρόταση που έχω χρησιμοποιήσει, με βάση την άμυνα σε βάθος. Δεν χρειάζεται να έχουν την ίδια auth & auth σύστημα για τους διαχειριστές και τους τακτικούς χρήστες. Μπορείτε να έχετε μια ξεχωριστή φόρμα σύνδεσης σε ένα ξεχωριστό url εκτέλεση ξεχωριστό κωδικό για τις αιτήσεις που θα παρέχουν υψηλής προνόμια. Αυτό μπορεί κανείς να κάνει επιλογές που θα είναι ένα σύνολο πόνος για τακτικούς χρήστες. Μια τέτοια που έχω χρησιμοποιήσει είναι να αγωνίζομαι στην πραγματικότητα το URL σύνδεσης για την πρόσβαση διαχειριστή και στείλτε το διαχειριστή τη νέα διεύθυνση URL. Σταματά κάθε επίθεση ωμής βίας αμέσως ως νέα διεύθυνση URL σας μπορεί να είναι αυθαίρετα δύσκολο (πολύ μεγάλο τυχαία σειρά), αλλά μόνο ταλαιπωρία σας χρήστη διαχειριστή του ακολουθεί ένα σύνδεσμο στο email τους. Ο εισβολέας δεν ξέρει πού να ακόμη Δημοσίευση στο.

Απαντήθηκε 18/07/2015 στις 01:18
πηγή χρήστη

ψήφοι
12

Έχω dont't ξέρω αν ήταν καλύτερα να απαντήσει σε αυτό ως απάντηση ή ως σχόλιο. Επέλεξα την πρώτη επιλογή.

Όσον αφορά το Poing ΜΕΡΟΣ IV: Ξεχάσατε τον κωδικό λειτουργικότητα στην πρώτη απάντηση, θα ήθελα να κάνω μια παρατήρηση σχετικά με το χρονοδιάγραμμα επιθέσεις.

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

Όσον αφορά τη Ξεχάσατε τον κωδικό έντυπο, θα ήθελα να προσθέσω ότι είναι μια καλή ιδέα να ισούται φορές μεταξύ επιτυχημένων και unsucessful ερωτήματα με κάποια λειτουργία καθυστέρησης.

https://crypto.stanford.edu/~dabo/papers/webtiming.pdf

Απαντήθηκε 16/08/2015 στις 17:31
πηγή χρήστη

ψήφοι
10

Θα ήθελα να προσθέσω ένα πολύ-σημαντικό σχόλιο:

  • «Σε εταιρικό, ενδο- καθαρό περιβάλλον,» τα περισσότερα, αν όχι όλα τα παραπάνω μπορεί να μην ισχύουν!

Πολλές εταιρείες αναπτύσσουν «εσωτερική χρήση» ιστοσελίδες που είναι, ουσιαστικά, «εταιρικές εφαρμογές» που τυχαίνει να έχουν υλοποιηθεί μέσω των διευθύνσεων URL. Αυτές οι διευθύνσεις URL μπορεί (υποτίθεται ...) να επιλυθούν μόνο μέσα στο «εσωτερικό δίκτυο της εταιρείας.» (Ποια δίκτυο μαγικά περιλαμβάνει όλα VPN συνδέσεις «πολεμιστές του δρόμου.»)

Όταν ένας χρήστης είναι υπάκουα συνδεδεμένο με το προαναφερθέν δίκτυο, την ταυτότητά τους ( «ταυτότητας») είναι [ήδη ...] «οριστικά γνωστή», όπως είναι η άδειά τους ( «άδεια») για να κάνει ορισμένα πράγματα ... όπως. .. «για να αποκτήσετε πρόσβαση σε αυτή την ιστοσελίδα.»

Αυτή η υπηρεσία «ταυτότητας + άδεια» μπορεί να παρέχεται από πολλές διαφορετικές τεχνολογίες, όπως LDAP (Microsoft OpenDirectory) , ή Kerberos.

Από την point-of-view σας, μπορείτε απλά να το γνωρίζουν αυτό: ότι ο καθένας που καταλήγει-up νόμιμα στην ιστοσελίδα σας πρέπει «token» να συνοδεύεται από [ένα περιβάλλον μεταβλητή μαγικά περιέχει ...] ένα ( Δηλαδή η απουσία ενός τέτοιου συμβολική πρέπει να είναι άμεση λόγους 404 Not Found.)

Η αξία του διακριτικού του δεν έχει νόημα να σας, αλλά, σε περίπτωση ανάγκης, «υπάρχουν τα κατάλληλα μέσα», με την οποία το web-site σας μπορεί να «[έγκυρα] ρωτήσω κάποιον που ξέρει (LDAP ... κλπ)» για οποιαδήποτε και κάθε ( !) ερώτηση που μπορεί να έχετε. Με άλλα λόγια, εσείς δεν τον εαυτό σας να επωφεληθούν από οποιοδήποτε «σπίτι-που καλλιεργούνται λογική.» Αντ 'αυτού, μπορείτε να ρωτήσετε της Αρχής και εμμέσως εμπιστεύονται την ετυμηγορία του.

Uh huh ... είναι αρκετά μια ψυχική-μετάβαση από την «άγρια-και-wooly Internet.»

Απαντήθηκε 29/04/2015 στις 01:06
πηγή χρήστη

ψήφοι
5

Χρησιμοποιήστε το OpenID Connect ή χρήστη για τη διαχείριση πρόσβασης .

Καθώς τίποτα δεν είναι πιο αποτελεσματικό από το να μην το κάνει καθόλου.

Απαντήθηκε 10/08/2016 στις 13:27
πηγή χρήστη

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more