DEV Community: Marius V

Two Unconventional Ways to store Passwords: Honeywords & Rock Salt

Marius V — Thu, 31 Oct 2024 10:08:42 +0000

As online threats keep evolving, storing passwords securely has become a constant challenge for developers. The usual methods, like hashing and salting passwords with algorithms such as Argon2, bcrypt, or PBKDF2, have worked well to make brute-force attacks harder. But as attackers get more sophisticated, these techniques alone may not be enough—especially for larger systems where a breach could be disastrous. Let’s dive into two creative approaches for password storage — Honeywords ** and **Rock Salt — that add layers of security with a focus on detection and resilience.

This article is not a recommendation; its intention is to stimulate thought by exploring unorthodox approaches.

Why Password Storage Needs a New Twist

Passwords are the gatekeepers of web applications. But traditional methods like salted hashes have their limits when facing today’s complex threats. This is where Honeywords and Rock Salt come in handy. Honeywords add fake passwords to trip up attackers and detect unauthorized access, while Rock Salt uses a unique, ultra-secure key to further protect against brute-force attacks. Together, they offer developers new ways to protect passwords against increasingly savvy cyber threats.

Honeywords: Decoy Passwords That Fight Back

The Honeywords technique spices things up by creating decoy passwords— “honeywords” — that sit alongside each real password in the database. These decoys look like the real thing but are designed to detect an attacker. If an attacker somehow gains access to the database and tries one of these honeywords, a separate system, the Honeychecker, will recognize the fake and trigger an alert, tipping off administrators that something’s up. Legitimate users remain unaffected since only the Honeychecker knows which passwords are real. Honeychecker is essentially just a separate system which keeps track of which passwords are real and which are decoys.

Imagine an attacker breaking into a database and attempting to use a password hash they think is legitimate. If they unknowingly pick a honeyword, the system flags this attempt, giving admins the chance to step in quickly. This way, Honeywords help catch intruders early on, increasing the chances of detecting breaches before significant damage is done.

How to Set Up Honeywords in Practice

Adding Honeywords is pretty straightforward. Each time a user creates or updates their password, the system generates several honeywords and shuffles them in with the real one. Only the Honeychecker knows which one is genuine. During login attempts, the Honeychecker verifies if the entered password is correct or just a decoy. If a decoy is used, an alert is raised for admins to investigate.

Creating convincing decoys can be tricky; they need to look realistic so attackers can’t easily tell them apart from real passwords. Many systems automate this by using algorithms to generate honeywords that mimic real passwords. That way, it’s hard for intruders to guess which ones are real.

Rock Salt: Password Security with a Physically Protected Key

While Honeywords focus on catching attackers in the act, Rock Salt’s strength lies in adding brute-force resilience by involving a physically protected Very Large Key (VLK). Here’s the basic idea: most password systems only involve hashing and salting, where an attacker could theoretically make countless guesses to reverse the password hash. Rock Salt changes this by making password verification depend on both the hashed password and access to a unique VLK stored in a secure, restricted-access Rock Salt Server (RSS).

Here’s how Rock Salt’s VLK works in practice:

Password Entry and Hashing: When a user logs in, their entered password is hashed with a “salt”—an additional random value that varies by user.
Salt Sent to the Rock Salt Server: This salt, along with the hashed password, is sent to the RSS. Inside the RSS, the salt acts as a kind of “map” to a specific segment of the VLK, essentially saying, “Give me these specific bytes.”
Combining Salt and VLK: The RSS uses these requested bytes of the VLK and combines them with the salt to generate a Rock Salt—a unique, one-time value that cannot be replicated without access to the RSS and VLK. This Rock Salt is then combined with the password hash to generate a final, unique hash element.
Final Hash Comparison: This final hash is what gets compared to the stored hash in the database. If it matches, access is granted; if not, the login attempt is denied.

By involving the VLK in every login attempt, Rock Salt makes brute-force attacks nearly impossible. Attackers would need access to both the hashed passwords and the secure VLK server, which is designed to be physically protected and inaccessible outside of verification.

