Kuidas luua head parooli?

Paroolid on enimlevinud vahend küberruumis enese tuvastamiseks ja seetõttu otseselt või kaudselt üks küberkriminaalide peamisi sihtmärke. Personaalsete veebiteenuste kasutamiseks tuleb paratamatult end kuidagi identifitseerida, seega käib tänapäevane veebis surfamine läbi paroolirägastiku. Paljud arvutikasutajad lähevad lihtsama vastupanu teed ja kasutavad sama parooli mitmes erinevas kohas, sest kümnete erinevate salasõnade meeles hoidmine on liiga keeruline. Lisaks valitakse sageli turvariskist hoolimata parooliks midagi sellist, mis võimalikult kergesti meelde jääks, näiteks kombinatsioon oma sünniajast, mõne sugulase nimest, aadressist ja telefoninumbrist. Selline tegutsemine suurendab aga märgatavalt riski, et mõni pahatahtlik isik suudab parooliga kaitstud kontole ligi pääseda. Kuidas siis ikkagi luua hea parool ja see ka korralikult meelde jätta?

Levinud ja lihtsasti äraarvatavad paroolid Järgnevalt mõned näited viisidest salasõnade loomiseks, mida tasub vältida, sest neid on suhteliselt lihtne ära arvata:

1. Sinu partneri, lapse või kodulooma nimi (või nimetähed), millele sageli järgneb number 1, 12 või 123 (sest alatasa nõutakse, et parool sisaldaks ka numbreid).
2. Sünniaeg – kuupäev või aasta, millal sündisid või mõni muu tähtis kuupäev, mille Sinu facebooki sõber kerge vaevaga üles leida suudaks.
3. Sinu aadress – tänav, linnaosa, linn või riik.
4. Sinu enda või mõne lähedase telefoninumber, mis on aja jooksul pähe kulunud.
5. “tere”, “teretere”, “123456”, “qwerty”, “salas6na”, “Pa$$w0rd” või mõni muu laialdaselt levinud märgijada.
6. Kuulsuse nimi - poliitikud, sportlased, filmistaarid ja teised meediast tuntud isikud
7. Kombinatsioon eelnevalt loetletud punktidest, näiteks “tere1972” või “Rakvere123”

Õnneks ei lase enamik veebiteenuseid parooli mitu korda järjest proovida, kuid paraku ei ole harvad juhud, kus küberkurjategijatel õnnestub andmebaasidest kätte saada paroolide krüpteeritud räsi, mille abil veebiteenused paroolide õigsust kontrollivad.

Räsi leidmise algoritm peab olema ühesuunaline - see tähendab, et räsidest paroole tuletada on praktiliselt võimatu, kuid paroolist räsi tuletada on suhteliselt lihtne. Ründaja hakkab pärast edukat räside kättesaamist suurel kiirusel katsetama erinevaid paroole. Tänapäevasel lauaarvutil kulub http://www.passwordstrengthcalculator.org/index.php andmetel 8 kohalise salasõna (mis sisaldab väike- ja suurtähti ning numbreid) ära arvamiseks umbes 44 sekundit.

Näpunäiteid turvalise parooli loomiseks

Kuidas siis ikkagi luua turvaline parool, mis samas ka suhteliselt kergesti meeles püsiks? Mõned ideed meeldejääva parooli loomiseks:

1. Pikkus - mida pikem, seda parem, seega oleks kasulik sisestada salasõna asemel salalause, mis võiks sisaldada ka kirjavahemärke ning numbreid. Näiteks “Eile lõunaks sõin 2 õuna, 2 pirni ja ühe porgandi.” ära arvamiseks kuluks https://howsecureismypassword.net/ andmetel enam kui 10^60 aastat. Üldiselt tasuks kasutada vähemalt 12 märgi pikkuseid paroole.
2. Lisa suvalisi sümboleid keset parooli. Näiteks “va#alaskala”, “ka^namu?na”, “lauala~mp”
3. Kasuta suurtähti salasõna keskel. Näiteks “tuRvaline?paRool”, “salaJANEsõna”
4. Ainult endale arusaadav lühend pikemast lausest. Näiteks lausest “Küll on hea, kui õues on rohkem kui 0 kraadi” saab lühendi “Koh,kõ=rk0k.” ja lausest “Ruudulisel särgil on 2 varrukat ja 7 nööpi.” saab lühendi “#lisels=2v&7n”.
5. Slängi, erinevate keelte ja kirjavigade oskuslik kasutamine muudab paroole raskemini arvatavateks. Näiteks “Täiega tshill on 30-kraadises kontoris tšättida” või “Tavai, kus on tshekk-in nr7?”

