Од чега вас хеширање лозинке заправо штити

Кратка верзија

Хеширање лозинке штити кориснике када ваша база лозинки буде украдена.

То је главни задатак. Не једини детаљ, не цео безбедносни модел, већ централни разлог због ког хеширамо лозинке уместо да их чувамо директно.

Правилно хеширана лозинка тешко се враћа у изворни облик. Ако нападач добије копију ваше табеле корисника, не би требало да одмах сазна да је Алисина лозинка Spring2026!. Уместо тога, добија сачуван хеш чије проверавање против нагађања захтева време, новац и хардвер.

Та разлика је важна. Хеширање лозинки није намењено томе да само по себи учини пријављивање безбедним. Оно не зауставља фишинг. Не зауставља некога да испробава процуреле лозинке на вашем формулару за пријаву. Не штити сесијски колачић након пријављивања. Оно купује време и смањује штету након врло конкретног отказа: складиште ваших верификатора лозинки постане изложено.

Ако разумете ту границу, доносићете боље одлуке о алгоритмима, факторима оптерећења, ресетовањима, логовању и реаговању на инциденте.

Шта је хеш лозинке

Хеш лозинке је излаз једносмерне функције примењене на лозинку, обично уз јединствену со и намерно спор алгоритам за хеширање лозинки.

Када корисник креира налог, систем би отприлике требало да уради ово:

1. Прими лозинку преко HTTPS.
2. Генерише насумичну, јединствену со.
3. Провуче лозинку и со кроз функцију за хеширање лозинки као што су Argon2id, bcrypt, scrypt или PBKDF2.
4. Сачува назив алгоритма, параметре, со и добијени хеш.
5. Одбаци оригиналну лозинку.

Када се корисник касније пријави, систем понавља исти процес хеширања са послатом лозинком и сачуваним параметрима. Ако се добијени хеш поклапа са сачуваним хешом, пријава успева.

Важан део: апликација не мора да зна оригиналну лозинку. Потребно је само да провери да ли послата лозинка производи очекивани резултат.

Зато је чување лозинки реверзибилном енкрипцијом обично погрешан модел. Ако ваша апликација може да дешифрује сваку лозинку, онда свако ко украде кључ за дешифровање може да уради исто. Лозинке би по правилу требало да буду непроверљиве у обрнутом смеру, а не само сакривене.

Од чега вас хеширање штити

1. Тренутно откривање лозинки након пробоја базе података

Ако нападач украде базу података која садржи лозинке у чистом тексту, штета је тренутна. Свака лозинка је изложена. Корисници су у ризику не само на вашем сајту, већ свуда где су поново употребили ту лозинку.

Ако база садржи добро хеширане лозинке, нападач има више посла. Мора да нагађа кандидатске лозинке, да хешира свако нагађање са исправном сољу и параметрима, и да упореди резултат.

За слабе лозинке, то и даље може бити брзо. За јаке јединствене лозинке, може бити непрактично.

Хеширање претвара катастрофално откривање у трку: могу ли корисници да ресетују лозинке и можете ли да обуздате инцидент пре него што нападачи разбију многе од њих?

То није савршено. И даље је пробој. Али је драматично бољи начин отказа.

2. Масовни напади на целу вашу корисничку базу

Соли су кључни део складиштења лозинки јер спречавају нападаче да ефикасно нападају много корисника одједном помоћу унапред израчунатих табела.

Со није тајна. Чува се уз хеш. Њен задатак је јединственост.

Ако два корисника изаберу исту лозинку, јединствене соли обезбеђују да се њихови сачувани хешеви разликују. То спречава нападаче да на први поглед виде да много корисника дели исту лозинку. Такође спречава класичне нападе rainbow табелама, где нападачи користе огромне унапред израчунате листе мапирања лозинки у хешеве.

Без соли, један разбијен хеш може открити сваког корисника са истом лозинком. Са солима, свако нагађање лозинке мора се тестирати посебно за сваког корисника.

3. Брзо офлајн нагађање

Када нападачи имају базу лозинки, могу да нагађају офлајн. То значи да ваша ограничења учесталости пријављивања, CAPTCHA, блокирање IP адреса и надзор више нису битни. Нападач може да тестира нагађања на сопственом хардверу.

Ту је избор алгоритма важан.

Општенаменски хешеви као што су SHA-256 и SHA-512 дизајнирани су да буду брзи. То је добро за интегритет датотека и дигиталне потписе. Лоше је за складиштење лозинки.

Алгоритми за хеширање лозинки дизајнирани су да буду спори, подесиви и понекад меморијски захтевни. Argon2id, bcrypt, scrypt и PBKDF2 омогућавају подешавање параметара трошка тако да свако нагађање траје смислено време.

