Autentisering

En virksomhetsgodkjent passordmanager løser den største utfordringen knyttet til håndtering av passord. At gode passord er lange, tilfeldige og unike - med andre ord tilnærmet umulige å huske.

Passordmanageren løser dette ved å redusere antall passord man må huske til passordet for PC-en og passordet for passordmanageren

Det er viktig at passordmanageren er satt opp slik at den er enkel å ta i bruk og bruke, og at det er en passordmanager tilgjengelig i hvert enkelt domene virksomheten har.

For de som vil lese mer om fordeler og ulemper med passordmanager generelt har Troy Hunt en god artikkel om temaet.

Innloggingsmetoder basert på smartkort med PIN-kode, biometri som fingeravtrykk og ansiktsgjennkjenning vil ofte betydelig kunne lette hverdagen for de som skal ha tilgang. De vil innføre noen nye angrepsvektorer, men ikke av typen som kan utnyttes remote, eller i stor skala. I sum vil de gjøre autentisering lettere, raskere og sikrere. For ekstra kritiske enheter/informasjon kan denne vurderingen være annerledes, men for alt av systemer man bruker i det daglige anbefaler vi at alternative innloggingsmetoder tillates hvor mulig.

Det er likevel viktig at det finnes alternative måter å få tilgang på. Dette for å unngå eksempelvis at skader på fingertupper gjøre at fingeravtrykk plutselig ikke fungerer som forventet.

Betinget tilgang, conditional access, på engelsk går ut på å kombinere forskjellige "faktorer" for å vurdere om en innlogging skal godtas eller ikke. Slike faktorer kan være passnøkler, passord, sertifikat fra innrullert enhet, hvor innlogging kommer fra (IP), Windows Hello,med mer.

Vi anbefaler at man krever
- Innrullert enhet[1] og passord/passordløs autentisering

ELLER
- Passnøkler

Merk at disse med fordel kan kombineres slik at det kreves passnøkler om bruker ikke sitter på en innrulelrt enhet.

Bruk av passord + flerfaktor anbefales IKKE da det er sårbar for phishing som beskrevet i et eget webinar.

[1] Innrullert enhet vil si en enhet som er administrert av virksomhet. Dette kan være en mobiltelefon med Intune, eller lignende løsninger på. Eller en laptop med sertifikat fra virksomhet installert. Dette vil typisk ekskludere BYOD-enheter. Disse vil da måtte gis tilgang med bruk av passnøkler.

Vi anbefaler at man bruker
- Enten: Fysisk MFA-token/kodegenerator (det sikreste)
- Eller: Kodegenerator på mobil (det enkleste)

Dette bør brukes på alle tjenester som vurderes som kritiske, og for alle administratorroller.

Vi anbefaler at man IKKE bruker SMS-basert MFA.

MFA er et veldig godt mottiltak mot gjenbruk av passord, svake passord og passord på avveie. Merk at MFA i seg selv IKKE beskytter mot phishing. For phishingbeskyttelse se punktet om betinget tilgang.

Vi har flere webinar som dekker dette teamet:
Hva finnes av MFA
Svakheter i MFA

Kort introduksjon til MFA:

Kritiske tjenester bør ikke være direkte nåbare fra internett noe som naturlig reduserer angrepsflaten deres. De bør likevel sikres med MFA for å forhindre at en angriper som har fått en fot innenfor enkelt kan skaffe seg tilgang videre.

Multifaktorautentisering innebærer å kreve mer enn en autentiseringsfaktor når bruker forsøker å logge inn.

Her brukes ofte begrepene multifaktorautentisering, flerfaktorautentisering, tofaktorautentisering, totrinnsbekreftelse m.fl. om hverandre. Vi kommer til å bruke multifaktorautentisering (MFA)

De fleste nordmenn er kjent med dette gjennom BankID hvor man kombinerer passord med en engangskode, eller BankID på mobil, hvor din mobil kombineres med din PIN-kode.

MFA kan implementeres på en rekke måter, det vanlige er å kombinere passord og noe annet.

Noen potensielle faktorer som kan kombineres er:

• Passord
• Fysisk kodegenerator
• Kodegenerator på mobilen, for eksempel Google Authenticator.
• Kode sendt på SMS
• Mobiltelefonens UID

Ekstra ressurser:

• Nettvett gir en kort og lettlestinnføring i flerfaktorautentisering (de kaller det to-trinnbekreftelse)
• NCSC UK har også en god artikkel om MFA.

• Bruk unike, tilfeldige, pasord for alle tredjepartstjenester. Lagre passord i passordmanager. Passord bør være minst 8 tilfeldige tegn, eller tre tilfeldige ord.
• Sett AD-passord-lengde til minst 14 tegn
• Sett administratorpassord til minst 20 tegn
• Fjern passord-kompleksitetskrav
• Ikke bruk utløpsdato. Bytt ved mistanke om kompromittering
• Gjennomfør intern passordknekking kvartalsvis ELLER tildel tilfeldige passordsetninger
• Bruk "passord på avveie" fra HelseCERT

Begrunnelse for anbefalinger:

Bruk unike, tilfeldige, pasord for alle tredjepartstjenester. Lagre passord i passordmanager

Mange vil ha en rekke kontoer i tredjepartstjenester man bruker i den daglige jobben. Mange av disse vil det ikke være praktisk mulig å bruke Singel-Sign-On (SSO) for. For å håndtere disse på en mest mulig sikker måte må det brukes unike passord på alle slike. For å håndtere dette på en god, effektiv måte bør passord tilfeldig genereres og lagres i en passordmanager. Dette resulterer økt sikkerhet, og enklere administrering for bruker.

