Si të ruani siç duhet fjalëkalimet: Kriposja, Hashimi dhe PBKDF2

Fjalëkalimet janë informacion shumë privat dhe ju nuk dëshironi të jeni përgjegjës për një shkelje të të dhënave. Ju duhet të merrni masat më të larta paraprake nëse duhet t'i trajtoni ato në aplikimin tuaj dhe t'i hasni siç duhet.

Shumica e problemeve të sigurisë me fjalëkalimet ndodhin pasi një sulmues ka fituar akses në serverin tuaj dhe është në gjendje të shikojë bazën e të dhënave ku ruani fjalëkalimet. Ndërsa është padyshim një ide e mirë të mbyllni serverin tuaj për të parandaluar hyrjen e paautorizuar në radhë të parë, ju duhet të zbatoni ende kontrollin e dëmtimit për skenarin më të keq.

Përdorni OAuth në vend të kësaj, nëse mundeni

Mënyra më e mirë për t'u marrë me fjalëkalimet nuk është aspak. Nëse nuk keni një nevojë specifike për të trajtuar drejtpërdrejt fjalëkalimet, mund të përdorni OAuth për t'i bërë dikush tjetër ta trajtojë atë për ju. Kjo quhet edhe identifikimi nga palët e treta dhe ndoshta e keni hasur më parë nëse ju është kërkuar ndonjëherë të identifikoheni me Google ose Facebook.

OAuth është më i ndërlikuar se vërtetimi i fjalëkalimit, por edhe nëse jeni komprometuar plotësisht, ka zero të dhëna fjalëkalimi për një sulmues për t'i parë, madje as hash.

Mos ruani kurrë fjalëkalime të tekstit të thjeshtë

Nëse duhet të ruani fjalëkalime, nuk duhet t'i ruani kurrë ato në tekst të thjeshtë në serverin tuaj. Tekst i thjeshtë do të thotë se është i lexueshëm nga një sulmues me qasje në diskun tuaj. Për shembull, nëse thjesht merrni fjalëkalimin e një përdoruesi dhe e ruani atë në bazën tuaj të të dhënave MySQL, kjo do të ruhet në tekst të thjeshtë. Kjo është arsyeja pse ju jepet gjithmonë një lidhje për të rivendosur fjalëkalimin tuaj në vend që kompania t'ju tregojë vetëm se cili ishte fjalëkalimi juaj i vjetër.

Zgjidhja për problemin e tekstit të thjeshtë është hashimi. Një hash është një funksion që merr një vlerë dhe gjeneron një çelës unik. Për shembull, fraza password ka një hash SHA256 prej:

6B3A55E0261B0304143F805A24924D0C1C44524821305F31D9277843B8A10F4E

Por duke ndryshuar qoftë edhe një shifër të vetme (passwerd) ndryshon plotësisht daljen:

0B503AEB841F18131DFA86FA052CEF91D9F4D81D301B89F6D035AF89C2CD8AA5

Pra, në vend që të ruani fjalëkalimin në server, ju e ruani këtë hash. Hashët janë të ndryshëm nga kriptimi në atë që janë funksione të njëanshme. Mund të hash diçka, por është e pamundur ta shpërndash atë pa e forcuar drejtpërdrejt hash-in. Kjo do të thotë se nuk ka asnjë çelës sekret për të ruajtur, dhe edhe nëse një sulmuesi kap një hash, ata do të duhet ta detyrojnë atë së pari për të parë përmbajtjen.

Ky rregull i tekstit të thjeshtë zbatohet edhe për gjëra ndihmëse si skedarët e regjistrit - nëse sulmuesi mund ta lexojë atë nga kudo, kjo është një çështje kryesore. Kjo vlen edhe për metodat e transmetimit të tekstit të thjeshtë si HTTP, megjithëse nuk duhet të dërgoni kurrë fjalëkalime përmes telit. Ju dëshironi të gjeneroni një hash në anën e klientit kur ata e futin atë, për të parandaluar që fjalëkalimet të nuhaten në rrjet.

Edhe pse sigurimi i trafikut me HTTPS do të parandalonte sulmet nga ana e klientit, nëse një sulmues do të kishte akses në serverin tuaj, ata mund të deshifronin dhe nuhasin fjalëkalimet e krijuara rishtazi. Kjo gjithashtu e bën shërbimin tuaj më të besueshëm, pasi një përdorues nuk do ta dijë nëse po e ruani fshehurazi fjalëkalimin e tij në prapaskenë. Por nëse shihni vetëm një hash, edhe serveri nuk e di se cili është fjalëkalimi i tij.

Nëse thjesht dëshironi një hash të mirë për t'u përdorur, zgjidhni PBKDF2, pasi përdoret posaçërisht për ruajtjen e fjalëkalimeve dhe është shumë i sigurt. Ndoshta do të dëshironi të përdorni zbatimin e JavaScript në anën e klientit, por nëse duhet ta përdorni atë nga ana e serverit, do të dëshironi të përdorni një zbatim për gjuhën tuaj.

Kriposni fjalëkalimet tuaja

Hashimi ka një problem dhe hash-et e rregullta të fjalëkalimeve mund të thyhen me një metodë të njohur si tabelat e ylberit.

Për të sulmuar një hash, thjesht mund të provoni çdo fjalëkalim të mundshëm për çdo hyrje hash në bazën tuaj të të dhënave, i cili njihet si bruteforcing - i ngadalshëm, por jo plotësisht i pamundur, në varësi të sa i dobët është fjalëkalimi dhe hash-i i përdorur për ta ruajtur atë. Mund të duhen disa ditë ose javë kohë llogaritjeje, por një fjalëkalim individual i dobët mund të hapet përfundimisht.