This system’s resistance to quantum computing and its reliance on physical security make Rock Salt an ideal solution for environments requiring long-term and high-resilience password protection.

Honeywords vs. Rock Salt: How They Work Together

Honeywords and Rock Salt have different strengths, but they work well together. Honeywords focus on detection, providing an early warning if an intruder is trying to break in, while Rock Salt offers brute-force protection, making it harder for anyone to crack passwords even if they’ve breached the database. Honeywords are simpler to deploy, so they’re ideal for systems that need an alert mechanism, while Rock Salt is better for environments with the infrastructure for secure physical storage.

Real-World Applications of Honeywords and Rock Salt

For web platforms with frequent user logins—like social media or e-commerce sites—Honeywords can be a lifesaver. They make it easier to spot intrusions quickly. If an attacker ever gets their hands on login data, honeywords can act as an immediate alarm when one of the fake passwords is used.

Rock Salt is perfect for places like banks or big corporations with highly sensitive data. Since the approach requires a bit of hardware security, it’s best suited to large-scale organizations that can handle the additional infrastructure.

Potential Hurdles and Downsides

For Honeywords, the main challenge is generating decoys that look real. Advanced honeyword generators use behavior models to make believable honeywords, but they need updating over time to stay effective. Rock Salt’s biggest hurdle is its cost, given the hardware and security requirements involved, which might be overkill for smaller applications. Of course it's quite easy to implement Rock Salt in a DIY fashion, by just storing few terabyte random file on a separate server and using it as "difficult to leak VLK".

Making the Most of Both Techniques

Using Honeywords and Rock Salt together can offer the best of both worlds. Honeywords give you that immediate alert if an intruder tries to use a decoy, while Rock Salt makes the real passwords tougher to crack. To make this work, developers should keep the honeywords fresh and manage Rock Salt’s storage securely across systems.

References

Honeywords: Making Password-Cracking Detectable by Ari Juels and Ronald L. Rivest
Rock Salt: A Method for Securely Storing and Utilizing Password Validation Data by Arnold Reinhold

Apie CityBee ir slaptažodžių saugumą

Marius V — Fri, 19 Feb 2021 14:46:01 +0000

Šis straipsnis parašytas po CityBee skandalo pradėjus plisti netiksliai informacijai apie slaptažodžių saugojimą. Skirta tiek IT specialistams, tiek norintiems labiau suprasti situaciją.

Trumpai (TL;DR;)

Iš įmonės CityBee, o vėliau ir iš OlyBet bei filmai.in nutekėjus klientų duomenims bei paaiškėjus, jog be viso kito, slaptažodžiai buvo saugomi nesaugiu SHA1 algoritmu, internete pradėjo plisti nuomonės apie tai, kaip įmonė turėjo teisingai saugoti slaptažodžius. Pasisakė visi, nuo IT "specialistų", iki mažai ką bendro su IT turinčių influencerių.

Beveik visi komentarai apsiriboja tuo pačiu teiginiu: CityBee saugodami slaptažodžius nenaudojo vadinamo "salt" metodo, o tai yra labai blogai ir jei būtų naudotas "salt" - klientų slaptažodžiai būtų buvę žymiai saugesni.

Dauguma apie "salt" kalbančių žmonių mažai ką supranta apie saugumą ir tik daro žalą IT industrijai klaidindami jaunus specialistus. Nepaisant, jog CityBee elgesys buvo aplaidus, tai tas pats, kas po avia-katastrofos, kur iš lėktuvo liko tik blynas, aiškinti, jog lėktuve nebuvo įrengti saugos diržai.

Saugant vartotojų slaptažodžius reikia naudoti specialius tam skirtus algoritmus. Jų yra daugybė, bet mano rekomenduojamas baigtinis sąrašas: PBKDF2, BCrypt, Argon2. Tai yra absoliutus minimumas, privalomas kiekvienai internetinei sistemai, nes nereikalauja pastangų ir duoda maksimaliai rezultato. Na, o apie viską išsamiai - žemiau.

Kaip "koduojami" slaptažodžiai

