Nuo ko iš tikrųjų apsaugo slaptažodžio maišavimas

Trumpai

Slaptažodžio maišavimas apsaugo naudotojus tada, kai pavagiama jūsų slaptažodžių duomenų bazė.

Tai yra pagrindinė jo paskirtis. Ne vienintelė detalė, ne visas saugumo modelis, bet centrinė priežastis, kodėl slaptažodžius maišome, o ne saugome tiesiogiai.

Tinkamai sumaišytą slaptažodį sunku atkurti. Jei užpuolikas gauna jūsų naudotojų lentelės kopiją, jis neturėtų iš karto sužinoti, kad Alice slaptažodis yra Spring2026!. Vietoj to jis gauna saugomą maišą, kurios tikrinimas pagal spėjimus reikalauja laiko, pinigų ir aparatinės įrangos.

Šis skirtumas svarbus. Slaptažodžių maišavimas nėra skirtas vienas pats padaryti prisijungimą saugų. Jis nesustabdo sukčiavimo. Jis nesustabdo žmogaus, bandančio nutekintus slaptažodžius jūsų prisijungimo formoje. Jis neapsaugo sesijos slapuko po prisijungimo. Jis laimi laiko ir sumažina žalą po labai konkrečios nesėkmės: tampa atskleista jūsų slaptažodžių tikrintuvų saugykla.

Jei suprasite šią ribą, priimsite geresnius sprendimus dėl algoritmų, darbo sąnaudų, slaptažodžių atkūrimo, žurnalų ir reagavimo į incidentus.

Kas yra slaptažodžio maiša

Slaptažodžio maiša yra vienkryptės funkcijos, pritaikytos slaptažodžiui, rezultatas, paprastai naudojant unikalią druską ir sąmoningai lėtą slaptažodžių maišavimo algoritmą.

Kai naudotojas susikuria paskyrą, sistema turėtų maždaug atlikti tai:

1. Gauti slaptažodį per HTTPS.
2. Sugeneruoti atsitiktinę, unikalią druską.
3. Paleisti slaptažodį ir druską per slaptažodžių maišavimo funkciją, pvz., Argon2id, bcrypt, scrypt arba PBKDF2.
4. Išsaugoti algoritmo pavadinimą, parametrus, druską ir gautą maišą.
5. Išmesti pradinį slaptažodį.

Kai naudotojas vėliau prisijungia, sistema pakartoja tą patį maišavimo procesą su pateiktu slaptažodžiu ir saugomais parametrais. Jei gauta maiša sutampa su saugoma maiša, prisijungimas pavyksta.

Svarbiausia: programai nereikia žinoti pradinio slaptažodžio. Jai reikia tik patikrinti, ar pateiktas slaptažodis sukuria tikėtiną rezultatą.

Štai kodėl slaptažodžių saugojimas naudojant grįžtamąjį šifravimą paprastai yra netinkamas modelis. Jei jūsų programa gali iššifruoti kiekvieną slaptažodį, tą patį gali padaryti bet kas, pavogęs iššifravimo raktą. Slaptažodžiai paprastai turėtų būti nepatikrinami atgaline kryptimi, o ne vien paslėpti.

Nuo ko apsaugo maišavimas

1. Tiesioginis slaptažodžių atskleidimas po duomenų bazės pažeidimo

Jei užpuolikas pavagia duomenų bazę su atvirojo teksto slaptažodžiais, žala yra akimirksniu. Atskleidžiami visi slaptažodžiai. Naudotojai rizikuoja ne tik jūsų svetainėje, bet ir visur, kur pakartotinai naudojo tą slaptažodį.

Jei duomenų bazėje yra gerai sumaišyti slaptažodžiai, užpuolikui reikia atlikti daugiau darbo. Jis turi spėti kandidatinius slaptažodžius, kiekvieną spėjimą sumaišyti su teisinga druska ir parametrais, tada palyginti rezultatą.

Silpniems slaptažodžiams tai vis tiek gali būti greita. Stipriems unikaliems slaptažodžiams tai gali būti nepraktiška.

Maišavimas katastrofišką atskleidimą paverčia lenktynėmis: ar naudotojai spės pasikeisti slaptažodžius ir ar jūs suvaldysite incidentą prieš užpuolikams nulaužiant daugelį jų?

Tai nėra tobula. Tai vis tiek yra pažeidimas. Tačiau tai gerokai geresnis nesėkmės scenarijus.

2. Masinės atakos prieš visą jūsų naudotojų bazę

Druskos yra esminė slaptažodžių saugojimo dalis, nes jos neleidžia užpuolikams efektyviai atakuoti daugelio naudotojų vienu metu naudojant iš anksto apskaičiuotas lenteles.

