Paano Naming Pinoprotektahan ang Iyong Passwords

Sa mga naunang artikulo, tinalakay natin kung paano pinoprotektahan ng HTTPS ang daan sa pagitan ng iyong app at ng aming server, at kung paano pinoprotektahan ng SSH ang mismong server. Ngayon, titingnan natin sa loob ng server—kung paano pinapanatiling ligtas ng Splync ang iyong password kapag narating na ito. Kapag nakuha ng isang tao ang iyong password, maaari siyang mag-log in sa iyong account at ma-access ang sensitibong impormasyon, tulad ng iyong mga tala ng gastos. Kaya't ang Splync ay hindi kailanman nag-iimbak ng mga password sa plain text. Sa halip, ang bawat password ay binabago sa isang hashed na bersyon bago mai-save sa database. Ano ang ibig sabihin nito? Ang hashing ay isang one-way conversion—kapag na-transform na, hindi na ito maibabalik sa orihinal na password. Ang pamamaraang ito ay karaniwan sa internet, mula sa mga bangko hanggang sa mga pangunahing cloud services, ngunit marami ang hindi alam kung paano talaga ito gumagana. Tuklasin natin ito gamit ang simpleng halimbawa sa pang-araw-araw na buhay.

Upang maunawaan kung paano gumagana ang proteksyon sa password, magsimula tayo sa simpleng hashing method na tinatawag na SHA-256. Isipin ito na parang isang blender na palaging pareho ang paghalo ng mga sangkap. Kung ilalagay mo ang parehong password sa blender at pipindutin ang pindutan, palaging makakakuha ka ng parehong natatanging smoothie—isang magulong halo ng mga letra at numero. Ang pangunahing ideya ay hindi maibabalik ang proseso. Tulad ng hindi mo maaaring kunin ang smoothie at paghiwalayin ito pabalik sa orihinal na saging at gatas, hindi mo maaaring kunin ang magulong hash at ibalik ito sa orihinal na password.

Ang SHA-256 ay isa sa pinakakaraniwang hashing algorithms. Halimbawa, ang password na "splync1234" ay nagiging “9cdafa20d069ecfb202e5f0bc937c73071cc6cd85634cc2d95d30ddcf2a71d41”. Sa loob ng milliseconds, sa tuwing maglalagay ang isang umiiral na user ng login password, palaging naglalabas ang SHA-256 ng parehong hashed na password. Ang app ay nagha-hash lamang muli ng inilagay na password at sinusuri kung tumutugma ito sa nakaimbak na hash. Sa alinmang punto, hindi nalalaman ng sistema ang orihinal na password ng user. Ngunit paano kung ang isang umaatake ay pre-compute ng listahan ng karaniwang mga password at kanilang mga hash (kilala bilang isang rainbow table attack) upang mabilis na hulaan ang mga password ng user? Ang alalahaning iyon ay tunay. Ito ang dahilan kung bakit ang mga modernong sistema, kabilang ang Splync, ay hindi umaasa sa plain SHA-256.

Ang bcrypt ay gumagamit ng random na per-user salt at ini-encode ang salt na iyon (at ang cost factor) direkta sa nakaimbak na hash string. Isipin ang bcrypt na parang blender na may lihim na pampalasa (salt) at mabagal na motor (work factor)—ginagawa nitong natatangi at mas mahirap kopyahin ang bawat halo. Dahil ang salt ay 128 bits (≈3×10³⁸ na posibilidad), ang parehong password ay maaaring mag-map sa isang astronomically malaking bilang ng iba't ibang nakaimbak na hashes. Ginagawang walang kwenta ang precomputed rainbow tables sa scale na ito. Sa panahon ng pag-login, binabasa ng Splync ang salt at cost mula sa naka-save na bcrypt string, muling pinapatakbo ang bcrypt sa inilagay na password gamit ang mga parameter na iyon, at inihahambing ang resulta sa nakaimbak na hash. Kapag nag-match, tama ang password—ngunit dahil ang bcrypt ay sadyang mabagal at natatangi ang salts, ang brute-force attacks ay nagiging mas magastos para sa isang umaatake.

Tingnan natin kung paano ito sa praktika. Kung iha-hash mo ang password na "splync1234" gamit ang bcrypt (gamit ang cost 12), maaari kang makakuha ng string na ganito: `$2b$12$gBeouKYdue9uvvuV0HtGgeVPymnrojMqP/wcRw28HFlGEGIQbyw7O`. Sa bcrypt string na ito, ang `$2b` ay marka ng bersyon ng algorithm, ang `$12` ay nagpapakita ng cost factor (ilang beses na pinoproseso ang password), ang `gBeouKYdue9uvvuV0HtGgeV` ay ang natatanging random salt, at ang `PymnrojMqP/wcRw28HFlGEGIQbyw7O` ay ang pinal na hashed na password. Dahil ang hash mismo ay naglalaman ng salt at cost, kayang ulitin ng Splync ang parehong proseso ng hashing para sa pag-verify sa pamamagitan ng pagkuha ng mga halagang iyon mula sa nakaimbak na string at paghahambing ng resulta. Sa kabilang banda, kung hindi alam ng isang umaatake ang salt at cost, hindi nila makakabuo ng isang rainbow table na gumagana para sa bawat user.

Ang pamamaraang ito ay may isa pang mahalagang bentahe. Dahil hindi kailanman nag-iimbak ng plain passwords ang Splync, kahit na ang database ay malantad o manakaw, hindi agad nasa panganib ang mga gumagamit. Hindi makakapag-log in ng direkta ang mga umaatake gamit ang nakaw na data, dahil ang mayroon sila ay mga magulong string lamang. Nagbibigay ang disenyo na ito ng karagdagang layer ng proteksyon para sa mga gumagamit, bukod pa sa mga proteksyon na umiiral sa paligid ng mismong server. Ang password hashing ay hindi natatangi sa Splync; ito ay pamantayan sa buong industriya ng teknolohiya, ginagamit ng mga higante tulad ng Google, Apple, at Amazon. Ang Splync ay itinayo nang napakaligtas, at lalo pang magiging ligtas habang patuloy naming pinapabuti ang seguridad sa mga tampok tulad ng email verification, proteksyon laban sa brute-force, at patuloy na pagsubaybay.