Τι είναι το Salting στην ασφάλεια; Εξήγηση του κατακερματισμού κωδικών πρόσβασης

Τον Ιούνιο του 2012, ένας εισβολέας διέρρευσε 117 εκατομμύρια αρχεία λογαριασμών LinkedIn σε ένα ρωσικό φόρουμ. Η λίστα ήταν ένας τοίχος από ανάλατα hashes SHA-1. Το SHA-1 είναι γρήγορο. Χωρίς salt για να διασπάσει πανομοιότυπους κωδικούς πρόσβασης, το ίδιο hash παρέμενε δίπλα στο ίδιο hash χιλιάδες φορές. Μέσα σε περίπου εβδομήντα δύο ώρες, οι ερευνητές ασφαλείας είχαν σπάσει περίπου το ενενήντα τοις εκατό του αρχείου. Όταν η παραβίαση επανεμφανίστηκε τον Μάιο του 2016 ως μέρος ενός συνόλου δεδομένων 167 εκατομμυρίων αρχείων, αυτά τα διαπιστευτήρια τροφοδότησαν εκστρατείες παραποίησης διαπιστευτηρίων για χρόνια.

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

Οι περισσότερες σύγχρονες αποτυχίες αποθήκευσης κωδικών πρόσβασης εξακολουθούν να προέρχονται από την ίδια βασική αιτία: κάποιος αποφάσισε ότι η φράση "χρησιμοποιούμε SHA-256" ήταν αρκετά καλή. Αυτό το άρθρο εξηγεί τι είναι στην πραγματικότητα το salting, πώς λειτουργεί στην πράξη, από τι προστατεύει και από τι δεν προστατεύει και τι συνιστά το OWASP ως προεπιλογή για το 2026.

Τι είναι το salting στην ασφάλεια και τον κατακερματισμό κωδικών πρόσβασης

Περιορίστε το θέμα σε μία πρόταση. Η προσθήκη τυχαίων δεδομένων σε έναν κωδικό πρόσβασης πριν αυτός ο κωδικός πρόσβασης κατακερματιστεί. Η τυχαία τιμή - το salt - δημιουργείται μία φορά ανά λογαριασμό όταν το salt δημιουργείται παράλληλα με το νέο hash κωδικού πρόσβασης, αποθηκεύεται στο clear δίπλα στο hash που προκύπτει και διαβάζεται ξανά σε κάθε σύνδεση. Δεν είναι κλειδί. Ούτε μυστικό. Ούτε κρυπτογράφηση. Ένας δημόσιος τροποποιητής με ακριβώς μία δουλειά: να διασφαλίζει ότι όταν δύο χρήστες έχουν τον ίδιο κωδικό πρόσβασης, δεν μοιράζονται ποτέ τον ίδιο αποθηκευμένο hash κωδικό πρόσβασης.

Το hashing από μόνο του είναι μονόδρομο. Περνώντας έναν κωδικό πρόσβασης μέσω του SHA-256 ή του Argon2id, λαμβάνετε μια τιμή σταθερού μήκους που κανένας αλγόριθμος δεν μπορεί να αντιστρέψει. Το πρόβλημα είναι ότι "κανένας αλγόριθμος" δεν αποκλείει μια φθηνή συντόμευση — αναζητώντας το hash σε ένα προ-υπολογισμένο λεξικό. Το Salting κλείνει αυτήν τη συντόμευση. Η προσθήκη ενός salt στη διαδικασία hashing δημιουργεί ένα μοναδικό hash για κάθε χρήστη, ακόμα και όταν το υποκείμενο κείμενο του κωδικού πρόσβασής του είναι λέξη προς λέξη πανομοιότυπο. Συνήθεις κωδικοί πρόσβασης όπως "password" και "qwerty" δεν συγκρούονται πλέον στη βάση δεδομένων. Το Salting διασφαλίζει ότι η διαρροή μιας γραμμής δεν λέει τίποτα στον εισβολέα για κανέναν άλλο.

