Από τι σας προστατεύει πραγματικά ο κατακερματισμός ενός κωδικού πρόσβασης

Η σύντομη εκδοχή

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

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

Ένας σωστά κατακερματισμένος κωδικός πρόσβασης είναι δύσκολο να αντιστραφεί. Αν ένας επιτιθέμενος αποκτήσει ένα αντίγραφο του πίνακα χρηστών σας, δεν θα πρέπει να μάθει αμέσως ότι ο κωδικός της Alice είναι Spring2026!. Αντί γι’ αυτό, παίρνει ένα αποθηκευμένο hash που απαιτεί χρόνο, χρήματα και υλικό για να δοκιμαστεί απέναντι σε εικασίες.

Αυτή η διάκριση έχει σημασία. Ο κατακερματισμός κωδικών πρόσβασης δεν προορίζεται να κάνει από μόνος του την είσοδο ασφαλή. Δεν σταματά το phishing. Δεν σταματά κάποιον από το να δοκιμάζει διαρρεύσαντες κωδικούς πρόσβασης στη φόρμα εισόδου σας. Δεν προστατεύει ένα session cookie μετά την είσοδο. Κερδίζει χρόνο και μειώνει τη ζημιά μετά από μια πολύ συγκεκριμένη αποτυχία: η αποθήκευση των επαληθευτών κωδικών πρόσβασής σας εκτίθεται.

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

Τι είναι ένα hash κωδικού πρόσβασης

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

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

1. Να λάβει τον κωδικό πρόσβασης μέσω HTTPS.
2. Να δημιουργήσει ένα τυχαίο, μοναδικό salt.
3. Να περάσει τον κωδικό πρόσβασης και το salt μέσα από μια συνάρτηση κατακερματισμού κωδικών πρόσβασης όπως Argon2id, bcrypt, scrypt ή PBKDF2.
4. Να αποθηκεύσει το όνομα του αλγορίθμου, τις παραμέτρους, το salt και το hash που προκύπτει.
5. Να απορρίψει τον αρχικό κωδικό πρόσβασης.

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

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

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

Από τι σας προστατεύει ο κατακερματισμός

1. Άμεση αποκάλυψη κωδικών πρόσβασης μετά από παραβίαση βάσης δεδομένων

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

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

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

Ο κατακερματισμός μετατρέπει μια καταστροφική αποκάλυψη σε αγώνα δρόμου: μπορούν οι χρήστες να επαναφέρουν τους κωδικούς πρόσβασης και μπορείτε εσείς να περιορίσετε το περιστατικό πριν οι επιτιθέμενοι σπάσουν πολλούς από αυτούς;

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

2. Μαζικές επιθέσεις εναντίον ολόκληρης της βάσης χρηστών σας

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

Ένα salt δεν είναι μυστικό. Αποθηκεύεται μαζί με το hash. Η δουλειά του είναι η μοναδικότητα.

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

Χωρίς salts, ένα σπασμένο hash μπορεί να αποκαλύψει κάθε χρήστη με τον ίδιο κωδικό πρόσβασης. Με salts, κάθε εικασία κωδικού πρόσβασης πρέπει να δοκιμάζεται ξεχωριστά για κάθε χρήστη.

3. Γρήγορες εικασίες offline

Μόλις οι επιτιθέμενοι αποκτήσουν μια βάση δεδομένων κωδικών πρόσβασης, μπορούν να μαντεύουν offline. Αυτό σημαίνει ότι τα όρια ρυθμού στη σύνδεσή σας, τα CAPTCHA, ο αποκλεισμός IP και η παρακολούθηση δεν έχουν πλέον σημασία. Ο επιτιθέμενος μπορεί να δοκιμάζει εικασίες στο δικό του υλικό.

Εδώ είναι που έχει σημασία η επιλογή αλγορίθμου.

Οι γενικής χρήσης συναρτήσεις hash όπως SHA-256 και SHA-512 έχουν σχεδιαστεί για να είναι γρήγορες. Αυτό είναι καλό για ακεραιότητα αρχείων και ψηφιακές υπογραφές. Είναι κακό για αποθήκευση κωδικών πρόσβασης.

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

Το Argon2id συνιστάται ευρέως για νέα συστήματα επειδή μπορεί να ρυθμιστεί ώστε να απαιτεί και χρόνο CPU και μνήμη, κάτι που κάνει το cracking μεγάλης κλίμακας με GPU πιο ακριβό. Το bcrypt παραμένει κοινό και αποδεκτό όταν ρυθμίζεται σωστά, αν και έχει περιορισμούς όπως ο χειρισμός μήκους κωδικού πρόσβασης. Το PBKDF2 εξακολουθεί να χρησιμοποιείται σε ορισμένα περιβάλλοντα που καθοδηγούνται από απαιτήσεις συμμόρφωσης, ειδικά όπου απαιτούνται στοιχεία επικυρωμένα κατά FIPS.

