Teeme selgeks: mis asi on HTTPS ja miks peaks selle enda kodulehele lisama?

Tõenäoliselt on sullegi mõnda veebilehte külastades brauseriribalt silma jäänud, et sellesama saidi aadressi alguses on kunagise standardi “HTTP” asemel “HTTPS”. Tavalisele internetikasutajale ei pruugi see suurt midagi öelda, ent tegelikkuses on tegu ühe olulisima turvalisust puudutava elemendiga veebis.

Mida kujutab endast HTTPS, miks see oluline on ja kuidas seda oma kodulehele lisada?

Turvalisem ja lihtsasti leitavam veeb

Mõistagi liigub erinevatest kodulehtedest ja e-poodidest läbi väga palju tundlikku informatsiooni ja on enesestmõistetav, et päris igaüks ei tohiks seal olevatele andmetele ligi pääseda.

Siin tulebki mängu HTTPS, mis tagab turvalise andmete edastamise. Sisuliselt krüpteerib see saadetava info ära taolisel viisil, et ainult selle vastuvõtja saab seda näha. Kui veebilehel puudub HTTPS tugi, siis tähendab see seda, et kogu internetis liikuv info on avalik ja sellele pääsevad ka kõrvalised osapooled lihtsa vaevaga ligi.

Osad brauserid isegi näiteks hoiatavad külastajat veebilehtede eest, mis ei kasuta krüpteeritud ühendust.

Inimesed on internetiturvalisuse osas üha teadlikumaks saanud, mistõttu on HTTPSi lisamine iga äriga seotud veebi jaoks ülimalt tähtis, sest nii tagad enda klientidele kindlustunde, et nende isiklikud andmed kellegi teise kätte ei satuks.

Samuti mõjutab HTTPS-i olemasolu ka suuresti SEO-d. Nimelt tõstavad paljud otsingumootorid tahapoole need veebisaidid, mis ei kasuta turvalist ühendust. Mõnel juhul võidakse see üldsegi blokeerida otsingutulemustest.

Kuidas HTTPS oma kodulehele lisada?

HTTPS-i lisamine kodulehele ei nõua õnneks spetsiaalseid IT-alaseid teadmisi ning sellega saab hakkama peaaegu igaüks. Kui sinu veebilehte majutab Zone, siis ei pea isegi muretsema selle pärast, sest seal on kõikidel uutel veebidel aktiveeritud Let’s Encyrpti automatiseeritud sertifikaaditeenus, mida kasutatakse HTTPS-i pakkumiseks. Küll aga võib veebirakenduse seadistamine vajada pisut seadistuste muutmist ja teatavatel juhtudel pisiparandusi koodis. Kui peaksid hätta jääma, siis küsi julgesti abi meie klienditoelt.

Kui su veebilehel ei peaks mingil põhjusel veel HTTPS tuge olema, siis selle aktiveerimine on ülimalt lihtne. Let’s Encrypt sertifikaadi tellimine virtuaalserverisse on võimalik läbi serveri halduse menüüst Veebiserver -> Let’s Encrypt. Lahtrist vali hosti nimi” võta oma domeeninimi ja klõpsa “Genereeri Let’s encrypt sertifikaat”. Ja 15 minuti möödudes võimaldabki sinu veebiserver edaspidi HTTPS ühendusi.

Käesolev blogipostitus on sündinud koostöös DigiGeeniusega.

Küberilm lubab turbulentsi, tuletame instruktsioone meelde

Täna meenus mulle jutt piloodist, kes hiljuti õnnetuse toimumipaigaks olnud rajale lennukit ruleerides teavitas oma reisijaid: “Kogenumad teie hulgast meie turvainstruktsioone tavaliselt ei vaata, aga äkki täna…?”

Küberturbevaldkonna inimestel on tihti mure, avades suu rääkimaks järjekordselt riskide maandamisest lülitab suur osa publikust end teisele lainele – kõike seda on ju kuuldud!

Kuid vaadates Euroopas toimuvat on internetikasutajatel kindlasti asjakohane küsida endalt… aga äkki täna?  Eksisteerib käegakatsutav oht, et hoolimatusest tingitud viga või laiskusest ripakil ressurss muutub tahtmatult kuritöövahendiks või osaks võõrvõimu digitaalsest sõjamasinast.