Erinevate paroolide haldamine

Turvalisest paroolist üksi on aga vähe abi, kui sama parooli kasutada erinevates kohtades, sest nii on suur tõenäosus, et keegi kuskilt mõne salasõna kätte saab või ära arvab ning proovib leitud parooli ka teiste teenuste puhul. Kindlasti peavad unikaalse salasõnaga olema Sinu peamised meilikontod (tavaliselt üks tööga seonduv ning teine eraotstarbeline). Sotsiaalmeedia ja teised süsteemid, kus leidub olulisel määral isiklikku infot võiksid samuti olla omanäolise salasõnaga ning soovitatavalt ka mitmeastmeliselt turvatud. Vähemoluliste lehtedega võib kasutada mõnda järgnevatest strateegiatest:

1. Kasutada paroolihaldurit (nt KeePass või LastPass), mis oskavad ise turvalisi paroole luua ja meeles pidada. Paroolihalduri kasutamisel tuleks kindlasti valida unikaalne ja võimalikult turvaline üldparool.
2. Kasutada osade lehtede puhul kattuvat osa salasõnas ja lisada täiendeid vastavalt leheküljele. Näiteks võtame kattuvaks osaks eelnevalt pakutud “#lisels=2v&7n” ja lisame sellele Wordpressi jaoks “wordpr-S” ja Twitteri jaoks “twitt-R”. Lisades veel keskele @-märgi, saame salasõnadeks vastavalt “#lisels=2v&7n@wordpr-S” ja “#lisels=2v&7n@twitt-R”. Loodud salasõnu saab ka mõnes tekstifailis salvestada näiteks kujul “{*}wordpr-S” ja “{*}twitt-R” ning see on märksa turvalisem kui nende täielikul kujul hoiustamine oma virtuaalsete dokumentide hulgas või klaviatuuri alla peidetud märkmepaberil.

Ükskõik kui keerulisest paroolist on vähe kasu, kui ründajal õnnestub kuidagi klahvivajutusi või krüpteerimata võrguliiklust pealt kuulata või oskab veenvalt kasutajalt otse küsides vajaliku info kätte saada. Samuti tasub hoolikalt läbi mõelda turvaküsimused, mis esitatakse juhul, kui parool on ununenud. Kui vastus turvaküsimusele on triviaalne, siis on ründajal võimalik hoopis sealtkaudu kontole ligi pääseda. Paljud teenused saadavad parooli ununemise korral e-maili salasõna uuesti seadmiseks vajaliku viitega. Seega võimaldab ligipääs peamisele meilikontole muuta ära ka mitmeid teisi salasõnu. Seetõttu on lisaks tugevatele paroolidele äärmiselt soovitatav kasutada võimaluse korral mitmeastmelist autentimist näiteks ID-kaardi või mobiili abil.

Sten Mäses
ASA Quality Services

BugFever Kivimäe Põhikoolis

ASA Akadeemia käis 4. märtsil külas Kivimäe Põhikoolis, kus tutvustasime kaheksandale klassile tarkvara testimise kirevat maailma.

BugFeveri formaat näeb ette kolme komponenti:

• Tarkvara või süsteem, mida testitakse.
• Osalejad, kes tahavad testimist õppida ja praktiseerida.
• Väike teoreetiline ettevalmistus, mida praktikasse rakendada. 

Testimishuvilisteks olid kaheksanda klassi õpilased, kes, tuleb tunnistada, ei ole just ASA koolituste tavapärane sihtrühm. Seetõttu pidin olema tavalisest oluliselt ettevaatlikum igasuguste spetsiifiliste väljendite kasutamisega – ekvivalentsiklass, kompilaator, operatsioonisüsteem, spetsifikatsioon... Kuid väike teoreetiline ülevaade sellest, kuidas üldse tarkvara tehakse, miks vead on halvad ja kuidas neid raporteerida, on ju kindlasti vajalik. Kuidas seletada kaheksanda klassi õpilastele tarkvaraarenduse ja testimise põhitõdesid? Sellest saad täpsemalt lugeda siit.

Kindluse mõttes tegime pärast rollide tutvustust ka väikese hääletuse – kes õpilastest tahaksid olla pigem analüütikud, kes programmeerijad, kes testijad ja kes projektijuhid? Kõigisse rollidesse leidusid mõned huviliseid, kuid testijaks soovijaid oli kõige rohkem :).