Tabelat Rainbow e përshpejtojnë këtë në mënyrë dramatike. Në vend që të bruteforcohet çdo fjalëkalim individualisht, hash-et për çdo fjalëkalim të mundshëm llogariten paraprakisht dhe ruhen në një skedar. Ky skedar mund të jetë masiv, në shkallën e shumë qindra terabajtëve. Gjithçka është një çift me vlerë kyçe të çdo fjalëkalimi të mundshëm (deri në një madhësi të caktuar, në varësi të tabelës) dhe hash-in përkatës.

Është një shkëmbim i hapësirës së ruajtjes me kohën; ju duhet të kryeni hash-in vetëm një herë, atëherë mund ta kërkoni në tabelë në vend të kësaj (e cila është shumë më e shpejtë). Këto tabela janë të disponueshme për publikun dhe janë të lehta për t'u gjeneruar.

Për të parandaluar këtë vektor sulmi, duhet të shtoni një kripë - një varg i rastësishëm që e vendosni në fund të fjalëkalimit përpara se të hash. Në vend që të hash password, ju do të hash:

password + 1D75BCA3...

Kjo kripë ruhet së bashku me hash-in e fjalëkalimit në bazën e të dhënave. Kur një përdorues fut fjalëkalimin e tij, ju ia dërgoni kripën përdoruesit që të mund ta shtojnë atë në hash. Mund ta mendoni sikur çdo përdorues të ketë tabelën e tij unike të ylberit, e cila e mposht plotësisht qëllimin e tyre.

Kripa në vetvete nuk është sekrete. Nuk ka pse të jetë, pasi gjithçka që po bën është të parandalojë krijimin e tabelës së ylberit, dhe ju gjithsesi po e ruani atë në tekst të thjeshtë. Fjalëkalimet e kripura ende mund të forcohen individualisht.

Në praktikë, madhësitë e hash-it prej 32 bajt janë mjaft të zakonshme, pasi hash-et vërtet të shkurtra janë ende të prekshme ndaj tabelave të ylberit. Dhe mos ripërdorni kripërat; ju duhet të gjeneroni një varg të ri të rastësishëm çdo herë.

Përdorni një Hash të Sigurt për Fjalëkalimet

Ndërsa SHA256 është një hash i sigurt, ai është krijuar gjithashtu për të qenë një hash për qëllime të përgjithshme. Kjo do të thotë se duhet të jetë i shpejtë, sepse përdoret gjithashtu për krijimin e shumave kontrolluese (të cilat duhet të përpunojnë gigabajt të dhëna). Shpejtësia zvogëlon drejtpërdrejt kohën e forcës brutale, dhe madje edhe me fjalëkalime të kripura, është ende relativisht e lehtë të thyesh vargjet e shkurtra individuale. Kripërat mbrojnë vetëm nga tavolinat e ylberit.

Në vend të kësaj, përdorni PBKDF2. Është menduar posaçërisht për fjalëkalimet, që do të thotë se është relativisht e ngadaltë për të llogaritur për gjatësinë mesatare të fjalëkalimit. Duhet shumë më shumë kohë për të bruteforce, dhe është praktikisht e pamundur të hapësh fjalëkalime më të gjata të ruajtura me të. Ju mund të përdorni zbatimin JavaScript, ose të përdorni një implementim nga ana e serverit.

Për të përdorur plotësisht PBKDF2, do të dëshironi të zbatoni një lloj standardi fjalëkalimi për faqen tuaj. Ju nuk keni nevojë të kërkoni që të gjithë të kenë shenja dhe numra të dollarit atje; gjatësia ka më shumë rëndësi se çdo gjë tjetër. Mundohuni të vendosni të paktën 8-12 fjalëkalime me karaktere.

Një listë kontrolli përfundimtare

Në mbyllje, këtu është një listë kontrolli sigurie për t'u siguruar që jeni gati:

Shmangni përdorimin e fjalëkalimeve dhe kaloni në OAuth nëse është e mundur.
Kurrë mos ruani fjalëkalime të tekstit të thjeshtë në asnjë bazë të dhënash, regjistër ose skedar dhe kurrë mos i transmetoni ato përmes lidhjeve HTTP.
Hash fjalëkalimet me një funksion hash të sigurt si PBKDF2 ose SHA256.
Shto gjithmonë një kripë të rastësishme në hash-et e fjalëkalimit dhe ruaje atë së bashku me hash-in.
Shmangni përdorimin e MD5 ose SHA1. (Ata të dy janë thyer dhe janë të pasigurt.)
Zbatoni standarde të mira fjalëkalimi për përdoruesit e faqes tuaj. (Gjatësia është çelësi këtu.)
Idealisht, mbajeni serverin tuaj plotësisht të pavetëdijshëm për fjalëkalimet e tekstit të thjeshtë në radhë të parë duke kryer hash në anën e klientit. Kjo mbrojtje për të ardhmen e fjalëkalimit, edhe në rast se një sulmues fiton akses të plotë të memories në serverin tuaj.
Sigurohu që vetë serveri të jetë i sigurt duke mbyllur aksesin SSH dhe duke mbajtur gjithçka të përditësuar, kështu që ka të ngjarë të mos e kesh kurrë këtë problem në radhë të parë.