Seepärast kordan taaskord meie “lennueelset” ohutussõnumit, toetudes Zone enda kasutatavatele reeglitele ja teistele kolleegidest “lennusaatjatele”.

Kahe faktoriga autentimine

Kus vähegi võimalik, lülita sisse kaheastmeline autentimine. See tähendab, et teenus hakkab sinult lisaks salasõnale (mida sa tead) küsima mõnd täiendavat faktorit, näiteks midagi mis sul on.

Zone võimaldab kahetasemelist autentimist kasutada nii ZoneID juures kui ka veebipõhise e-posti kliendi juures. Mõlema puhul on toetatud Google Authenticatori ja teiste sarnaste rakenduste poolt kasutatav TOTP standard.

ZoneID toetab lisaks oma olemuselt kahe faktoriga autentimisvahendeid nagu ID-kaart, Mobiil-ID ja Smart-ID. Zone veebipõhine e-post toetab ka U2F riistvaravõtmega sisselogimist, kui kasutada vähegi uuemat brauserit.

Kui ZoneID kasutajakonto on seotud ID-kaardi, Mobiil-ID või Smart-ID autentimisvahendiga, tasub salasõnaga autentimine üldse välja lülitada.

Turvalise autentimise kasutamise kohta leiab lisamaterjale meie kasutajatoe lehtedelt:

ZoneID: https://help.zone.eu/kb/turvaline-autentimine/

E-post: https://help.zone.eu/kb/e-posti-2fa/

Salasõnad (-fraasid)

Veendu, et sinu poolt kasutatavad salasõnad oleksid turvalised. Meie soovitame, et salasõnad oleksid vähemalt 10 tähemärki pikad, maksimaalset pikkust ei ole. Mõtle salasõnast pigem kui salafraasist.

Fraas ei sobi salasõnaks, kui:

  • see on sõna või kohanimi sõnaraamatust (näited: “Kalamaja”, “Ameerika”, “Secret”)
  • see sisaldab kasutaja kasutajanime või teenuse nime (näited: “ZoneID123”, “DataZone666”)
  • see koosneb korduvatest või järjestikustest märkidest (näited: “aaaaaaaaaaaa” , “abcdefghi”, “12345678”)
  • see esineb varem lekkinud paroolide nimekirjas (näiteks “Have I been pwned” poolt avaldatud nimekirjas).