Η αρχή είναι απλή: κάντε τις νόμιμες εισόδους αποδεκτά γρήγορες, ενώ κάνετε δισεκατομμύρια εικασίες ακριβές.

Από τι δεν σας προστατεύει ο κατακερματισμός

1. Phishing

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

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

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

2. Credential stuffing

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

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

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

Η ίδια πρακτική σκέψη ισχύει για κάθε εκτεθειμένη φόρμα. Αν επανεξετάζετε την επιφάνεια ελέγχου ταυτότητας, αξίζει να διαβάσετε γιατί η φόρμα επικοινωνίας σας είναι η μεγαλύτερη ευθύνη σας για spam· οι μηχανισμοί διαφέρουν, αλλά το μάθημα είναι παρόμοιο: οι δημόσιες είσοδοι χρειάζονται ελέγχους κατάχρησης, όχι μόνο καθαρό backend code.

3. Κωδικοί πρόσβασης που καταγράφονται σε logs ή analytics

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

Συνηθισμένες αποτυχίες περιλαμβάνουν:

• Καταγραφή ολόκληρων σωμάτων αιτημάτων σε αποτυχημένες προσπάθειες εισόδου.
• Αποστολή κωδικών πρόσβασης σε εργαλεία παρακολούθησης σφαλμάτων.
• Καταγραφή πεδίων κωδικού πρόσβασης σε προϊόντα session replay.
• Συμπερίληψη διαπιστευτηρίων σε URLs κατά τη διάρκεια κακοσχεδιασμένων ροών επαναφοράς ή μετεγκατάστασης.
• Αποθήκευση προσωρινών κωδικών πρόσβασης σε απλό κείμενο κατά τις εισαγωγές.

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

Αντιμετωπίστε τα πεδία κωδικού πρόσβασης ως τοξικά δεδομένα. Απαλείψτε τα πριν την καταγραφή. Εξαιρέστε τα από τα analytics. Κρατήστε τα έξω από URLs. Περιορίστε ποιος μπορεί να έχει πρόσβαση σε production traces.

4. Κακή ασφάλεια συνεδριών

Μετά την είσοδο, ο browser του χρήστη λαμβάνει συνήθως ένα session cookie ή token. Αν αυτό το token κλαπεί, ο επιτιθέμενος μπορεί να μη χρειάζεται καθόλου τον κωδικό πρόσβασης.

Ο κατακερματισμός κωδικών πρόσβασης δεν προστατεύει από cross-site scripting, μη ασφαλή cookies, session fixation, αδύναμη δημιουργία token ή υπερβολικά μεγάλες διάρκειες συνεδρίας.

Τα session cookies αξίζουν τη δική τους ανασκόπηση: HttpOnly, Secure, κατάλληλο SameSite, βραχύβιες συνεδρίες υψηλού κινδύνου και ακύρωση από την πλευρά του διακομιστή σε αλλαγές κωδικού πρόσβασης. Το ευρύτερο τοπίο ιδιωτικότητας και browsers επίσης συνεχίζει να αλλάζει, όπως καλύπτεται στο τι άλλαξε για τα cookies το 2026.

5. Αδύναμη επαναφορά κωδικού πρόσβασης και ανάκτηση λογαριασμού

Πολλές καταλήψεις λογαριασμών δεν ξεκινούν με τον κωδικό πρόσβασης. Ξεκινούν με τη ροή επαναφοράς.

Αν τα reset tokens είναι προβλέψιμα, μακρόβια, διαρρέουν μέσω referrer headers ή αποστέλλονται σε παραβιασμένους λογαριασμούς email, ο κατακερματισμός κωδικών πρόσβασης δεν θα σας σώσει.

Χρησιμοποιήστε reset tokens υψηλής εντροπίας, σύντομα παράθυρα λήξης, εφάπαξ χρήση και σαφείς ειδοποιήσεις χρηστών. Επειδή το email είναι συχνά το κανάλι ανάκτησης, έχει σημασία και ο βασικός έλεγχος ταυτότητας domain. Αν η ομάδα σας αντιμετωπίζει τις εγγραφές DNS ως μυστηριώδη τελετουργία, ξεκινήστε με μια φιλική προς developers περιήγηση στα MX, SPF, DKIM και DMARC.

Η επιλογή αλγορίθμου: τι να χρησιμοποιήσετε τώρα

Για νέες εφαρμογές, χρησιμοποιήστε Argon2id αν η πλατφόρμα σας το υποστηρίζει καλά. Είναι ο νικητής του Password Hashing Competition και έχει σχεδιαστεί για αποθήκευση κωδικών πρόσβασης, συμπεριλαμβανομένης της αντοχής σε cracking με έντονη χρήση GPU.