Druska nėra slapta. Ji saugoma kartu su maiša. Jos paskirtis yra unikalumas.

Jei du naudotojai pasirenka tą patį slaptažodį, unikalios druskos užtikrina, kad jų saugomos maišos skirtųsi. Tai neleidžia užpuolikams iš pirmo žvilgsnio matyti, kad daugelis naudotojų turi tą patį slaptažodį. Tai taip pat apsaugo nuo klasikinių rainbow table atakų, kai užpuolikai naudoja didžiulius iš anksto apskaičiuotus slaptažodžių ir maišų atitikmenų sąrašus.

Be druskų viena nulaužta maiša gali atskleisti kiekvieną naudotoją su tuo pačiu slaptažodžiu. Su druskomis kiekvienas slaptažodžio spėjimas turi būti tikrinamas atskirai kiekvienam naudotojui.

3. Greitas spėliojimas neprisijungus

Kai užpuolikai turi slaptažodžių duomenų bazę, jie gali spėlioti neprisijungę. Tai reiškia, kad jūsų prisijungimo dažnio ribojimai, CAPTCHA, IP blokavimas ir stebėsena nebeturi reikšmės. Užpuolikas gali tikrinti spėjimus savo aparatinėje įrangoje.

Čia svarbus algoritmo pasirinkimas.

Bendros paskirties maišos, tokios kaip SHA-256 ir SHA-512, sukurtos būti greitos. Tai gerai failų vientisumui ir skaitmeniniams parašams. Tai blogai slaptažodžių saugojimui.

Slaptažodžių maišavimo algoritmai sukurti būti lėti, derinami ir kartais reikalaujantys daug atminties. Argon2id, bcrypt, scrypt ir PBKDF2 leidžia reguliuoti sąnaudų parametrus taip, kad kiekvienas spėjimas užtruktų reikšmingą laiką.

Argon2id plačiai rekomenduojamas naujoms sistemoms, nes jį galima sukonfigūruoti taip, kad reikėtų ir CPU laiko, ir atminties, todėl didelio masto nulaužimas naudojant GPU tampa brangesnis. bcrypt išlieka paplitęs ir priimtinas, kai yra gerai sukonfigūruotas, nors turi apribojimų, pavyzdžiui, dėl slaptažodžio ilgio tvarkymo. PBKDF2 vis dar naudojamas kai kuriose atitikties reikalavimų valdomose aplinkose, ypač ten, kur būtini FIPS patvirtinti komponentai.

Principas paprastas: teisėti prisijungimai turi būti priimtinai greiti, o milijardai spėjimų — brangūs.

Nuo ko maišavimas neapsaugo

1. Sukčiavimas

Jei naudotojas įveda savo slaptažodį netikrame prisijungimo puslapyje, maišavimas jūsų serveryje nepadės. Užpuolikas gauna slaptažodį dar prieš jūsų sistemai jį pamatant.

Apsaugos priemonės čia yra kitokios: daugiafaktorinis autentifikavimas, passkeys, naudotojų švietimas, domenų higiena, sukčiavimui atsparus autentifikavimas ir apgalvoti slaptažodžio atkūrimo srautai.

Slaptažodžių maišavimas yra atsarginė apsauga saugomoms paslaptims. Tai nėra gynyba nuo naudotojų apgaulės, kai jie patys atiduoda tas paslaptis.

2. Credential stuffing

Credential stuffing vyksta tada, kai užpuolikai paima iš vienos paslaugos nutekintas naudotojo vardo ir slaptažodžio poras ir bando jas kitoje.

Jūsų slaptažodžių maišos gali būti puikios, o credential stuffing vis tiek gali suveikti, jei naudotojai pakartotinai naudoja slaptažodžius.

Tai internetinė ataka prieš jūsų prisijungimo formą, o ne neprisijungus vykdoma ataka prieš jūsų duomenų bazę. Jums reikia dažnio ribojimo, anomalijų aptikimo, nutekintų slaptažodžių tikrinimo, MFA ir protingų blokavimo politikų, kurios nesukurtų lengvų paslaugos trikdymo galimybių.

Tas pats praktinis mąstymas taikomas bet kuriai viešai formai. Jei peržiūrite savo autentifikavimo paviršių, verta paskaityti, kodėl jūsų kontaktų forma yra didžiausia jūsų šlamšto rizika; mechanika skiriasi, bet pamoka panaši: viešoms įvestims reikia piktnaudžiavimo kontrolės, o ne vien švaraus backend kodo.

3. Slaptažodžiai, užfiksuoti žurnaluose ar analitikoje

Maišavimas padeda tik tada, jei atvirojo teksto slaptažodis greitai išmetamas ir niekur kitur nenukopijuojamas.