Nüüd, kui tarkvara tegemine oli üldjoontes selgeks saanud, võisime asuda testimisega lähemalt tutvuma. Küsisin õpilaste käest, kas nad on kunagi mõne tarkvaravea otsa „koperdanud“. Tuli välja, et kõigil oli kunagi vähemasti „arvuti kokku jooksnud“ , ja kõik tunnistasid, et sellised apsakad on väga ebamugavad. Tarkvaravead ongi ebamugavad. Mõelda vaid, kui tahad saata e-kirja sõbrannale, aga tarkvaravea tõttu läheb see hoopis sinu emale... Rääkimata siis sellest, kui palju raha on sõna otseses mõttes „vastu taevast“ läinud näiteks kosmosetööstuses, kus nii mõnigi kallihinnaline kosmosetehnika on tarkvaravigade tõttu hävinenud.

Huvitav statistika on võib-olla seegi, et hinnangulised iga-aastased tarkvararavigade kahjud USAs [1] on umbes 6 korda suuremad kui Eesti riigi tulud 2013. aastal [2]. Niisiis on testimine üks vajalik tegevus, et vead üles leida enne, kui mõni kosmoserakett õhku lendab, lennuk alla kukub või arvuti kokku jookseb.

Kuidas testida?

Nagu juba varem öeldud – pane testitav tarkvara igasugustesse olukordadesse, mida vähegi suudad välja mõelda. Kindlasti proovi teha ka selliseid tegevusi, mida „ükski normaalne inimene kunagi ei tee“. Sellepärast, et tegijal juhtub nii mõndagi, ka selliseid asju, mida ei tohiks. Samuti võib vigade ilmnemine sõltuda sellest, missugust arvutit, tahvelarvutit, telefoni,  brauserit, ID-kaardi lugejat ja muid seadmeid sa testimisel kasutad. Ka keskmisest pikemad ning täpitähti ja sidekriipsu sisaldavad nimed on head testimisel kasutamiseks. Kui mõni väli on märgitud aga täitmisel kohustuslikuks, siis õige testija kontrollib alati järele, mis juhtub siis, kui see tühjaks jätta.

Tihti juhtubki nii, et mõni funktsionaalsus ei tööta. Siis peab testija kirja panema, mis siis ikka täpselt ei tööta, sest ega testija ise ühtegi viga ei paranda, seda teeb programmeerija. Vigade raporteerimine on ka paras kunst, aga kui meeles pidada lihtsaid reegleid, siis on see tegelikult päris lihtne:

• Pane oma bugile lühike kokkuvõtlik nimi, näiteks „Firefoxiga ID kaardiga sisselogimine ei õnnestu“.
• Kirjelda putukat nii, et ka teised (näiteks programmeerijad) selle ära tunneksid ja üles leiaksid – soovitavalt sammude kaupa.
• Kirjelda keskkonda, kus putukas „elab“ – missuguse operatsioonisüsteemi, brauseriga viga avaldus.
• Kirjelda, kui „mürgine“ see putukas on – kas surmav, või lihtsalt tüütu kõrva ääres piniseja. 

Ega hea testija ei ole see, kes ainult palju vigu leiab. Testimata tarkvara ja testitud tarkvara on täpselt sama head (halvad), sest ainult testimine ei tee tarkvara paremaks. Hea testija on see, kes annab teistele osapooltele (programmeerija, projektijuht, analüütik) võimalikult kvaliteetset infot tarkvara paremaks tegemiseks.

Pärast teooria selgitamist jagasime ülesanded kätte ning kõik grupid mõtlesid esmalt välja, missugustes olukordades nad oma tarkvarasid proovile panevad, ning siis läks juba testimiseks. Testisime näiteks Facebooki, Gmaili ja Forumcinemas kinokavasid. Lõppkokkuvõttes leidis iga grupp midagi, mis korralikult ei töötanud või võiks olla paremini arusaadav.

Pean kaheksandikke kiitma – võrreldes näiteks ülikooli IT tudengitega, kes on juba mõned aastad õppinud tarkvara arendamist, olid kaheksandikud palju avatuma suhtumisega testimisse. Ülikooliõpilastel on miskipärast juba päris tugevalt juurdunud mõtteviis: „ainult nõrgad teevad vigu“, „ega ükski normaalne inimene nii ju ei kasuta seda süsteemi“, „seda pole vaja kontrollida“ jne. See paneb mind mõtlema, mis „juhtuks“ siis, kui testimise baaskursus oleks noortele IT-inimestele kohustuslik aine esimesel õppeaastal?

Minu jaoks oli see kindlasti huvitav ja teistmoodi kogemus, kus sõnade ja näidetega pidi väga ettevaatlikult ümber käima, kuna minu ja kuulajate taustsüsteemid on väga erinevad. Loodan, et mõne osalejaga kohtun ka mõne aasta pärast ülikoolis ja võib-olla kunagi hiljem tööl.

