Od čega vas zapravo štiti hashiranje lozinke

Kratka verzija

Hashiranje lozinke štiti korisnike kada je vaša baza lozinki ukradena.

To je njegova glavna zadaća. Ne jedini detalj, ne cijeli sigurnosni model, nego središnji razlog zašto lozinke hashiramo umjesto da ih izravno pohranjujemo.

Ispravno hashiranu lozinku teško je vratiti u izvorni oblik. Ako napadač dobije kopiju vaše tablice korisnika, ne bi smio odmah saznati da je Alicina lozinka Spring2026!. Umjesto toga dobiva pohranjeni hash koji zahtijeva vrijeme, novac i hardver za provjeru pogodaka.

Ta je razlika važna. Hashiranje lozinki nije namijenjeno tome da samo po sebi učini prijavu sigurnom. Ne zaustavlja phishing. Ne zaustavlja nekoga tko pokušava procurjele lozinke na vašem obrascu za prijavu. Ne štiti sesijski kolačić nakon prijave. Ono kupuje vrijeme i smanjuje štetu nakon vrlo specifičnog neuspjeha: vaša pohrana verifikatora lozinki postane izložena.

Ako razumijete tu granicu, donositi ćete bolje odluke o algoritmima, faktorima rada, resetiranju, zapisnicima i odgovoru na incident.

Što je hash lozinke

Hash lozinke izlaz je jednosmjerne funkcije primijenjene na lozinku, obično uz jedinstveni salt i namjerno spor algoritam za hashiranje lozinki.

Kada korisnik izradi račun, sustav bi otprilike trebao učiniti ovo:

1. Primiti lozinku preko HTTPS-a.
2. Generirati nasumičan, jedinstven salt.
3. Provuci lozinku i salt kroz funkciju za hashiranje lozinki kao što su Argon2id, bcrypt, scrypt ili PBKDF2.
4. Pohraniti naziv algoritma, parametre, salt i dobiveni hash.
5. Odbaciti izvornu lozinku.

Kada se korisnik kasnije prijavi, sustav ponavlja isti postupak hashiranja s poslanom lozinkom i pohranjenim parametrima. Ako dobiveni hash odgovara pohranjenom hashu, prijava uspijeva.

Važan dio: aplikacija ne mora znati izvornu lozinku. Mora samo provjeriti daje li poslana lozinka očekivani rezultat.

Zato je pohranjivanje lozinki reverzibilnom enkripcijom obično pogrešan model. Ako vaša aplikacija može dešifrirati svaku lozinku, isto može učiniti i svatko tko ukrade ključ za dešifriranje. Lozinke bi u pravilu trebale biti neprovjerljive unatrag, a ne samo skrivene.

Od čega vas hashiranje štiti

1. Trenutačno otkrivanje lozinki nakon proboja baze podataka

Ako napadač ukrade bazu podataka koja sadrži lozinke u običnom tekstu, šteta je trenutačna. Svaka je lozinka izložena. Korisnici su ugroženi ne samo na vašoj stranici, nego svugdje gdje su ponovno upotrijebili tu lozinku.

Ako baza podataka sadrži dobro hashirane lozinke, napadač mora uložiti više rada. Mora pogađati moguće lozinke, hashirati svaki pokušaj s ispravnim saltom i parametrima te usporediti rezultat.

Za slabe lozinke to i dalje može biti brzo. Za snažne jedinstvene lozinke može biti nepraktično.

Hashiranje pretvara katastrofalno otkrivanje u utrku: mogu li korisnici resetirati lozinke i možete li obuzdati incident prije nego što napadači razbiju velik broj njih?

To nije savršeno. I dalje je riječ o proboju. Ali to je dramatično bolji način neuspjeha.

2. Masovni napadi na cijelu korisničku bazu

Saltovi su ključan dio pohrane lozinki jer sprječavaju napadače da učinkovito napadaju mnogo korisnika odjednom pomoću unaprijed izračunatih tablica.

Salt nije tajan. Pohranjuje se uz hash. Njegova je zadaća jedinstvenost.