Τρεις κανόνες διαχωρίζουν ένα χρησιμοποιήσιμο salt από ένα άχρηστο. Πρώτος κανόνας: κάθε κωδικός πρόσβασης λαμβάνει το δικό του τυχαίο salt, που δημιουργείται πρόσφατα όταν ο χρήστης εγγράφεται ή επαναφέρει τον κωδικό του. Ένας κωδικός πρόσβασης salt που επαναχρησιμοποιείται σε διάφορους λογαριασμούς δεν είναι καλύτερος από έναν μη αλατισμένο κωδικό πρόσβασης — η μαζική επίθεση λειτουργεί με τον ίδιο τρόπο. Δεύτερος κανόνας: το salt μπορεί να είναι δημόσιο. Η γνώση του salt από μόνη της δίνει στον εισβολέα μηδενική συντόμευση έναντι της υποκείμενης συνάρτησης κατακερματισμού. Έτσι, το salt βρίσκεται στη βάση δεδομένων δίπλα στο hash, και αυτή η τοποθέτηση είναι καλή, ακόμη και ενθαρρύνεται. Τρίτος κανόνας: οι τιμές salt προέρχονται από μια κρυπτογραφικά ασφαλή γεννήτρια ψευδοτυχαίων αριθμών. Το Linux εκθέτει μία μέσω του `getrandom(2)`. Το Node το ονομάζει `crypto.randomBytes`. Η τυπική βιβλιοθήκη της Python την τυλίγει σε `secrets.token_bytes`. Το μη κρυπτογραφικό `Math.random()` είναι ακατάλληλο, παρόλο που εμφανίζεται σε πραγματικό ελεγμένο κώδικα πολύ πιο συχνά από ό,τι θα έπρεπε.

Δύο άτομα που επιλέγουν το "hunter2" ως κωδικό πρόσβασής τους θα πρέπει να έχουν δύο εντελώς διαφορετικά αποθηκευμένα hashes. Το Salting είναι αυτό που το κάνει να συμβαίνει αυτό. Παραλείψτε το salt και η βάση δεδομένων θα διαρρεύσει όχι μόνο τα hashes, αλλά και το κοινωνικό γράφημα του ποιος μοιράζεται ποιον κωδικό πρόσβασης με ποιον.

Πώς λειτουργεί η προσθήκη κωδικού πρόσβασης

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

Το πρώτο βήμα εκτελείται κατά την εγγραφή. Η εφαρμογή ζητά από ένα CSPRNG δεκαέξι έως τριάντα δύο τυχαία byte. Αυτό είναι το αλάτι. Οι οδηγίες του OWASP για το 2025 αντιμετωπίζουν τα δεκαέξι byte (128 bit) ως το κατώτατο όριο. Το auth0 και αρκετοί προμηθευτές διαχειριστή κωδικών πρόσβασης συνιστούν να φτάσουμε στα τριάντα δύο. Το SP 800-63B-4 του NIST ορίζει ένα ελάχιστο όριο τεσσάρων byte, αλλά προειδοποιεί ότι οι συγκρούσεις που σχετίζονται με γενέθλια αρχίζουν να εμφανίζονται σε περίπου εξήντα πέντε χιλιάδες χρήστες σε αυτό το μέγεθος, γι' αυτό και κανείς δεν χρησιμοποιεί στην πραγματικότητα τέσσερα byte.

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

