Applikasjonsspesifikke passord er farligere enn de høres ut. Til tross for navnet deres, er de alt annet enn applikasjonsspesifikke. Hvert applikasjonsspesifikke passord er mer som en skjelettnøkkel som gir ubegrenset tilgang til kontoen din.
"Applikasjonsspesifikke passord" er såkalte å oppmuntre god sikkerhetspraksis - du skal ikke bruke dem på nytt. Imidlertid kan navnet også gi en falsk trygghet for mange mennesker.
Hvorfor applikasjonsspesifikke passord er nødvendige
I SLEKT: Hva er tofaktorautentisering, og hvorfor trenger jeg det?
To-faktor autentisering - eller totrinnsbekreftelse, eller hva en tjeneste kaller det - krever to ting for å logge på kontoen din. Du må først oppgi passordet ditt, og deretter må du angi en engangskode generert av en smarttelefonapp, sendt via SMS eller sendt til deg.
Slik fungerer det normalt når du logger på en tjenestes nettsted eller et kompatibelt program. Du skriver inn passordet ditt og blir bedt om engangskoden. Du skriver inn koden, og enheten din mottar et OAuth-token som anser applikasjonen eller nettleseren som autentisert, eller noe sånt - den lagrer faktisk ikke passordet.
I SLEKT: Sikre deg selv ved å bruke totrinnsbekreftelse på disse 16 webtjenestene
Noen applikasjoner er imidlertid ikke kompatible med dette totrinnsskjemaet. La oss for eksempel si at du vil bruke en e-postklient på skrivebordet for å få tilgang til Gmail, Outlook.com eller iCloud-e-post. Disse e-postklientene fungerer ved å be deg om et passord, og deretter lagrer de passordet og bruker det hver gang de får tilgang til serveren. Det er ingen måte å legge inn en to-trinns bekreftelseskode i disse eldre appene.
For å fikse dette, Google, Microsoft, Apple og forskjellige andre kontoleverandører som tilbyr totrinnsbekreftelse tilbyr også muligheten til å generere et "applikasjonsspesifikt passord." Deretter skriver du inn dette passordet i applikasjonen - for eksempel din valgte e-postklient - og det programmet kan gjerne koble til kontoen din. Problem løst - applikasjoner som ikke er kompatible med totrinnsgodkjenning, fungerer nå med det.
Vent litt, hva skjedde akkurat?
I SLEKT: Hvordan unngå å bli sperret når du bruker tofaktorautentisering
De fleste vil trolig fortsette på vei, sikre seg i kunnskapen de bruker tofaktorautentisering og er trygge. Imidlertid er det "applikasjonsspesifikke passordet" faktisk et nytt passord som gir tilgang til hele kontoen din, helt utenom tofaktorautentisering. Slik lar disse applikasjonsspesifikke passordene eldre applikasjoner som er avhengig av å huske passord, fungere.
Sikkerhetskopikoder lar deg også omgå tofaktorautentisering, men de kan bare brukes en gang hver. I motsetning til sikkerhetskopikoder kan applikasjonsspesifikke passord brukes for alltid - eller til du manuelt tilbakekaller dem.
Hvorfor de kalles programspesifikke passord
Disse kalles ofte applikasjonsspesifikke passord fordi du skal generere et nytt for hvert program du bruker. Derfor tillater Google og andre tjenester deg ikke å se disse applikasjonsspesifikke passordene når du har generert dem. De vises på nettstedet en gang, du skriver dem inn i applikasjonen, og så ser du ideelt sett aldri mer. Neste gang du trenger å bruke et slikt program, genererer du bare et nytt app-passord.
Dette gir noen sikkerhetsfordeler. Når du er ferdig med et program, kan du bruke knappen her for å "tilbakekalle" et applikasjonsspesifikt passord, og passordet gir ikke lenger tilgang til kontoen din. Alle applikasjoner som bruker det gamle passordet, fungerer ikke. Apppassordet i skjermbildet nedenfor ble tilbakekalt, så det er derfor det er trygt å vise det frem.
Applikasjonsspesifikke passord er absolutt en stor forbedring i forhold til å ikke bruke tofaktorautentisering i det hele tatt. Å gi bort applikasjonsspesifikke passord er bedre enn å gi alle applikasjoner ditt primære passord. Det er lettere å tilbakekalle et appspesifikt passord enn å endre hovedpassordet ditt helt.
Risikoen
Hvis du har generert fem applikasjonsspesifikke passord, er det fem passord som kan brukes til å få tilgang til kontoene dine. Risikoen er tydelig:
- Hvis passordet er kompromittert, kan det brukes til å få tilgang til kontoen din. La oss for eksempel si at du har konfigurert tofaktorautentisering på Google-kontoen din, og datamaskinen din er infisert av skadelig programvare. Tofaktorautentisering vil normalt beskytte kontoen din, men skadelig programvare kan høste applikasjonsspesifikke passord som er lagret i applikasjoner som Thunderbird og Pidgin. Disse passordene kan deretter brukes til å få direkte tilgang til kontoen din.
- Noen med tilgang til datamaskinen din kan generere et applikasjonsspesifikt passord og deretter holde på det og bruke det til å komme inn på kontoen din uten tofaktorautentisering i fremtiden. Hvis noen så over skulderen din mens du genererte et applikasjonsspesifikt passord og hentet passordet ditt, ville de ha tilgang til kontoen din.
- Hvis du gir et applikasjonsspesifikt passord til en tjeneste eller applikasjon og det programmet er skadelig, har du ikke bare gitt en applikasjon tilgang til kontoen din - eieren av applikasjonen kan sende passordet videre, og andre kan bruke det til ondsinnede formål .
Noen tjenester kan forsøke å begrense pålogginger på nettet med applikasjonsspesifikke passord, men det er mer en bandaid. Til slutt gir applikasjonsspesifikke passord ubegrenset tilgang til kontoen din etter design, og det er ikke mye som kan gjøres for å forhindre det.
Vi prøver ikke å skremme deg for mye her. Men virkeligheten med applikasjonsspesifikke passord er at de ikke er applikasjonsspesifikke. De er en sikkerhetsrisiko, så du bør tilbakekalle applikasjonsspesifikke passord du ikke lenger bruker. Vær forsiktig med dem, og behandle dem som hovedpassordene til kontoen din som de er.
