Kuidas disainida turvalist kasutajate süsteemi

Meie eesmärgiks siin blogis on katta internetiturvalisuse valdkonda võimalikult laiahaardeliselt. Kui varasemad postitused on suunatud olnud tavakasutajatele, siis antud postitus on esimene, mis on mõeldud tarkvaraarendajatele. Käime koos läbi kõik aspektid, mis on vajalikud turvalise kasutajatesüsteemi loomiseks. See on keerulisem, kui esmapilgul välja paista võib.

Turvalisuse all ei pea ma antud hetkel silmas mitte tehnilist turvalisust nagu kaitse SQL injection ja XSS rünnakute vastu. Mõeldud on süsteemi arhidektuuri ja funktsionaalsust, kus on tegelikult peidus suurem osa turvaauke. Samuti mõtleme turvalisuse all kasutaja ning ta andmete kaitsmist muuhulgas ta enda eest – teadupärast on suurim turvarisk tooli ja klaviatuuri vahel. Disinides kasutajasüsteemi tuleb seda riski nii palju minimeerida, kui vähegi võimalik.

Postitus on üles ehitatud nn checklisti süsteemis. Ideaalis peaks iga aspekt kasutajasüsteemist vastama kõigile tingimustele. Kõik tingimused kehtivad olenemata, kas ehitad veebi- või mobiilirakendust.

Turvaline registreerimisvorm

  • Registreerimisvorm toimib ainult üle turvatud ühenduse (https).
  • Kasutajanimi (kui on) ja E-maili aadress peavad olema unikaalsed.
  • Samast e-mailist pole olemas ühtegi variatsiooni. toomas.tammtest123@gmail.com, toomastammtest123@gmail.com ja toomas.tamm.test.123@gmail.com kirjad lähevad kõik kohale samale kontole, vähemalt Gmailis. Kui mitte kontrollida e-maili variatsioonide olemasolu on võimalik ühe e-maili kontoga luua piiramatul arvul kontosid. Lisaks kasutaja sisestatud e-maili aadressile tuleks salvestada e-mail aadress ka kirjavahemärkideta ning registreerumisel just seda kontrollida.
  • Järjest pole võimalik luua mitut kontot. Kahe registratsiooni vahepeale peab jääma mõistlik aeg. Ühel inimesel pole mingit vajadust järjest registreerida rohkem, kui üht kasutajakontot, seetõttu ei tohiks seda ka lubada.
  • Kasutaja parool on vähemalt 8 tähemärki pikk. Artiklis “Kuidas valida turvalist ja meeldejäävat parooli” soovitan pikkuseks vähemalt 12 tähemärki, kuid päris nii pikka parooli kasutajalt nõuda on liig. Soovikorral võid nõuda ka, et paroolis oleks vähemalt 1 suur täht, number ja/või eriline tähemärk, kuid kõige olulisem on parooli pikkus. Liiga keerulise parooli nõue võib olla vastupidise efektiga – kasutajale ei jää parool meelde ja ta paneb selle Hollywoodi filmidest tuttaval moel Post-It kleepsuga kuvari külge.
  • Kasutaja parool pole enimlevinud ega liiga lihtne. Soovitatav on parooli kontrollida nimekirja kergelt ära arvatavate sõnede vastu nagu “parool”, “123456”, “qwerty” jms. Siit leiad mitu nimekirja enimlevinud paroolidga, mis on koostatud erinevate lekete põhjal. Tasub tähele panna, et need ei sisalda üldjuhul eesti keelseid fraase. Kui su toode või teenud on suunatud eesti turule tuleks ise koostada nimekiri populaarseimatest sõnadest, mis paroolks ei sobi.
  • Parool tuleks salvestada bcrypt krüpteeringuga. Bcrypt räside lahtimurdmine on oluliselt keerulisem, kui näiteks Sha1 või MD5 puhul. Ta on disainitud olema aeglane, mis ei ole eriline probleem sihtotstarbelisel kasutamisel, kuid muudab parooli toore jõu meetodil murdmise tülikaks. Bcrypt algoritmi on sisse ehitatud “sool”, mis muudab vikerkaare tabeli rünnakud (räsi võrdlemine juba eelnevalt genereeritud parooli ja räsi kombinatsioonidede tabeli vastu) tulutuks.
  • Kindalsti ei tohiks valitud parooli tekstikujul kasutajale e-mailile saata. See kehtib ka siis, kui sa parooli siiski krüpteerituna salvestad.