Dažnos klaidos:

• Pilnų užklausų kūnų žurnalavimas po nepavykusių prisijungimo bandymų.
• Slaptažodžių siuntimas į klaidų stebėsenos įrankius.
• Slaptažodžio laukų fiksavimas sesijų atkūrimo produktuose.
• Prisijungimo duomenų įtraukimas į URL per prastai suprojektuotus atkūrimo ar migracijos srautus.
• Laikinų atvirojo teksto slaptažodžių saugojimas importavimo metu.

Šios klaidos visiškai apeina slaptažodžių maišavimą. Jei atvirasis tekstas patenka į žurnalus, atsargines kopijas, duomenų saugyklas ar trečiųjų šalių įrankius, jūsų maišos funkcija tampa nereikšminga.

Slaptažodžių laukus laikykite toksiškais duomenimis. Užmaskuokite juos prieš žurnalavimą. Neįtraukite jų į analitiką. Nelaikykite jų URL. Apribokite, kas gali pasiekti produkcijos trasas.

4. Prasta sesijų sauga

Po prisijungimo naudotojo naršyklė paprastai gauna sesijos slapuką arba žetoną. Jei tas žetonas pavagiamas, užpuolikui slaptažodžio gali visai neprireikti.

Slaptažodžių maišavimas neapsaugo nuo cross-site scripting, nesaugių slapukų, sesijos fiksavimo, silpno žetonų generavimo ar per ilgų sesijų galiojimo laikų.

Sesijos slapukai nusipelno atskiros peržiūros: HttpOnly, Secure, tinkamas SameSite, trumpaamžės didelės rizikos sesijos ir serverio pusės panaikinimas pakeitus slaptažodį. Platesnis privatumo ir naršyklių kontekstas taip pat nuolat keičiasi, kaip aprašyta straipsnyje kas pasikeitė slapukams 2026 m..

5. Silpnas slaptažodžio atkūrimas ir paskyros susigrąžinimas

Daugelis paskyrų perėmimų neprasideda nuo slaptažodžio. Jie prasideda nuo atkūrimo srauto.

Jei atkūrimo žetonai yra nuspėjami, ilgai galiojantys, nutekinami per referrer antraštes arba siunčiami į kompromituotas el. pašto paskyras, slaptažodžių maišavimas jūsų neišgelbės.

Naudokite didelės entropijos atkūrimo žetonus, trumpus galiojimo langus, vienkartinį naudojimą ir aiškius pranešimus naudotojams. Kadangi el. paštas dažnai yra atkūrimo kanalas, bazinis domeno autentifikavimas taip pat svarbus. Jei jūsų komanda DNS įrašus laiko paslaptingu ritualu, pradėkite nuo programuotojams draugiškos MX, SPF, DKIM ir DMARC apžvalgos.

Algoritmo pasirinkimas: ką naudoti dabar

Naujoms programoms naudokite Argon2id, jei jūsų platforma jį gerai palaiko. Jis yra Password Hashing Competition laimėtojas ir sukurtas slaptažodžių saugojimui, įskaitant atsparumą GPU intensyviam nulaužimui.

Protinga šiuolaikinė hierarchija atrodo taip:

1. Argon2id naujoms sistemoms, kur jis prieinamas.
2. bcrypt, kai Argon2id nepraktiškas, o bcrypt palaikymas brandus.
3. scrypt, kai gerai palaikoma daug atminties reikalaujanti konfigūracija.
4. PBKDF2, kai to reikalauja platformos ar atitikties apribojimai.

Venkite paprasto SHA-256, SHA-512, MD5 arba savadarbio derinio, pavyzdžiui, sha256(password + salt). Greitos maišos nėra slaptažodžių saugojimo funkcijos. Gudrios nestandartinės konstrukcijos paprastai būna blogesnės už nuobodžias standartines.

Taip pat nekurkite savo slaptažodžių politikos pagal algoritmų smulkmenas. Naudotojams nenaudinga 12 taisyklių slaptažodžio sudėties atmintinė, jei ji stumia juos link nuspėjamų šablonų. Ilgesni unikalūs slaptažodžiai, slaptažodžių tvarkyklės, nutekintų slaptažodžių tikrinimas ir MFA paprastai yra svarbesni.

Sąnaudų parametrai nėra nustatomi visam laikui

Slaptažodžių maišavimas turi parametrų. Argon2id turi atmintį, iteracijas ir lygiagretumą. bcrypt turi sąnaudų koeficientą. PBKDF2 turi iteracijų skaičių.

Šias reikšmes reikia pasirinkti pagal jūsų produkcijos aplinką. Per mažos — ir užpuolikai spėlios pigiai. Per didelės — ir jūsų prisijungimo sistema taps lėta arba pažeidžiama paslaugos trikdymui.