Το τρίτο βήμα εκτελεί τη συνδυασμένη είσοδο μέσω ενός αλγορίθμου κατακερματισμού κωδικών πρόσβασης — αυτό που τα εγχειρίδια κρυπτογραφίας ονομάζουν συνάρτηση παράγωγης κλειδιού ή KDF. Αυτό είναι το βήμα όπου οι περισσότερες ομάδες συνήθιζαν να αποτυγχάνουν, συχνά καταφεύγοντας σε έναν γενικό αλγόριθμο κατακερματισμού και θεωρώντας την εργασία ολοκληρωμένη. Το απλό SHA-256 είναι ακατάλληλο ως τρόπος αποθήκευσης κωδικών πρόσβασης από μόνο του. Μια GPU καταναλωτή το 2026 εκτελεί κύκλο μέσω πάνω από εκατό δισεκατομμύρια κατακερματισμών SHA-256 ανά δευτερόλεπτο, επομένως ακόμη και με ένα salt, το κόστος ανά εικασία στο κρυπτογραφικό hashing παραμένει ασήμαντο. Το salting σκοτώνει τους φορείς επίθεσης πίνακα ουράνιου τόξου. Δεν επιβραδύνει το σπάσιμο κωδικών πρόσβασης με ωμή βία από μόνο του. Το σωστό εργαλείο εδώ είναι μια σκόπιμα αργή, σκληρή με μνήμη συνάρτηση: Το Argon2id είναι η προεπιλογή που προτιμάται από το OWASP, με αποδεκτά τα scrypt και bcrypt, και το PBKDF2 με πολύ υψηλούς αριθμούς επαναλήψεων που επιτρέπονται όπου η συμμόρφωση με το FIPS-140 επιβάλλει την επιλογή.

Το τέταρτο βήμα αποθηκεύει τόσο το hash όσο και το salt. Οι σύγχρονες βιβλιοθήκες χειρίζονται τη μορφή αποθήκευσης, επομένως δεν χρειάζεται να διαχειρίζεστε το αποθηκευμένο salt χειροκίνητα. Μια έξοδος bcrypt μοιάζει με `$2b$12$9f4c8a7b...kQR8YZpL9` — αυτή η μοναδική συμβολοσειρά φέρει το αναγνωριστικό αλγορίθμου, τον παράγοντα κόστους, το salt και την τιμή hash. Το Argon2id χρησιμοποιεί την ανάλογη μορφή συμβολοσειράς PHC, `$argon2id$v=19$m=19456,t=2,p=1$$`. Γράφετε αυτήν τη συμβολοσειρά σε μια στήλη βάσης δεδομένων και αποχωρείτε. Η βιβλιοθήκη έχει κάνει ό,τι χρειάζεται για να αποθηκεύσει τους κωδικούς πρόσβασης με ασφάλεια — έχει δημιουργήσει τυχαία δεδομένα για το salt, έχει εκτελέσει τον κωδικό πρόσβασης μέσω ενός αργού αλγορίθμου hash και έχει ομαδοποιήσει το αποτέλεσμα για ανάκτηση.

Η σύνδεση ακολουθεί την ίδια διαδικασία αντίστροφα. Η εφαρμογή αναζητά το salt και το αποθηκευμένο hash του χρήστη, εκτελεί τον υποβληθέντα κωδικό πρόσβασης μέσω του ίδιου αλγορίθμου με το ίδιο salt και συγκρίνει το αποτέλεσμα με το αποθηκευμένο hash χρησιμοποιώντας μια σύγκριση σταθερού χρόνου. Ο σταθερός χρόνος έχει σημασία: μια αφελής `==` διαρρέει πληροφορίες σχετικά με το πόσα byte ταιριάζουν, γεγονός που έχει δημιουργήσει ευπάθειες σε επιθέσεις πραγματικού χρονισμού. Χρησιμοποιήστε `hmac.compare_digest`, `crypto.timingSafeEqual` ή το αντίστοιχο του framework σας.

Γιατί το αλάτισμα έχει σημασία: το πρόβλημα του ουράνιου τόξου στο τραπέζι