Slaptažodžiai naudojami daug kur: jungiantis prie kompiuterio, apsaugant failus, registruojantis internetiniuose puslapiuose. Kad būtų paprasčiau, apsiribokime CityBee pavyzdžiu.

Vartotojas registruodamasis CityBee programėlėje nurodo savo pasirinktą slaptažodį. Sistema jį turi kažkur išsaugoti, kad vėliau vartotojui jungiantis galėtų sutikrinti ar slaptažodžiai sutampa. Kadangi įsiminti krūvą slaptažodžių sudėtinga, žmonės visur linkę naudoti tuos pačius arba panašius slaptažodžius. Tarkim, jeigu žmogaus CityBee slaptažodis yra LinksmasBebras, didelė tikimybė, jog Gmail, Facebook ar net banko slaptažodis bus LinksmasBebras1!.

Natūralu, jog CityBee negali saugoti slaptažodžio paprastu tekstu (angl. plain text), nes tiek duomenų vagys, tiek ir vidiniai įmonės darbuotojai galėtų vartotojams pridaryti daugybę problemų. Išeitys yra dvi: slaptažodžius šifruoti arba "hash'uoti".

Šifravimas (dar klaidingai vadinamas kodavimu, angl. encryption) yra operacija, kurios metu, naudojant slaptą raktą, duomenys užšifruojami taip, jog be rakto jų nebūtų įmanoma perskaityti. Panaudojus tą patį raktą duomenis galima iššifruoti į jų pradinę formą. Šifruoti slaptažodžius nėra labai populiaru, nes sunku saugiai prižiūrėti raktą, kuris irgi gali būti pavogtas arba prieinamas įmonės darbuotojų.

Hash'avimas (liet. maiša), paprastai pasakius, yra algoritmas iš teksto gauti fiksuoto ilgio simbolių kratinį. Iš to paties teksto visuomet gaunamas tas pats simbolių kratinys. Iš hash funkcijos rezultato nebeįmanoma atstatyti pradinio teksto. Štai paprasta hash funkcija aprašyta žmonių kalba:

Sudauginkime teksto kiekvienos raidės eilės numerį abėcėlėje;
Gautą sandaugą padalinkime iš 100;
Liekana bus mūsų hash'as;
Pvz.: "abce" hash'as pagal šį algoritmą yra 1*2*3*5 = "30";

Mūsų asmens kodų paskutinis skaitmuo irgi yra hash'as išskaičiuotas iš prieš jį einančių 10 simbolių.

Hash'avimas skamba kaip idealus būdas saugoti slaptažodžius - galima išsaugoti ir vėliau patikrinti ar įvesto slaptažodžio hash'as sutampa su išsaugota reikšme. O hash algoritmų yra labai daug ir įvairių, CityBee pasirinko gana populiarų, bet senstelėjusį, SHA1 algoritmą, jis iš bet kokio ilgio duomenų sugeneruoja 20 baitų ilgio reikšmę. Pvz. teksto LinksmasBebras SHA1 rezultatas yra "304c888dc981169e1dca9f31998cece8da2c2458". Iš dviejų skirtingų slaptažodžių gauti tą pačią hash reikšmę teoriškai įmanoma, bet praktiškai nelabai (priešingai nei naudojant aukščiau pavaizduotą supaprastintą algoritmą). Yra ir kitų populiarių hash algoritmų: MD5, SHA256, SHA512 ir pan.

Visas CityBee darbo su slaptažodžiais procesas buvo toks:

Vartotojas registruodamasis programėlėje įveda slaptažodį LinksmasBebras.
Slaptažodis nukeliauja į centrinę CityBee sistemą.
Sistema suskaičiuoja gauto slaptažodžio hash'ą naudodama SHA1 algoritmą.
Sistema išsaugo gautą hash reikšmę 304c888dc981169e1dca9f31998cece8da2c2458 į duomenų bazę, kartu su kitais vartotojo duomenimis. Registracija sėkminga.

<..>