Salasõnade säilitamiseks tuleb kasutada selleks ette nähtud spetsiaalset tarkvara. Meie soovitame kasutada Bitwarden (https://bitwarden.com/) nimelist avatud lähtekoodiga tarkvara, mille kasutusõigus on tasuta.

Salasõnade teemal on varem siin blogis kirjutanud minu kogenumad kolleegid:

Veel kord paroolidest

 

Ära seda soovitust jälgi: täna on rahvusvaheline paroolivahetamispäev

E-Post

Võta vastu ja edasta oma e-kirju ainult turvatud transpordikihiga (TLS ehk Transport Layer Security) ühenduse kaudu. Kui saad serveriga ühendumisel TLS sertifikaadi valideerimisvea, ära proovi sellest mööda minna.

Enne e-kirjadele lisatud failide avamist või e-kirjades olevatele URL-aadressidele klõpsamist ole äärmiselt ettevaatlik ja veendu, et see on ohutu. Võimalusel eelista selleks isoleeritud keskkonda, mis ei jaga teavet kolmandate osapooltega. Kui tegemist ei ole konfidentsiaalsete andmetega, võid  faili kontrolliks kasutada https://www.virustotal.com/ keskkonda.

Kui saad kirja, mis puudutab rahalisi transakstioone või mis nõuab salasõna lähtestamist, seadistamist või avalikustamist, tuleb sellise kirja autentsus kindlasti üle kontrollida, kasutades alternatiivseid kanaleid. Väiksemagi kahtluse puhul tuleb konsulteerida oma infoturbespetsialistiga või teadlikuma kolleegiga.

Näiliselt Zone poolt saadetud kirjade autentsuses on võimalik alati veenduda meiega ühendust võttes.

Tööjaamade ja seadmete turvalisus

Varustage kõik oma Windows, MacOS või Android seadmed pahavara tuvastamise ja ennetamiseks vajaliku tarkvaraga.

Microsoft Windows sisaldab vaikimisi küllaltki suurepärast Windows Defender tarkvara, tasub veenduda, et see on sisse lülitatud või sellele on alternatiiv. Mitmetel spetsiaalse tarkvara pakkujatel on olemas tasuta versioonid, nende võrdluse leiate näiteks aadressilt https://www.pcmag.com/picks/the-best-free-antivirus-protection

Veebirakenduste turvalisus

Uuendage kindlasti oma veebirakendusi.

Kui olete endale paigaldanud veebirakenduse Zone+ abil, veenduge, et see on jäänud väikesätetesse - ehk Zone uuendab rakendust teie eest automaatselt. Muutke seda ainult äärmisel vajadusel.

Kui olete veebirakenduse paigaldanud iseseisvalt, kontrollige, kas see uueneb automaatselt või vajab käsitsi uuendamist. Kui rakendus vajab uuendamist, tehke seda ja kontrollige edaspidi uuendusi regulaarselt.

Koristage oma veebiserveritest vana träni! Suurel osal juhtudest kui mõne meie kliendi veebileht kompromiteeritakse, on põhjuseks asjaolu, et seal vedeleb reaalselt kasutuses oleva veebirakenduse kõrval üks või mitu koopiat, mida keegi ei uuenda. Tavaliselt on need veebilehe varasemad versioonid ja arenduseks või testimiseks kasutatavad versioonid. Ka seda teemat on siinsamas blogis kajastatud:

“Teeme ära” koristustalgud sinu (tehtud) veebis – kõik /uus, /vana, /arhiiv ja /newsletter välja!

Turvamata WiFi võrgud

Ära kasuta oma e-posti lugemiseks või veebirakenduse haldamiseks avalikke või turvamata traadita võrke. Soovitame pigem kasutada oma telefoni "hot-spot" funktsionaalsust, veendudes ka selle salasõna turvalisuses.

Kokkuvõtteks

Suur tänu, kui vaevusid need nõuanded lõpuni lugema.

Lisalugemiseks soovitame viia end kurssi ka nippidega, mida jagab Riigi Infosüsteemi Amet aadressil https://www.itvaatlik.ee/.

Jääge turvaliseks ja terveks!

Log4Shell turvanõrkus

Käesolevas postituses teeme kiire ülevaate infotehnoloogia maailma tormina tabanud turvanõrkusest Log4Shell ja sellest, kuivõrd see mõjutab (või ei mõjuta) Zone kliente.

Möödunud 24 tundi on olnud ülemaailmselt infotehnoloogia valdkonna jaoks pingelised. 

Maailma ühe eelistatuma tarkvaraarendusplatvormi Java populaarsest logide käitlemise raamistikust Log4j avastati turvanõrkus (https://nvd.nist.gov/vuln/detail/CVE-2021-44228), mida on väga lihtne ära kasutada. Nõrkuse edukal ekspluateerimisel on ründajal võimalik panna ohvri server, arvuti vms seade  oma pilli järgi tantsima. Seepärast on nõrkus saanud endale ka vastava nime: Log4Shell.

Nagu arvata võite, siis on süsteemiadministraatorid, tehnikud ja tarkvaraarendajad jt üle maailma  rakkes sellega, et maandada selle nõrkusega seotud riske.

Sellest, kuivõrd laialdane on selle intsidendi mõju, annab aimu järgmine nimekiri mõjutatud ettevõtetest ja platvormidest: https://github.com/YfryTchsGD/Log4jAttackSurface

Nõrkus saab ilmneda pea igas situatsioonis kus üritatakse logida midagi, mis saabub ründajalt. Olgu see siis kasutaja veebibrauseri User Agent või vea tekitanud sisend. Turvaauk tekkiski sellest, et logimise mugavdamiseks mõeldud funktsionaalsus oli kättesaadav igale logisõnele mis log4j-ni jõudis. Võimalus küsida lisainfot JNDIga suvalisest LDAP kataloogiserverist (sellest ka näidetes leiduv jdni:ldap:// osa) võimaldab serverisse tõmmata täiesti ründaja valitud Java objekte. See on juba püha graal igale ründajale.

Zone poolt hallatud veebimajutusteenuste osas oli Log4j nõrkuse ärakasutamise risk õnneks minimaalne, ka täiendavaid turvameetmeid rakendamata.

Meie pakutavas platvormis pole lihtsalt kuigi palju Java põhiseid komponente, mis seda teeki kasutaks. 

Välja toomist tasub neist vaid üks – Elasticsearch, aga Zone teenuste raames kliendile pakutav Elasticsearch instants pole interneti kaudu saabunud külastajatele või teistele klientidele ligipääsetav, mis maandab nii selle kui ka teiste sarnaste nõrkuste ärakasutamise riski.

Sellegipoolest rakendasime juba eile Elasticsearchi osas täiendavaid turvameetmeid, et takistada teadaolevaid nõrkuse ärakasutamise meetodeid.

Meie kliendid peaksid siiski pöörama tähelepanu sellele, et nende tarkvaraarendajad või veebimeistrid võivad olla ise paigaldanud meie serveritesse tarkvara, mis Log4j kasutab. Selline tarkvara vajab kindlasti uuendamist või nõrkusega seotud riskide maandamist.

Täiendus: Ilmselt on üks levinumatest mõjutatud rakendustest Minecraft, kui teil tiksub kuskil pilve nurgas mõni ununenud Minecrafti server, siis nüüd on õige aeg sellega tegeleda!

Soovitame teemast huvitatutele ja mõjutatutele jälgimiseks järgmist Redditi jutulõime: https://www.reddit.com/r/netsec/comments/rcwws9/rce_0day_exploit_found_in_log4j_a_popular_java/

Rõhutame ka, et üldlevinud rakendused nagu WordPress, Drupal, Joomla ja nende laiendused, ei kasuta reeglina Java põhiseid komponente, mis võiksid sõltuda Log4j teegist.

Kas Internet läheb katki?

30. septembril 2021 aegub Let’s Encrypt „DST Root CA X3“ sertifikaat ja teeb nii mõndagi internetis katki!“ Sellised uudised on pannud muretsema ka Zone kliente, sest valdav enamus meie klientide veebilehti kasutab just Let’s Encrypt sertifikaate.

Ütleme kohe siin alguses ära, et kui sa enam kui viis aastat vana operatsioonisüsteemi (Windows, Android) ei kasuta, siis ei lähe sul katki mitte midagi.

Kes ja kui palju muretsema peab ning mis täpselt ikkagi katki läheb, sellele püüamegi alljärgnevalt veidi valgust heita.

Kõigepealt natuke sellest, mis asi on üldse serveri sertifikaat.

Kui klient (brauser, meiliklient või mõni muu rakendus) loob ühendust serveriga, siis tahab ta veenduda, et tegemist on tõepoolest selle serveriga, millega ühendust luua soovitakse. Et klient seda teha saaks, saadab server kliendile oma digitaalse tõendi (sertifikaadi), kus on põhimõtteliselt kirjas: „Käesolevaga tõendan, et selle sertifikaadi esitaja on tõepoolest server pank.ee.“

Kuid igaüks võib ju nii öelda? Nagu hunt kitsetalledele? Kuidas klient teab, et server ei valeta ja tegemist on tõepoolest pank.ee serveriga?

Sertifikaat, mida klient tegelikult usaldada saab, pole niisama tõend, vaid digitaalse notari (CA – Certificate Authority) poolt ka allkirjastatud. Kliendi usaldus rajaneb ainult sellel allkirjal – kui digitaalse notari allkiri serveri sertifikaadil on õige ja hetkel ka kehtiv, siis usaldab klient ka sertifikaadis olevat infot. Kui sertifikaadil puudub usaldusväärse notari allkiri või on see aegunud, sertifikaati ei usaldata ja ühendus katkestatakse.

Kuna usaldus rajaneb ainult notarite allkirjadele, siis on info usaldusväärsete notarite kohta ülihästi valvatud. See info (so notarite sertifikaadid) on tüüpiliselt kaasas iga op-süsteemiga ning notarite lisamine usaldusväärsete hulka on väga pikk ja keeruline protsess.

Oletame, et turule tuleb uus digitaalne notar ning läbib mõne aastaga ka sertifitseerimisprotsessi ning tema sertifikaat saab usaldusväärsete hulka lisatud. Millal kõik opsüsteemide tootjad selle info oma uuendustega kaasa panevad? See võib võtta omakorda aastaid ja see lahendab probleemi ainult nende süsteemidega, mis uuendusi ka saavad. Internetis on igapäevaselt kasutusel ka sadu miljoneid seadmeid, mis enam uuendusi ei saa ning selleks läheb omakorda aastaid kuni nende kasutamine lõpetatakse. Realistlikult peaks uus diginotar ootama ca 10 aastat, enne kui ideest teostuseni ehk sertifikaatide allkirjastamiseni jõuab.

Just selle probleemiga seisis silmitsi Let’s Encrypt, kui ta asutajad 2012. aastal tasuta sertifikaatide pakkumise idee realiseerimisega algust tegid. Ometi jõudsid nad sertifikaatide väljastamiseni juba 2015. aasta sügisel. Kuidas?

Let’s Encrypt kasutas ära juba olemasolevaid notareid. Kliendid on seni usaldanud Let’s Encrypt poolt allkirjastatud sertifikaate kahel juhul:

1) Neil on info, et Let’s Encrypt sertifikaat „ISRG Root X1“ ning sellega allkirjastatud serveri sertifikaadid on usaldusväärsed. Need on süsteemid, mis on saanud diginotarite info uuendusi pärast 2015. aastat.

2) Neil on info, et diginotarid, mis on allkirjastanud Let’s Encrypt sertifikaadi „IdentTrust DST Root CA X3“, on usaldusväärsed. Sellega tagati Let’s Encrypt sertifikaatide usaldusväärsus ka neile opsüsteemidele ja rakendustele, mida 2015. aastal enam ei uuendatudki.

Mis siis 30. septembril täpsemalt juhtub?

Valdava enamuse Zone klientide jaoks ei juhtu midagi. Siis aegub „IdentTrust DST Root CA X3“ sertifikaat ning sellega kaotavad kehtivuse kõik sellega antud allkirjad. Kõik kaasaegsed opsüsteemid, brauserid jm rakendused saavad Zones majutatud veebe ja muid rakendusi probleemivabalt edasi kasutada. Probleeme võib tekkida AINULT siis, kui soovitakse kasutada opsüsteeme või brausereid, mis pole pärast 2015. aastat uuendusi saanud.

NB! Täpsemat infot probleemsete opsüsteemide ja rakenduste kohta leiab aadressilt https://letsencrypt.org/docs/certificate-compatibility/ – KÕIK süsteemid, mis on üles loetletud sektsioonis “Platforms that trust ISRG Root X1”, saavad probleemivabalt ühendust Let’s Encrypt sertifikaate kasutatavate serveritega ka pärast 30. septembrit.

Küll aga pole Let’s Encrypt sertifikaadid enam usaldusväärsed süsteemidele, mis ei tea „ISRG Root X1“ sertifikaadist midagi – so peamiselt vanad opsüsteemid, mis pole pärast 2015. aastat uuendusi saanud. Mida teha, kui on soov sellise süsteemiga Zones asuvat serverit edasi kasutada?

Kui sul on selline süsteem ja soovid Let’s Encrypt sertifikaadiga veebilehti ja -rakendusi edasi kasutada, siis on võimalus lisada „ISRG Root X1“ ise käsitsi süsteemi. Täpsemad juhised sõltuvad süsteemist ja veebiotsing võtmesõnadega “add root ca” koos sinu süsteemi või rakenduse nimega aitab kindlasti.

Kui sa oled Zones serveris asuva veebi omanik, kasutad praegu Let’s Encrypt sertifikaati, kuid sinu klientidel või sul endil on millegi pärast palju selliseid vanu süsteeme, siis on võimalik loobuda Let’s Encrypti kasutamisest ja võtta kasutusele mõne teise diginotari sertifikaat. Need on küll tasulised, kuid neid usaldavad ka vanemad seadmed.

Kui jääd hätta, siis abistab sind meie klienditugi.

Ära seda soovitust jälgi: täna on rahvusvaheline paroolivahetamispäev

Tõepoolest, väidetavasti on 1. veebruar “change your password day” ning seega äärmiselt sobilik hetk rääkida … tõsiselt halbadest infoturbe-nõuannetest.

Me oleme paroolidega seotust kirjutanud korduvalt: nt Hasso pikem lugu Veel kord paroolidest, siis täpselt seal välja toodud halva parooli-nõuande kasutamise tulemusest Nõrgast paroolist häkitud WordPressini 42 katsega ja loomulikult rahvusvahelise mõõtmega “Paha Panda” varastab postkaste.

Häid nõuandeid jagab aga NIST, mille “Special Publication 800-63B” võtab arvesse seniste parooli-reeglite tekitatud ebaturvalised käitumismustrid. Võid selle spikriks kõrvale võtta ja proovida vastata küsimusele:

Millised järgnevatest EI OLE NIST’i nõuded turvalisele paroolile?

(õiged vastused postituse lõpus)

  1. peab olema vähemalt 10 märki pikk
  2. peab olema vähemalt 8 märki pikk
  3. peab olema vähemalt 6 märki pikk, võib koosneda ainult numbritest
  4. peab sisaldama suur- ja väiketähte, numbrit, märki
  5. peab vähemalt X kuu järel vahetama
  6. ei tohi olla sama, mis viimased X parooli
  7. parooli või kasutajanime sisestamise lahtris ei tohi toimida copy ja paste
  8. ei tohi sisaldada nime, järjestikuseid märke, levinud salasõnu

Kasutasin seda nimekirja just turva-teemalisel esinemisel ja tuleb tunnistada, et paljud kuulajad noogutasid täpselt valede kohtade peal. Põhjuseks see, et IT-osakonnad jõustavad endiselt iganenud reegleid ning neid tirazeeritakse endiselt nii paberil kui digitaalses meedias.

Milline on siis hea ja milline halb reegel?

Hea parooli-nõue on selline, mis ei koorma liigselt kasutajat ning ei sunni teda ebaturvalisele optimeerimisele – inimene pole rumal, küll aga evolutsiooniliselt harjunud leidma kõige tõhustamat teed seatud eesmärgi saavutamiseni. Samas peaks see reegel aitama infosüsteemide arendajatel ja haldajatel meid kaitsta.

Näiteks – selleks, et parooli ei saaks N korda proovides ära arvata, peaks rakendus suutma sellist rünnet tuvastada ja takistada (konto ajutiselt lukustama), ent samas vältida teenustõkestusrünnet läbi kontode lukku ajamise.

Levinud tavad nagu sage vahetamine ja keerukusnõuded annavad aga soovitule vastupidise tulemuse: kasutaja lisab sõnale mõne numbri ja märgi ning siis suurendab sammhaaval numbrit või kasutab selleks aasta-arvu.

Kaks reeglit, mille puhul tasub viidata sellel blogipostile:

  • märgi-põhised keerukusnõuded
  • parooli kohustuslik vahetamine iga X ajavahemiku järel (aga: NIST nõuab vahetamist juhul kui  on kahtlus, et see on lekkinud)

3+2 lihtsat reeglit, mida järgida

  • salasõna asemel räägime sala-fraasist – veidi pikem isekomponeeritud liitsõna või sõnamäng/kalamburism on väga hea (jalgpallisupikulp, lumehangumine, vt insipratsiooni twitter.com/keitivilms)
  • ära kasuta sala-fraasis enda või kasutuskoha nime, levinud (sala)sõnu (Passw0rd!, kalamaja) ja järjestikuseid märgijadasid (q1w2e3r4)
  • oluliste teenuste jaoks (töökoha kasutajakonto, e-post, sotsmeedia) kasuta unikaalset sala-fraasi

Sellega on 98% tööd tehtud, kaks veidi suuremat pühendumist nõudvat soovitust on aga veel:

  • lülita olulistes teenustes (e-post, sotsmeedia) sisse kaheastmeline autentimine (2fa ehk two-factor authentication – nt SMSiga saadetav turvakood)
  • kasuta parooliseifi (LastPass, 1Password, KeePass, BitWarden) unikaalsete paroolide loomiseks ja haldamiseks, pea meeles ainult üks tugev ehk seifi sala-fraas

Viimase punkti juurde vihjeks, et KeePass on täiesti tasuta ja LastPassis saab erakonto teha tasuta (ja kui su tööandja peaks LastPassi ametlikult kasutusele võtma saad era- ja töökontole ligi ühe sisselogimisega – seejuures mõistagi nii, et tööandja EI SAA sinna ligi 🙂

Ja lõpuks…

See paroolivahetuspäev on Gizmodo klikimeelitustrikk aastast 2012, seeria viimane lugu kannab muideks pealkirja Don’t Change Your Password ning jõuab umbes samade soovitusteni ehk “ära vali lolli parooli”.

Kui su IT-osakond Gizmodot adekvaatseks allikaks ei pea, siis olgu öeldud, et maikuus on tulemas World Password Day ning TheRegister on selle kokku võtnud pealkirjaga It’s World (Terrible) Password (Advice) Day!


Õige vastus – NISTi nõuded EI OLE 1, 4, 5, 6, ja 7.