Οι πίνακες Rainbow είναι η συγκεκριμένη επίθεση για την οποία εφευρέθηκε το salting. Φανταστείτε έναν προυπολογισμένο πίνακα αναζήτησης που αντιστοιχίζει κάθε πιθανό κωδικό πρόσβασης - κάθε λέξη λεξικού, κοινή παραλλαγή, καταχώρηση σε λίστα που έχει διαρρεύσει - στο hash SHA-256 του. Αυτοί οι πίνακες υπάρχουν, πωλούνται σε φόρουμ cracking και εκτελούνται σε terabytes. Μόλις ένας εισβολέας κατέχει μια βάση δεδομένων με μη αλατισμένα hashes, η αναζήτηση ενός hashes σε έναν πίνακα rainbow είναι ένα ερώτημα βάσης δεδομένων, όχι μια εργασία cracking. Το LinkedIn το 2012 πήγε ακριβώς ως εξής: 117 εκατομμύρια μη αλατισμένα hashes SHA-1 σε έναν πίνακα rainbow, το ενενήντα τοις εκατό έσπασε σε περίπου τρεις ημέρες.

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

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

Τι μετριάζει αξιόπιστα το salting: τους πίνακες rainbow και τη διαρροή πληροφοριών επαναχρησιμοποίησης κωδικών πρόσβασης μεταξύ χρηστών στην ίδια βάση δεδομένων. Τι μετριάζει το αργό hashing: το κόστος ανά εικασία. Τι μετριάζει το pepper: την κλοπή μόνο της βάσης δεδομένων. Τι μετριάζει το MFA: την υπερφόρτωση διαπιστευτηρίων. Το salting είναι ένα επίπεδο ασφάλειας σε μια στοίβα — η προσθήκη ενός salt για την πιο δύσκολη παραβίαση των κωδικών πρόσβασης δεν είναι το ίδιο με το να γίνεται κάθε κωδικός πρόσβασης ξεχωριστά δύσκολος στην μαντεία. Ένας διαφορετικός hash για κάθε χρήστη είναι ο στόχος που επιτυγχάνει το salting. Το να γίνεται κάθε εικασία ακριβή είναι ένα ξεχωριστό πρόβλημα.

Κατακερματισμός έναντι κρυπτογράφησης έναντι αλάτισης

Τρεις όροι που συγχέονται, ειδικά σε κείμενα από μη ειδικούς. Δεν είναι εναλλάξιμοι.

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

Η παραβίαση της Adobe το 2013 αποτελεί το προειδοποιητικό παράδειγμα εδώ. Η Adobe αποθήκευσε 153 εκατομμύρια αρχεία χρηστών κρυπτογραφώντας κωδικούς πρόσβασης με 3DES σε λειτουργία ECB με ένα μόνο κλειδί σε ολόκληρο τον ιστότοπο. Αυτή η επιλογή ήταν μια τριπλή αποτυχία. Η κρυπτογράφηση είναι το λάθος πρωτόγονο για την αποθήκευση κωδικών πρόσβασης. Η λειτουργία ECB διαρρέει πανομοιότυπες εισόδους ως πανομοιότυπες εξόδους. Η επαναχρησιμοποίηση ενός κλειδιού σε ολόκληρη τη βάση δεδομένων σήμαινε ότι η αποκωδικοποίηση του κλειδιού κάποτε αποκωδικοποίησε και τα 153 εκατομμύρια αρχεία. Ο Schneier το χαρακτήρισε ως μία από τις χειρότερες παραβιάσεις κωδικών πρόσβασης στην ιστορία. Η λύση σε κάθε επίπεδο ήταν η μετάβαση σε αλατισμένο, αργό κατακερματισμό.

Αλάτι εναντίον πιπεριού: η άμυνα δύο επιπέδων

Το Pepper είναι ο λιγότερο γνωστός ξάδερφος του Salt. Η έννοια: μια πρόσθετη μυστική τιμή, που εφαρμόζεται σε κάθε κωδικό πρόσβασης που επεξεργάζεται η εφαρμογή, αλλά αποθηκεύεται εκτός της βάσης δεδομένων. Μια μεταβλητή περιβάλλοντος, μια καταχώρηση υπηρεσίας διαχείρισης κλειδιών ή ένα κλειδί που βρίσκεται στο HSM. Το Salt βρίσκεται δίπλα στο hash σε απλό κείμενο. Το Pepper όχι.