Turvaline sisselogimisvorm

  • Sisselogimisvorm toimib alati üle turvatud ühenduse
  • Sisestades vale kasutajanime ja parooli kindel arv kordi keelatakse antud IPl sisselogimine
  • Sisestades vale parool kindlale kasutajakontole piisav arv kordi lukustatakse kasutajakonto teatud ajaks. Soovikorral võid pakkuda võimaluse kasutajakonto e-mailile saadetud lingiga lahti lukustada.
  • Iga järgneva “rikkumisega” pikeneb aeg, milleks on blokeeritud IP aadress ja kasutajakonto
  • Logi iga kasutaja sisselogimine koos IP aadressi ning veebirakenduse korral veebilehitseja infoga
  • Kui vähegi võimalik paku kasutajale kaksikaudentimise võimalust. Kui SMSide saatmine liiga kulukas on, kasuta vähemalt kinnitus e-maili juhuks, kui kasutaja pole sellelt IP aadressilt varasemalt sisse loginud. Hea tava järgi võiks kasutaja saada selle ka soovikorral maha keerata, kuid vaikimisi võiks kaksikaudentimine aktiivne olla.
  • Kindlasti ole tuttav sellega, kuidas kasutaja audentimine su rakenduses tehniliselt toimib. Kas kasutad selleks küpsiseid? OAuth protokolli? JSON Web Tokene? Igaühe puhul on nüansid, mida pead tähele panema.
  • Kui kasutad küpsist ära määra selle skoopi laiemaks, kui vaja. Alamdomeenidel pole üldjuhul vaja küpsisele ligi pääseda. Kindlasti hoia küpsises olevaid andmeid krüpteerituna. Küpsises ei tohiks kindlasti olla kasutaja parooli, isegi krüpteeritud kujul. Küpsise puhul kasuta kindlasti http only parameetrit, et see poleks Javascriptiga loetav.

Turvaline parooli taastamise vorm

  • Parooli taastamist saab ühelt IP aadressilt küsida piiratud arv kordi määratud aja jooksul ning piiratud arvule kontodele. Tavakasutuse korral pole reaalne, et ühest arvutist üritatakse järjest taastada 4-5 erineva konto parooli. Sellisel juhul peaks IP aadressil mõneks ajaks parooli taastamise vormi keelama. Limiit peaks kehtima ka ühe kasutajakonto parooli taastamisel. Võimalik on, et kiri ei tulnud esimese korraga kohale, kasutaja suutis selle ära kustutada või soovib ta seda mingil põhjusel uuesti. Kui ta aga küsib järjest kontole parooli 3-4 korda on tegemist potensiaalse rünnakuga. Näiteks võib ründaja eesmärk olla su domeen liiga paljude kirjade korraga saatmisega SPAM filtrisse saada või vähemalt sihtmärgi e-posti aadress üle ujutada.
  • Iga uus parooli taastamine muudab vana lingi kasutuskõlbmatuks
  • Genereeritud parooli vahetamise linki saab kasutada ainult korra
  • Genereeritud parooli vahetamise link kehtib ainult fikseeritud aja jooksul
  • Genereeritud parooli vahetamise link ei sisalda vihjet kasutajakontole, mille parooli vahetatakse. Seda ei tohiks olla kuidagi võimalik ära arvata.

Veel võimalusi kasutajatesüsteemi turvamiseks

  • Kasuta kolmanda osapoolse kasutajatuvastust nagu Google või Facebook. Sellisel juhul ei pea sa ise muretsema kasutaja parooli turvamise pärast.
  • Kasuta sisselogimiseks ID kaarti või Mobiil-IDd. Kahjuks pole sellest palju kasu rahvusvaheliste keskkondade puhul.

 

Kasutajasüsteem on iga rakenduse selgroog. See peab olema tugev, et kõik koost ei kukuks.