Praktinis tikslas dažnai yra nuo kelių dešimčių iki kelių šimtų milisekundžių vienam slaptažodžio patikrinimui jūsų tikruose serveriuose, priklausomai nuo srauto ir rizikos. Aukšto saugumo sistemos gali rinktis daugiau. Vartotojų masto sistemoms gali reikėti kruopštaus pajėgumų planavimo.

Nekopijuokite sąnaudų koeficiento iš penkerių metų senumo tinklaraščio įrašo. Aparatinė įranga keičiasi. Bibliotekos keičiasi. Jūsų srautas keičiasi.

Periodiškai peržiūrėkite parametrus ir planuokite pakartotinį maišavimą. Dažnas modelis — saugoti algoritmą ir parametrus kartu su kiekviena maiša. Sėkmingo prisijungimo metu, jei saugomi parametrai pasenę, pateiktas slaptažodis iš naujo sumaišomas su naujesne konfigūracija ir įrašas atnaujinamas.

Pipirai: naudingi, bet ne pakaitalas

Pipiras yra slapta reikšmė, pridedama prie slaptažodžių maišavimo proceso ir saugoma atskirai nuo duomenų bazės, dažnai paslapčių tvarkyklėje arba aparatinės saugos modulyje.

Skirtingai nei druska, pipiras turi likti slaptas.

Pipirai gali sumažinti žalą, jei nuteka duomenų bazė, bet programos paslaptys nenuteka. Jie naudingiausi brandžiose aplinkose su gera raktų valdymo praktika. Jie mažiau naudingi, jei tas pats užpuolikas gali pavogti ir duomenų bazę, ir programos konfigūraciją.

Jei naudojate pipirą, kruopščiai suplanuokite rotaciją. Jo keitimas gali pareikalauti, kad naudotojai vėl prisijungtų arba pasikeistų slaptažodžius, priklausomai nuo dizaino. Pipiras yra papildomas sluoksnis, o ne priežastis silpninti pagrindinės maišos nustatymus.

Operacinis kontrolinis sąrašas

Jei esate atsakingi už tikrą sistemą, praktinis kontrolinis sąrašas trumpas:

• Slaptažodžius saugokite tik su standartiniu slaptažodžių maišavimo algoritmu.
• Kiekvienam slaptažodžiui naudokite unikalią atsitiktinę druską.
• Naujiems kūrimams teikite pirmenybę Argon2id.
• Sąnaudų parametrus derinkite produkcijai panašioje aparatinėje įrangoje.
• Su kiekviena maiša saugokite algoritmą ir parametrus.
• Prisijungimo metu atlikite pakartotinį maišavimą, kai parametrai pasensta.
• Niekada nežurnaluokite slaptažodžių ir nesiųskite jų į analitikos įrankius.
• Visur, kur pateikiami prisijungimo duomenys, naudokite TLS.
• Pridėkite MFA arba passkeys ten, kur rizika tai pateisina.
• Atkūrimo srautus saugokite taip pat rimtai kaip prisijungimo srautus.
• Turėkite incidento planą priverstiniams slaptažodžių keitimams ir naudotojų informavimui.

Slaptažodžių maišavimas nėra žavus. Tai infrastruktūros vamzdynas. Tačiau būtent toks vamzdynas lemia, ar pažeidimas taps skausmingu incidentu, ar katastrofa visiems naudotojams.

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

💡 Išbandykite tai: Su Hash Generator pamatykite, kaip ta pati įvestis susiejama su skirtingais algoritmais, ir aiškiai supraskite skirtumą tarp greitų maišų ir slaptažodžiams tinkamo lygio maišų.

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

Sąžiningas mąstymo modelis

Geriausias būdas galvoti apie slaptažodžių maišavimą yra toks:

Maišavimas neapsaugo slaptažodžio, kol naudotojas jį įveda. Jis neapsaugo paskyros po to, kai naudotojas prisijungia. Jis neapsaugo naudotojų, kurie pakartotinai naudoja slaptažodžius internete.

Jis apsaugo saugomą tikrintuvą.

Tai skamba siaurai, bet yra itin svarbu. Duomenų bazės nuteka. Atsarginės kopijos nuteka. Parengimo aplinkos nukopijuojamos. Tiekėjai gauna prieigą, kurios neturėtų turėti. Seni eksportai objektų saugyklose guli ilgiau, nei kas nors prisimena.

Kai taip nutinka, jūsų slaptažodžių saugojimo dizainas tampa skirtumu tarp to, ar užpuolikai gauna slaptažodžius, ar brangią spėjimo problemą.

Štai nuo ko iš tikrųjų apsaugo slaptažodžio maišavimas.