Vartotojas jungdamasis prie sistemos įveda slaptažodį LinksmasBebras.
Slaptažodis nukeliauja į centrinę CityBee sistemą.
Sistema suskaičiuoja gauto slaptažodžio hash'ą naudodama SHA1 algoritmą.
Sistema palygina gautą hash reikšmę 304c888dc981169e1dca9f31998cece8da2c2458 su vartotojo hash reikšme iš duomenų bazės. Kadangi sutampa - prisijungimas sėkmingas.

Kodėl CityBee slaptažodžius "kodavo" blogai

Primenu, kad iš CityBee, be kita ko, buvo pavogti vartotojų slaptažodžiai SHA1 hash'ų pavidalu. Ar kaip jie patys klaidina: "užkoduoti".

Nors iš hash reikšmės ir neįmanoma atkurti pradinio teksto, tačiau niekas netrukdo skaičiuoti visų įmanomų simbolių kombinacijų SHA1 hash'o, kol atrasime ieškomą. Pradėję nuo "a", paskiau "b" ir t.t. ilgainiui (po nesuvokiamos galybės bandymų) prieisime prie LinksmasBebras, gausime atsakymą "304c888dc981169e1dca9f31998cece8da2c2458" ir taip sužinosime koks tekstas slėpėsi po šia hash reikšme. Toks visų reikšmių išbandymas vadinamas brute-force ataka.

SHA1 ypatybė yra ta, jog jis sukurtas būti labai efektyvus, kompiuteriui suskaičiuoti teksto SHA1 hash'ą yra vieni juokai. Nepaisant to, jog net mano kompiuteris gali išbandyti kelis milijardus kombinacijų per sekundę, jų yra tiek daug, jog užtruktume daugybę metų kol prieitume iki LinksmasBebras. Tačiau kas trukdo pasiėmus Lietuvių kalbos žodyną išbandyti visų žodžių junginių kombinacijas? Įtraukus visas didžiųjų-mažųjų raidžių kombinacijas, belieka tik keliolika milijardų spėjimų - vienas juokas šiuolaikinei technikai. Apie tai, kaip nulaužinėjami hash'ai - šiek tiek vėliau.

Pasitelkus įvairius genialius būdus, galima sugeneruoti milžiniskas duomenų bazes su potencialiais slaptažodžiais ir jų hash reikšmėmis. Į tokias duomenų bazes patenka ir įvairiais būdais nutekėję realūs slaptažodžiai. Pavyzdžiui, crackstation.net leidžia net parsisiųsti savo turimą 15GB slaptažodžių duomenų bazę. Nebereikia nieko laužti, belieka tik surasti domenų bazėje kokį tekstą atitinka jūsų turima hash reikšmė.

Panacėja, vardu "Druska"

Po CityBee skandalo bent kiek IT sistemose nusimanantys specialistai suskubo aiškinti, jog saugoti slaptažodžius SHA1 pavidalu buvo kvailystė ir CityBee (tiksliau jų sistemos pamatus padėjusi įmonė) turėjo naudoti salt'ą.

Salt'inimas, tai yra slaptažodžių saugojimo patobulinimas, kai prie teksto pridedami atsitiktiniai simboliai (salt'as) ir tik tuomet skaičiuojamas hash'as. SHA1 reikšmę reikėtų skaičiuoti iš teksto LinksmasBebrasE1F53135E559C253, o rezultatą ir salt'ą išsaugoti duomenų bazėje. CityBee registracijos ir prisijungimo procesas naudojant salt būtų buvęs toks:

Vartotojas registruodamasis programėlėje įveda slaptažodį LinksmasBebras.
Slaptažodis nukeliauja į centrinę CityBee sistemą.
Sistema sugeneruoja atsitiktinę salt reikšmę, prideda ją prie gauto slaptažodžio ir suskaičiuoja teksto LinksmasBebrasE1F53135E559C253 hash'ą naudodama SHA1 algoritmą.
Sistema išsaugo gautą hash reikšmę ae679d1015ee8dd586036c9de34ade76c33f1c3a ir panaudotą salt'ą E1F53135E559C253 į duomenų bazę, kartu su kitais vartotojo duomenimis. Registracija sėkminga.

<..>