Ako dva korisnika odaberu istu lozinku, jedinstveni saltovi osiguravaju da se njihovi pohranjeni hashevi razlikuju. To sprječava napadače da na prvi pogled vide kako mnogi korisnici dijele istu lozinku. Također sprječava klasične napade rainbow tablicama, u kojima napadači koriste golemo unaprijed izračunate popise preslikavanja lozinki u hasheve.

Bez saltova, jedan razbijeni hash može otkriti svakog korisnika s istom lozinkom. Sa saltovima se svaki pokušaj lozinke mora zasebno testirati za svakog korisnika.

3. Brzo offline pogađanje

Kada napadači imaju bazu lozinki, mogu pogađati offline. To znači da vaša ograničenja učestalosti prijave, CAPTCHA, blokiranje IP adresa i nadzor više nisu bitni. Napadač može testirati pokušaje na vlastitom hardveru.

Tu je izbor algoritma važan.

Hash funkcije opće namjene kao što su SHA-256 i SHA-512 dizajnirane su da budu brze. To je dobro za integritet datoteka i digitalne potpise. Loše je za pohranu lozinki.

Algoritmi za hashiranje lozinki dizajnirani su da budu spori, podesivi i ponekad memorijski zahtjevni. Argon2id, bcrypt, scrypt i PBKDF2 omogućuju podešavanje parametara troška tako da svaki pokušaj traje značajno vrijeme.

Argon2id se široko preporučuje za nove sustave jer se može konfigurirati tako da zahtijeva i CPU vrijeme i memoriju, što poskupljuje GPU razbijanje u velikim razmjerima. bcrypt je i dalje čest i prihvatljiv kada je dobro konfiguriran, iako ima ograničenja poput rukovanja duljinom lozinke. PBKDF2 se još koristi u nekim okruženjima vođenima usklađenošću, osobito ondje gdje su potrebne komponente validirane prema FIPS-u.

Načelo je jednostavno: neka legitimne prijave budu prihvatljivo brze, a milijarde pokušaja skupe.

Od čega vas hashiranje ne štiti

1. Phishing

Ako korisnik upiše svoju lozinku na lažnu stranicu za prijavu, hashiranje na vašem poslužitelju ne pomaže. Napadač prima lozinku prije nego što je vaš sustav uopće vidi.

Obrane su ovdje drukčije: višefaktorska autentikacija, passkeys, edukacija korisnika, higijena domena, autentikacija otporna na phishing i pažljivo osmišljeni tokovi resetiranja lozinke.

Hashiranje lozinki zadnja je zaštita za pohranjene tajne. Nije obrana od toga da korisnici budu prevareni i sami predaju te tajne.

2. Credential stuffing

Credential stuffing događa se kada napadači uzmu parove korisničkih imena i lozinki procurjele s jedne usluge i pokušaju ih na drugoj.

Vaši hashevi lozinki mogu biti izvrsni, a credential stuffing i dalje može uspjeti ako korisnici ponovno upotrebljavaju lozinke.

To je online napad na vaš obrazac za prijavu, a ne offline napad na vašu bazu podataka. Trebate ograničavanje učestalosti, otkrivanje anomalija, provjere kompromitiranih lozinki, MFA i razumna pravila zaključavanja koja ne stvaraju jednostavne prilike za denial-of-service.

Isto praktično razmišljanje vrijedi za svaki izloženi obrazac. Ako pregledavate svoju autentikacijsku površinu, vrijedi pročitati zašto je vaš kontaktni obrazac vaša najveća spam odgovornost; mehanika je drukčija, ali pouka je slična: javni unosi trebaju kontrole protiv zloupotrebe, a ne samo čist backend kod.

3. Lozinke uhvaćene u zapisnicima ili analitici

Hashiranje pomaže samo ako se lozinka u običnom tekstu brzo odbaci i nikada ne kopira drugdje.

Česti propusti uključuju:

• Zapisivanje cijelih tijela zahtjeva pri neuspjelim pokušajima prijave.
• Slanje lozinki alatima za nadzor pogrešaka.
• Snimanje polja za lozinke u proizvodima za ponavljanje sesija.
• Uključivanje vjerodajnica u URL-ove tijekom loše dizajniranih tokova resetiranja ili migracije.
• Pohranjivanje privremenih lozinki u običnom tekstu tijekom uvoza.

Te pogreške u potpunosti zaobilaze hashiranje lozinki. Ako običan tekst završi u zapisnicima, sigurnosnim kopijama, podatkovnim skladištima ili alatima trećih strana, vaša hash funkcija nije relevantna.

Tretirajte polja za lozinke kao toksične podatke. Redigirajte ih prije zapisivanja. Isključite ih iz analitike. Držite ih izvan URL-ova. Ograničite tko može pristupiti produkcijskim tragovima.

4. Loša sigurnost sesija

Nakon prijave korisnikov preglednik obično prima sesijski kolačić ili token. Ako se taj token ukrade, napadaču lozinka možda uopće neće trebati.

Hashiranje lozinki ne štiti od cross-site scriptinga, nesigurnih kolačića, session fixationa, slabog generiranja tokena ili predugih trajanja sesija.

Sesijski kolačići zaslužuju vlastitu provjeru: HttpOnly, Secure, odgovarajući SameSite, kratkotrajne visokorizične sesije i poslužiteljsko poništavanje pri promjeni lozinke. Širi krajolik privatnosti i preglednika također se stalno mijenja, kao što je opisano u članku što se promijenilo za kolačiće u 2026..

5. Slabo resetiranje lozinke i oporavak računa

Mnoga preuzimanja računa ne počinju lozinkom. Počinju tokom resetiranja.

Ako su tokeni za resetiranje predvidljivi, dugotrajni, procure kroz referrer zaglavlja ili se pošalju na kompromitirane račune e-pošte, hashiranje lozinki vas neće spasiti.

Koristite tokene za resetiranje visoke entropije, kratke rokove isteka, jednokratnu upotrebu i jasne obavijesti korisnicima. Budući da je e-pošta često kanal za oporavak, važna je i osnovna autentikacija domene. Ako vaš tim DNS zapise tretira kao tajanstveni obred, počnite s razvojnim obilaskom MX, SPF, DKIM i DMARC zapisa.

Izbor algoritma: što sada koristiti

Za nove aplikacije koristite Argon2id ako ga vaša platforma dobro podržava. Pobjednik je Password Hashing Competitiona i dizajniran je za pohranu lozinki, uključujući otpornost na razbijanje s mnogo GPU resursa.

Razumna moderna hijerarhija izgleda ovako:

1. Argon2id za nove sustave gdje je dostupan.
2. bcrypt kada Argon2id nije praktičan, a podrška za bcrypt je zrela.
3. scrypt kada je memorijski zahtjevna konfiguracija dobro podržana.
4. PBKDF2 gdje to zahtijevaju platforma ili ograničenja usklađenosti.

Izbjegavajte obični SHA-256, SHA-512, MD5 ili vlastitu kombinaciju kao što je sha256(password + salt). Brzi hashevi nisu funkcije za pohranu lozinki. Domišljate vlastite konstrukcije obično su lošije od dosadnih standardnih.

Također izbjegavajte izmišljanje vlastite politike lozinki oko trivijalnosti algoritama. Korisnici nemaju koristi od popisa s 12 pravila za sastav lozinke ako ih to gura prema predvidljivim obrascima. Dulje jedinstvene lozinke, upravitelji lozinki, provjera kompromitiranih lozinki i MFA obično su važniji.

Faktori troška nisu postavi-i-zaboravi

Hashiranje lozinki ima parametre. Argon2id ima memoriju, iteracije i paralelizam. bcrypt ima faktor troška. PBKDF2 ima broj iteracija.

Te vrijednosti treba odabrati na temelju vašeg produkcijskog okruženja. Preniske su i napadači pogađaju jeftino. Previsoke su i vaš sustav prijave postaje spor ili ranjiv na denial-of-service.