Μια λογική σύγχρονη ιεράρχηση μοιάζει ως εξής:

1. Argon2id για νέα συστήματα όπου είναι διαθέσιμο.
2. bcrypt όταν το Argon2id δεν είναι πρακτικό και η υποστήριξη bcrypt είναι ώριμη.
3. scrypt όταν υποστηρίζεται καλά η διαμόρφωση με απαιτήσεις μνήμης.
4. PBKDF2 όπου απαιτείται από περιορισμούς πλατφόρμας ή συμμόρφωσης.

Αποφύγετε απλό SHA-256, SHA-512, MD5 ή έναν αυτοσχέδιο συνδυασμό όπως sha256(password + salt). Τα γρήγορα hashes δεν είναι συναρτήσεις αποθήκευσης κωδικών πρόσβασης. Οι έξυπνες προσαρμοσμένες κατασκευές τείνουν να είναι χειρότερες από τις βαρετές τυποποιημένες.

Επίσης, αποφύγετε να εφευρίσκετε τη δική σας πολιτική κωδικών πρόσβασης γύρω από λεπτομέρειες αλγορίθμων. Οι χρήστες δεν ωφελούνται από μια λίστα 12 κανόνων σύνθεσης κωδικού πρόσβασης αν τους ωθεί προς προβλέψιμα μοτίβα. Οι μεγαλύτεροι μοναδικοί κωδικοί πρόσβασης, οι password managers, ο έλεγχος για παραβιασμένους κωδικούς πρόσβασης και το MFA συνήθως έχουν μεγαλύτερη σημασία.

Οι συντελεστές κόστους δεν ρυθμίζονται μία φορά και ξεχνιούνται

Ο κατακερματισμός κωδικών πρόσβασης έχει παραμέτρους. Το Argon2id έχει μνήμη, επαναλήψεις και παραλληλισμό. Το bcrypt έχει συντελεστή κόστους. Το PBKDF2 έχει πλήθος επαναλήψεων.

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

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

Μην αντιγράφετε έναν συντελεστή κόστους από ένα blog post πέντε ετών. Το υλικό αλλάζει. Οι βιβλιοθήκες αλλάζουν. Η κίνησή σας αλλάζει.

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

Peppers: χρήσιμα, αλλά όχι υποκατάστατο

Ένα pepper είναι μια μυστική τιμή που προστίθεται στη διαδικασία κατακερματισμού κωδικού πρόσβασης και αποθηκεύεται ξεχωριστά από τη βάση δεδομένων, συχνά σε έναν secrets manager ή σε hardware security module.

Σε αντίθεση με ένα salt, ένα pepper πρέπει να παραμείνει μυστικό.

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

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

Η επιχειρησιακή λίστα ελέγχου

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

• Αποθηκεύετε κωδικούς πρόσβασης μόνο με έναν τυποποιημένο αλγόριθμο κατακερματισμού κωδικών πρόσβασης.
• Χρησιμοποιείτε ένα μοναδικό τυχαίο salt ανά κωδικό πρόσβασης.
• Προτιμήστε Argon2id για νέες υλοποιήσεις.
• Ρυθμίστε τις παραμέτρους κόστους σε υλικό παρόμοιο με production.
• Αποθηκεύετε τον αλγόριθμο και τις παραμέτρους με κάθε hash.
• Κάνετε rehash κατά την είσοδο όταν οι παράμετροι γίνονται παρωχημένες.
• Μην καταγράφετε ποτέ κωδικούς πρόσβασης ούτε να τους στέλνετε σε εργαλεία analytics.
• Χρησιμοποιείτε TLS παντού όπου υποβάλλονται διαπιστευτήρια.
• Προσθέστε MFA ή passkeys όπου ο κίνδυνος το δικαιολογεί.
• Προστατεύετε τις ροές επαναφοράς εξίσου σοβαρά με τις ροές εισόδου.
• Έχετε σχέδιο περιστατικού για αναγκαστικές επαναφορές και ειδοποίηση χρηστών.

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

<!-- tool-cta:start -->

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

<!-- tool-cta:end -->

Το ειλικρινές νοητικό μοντέλο

Ο καλύτερος τρόπος να σκέφτεστε τον κατακερματισμό κωδικών πρόσβασης είναι αυτός:

Ο κατακερματισμός δεν προστατεύει τον κωδικό πρόσβασης όσο ο χρήστης τον πληκτρολογεί. Δεν προστατεύει τον λογαριασμό αφού ο χρήστης έχει συνδεθεί. Δεν προστατεύει χρήστες που επαναχρησιμοποιούν κωδικούς πρόσβασης στο web.

Προστατεύει τον αποθηκευμένο επαληθευτή.

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

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

Αυτό είναι από τι σας προστατεύει πραγματικά ο κατακερματισμός ενός κωδικού πρόσβασης.