Krev at alle AD-passord er minst 14 tegn

Alle brukerkontoer i Active Directory (AD) bør ha minimum 14 tegn. Dette for å unngå de enkleste mest forutsigbare passordene. Erfaringer fra inntrengningstester er at når lengdekravet økes fra 8 til 14 reduserer dette antall passord vi gjetter dramatisk.

Dette sikrer mot passord-spray-angrep og mot at angripere med fotfeste på innsiden knekker passordhasher for å utvide egen tilgang.

Administratorpassord skal være på minst 20 tegn

Som over er målet her å ta bort muligheten angriper har til å gjette passordet. Siden administratorkontoer er en mye mer kritisk ressurs enn passordet til vanlige brukere er kravet strengere.

Som over skal lengden her beskytte mot knekking av passord.

Ikke krev kompleksistetskrav for passord

Kompleksitetskrav er en vanlig måte å tenke at man gjør det vanskeligere for angriper å gjette rett passord. Et vanlig slikt krav er å kreve en blanding av store og små bokstaver og tegn. Resultatet av dette er at flertallet av brukerne oppretter passord av typen "Passord1". Altså start med stor bokstav, resten av ordet, og et (eller to) tall på slutten. Angripere vet også dette og legger opp angrep deretter. Kompleksitetskrav gjør det vanskeligere for brukere å lage og huske passord mens angriperen i liten grad er påvirket.

NCSC UK har en god artikkel om hvorfor dette i liten grad gir ønsket effekt. Se under "Do not use complexity requirements".

Ikke ha utløpsdato på passord. Bytt ved mistanke om kompromittering

Tvungne passordbytter resulterer i at brukere lager passord basert på mønster som er enkle å huske. I tillegg brukes kompromitterte passord som regel umiddelbart etter at de kommer på avveie.

NCSC UK har en god artikkel om hvorfor dette i liten grad gir ønsket effekt. Se under "Don't enforce regular password expiry".

Sjekk kvartalsvis etter dårlige passord ELLER benytt tilfeldig passordtildeling

Dårlige passord, f.eks. Sommer21, Sommerferie2021 og lignende tilfredsstiller stort sett alle kompleksitetskrav, men er likevel enkle å gjette for en angriper. Våre erfaringer fra inntrengningstester viser at med tilgang på nok brukerkontoer finner vi alltid noen med et slikt passord.

Erfaringsmessig er det vanskelig å opprette utfyllende lister over passord som ikke er godkjent. I tillegg gir det en dårlig brukeropplevelse å forsøke å lage et passord som er innenfor passordpolicy, for deretter å få beskjed om at valgt passord er svartelistet.

Dette tiltaket er todelt og tanken er at man gjør en av delene.

Å sjekke etter dårlige passord er relativt enkelt, men krever kontinuerlig arbeid.

Å tildele passord semi-tilfeldig krever mer i implementering men gir mindre gjentagende arbeid.

Målet uansett metode er å redusere angripers mulighet til å gjette seg fram til forutsigbare passord.

Sjekk etter dårlige passord:

Denne oppskriften er basert på rutinen Sykehuspartner bruker i dag.

Brukere kan opprette passord på minimum 14 tegn som ikke utløper på tid. De må kun byttes om passordet kommer på avveie. Samtidig gjennomføres det, minimum kvartalsvis, sjekker for å finne svake passord. Om et svakt passord oppdages regnes dette som på avveie og må byttes.

Rent praktisk trenger man en som administrerer Windows (administrator), og en som forsøker å knekke passord (knekkeren).

Administratoren henter ut listen over (NTLM) passordhasher i bruk i domenet og gir denne til knekkeren. Her gis hashlisten, ikke tilhørende brukernavn. Knekkeren forsøker å knekke hashene. Lykkes hen meldes aktuell hash tilbake som et svakt passord, men administratoren får kun vite hvilken hash det er snakk om, ikke hvilket passord det er. Dermed har verken administratoren eller knekkeren tilgang til et brukernavn med tilhørende passord.

Det er viktig at denne tilnærmingen er kombinert med informasjon til bruker.

Vi har et ~16 minutters webinar som beskriver metoden

Tilfeldig passordtildeling:

Denne metoden går ut på at brukere tildeles passord som er generert tilfeldig. Passordene bør være bygd opp av 3-4 tilfeldige sammensatte ord. Ord med særnorske bokstaver bør unngås. Denne metoden for å huske passord er beskrevet av NCSC UK for de som ønsker en faglig begrunnelse. Tegneserien XKCD har også en visuell beskrivelse.

To viktige poeng her er at passordene genereres automatisk for å unngå brukermønster, og at det er enkelt for brukere å generere nye slik at de har anledning til å få en kombinasjon de kan lage seg en huskeregel på.

Bruk "passord på avveie" fra HelseCERT

Vi tilbyr en tjeneste hvor vi leter etter passord på avveie og varsler om vi oppdager dette for din virksomhet.

Vi anbefaler at man lager en rutine for hvordan man skal reagere på varsler man får.

Du kan lese mer om tjenesten Passord på avveie under nasjonalt beskyttelsesprogram.

Tjenesten er tilgjengelig og gratis for alle medlemmer i NBP.