Praktična meta često je u rasponu od nekoliko desetaka do nekoliko stotina milisekundi po provjeri lozinke na vašim stvarnim poslužiteljima, ovisno o prometu i riziku. Sustavi visoke sigurnosti mogu odabrati više. Sustavi potrošačkog opsega mogu trebati pažljivo planiranje kapaciteta.

Nemojte kopirati faktor troška iz pet godina starog blog posta. Hardver se mijenja. Biblioteke se mijenjaju. Vaš promet se mijenja.

Periodično pregledavajte parametre i planirajte ponovno hashiranje. Čest obrazac je pohraniti algoritam i parametre uz svaki hash. Pri uspješnoj prijavi, ako su pohranjeni parametri zastarjeli, ponovno hashirajte poslanu lozinku novijom konfiguracijom i ažurirajte zapis.

Pepperi: korisni, ali nisu zamjena

Pepper je tajna vrijednost dodana postupku hashiranja lozinke i pohranjena odvojeno od baze podataka, često u upravitelju tajni ili hardverskom sigurnosnom modulu.

Za razliku od salta, pepper mora ostati tajan.

Pepperi mogu smanjiti štetu ako baza podataka procuri, ali aplikacijske tajne ne. Najkorisniji su u zrelim okruženjima s dobrim upravljanjem ključevima. Manje su korisni ako isti napadač može ukrasti i bazu podataka i konfiguraciju aplikacije.

Ako koristite pepper, pažljivo planirajte rotaciju. Njegova rotacija može zahtijevati da se korisnici ponovno prijave ili resetiraju lozinke, ovisno o dizajnu. Pepper je dodatni sloj, a ne razlog za slabljenje temeljnih postavki hasha.

Operativni kontrolni popis

Ako ste odgovorni za stvarni sustav, praktični kontrolni popis je kratak:

• Pohranjujte lozinke samo standardnim algoritmom za hashiranje lozinki.
• Koristite jedinstveni nasumični salt za svaku lozinku.
• Preferirajte Argon2id za nove sustave.
• Podesite parametre troška na hardveru sličnom produkcijskom.
• Pohranite algoritam i parametre uz svaki hash.
• Ponovno hashirajte pri prijavi kada parametri zastare.
• Nikada ne zapisujte lozinke niti ih šaljite alatima za analitiku.
• Koristite TLS svugdje gdje se šalju vjerodajnice.
• Dodajte MFA ili passkeys ondje gdje rizik to opravdava.
• Zaštitite tokove resetiranja jednako ozbiljno kao tokove prijave.
• Imajte plan za incidente koji uključuje prisilna resetiranja i obavještavanje korisnika.

Hashiranje lozinki nije glamurozno. To je infrastruktura. Ali to je ona vrsta infrastrukture koja određuje hoće li proboj postati bolan incident ili katastrofa za sve korisnike.

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

💡 Isprobajte ovo: Pogledajte kako se isti unos mapira na različite algoritme pomoću Hash Generator, koji razliku između brzih hasheva i onih prikladnih za lozinke čini konkretnom.

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

Iskren mentalni model

Najbolji način razmišljanja o hashiranju lozinki je ovaj:

Hashiranje ne štiti lozinku dok je korisnik upisuje. Ne štiti račun nakon što se korisnik prijavi. Ne štiti korisnike koji ponovno upotrebljavaju lozinke diljem weba.

Štiti pohranjeni verifikator.

To zvuči usko, ali je iznimno važno. Baze podataka cure. Sigurnosne kopije cure. Staging sustavi se kopiraju. Dobavljači dobivaju pristup koji ne bi trebali imati. Stari izvozi ostaju u objektnoj pohrani dulje nego što se itko sjeća.

Kada se to dogodi, dizajn vaše pohrane lozinki postaje razlika između toga da napadači dobiju lozinke i toga da napadači dobiju skup problem pogađanja.

To je ono od čega vas hashiranje lozinke zapravo štiti.