Argon2id се широко препоручује за нове системе јер се може конфигурисати тако да захтева и CPU време и меморију, што поскупљује масовно разбијање помоћу GPU-а. bcrypt је и даље чест и прихватљив када је добро конфигурисан, иако има ограничења као што је руковање дужином лозинке. PBKDF2 се и даље користи у неким окружењима вођеним усаглашеношћу, посебно тамо где су потребне FIPS-валидиране компоненте.

Принцип је једноставан: учинити легитимне пријаве прихватљиво брзим, а милијарде нагађања скупим.

Од чега вас хеширање не штити

1. Фишинг

Ако корисник унесе своју лозинку на лажну страницу за пријаву, хеширање на вашем серверу не помаже. Нападач добија лозинку пре него што је ваш систем уопште види.

Одбране су овде другачије: вишефакторска аутентификација, passkeys, едукација корисника, хигијена домена, аутентификација отпорна на фишинг и пажљиви токови ресетовања лозинки.

Хеширање лозинки је последња линија заштите за сачуване тајне. Није одбрана од тога да корисници буду преварени да те тајне предају.

2. Credential stuffing

Credential stuffing се дешава када нападачи узму парове корисничких имена и лозинки процуреле са једне услуге и испробавају их на другој.

Ваши хешеви лозинки могу бити одлични, а credential stuffing и даље може да успе ако корисници поново користе лозинке.

Ово је онлајн напад на ваш формулар за пријаву, не офлајн напад на вашу базу података. Потребни су вам ограничење учесталости, откривање аномалија, провере компромитованих лозинки, MFA и разумне политике закључавања које не стварају лаке прилике за ускраћивање услуге.

Исто практично размишљање важи за сваки изложени формулар. Ако прегледате своју површину за аутентификацију, вреди прочитати зашто је ваш контакт формулар ваша највећа spam одговорност; механика се разликује, али поука је слична: јавним уносима су потребне контроле злоупотребе, не само чист backend код.

3. Лозинке ухваћене у логовима или аналитици

Хеширање помаже само ако се лозинка у чистом тексту брзо одбаци и никада не копира негде другде.

Чести пропусти укључују:

• Логовање целих тела захтева при неуспелим покушајима пријаве.
• Слање лозинки алатима за праћење грешака.
• Хватање поља за лозинку у производима за репродукцију сесија.
• Укључивање акредитива у URL-ове током лоше дизајнираних токова ресетовања или миграције.
• Чување привремених лозинки у чистом тексту током увоза.

Ове грешке у потпуности заобилазе хеширање лозинки. Ако чист текст заврши у логовима, резервним копијама, складиштима података или алатима трећих страна, ваша хеш функција је небитна.

Третирајте поља за лозинке као токсичне податке. Редигујте их пре логовања. Искључите их из аналитике. Држите их ван URL-ова. Ограничите ко може да приступи продукционим траговима.

4. Лоша безбедност сесија

Након пријаве, корисников прегледач обично добија сесијски колачић или токен. Ако се тај токен украде, нападачу лозинка можда уопште није потребна.

Хеширање лозинки не штити од cross-site scripting-а, небезбедних колачића, фиксације сесије, слабог генерисања токена или предугих трајања сесија.

Сесијски колачићи заслужују посебан преглед: HttpOnly, Secure, одговарајући SameSite, краткотрајне сесије високог ризика и серверска инвалидaција при промени лозинке. Шири пејзаж приватности и прегледача такође се стално мења, као што је обрађено у тексту шта се променило за колачиће у 2026.

5. Слабо ресетовање лозинке и опоравак налога

Многа преузимања налога не почињу лозинком. Почињу током ресетовања.

Ако су токени за ресетовање предвидљиви, дуготрајни, процуре кроз referrer заглавља или се пошаљу на компромитоване имејл налоге, хеширање лозинки вас неће спасити.

Користите токене за ресетовање високе ентропије, кратке прозоре важења, једнократну употребу и јасна обавештења корисницима. Пошто је имејл често канал за опоравак, важна је и основна аутентификација домена. Ако ваш тим третира DNS записе као мистериозан обред, почните са обиласком MX, SPF, DKIM и DMARC прилагођеним програмерима.

Избор алгоритма: шта сада користити

За нове апликације користите Argon2id ако га ваша платформа добро подржава. Он је победник Password Hashing Competition и дизајниран је за складиштење лозинки, укључујући отпорност на разбијање које се много ослања на GPU.

Разумна модерна хијерархија изгледа овако:

1. Argon2id за нове системе где је доступан.
2. bcrypt када Argon2id није практичан, а подршка за bcrypt је зрела.
3. scrypt када је меморијски захтевна конфигурација добро подржана.
4. PBKDF2 где то захтевају платформа или ограничења усаглашености.

Избегавајте обичан SHA-256, SHA-512, MD5 или сопствену комбинацију као што је sha256(password + salt). Брзи хешеви нису функције за складиштење лозинки. Паметне прилагођене конструкције обично су горе од досадних стандардних.

Такође избегавајте да измишљате сопствену политику лозинки око тривијалности алгоритама. Корисници немају користи од листе за састав лозинке са 12 правила ако их она гура ка предвидљивим обрасцима. Дуже јединствене лозинке, менаџери лозинки, провера компромитованих лозинки и MFA обично су важнији.

Фактори трошка нису „подеси и заборави”

Хеширање лозинки има параметре. Argon2id има меморију, итерације и паралелизам. bcrypt има фактор трошка. PBKDF2 има број итерација.

Ове вредности треба изабрати на основу вашег продукционог окружења. Ако су прениске, нападачи јефтино нагађају. Ако су превисоке, ваш систем за пријаву постаје спор или рањив на ускраћивање услуге.

Практична мета је често у опсегу од десетина до неколико стотина милисекунди по провери лозинке на вашим стварним серверима, у зависности од саобраћаја и ризика. Системи високе безбедности могу изабрати више. Системима потрошачког обима може бити потребно пажљиво планирање капацитета.

Не копирајте фактор трошка из блог поста старог пет година. Хардвер се мења. Библиотеке се мењају. Ваш саобраћај се мења.

Периодично прегледајте параметре и планирајте поновно хеширање. Уобичајен образац је да се алгоритам и параметри чувају уз сваки хеш. При успешној пријави, ако су сачувани параметри застарели, поново хеширајте послату лозинку новијом конфигурацијом и ажурирајте запис.

Peppers: корисни, али нису замена

Pepper је тајна вредност додата процесу хеширања лозинке и чува се одвојено од базе података, често у менаџеру тајни или хардверском безбедносном модулу.

За разлику од соли, pepper мора остати тајан.

Peppers могу смањити штету ако база података процури, али апликационе тајне не. Најкориснији су у зрелим окружењима са добрим управљањем кључевима. Мање су корисни ако исти нападач може да украде и базу података и конфигурацију апликације.

Ако користите pepper, пажљиво планирајте ротацију. Његова ротација може захтевати да се корисници поново пријаве или ресетују лозинке, у зависности од дизајна. Pepper је додатни слој, не разлог да ослабите основна подешавања хеша.

Оперативна контролна листа

Ако сте одговорни за стварни систем, практична контролна листа је кратка:

• Чувајте лозинке само стандардним алгоритмом за хеширање лозинки.
• Користите јединствену насумичну со за сваку лозинку.
• Дајте предност Argon2id за нове пројекте.
• Подесите параметре трошка на хардверу сличном продукционом.
• Чувајте алгоритам и параметре уз сваки хеш.
• Поново хеширајте при пријави када параметри застаре.
• Никада не логујте лозинке нити их шаљите алатима за аналитику.
• Користите TLS свуда где се шаљу акредитиви.
• Додајте MFA или passkeys тамо где ризик то оправдава.
• Штитите токове ресетовања једнако озбиљно као токове пријаве.
• Имајте план инцидента за принудна ресетовања и обавештавање корисника.

Хеширање лозинки није гламурозно. То је инфраструктурна водоводна инсталација. Али то је врста инсталације која одређује да ли пробој постаје болан инцидент или катастрофа за све кориснике.

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

💡 Пробајте ово: Погледајте како се исти унос мапира на различите алгоритме помоћу Hash Generator, који конкретно показује разлику између брзих хешева и оних на нивоу лозинки.

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

Искрен ментални модел

Најбољи начин да размишљате о хеширању лозинки је овај:

Хеширање не штити лозинку док је корисник куца. Не штити налог након што се корисник пријави. Не штити кориснике који поново користе лозинке широм веба.

Оно штити сачувани верификатор.

То звучи уско, али је изузетно важно. Базе података цуре. Резервне копије цуре. Staging системи се копирају. Добављачи добијају приступ који не би требало да имају. Стари извози остају у објектном складишту дуже него што ико памти.

Када се то догоди, ваш дизајн складиштења лозинки постаје разлика између тога да нападачи добију лозинке и тога да нападачи добију скуп проблем нагађања.

То је оно од чега вас хеширање лозинке заправо штити.