Το μοντέλο απειλής είναι η κλοπή μόνο της βάσης δεδομένων. Εάν ένας εισβολέας κλέψει μόνο τη βάση δεδομένων — μέσω SQL injection, ενός λανθασμένα διαμορφωμένου αντιγράφου ασφαλείας ή μιας διαρροής dump — έχει salts και hashes αλλά όχι το pepper. Χωρίς το pepper, δεν μπορεί καν να ξεκινήσει brute-force επειδή κάθε εικασία που κατακερματίζει λείπει ο καθολικός τροποποιητής μυστικού.

Μια τυπική υλοποίηση εκτελεί την εντολή `argon2id(salt + password + pepper)` ή, πιο προσεκτικά, υπολογίζει πρώτα την εντολή `HMAC(pepper, password + salt)` και τροφοδοτεί το αποτέλεσμα στο Argon2id. Το OWASP συνιστά το pepper για συστήματα υψηλής αξίας, αλλά αναγνωρίζει το μειονέκτημα: η εναλλαγή του pepper είναι λειτουργικά επώδυνη. Η εναλλαγή του σημαίνει επανάληψη του κωδικού πρόσβασης κάθε χρήστη στην επόμενη σύνδεση και, εάν το pepper χαθεί ποτέ χωρίς αντίγραφο ασφαλείας, κάθε λογαριασμός καθίσταται μη ελεγμένος. Οι περισσότερες εφαρμογές καταναλωτών παραλείπουν το pepper. Οι φόρτοι εργασίας των τραπεζών, της κυβέρνησης και της υγειονομικής περίθαλψης συνήθως δεν το κάνουν.

Σύγχρονος κατακερματισμός κωδικών πρόσβασης το 2026

Οι οδηγίες αποθήκευσης κωδικών πρόσβασης του OWASP για το 2025 κατατάσσουν τέσσερις αλγόριθμους κατά σειρά προτίμησης. Το Salt είναι ενσωματωμένο σε όλους τους αλγόριθμους — δεν το δημιουργείτε χειροκίνητα.

Το Argon2id απαιτεί μεγάλη μνήμη, που σημαίνει ότι κάθε πρόβλεψη δεν κοστίζει μόνο κύκλους CPU αλλά και ένα καθορισμένο κομμάτι RAM. Το ελάχιστο OWASP των 19 MiB ανά hash σημαίνει ότι ένας εισβολέας που κατασκευάζει ένα προσαρμοσμένο ASIC πρέπει επίσης να δημιουργήσει πολλή γρήγορη μνήμη, και η μνήμη είναι το ακριβό μέρος κάθε συστήματος. Η παραλλαγή "id" συνδυάζει το Argon2i (ανθεκτικό στα πλευρικά κανάλια) και το Argon2d (ανθεκτικό στην GPU) εκτελώντας το Argon2i για το πρώτο μισό και το Argon2d για το δεύτερο.

Το scrypt προηγείται του Argon2id και λειτουργεί με την ίδια αρχή σκληρότητας μνήμης. Το bcrypt είναι ακόμη παλαιότερο, απλούστερο και έχει ένα σκληρό όριο εισόδου 72 byte που περιστασιακά διακόπτει εφαρμογές που χρησιμοποιούν μεγάλες φράσεις πρόσβασης — pre-hash με SHA-256 και base64-encode εάν χρειάζεστε μεγαλύτερες εισόδους. Το PBKDF2 είναι η αργή αλλά συμβατή με FIPS επιλογή. Το OWASP αύξησε τον αριθμό επαναλήψεων σε 600.000 για το SHA-256 το 2023, από 310.000.