Lõpetuseks ka üks tagasiside üritusel osalenud õpilaselt:

„Koolis toimunud arvuti tund. Minu arust oli see üritus väga tore ja põnev. Sain teada seal uusi asju tegeliku interneti maailma kohta. See andis mulle infot olla hoolikam internetis. Kõik, mis me seal õppisime, oli uus ja huvitav, igav ei hakanud. Meie grupil õnnestus päris hästi testimine, minu arust. Ühesõnaga see oli väga tore üritus!“

Maili Markvardt
ASA Quality Academy

Maili on Eesti Testijate Liidu asutajaliige ja kuulub ka ETLi juhatusse. Ühtlasi õpetab ta tarkvara kvaliteediteemasid Tallinna Tehnikaülikoolis ja Eesti Infotehnoloogia Kolledžis. "Testimine ei ole elukutse, testimine on elustiil!"

Kuidas seletada tarkvaraarendust 15-aastastele?

Tarkvara on tänapäeval kõikjal meie ümber: juba algkooliõpilased teavad ja on mänginud arvutimänge ning kasutanud nutitelefoni app’e. Kõik need suuremad ja väiksemad programmikesed kokku võetavad üldise mõiste tarkvara alla ning nende loomine ongi tarkvaraarendus.

Nagu maja ehitamisel ei piisa ainult müüriladujatest, on ka tarkvara loomisel vajalikud erinevad rollid. Kõige tähtsamad on tarkvara kasutajad – neist ja nende soovidest ja vajadustest algab kogu tarkvaraarendus, ja nende juures see ka lõpeb – valmis tarkvaraga. Tarkvaraarenduse ülimaks eesmärgiks on teha kasutaja õnnelikuks ja rahulolevaks :). Analüütik on see inimene, kes kogub kokku, mõtleb läbi ja paneb ilusasti kirja kõik selle, mida kasutajatele õnneks vaja oleks. Analüütikut tunned muuhulgas selle järgi, et talle meeldib teisi kuulata, infot süstematiseerida ja ka on ta väga hea kirjandite kirjutamisel.

Edasi läheb analüütiku kirjutatud „kirjand“ (ehk nõuded loodavale tarkvarale) programmeerija kätte. Tema on see, kes tarkvara tegelikult valmis programmeerib. Head programmeerijat iseloomustab vaimustumine tehnoloogiast ja uute oskuste õppimisest, aga samas ei pea ta olema tihti tähelepanu keskmes, vaid saab päris hästi hakkama ka siis, kui ainult analüütiku ning lähemate kolleegidega suhtleb.

Kui programmeerija on tarkvara enda meelest valmis saanud, siis tuleb mängu testija, kes seda kontrollib ja igakülgselt proovile paneb. Testija hea omadus on see, et ta ei pea mõtlema nagu kõik teised, vaid peabki mõtlema „kastist väljas“, ja ühtegi eksperimenti ei saa testijale pahaks panna. Testija on nagu detektiiv või varanduseotsija – hüljatud lossi on peidetud teadmata arv aardeid, ning testija ülesandeks on need kõik üles otsida. Mida kavalam, tähelepanelikum ja järjekindlam ta on, seda rohkem aardeid ta üles leiab. Tarkvara testimisel on aarded muidugi vead tarkvaras ehk bugid.

Kui kõik bugid on üles otsitud ja ära parandatud, siis jõuab tarkvara oma lõppkasutajateni, kes loodetavasti on õnnelikud :).

Aga ega koostöö alati ei suju ja suuremad ja väiksemad takistused on elu tavapärane osa... seega on veel üks oluline roll tarvis ära rääkida – projektijuht loomulikult. Projektijuht ise ei tee suurt midagi (ei kirjuta nõudeid ega koodi ja ka ei testi, kas tuli hea välja), aga ometigi on ta vajalik, et projekt püsiks ajakavas ja komplikatsioonide korral oleks kõigil selge, kuidas edasi toimida.

Kui sul on kunagi vaja 15-aastastele tarkvaraarenduse alustalasid selgitada, võid eeltoodut julgelt kasutada. Lähenemine on testitud ja töötas.

Kui aga tundub, et tahaks vastu vaielda või täiendada, kasuta siinsamas postituse all olevat kommenteerimiskasti. Me ei hammusta! :)

Maili Markvardt
ASA Quality Academy

Maili on Eesti Testijate Liidu asutajaliige ja kuulub ka ETLi juhatusse. Ühtlasi õpetab ta tarkvara kvaliteediteemasid Tallinna Tehnikaülikoolis ja Eesti Infotehnoloogia Kolledžis. "Testimine ei ole elukutse, testimine on elustiil!"