Vartotojas jungdamasis prie sistemos įveda slaptažodį LinksmasBebras.
Slaptažodis nukeliauja į centrinę CityBee sistemą.
Sistema pasiima iš duomenų bazės seniau išsaugotą salt reikšmę E1F53135E559C253, prideda ją prie įvesto slaptažodžio ir paskaičiuoja teksto LinksmasBebrasE1F53135E559C253 hash reikšmę.
Sistema palygina gautą hash reikšmę su vartotojo hash reikšme duomenų bazėje. Jei sutampa - prisijungimas sėkmingas.

Įsidėmėkite, kad salt reikšmė saugoma šalia slaptažodžio toje pačioje duomenų bazėje. Jei daroma kaip nors kitaip, tai nebėra salt.

Salt naudojimas išsprendžia dvi problemas:

Nebeįmanoma naudoti iš anksto sugeneruotos slaptažodžių duomenų bazės, nes net visuose pasaulio diskuose netilps tiek daug teksto kombinacijų.
Jei du skirtingi vartotojai naudos tą patį slaptažodį, jo hash'as duomenų bazėje bus skirtingas.

Prieš ~15 metų, salt naudojimas buvo gana adekvati apsauga, nes negalėjimas pasinaudoti kažkieno ilgus metus kauptomis duomenų bazėmis reiškė, jog įsilaužėlis turės pats bandyti perrinkinėti kiekvieno vartotojo slaptažodį.

Atsiradus pirmosioms galingoms vaizdo plokštėms buvo pastebėta, jog hash'us jos moka skaičiuoti daug greičiau nei kompiuterio procesorius. Tūkstančius kartų greičiau. Nuo to laiko viskas pasikeitė ir jau prieš daugiau nei 10 metų tapo galutinai aišku, jog slaptažodžių saugojimui reikia geresnių priemonių.

Apie IT saugumą gali kalbėti vos saujelė žmonių

Few false ideas have more firmly gripped the minds of so many intelligent men than the one that, if they just tried, they could invent a cipher that no one could break. - David Kahn

Viena iš problemų kuri persekioja kibernetinio saugumo industriją, nekompetetingi žmonės, kurie turėdami paviršutiniškas žinias dedasi šios srities specialistais. Dėl to sistemose ir atsiranda tūkstančiai saugumo spragų. Tai klasikinis Dunning-Kruger efekto pavyzdys.