Τι δεν ανήκει σε αυτήν τη λίστα: το απλό SHA-256, το απλό SHA-512, το MD5, το SHA-1 και οποιαδήποτε προσαρμοσμένη συνάρτηση που τελειώνει σε "+ salt". Η ταχύτητα είναι ο αποκλεισμός. Το SHA-256 σχεδιάστηκε για να είναι γρήγορο σε συμβατικό υλικό. Αυτό είναι το αντίθετο από αυτό που χρειάζεται η αποθήκευση κωδικών πρόσβασης.

Συνηθισμένα λάθη στο αλάτισμα που εμφανίζονται σε πραγματικούς ελέγχους

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

Η επαναχρησιμοποίηση ενός αλατιού (salt) για κάθε χρήστη ακυρώνει ολόκληρο τον μηχανισμό — το πρόβλημα του πίνακα ουράνιου τόξου επιστρέφει, μόνο με ένα επιπλέον βήμα. Η χρήση του ονόματος χρήστη ως αλατιού (salt) είναι χειρότερη, επειδή τα ονόματα χρήστη επαναλαμβάνονται σε όλα τα συστήματα και οι πίνακες ουράνιου τόξου μπορούν να υπολογιστούν εκ των προτέρων για τα δημοφιλή. Μήκη αλατιού κάτω των δεκαέξι byte αρχίζουν να δέχονται συγκρούσεις στην κλίμακα μεγάλων βάσεων χρηστών. Η δημιουργία αλατιού (salt) με μια μη κρυπτογραφική τυχαία συνάρτηση — `Math.random()`, `time(0)` mod something, το προεπιλεγμένο RNG της γλώσσας — παράγει προβλέψιμες τιμές που αφαιρούν το αλατισμό από το πλεονέκτημά του.

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

Η μεγαλύτερη, σε ελέγχους του 2026, είναι το hashing με απλό SHA-256 συν salt και shipping. Το salt αποτρέπει τους πίνακες rainbow. Δεν κάνει τίποτα σε ένα GPU compar που εκτελεί δέκα δισεκατομμύρια εικασίες ανά δευτερόλεπτο σε έναν μόνο λογαριασμό. Η λύση δεν είναι η προσθήκη ενός δεύτερου salt. είναι η μετάβαση σε ένα αργό KDF όπως το Argon2id.

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

Γιατί το αλάτισμα από μόνο του δεν είναι αρκετό

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

Η πραγματική ασφάλεια κωδικών πρόσβασης το 2026 συνδυάζει τέσσερις άμυνες. Το Argon2id με ένα salt δεκαέξι byte ανά χρήστη χειρίζεται τον χώρο αποθήκευσης. Ένα pepper, προαιρετικό αλλά χρήσιμο για ευαίσθητα συστήματα, εμποδίζει την κλοπή μόνο της βάσης δεδομένων. Ο έλεγχος ταυτότητας πολλαπλών παραγόντων εμποδίζει την παραβίαση διαπιστευτηρίων και το μεγαλύτερο μέρος του ηλεκτρονικού "ψαρέματος" (phishing). Η συνεχής παρακολούθηση παραβιάσεων — υπηρεσίες όπως το Have I Been Pwned και το API του — καταγράφει τη στιγμή που τα διαπιστευτήρια ενός χρήστη εμφανίζονται σε μια διαρροή, ώστε να μπορεί να αναγκαστεί να κάνει επαναφορά.

Παραλείψτε οποιοδήποτε από αυτά τα επίπεδα και ένας εισβολέας τελικά θα βρει το κενό. Το Salting μόνο του, ή οποιαδήποτε άμυνα μόνο του, είναι ακριβώς αυτό που κάθε παραβίαση μετά θάνατον την τελευταία δεκαετία έχει εντοπίσει ως σημείο αποτυχίας.

Jordan Morris

Jordan Morris is an AI expert with over a decade of experience and the author of a widely-read blog focused on artificial intelligence. His content spans a range of topics—from the ethics of machine learning to real-world applications of neural networks in business. Known for his clear writing and deep insights, Jordan has become a trusted voice in the AI community, appealing to both newcomers and seasoned professionals alike.