Applikasjonsspesifikke passord er farligereenn de høres ut. Til tross for navnet sitt, er de alt annet enn applikasjonsspesifikt. Hvert applikasjonsspesifikt passord ligner mer på en skjelettnøkkel som gir ubegrenset tilgang til kontoen din.
"Applikasjonsspesifikke passord" er såkalt for å oppmuntre til 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, og deretter må du oppgi en engangskode som er generert av en smarttelefon-app, sendt via SMS eller sendt til deg.
Slik fungerer det normalt når du logger inn på entjenestens nettsted eller et kompatibelt program. Du oppgir passordet ditt, og deretter blir du bedt om en engangskode. Du oppgir koden, og enheten din mottar et OAuth-token som anser applikasjonen eller nettleseren som autentisert, eller noe sånt - den lagrer ikke passordet faktisk.
I SLEKT: Sikre deg selv ved å bruke totrinnsverifisering på disse 16 webtjenestene
Noen applikasjoner er imidlertid ikke kompatible meddenne totrinnsordningen. La oss for eksempel si at du vil bruke en stasjonær e-postklient for å få tilgang til Gmail, Outlook.com eller iCloud e-post. Disse e-postklientene fungerer ved å be deg om et passord, og så lagrer de passordet og bruker det hver gang de får tilgang til serveren. Det er ingen måte å legge inn en totrinns bekreftelseskode i disse eldre applikasjonene.
For å fikse dette, Google, Microsoft, Apple ogforskjellige andre kontoleverandører som tilbyr totrinnsverifisering, tilbyr også muligheten til å generere et "applikasjonsspesifikt passord." Du angir deretter dette passordet i applikasjonen - for eksempel den stasjonære e-postklienten du velger - og applikasjonen kan gjerne koble seg til kontoen din. Problem løst - applikasjoner som ikke ville være kompatible med totrinnsgodkjenning, fungerer nå med det.
Vent litt, hva skjedde nettopp?
I SLEKT: Slik unngår du å bli låst når du bruker tofaktorautentisering
De fleste vil nok fortsette på vei,sikre kunnskapen de bruker tofaktorautentisering og er trygge. Imidlertid er det "applikasjonsspesifikke passordet" faktisk et nytt passord som gir tilgang til hele kontoen din og omgår fullstendig tofaktorautentisering. Slik lar disse applikasjonsspesifikke passordene eldre applikasjoner som er avhengige av å huske passord, fungere.
Sikkerhetskopieringskoder lar deg også omgå tofaktorerautentisering, men de kan bare brukes én gang hver. I motsetning til sikkerhetskodekoder, kan applikasjonsspesifikke passord brukes for alltid - eller til du tilbakekaller dem manuelt.
Hvorfor de kalles applikasjonsspesifikke passord
Disse kalles ofte applikasjonsspesifikkepassord fordi du skal generere et nytt for hver applikasjon du bruker. Det er derfor Google og andre tjenester ikke tillater deg å faktisk se disse applikasjonsspesifikke passordene når du har generert dem. De blir vist på nettstedet en gang, du skriver dem inn i applikasjonen, og så ser du dem ideelt sett aldri mer. Neste gang du trenger å bruke en slik applikasjon, genererer du bare et nytt apppassord.
Dette gir noen sikkerhetsfordeler. Når du er ferdig med en applikasjon, kan du bruke knappen her for å "trekke tilbake" et applikasjonsspesifikt passord, og det passordet vil ikke lenger gi tilgang til kontoen din. Programmer som bruker det gamle passordet fungerer ikke. Apppassordet på skjermdumpen nedenfor ble opphevet, så det er derfor det er trygt å vise det frem.
Applikasjonsspesifikke passord er absolutt etstor forbedring enn å 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 klar:
- Hvis passordet er kompromittert, kan det brukesfor å få tilgang til kontoen din. La oss for eksempel si at du har satt opp tofaktorautentisering på Google-kontoen din, og datamaskinen din er infisert av skadelig programvare. To-faktor-godkjenning 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 kunnegenerer et applikasjonsspesifikt passord, og hold deretter fast ved å 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 fanget passordet ditt, hadde de tilgang til kontoen din.
- Hvis du oppgir et applikasjonsspesifikt passordtil en tjeneste eller applikasjon, og den applikasjonen er skadelig, du har ikke bare gitt en enkelt applikasjon tilgang til kontoen din - eier av applikasjonen kan passere passordet, og andre kan bruke det til ondsinnede formål.
Noen tjenester kan forsøke å begrense nettinnloggingmed applikasjonsspesifikke passord, men det er mer en bandaid. Til slutt gir applikasjonsspesifikke passord ubegrenset tilgang til kontoen din ved design, og det er ikke mye som kan gjøres for å forhindre den.
Vi prøver ikke å skremme deg for mye her. Men virkeligheten med applikasjonsspesifikke passord er at de ikke er applikasjonsspesifikke. Det er en sikkerhetsrisiko, så du bør inndra applikasjonsspesifikke passord du ikke lenger bruker. Vær forsiktig med dem, og behandle dem som hovedpassordene til kontoen din som de er.