Tikri profesionalai, o ypač kriptografijos, dažniausiai būna labai kuklūs ir retai ką nors teigia užtikrintai, nes jie supranta, kad daugelis atsakymų priklauso nuo konteksto, detalių ir auditorijos išsilavinimo. Tad jei jaučiate, jog kažkas jums autoritetingai bando aiškinti apie IT saugumą - tikriausiai galite nustoti to žmogaus klausyti. Šitai, deja, galioja ir man :(

Kodėl salt'as ne panacėja

Duomenų bazėse internete galima rasti šimtus milijonų nulaužtų slaptažodžių (paskaičiuotų hash'ų). Kalbu apie tas bazes, kuriose copy-paste pagalba galima iš hash'o atrasti slaptažodį.

Primenu, jog nebloga vaizdo plokštė sugeba paskaičiuoti kelis milijardus SHA1 hash'ų per sekundę. Taip pat primenu, jog salt'as, jeigu toks būtų, būtų gulėjęs duomenų bazėje šalia slaptažodžio. Tad paskaičiuoti pusės milijardo slaptažodžių SHA1 hash'us, prie kiekvieno pridedant unikalų salt'ą užtruktų nedaug ilgiau, nei to hash'o paieška duomenų bazėje. Tiesa, reikia pastebėti, jog naudojant salt, nebebūtų įmanoma suskaičiuoto slaptažodžio varianto patikrinti visame hash'ų sąraše, o reikėtų paskaičiuoti hash'ą kiekvienam vartotojui atskirai.

Egzistuojant salt'ui, nebūtų įmanoma pompastiška slaptažodžio hash'o nulaužimo demonstracija naudojant copy-paste. Taip pat pailgėtų didelio slaptažodžių sąrašo nulaužimas, bet esmės tai nepakeistų, tik suteiktų įmonei daugiau argumentų nusimesti kaltę.

Kaip nulaužinėjami slaptažodžiai

Yra du pagrindiniai slaptažodžių atakų tipai - online ir offline. Online - tai bandymas prisijungti prie pvz., web sistemos išmėginant įvairius slaptažodžius. Tokios atakos nepraktiškos, nes web sistema gali riboti prisijungimų skaičių, rodyti capcha ir pan.

CityBee atveju aktuali offline ataka - vartotojų slaptažodžių hashus galima pasisiųsti į savo kompiuterį ir neribotai nulaužinėti.

Viena populiariausių ir labiausiai išvystytų programų skaičiuoti hash'ams yra HashCat, ji moka efektyviai išnaudoti vaizdo plokštę ir palaiko daugybę hash algoritmų. Iš esmės ką ji daro, tai užsikrauna nurodytą hash'ų sąrašą ir įvairiais būdais generuoja galimas raidžių kombinacijas, skaičiuoja hash'ą ir ieško ar toks hash'as yra sąraše. Visas įdomumas slepiasi po "įvairiais būdais", apie juos ir pakalbėkime.

Kaip jau minėjau, bukai bandyti įvairias simbolių kombinacijas nepraktiška. Viskas priklauso nuo skaičiavimo pajėgumų, bet išbandyti net 9 simbolių kombinacijas yra keblu ir kiekvienas naujas simbolis eksponentiškai didina reikalingą nulaužimui laiką.

Reikia pasitelkti išmonę, žodynus ir žodžių manipuliavimo taisykles. Žodynai - tai didžiuliai įvairių žodžių sąrašai, pavyzdžiui visi lietuviški žodžiai, aktorių vardai, prieš tai nutekėję slaptažodžiai ir t.t. Taisyklės - tai žodžių manipuliacijų formulės. Pavyzdžiui, imame kiekvieną žodį iš LT žodyno ir atliekam su juo 10000 manipuliacijų: pridedame simbolį 1, pakeičiame visus simbolius a į @ ir t.t. Taip "nusilaužia" net tokie slaptažodžiai kaip "Valkyre1986" ar "K1eti@k@s69". CityBee atveju tai sudaro >50% visų slaptažodžių, priklausomai nuo naudojamo žodyno.

Sudėtingesniems slaptažodžiams atrasti galima naudoti žodynų kombinaciją, t.y. bandyti prie kiekvieno lietuviško žodžio lipdyti visus kitus įmanomus lietuviškus žodžius. Taip nusilaužia visi tokie slaptažodžiai kaip LinksmasBebras1 ir pan.

Išsisėmus galima paimti jau nulaužtų slaptažodžių sąrašą ir pradėti kombinuoti jį su žodynais. Kaip sakoma - rinse and repeat. Tokiu būdu nusilaužia sudėtingesni slaptažodžiai, tokie kaip "labasrytasmazule2020", nes jau kažkas turėjo slaptažodį "labasrytas" ir jis sėkmingai susikombinavo su papildomu žodžiu bei taisyklėmis.

Tai be galo smagus procesas, dėl to yra net konkursų, kur susirinkę mėgėjai varžosi, kas daugiau atras slaptažodžių. Žinoma, profesionalai turi sukaupę rimtus žodynus ir taisyklių rinkinius. Naudojantis nesudėtinga įranga ir RX5700XT vaizdo plokšte, per parą pavyko atkurti ~90% visų CityBee slaptažodžių (eksperimentui naudoti tik visiems viešai prienami duomenys). Tikiu, kad panaudojus, pvz., iš Darni Pora ar Filmai.in pavogtus visiškai atvirus slaptažodžius kaip žodyną, pavyktų išspausti dar vieną kitą procentą. Maždaug nuo 90% atkurtų slaptažodžių skaičius sunkiai auga, nes dalis žmonių naudoja password manager'ius, turi susigalvoję sudėtingus slaptažodžius ir pan.

Minutėlę pabandykite įsivaizduoti kaip vyktų slaptažodžių nulaužinėjimas vietoj vieno kompiuterio panaudojus tokią vaizdo plokščių fermą:

Tokios fermos išpopuliarėjo kartu su Bitcoin bumu (nes BitCoin kasimas irgi paremtas hash'ų skaičiavimu) ir dabar neretai panaudojamos slaptažodžių nulaužinėjimui.

Slaptažodžiai "nulaužinėjimi" ne tik blogiems tikslams ar hobiui. Lygiai toks pats būdas naudojamas ir įmonėse audituojant savo vartotojus, kad jiems būtų galima pranešti apie žinomus nutekėjusius slaptažodžius. Deja, ne visos valstybės pakankamai supratingos, štai Vokietija kenčia nuo drakoniškų įstatymų labai ribojančių darbą saugumo srityje. Kiek žinau, Lietuvoje tai vis dar pilkoji zona, kur kiekvienas atvejis sprendžiamas individualiai ir etiniai įsilaužimai (angl. ethical hacking) teisėsaugos vertinami labai selektyviai. Netgi aš, rašydamas šį edukacinį straipsnį, negaliu jaustis visiškai ramiai.

Kaip reikėtų saugoti slaptažodžius

Labai paprasta, 80% naudos galima pasiekti su visiškai minimaliomis pastangomis. Tereikia vietoj SHA1 ar kito netinkamo algoritmo naudoti vieną iš slaptažodžiams pritaikytų: PBKDF2, Bcrypt, Scrypt, Argon2 ar pan. Argon2 šiuo metu yra de facto geriausias algoritmas. Apie tai, kaip gauti likusius 20% naudos, reikėtų atskiro straipsnio.

Specialių algoritmų esmė yra tokia, kad jie paskaičiuojami lėtai (angl. slow hashing). SHA1 hash'ą paskaičiuoti užtrunka nanosekundes, o, pvz., Argon2 turi konfigūruojamą parametrą (angl. work factor), nurodantį, kiek ilgai hash algoritmas atliks operaciją. Jei paskaičiuoti slaptažodžio hash'ą ilgai užtrunka web sistemai, reiškia, jog ilgai užtruks ir tokių slaptažodžių nulaužinėjimas. Be to, Argon2 algoritmas labai prastai skaičiuojamas naudojant vaizdo plokštes ar kitą specialią įrangą.

Yra ir krūva kitų priemonių apsaugoti slaptažodžiams, pavyzdžiui finansų įstaigos naudoja dedikuotą įrangą (HSM), skirtą būtent šifravimo operacijoms atlikti. Svarbiausia nepatikėti tokių svarbių sprendimų žmonėms, kurie turi mažai ką bendro su saugumu, nes tuomet būna "išrandami" įvairūs algoritmai, kurie atneša daugiau gėdos, nei naudos. Pavyzdžiui, šiek tiek prakutęs programuotojas gali pasiūlyti vietoj ar šalia salt naudoti pepper metodą, kuris gal ir nepakenks, bet didelė tikimybė, jog sukurs klaidinančią saugumo iliuziją. OWASP organizacija teikia rekomendacijas ir siūlo gerąsias saugumo praktikas, įskaitant ir slaptažodžių saugojimą.

Mano asmenine nuomone, kiekviena įmonė, dirbanti su klientų duomenimis turėtų užsisakyti išorinio konsultanto ar audito paslaugas. Ir nebūtina tam leisti tūkstančių pinigų, bei pirkti konsultantų siūlomos programinės įrangos. Dažnu atveju pakaktų freelancer'io, kuris padėtų į savo sistemą pažiūrėti iš šalies.
Tikiuosi suprasti duomenų apsaugos svarbą padės karti nukentėjusių įmonių patirtis ir baudos, kurias jos gaus už aplaidumą.

Ir kaip visada - nepaisant to, jog šiame straipsnyje aiškinau techninius dalykus, didžiausia problema išlieka žmonės. Galima naudoti kokius nori algoritmus, bet jei admin'as netyčia sugalvos išsaugoti visą į sistemą įeinantį srautą, kartu išsisaugos ir asmeniniai duomenys prieš juos tinkamai užšifruojant.

If you think cryptography is the answer to your problem, then you don't know what your problem is. - Peter G. Neumann