Lagret VPN på Android: hvilken hemmelighet kan du gjenopprette?
En telefon som kobler til på nytt uten å spørre om passord, lagrer ikke et du kan kopiere. Sammenlign de fire legitimasjonene og gjenopprettingen hver av dem trenger.
Telefonen kobler til VPN på nytt hver morgen uten å spørre om noe. Det antyder at legitimasjonen ligger der inne et sted. Vanligvis gjør den ikke det, i det minste ikke i en form du kan lese opp og skrive inn på en ny enhet.
Det telefonen har, er tillatelse til å koble til. Det du vil ha, er en hemmelighet du kan ta med deg, og det er forskjellige egenskaper som tilfeldigvis gir samme atferd på skjermen.
Før du nullstiller noe, må du finne ut hvilken av fire slags hemmeligheter som faktisk mangler, fordi hver har en annen eier og en annen gjenoppretting.
En fungerende tilkobling er ikke et lagret passord
En app som kobler til på nytt i det stille, kan holde på et passord, et sesjonstoken, en referanse til et sertifikat eller ikke noe mer enn en enhetsbundet nøkkel den ikke kan eksportere. Alle fire gir samme brukeropplevelse, og ingen av dem kan byttes ut.
En rad med prikker i et innstillingsfelt er en visningsavgjørelse, ikke bevis. Noen apper lagrer faktisk et passord som kan gjenopprettes, og tilbyr å vise eller eksportere det; andre tar et token fra en flyt for enkeltpålogging og ser aldri passordet.
Så det første spørsmålet er ikke hvor filen er. Det er hvilken type tillatelse appen fikk, og svaret kommer fra leverandøren, ikke fra enheten.
Fire hemmeligheter, fire gjenopprettinger
Tilpass situasjonen din til én rad før du kontakter noen, fordi forespørselen endres fullstendig avhengig av hvilken det er.
| What is missing | Who can restore it |
|---|---|
| Account password used with a username | The identity provider, through a reset |
| Password protecting a private key or PKCS#12 package | Nobody, if it is forgotten; a fresh profile and key are issued instead |
| Session token or SSO session | Nobody; sign in again to obtain a new session |
| Reference to a certificate or key held on the device | The administrator, by enrolling the new device |
Den andre raden fanger folk oftest. Et PKCS#12-importpassord beskytter nøkkelmateriale og har ingenting med kontopålogging å gjøre, så nullstilling av kontopassordet gjenoppretter ingenting. Hvis pakkepassordet virkelig er tapt, er løsningen å utstede det på nytt.
Den fjerde raden forklarer mange forvirrende støttetråder. Profilen kan referere til en legitimasjon i plattformens nøkkellager i stedet for å inneholde en flyttbar kopi, og i så fall er det ingenting i profilen å trekke ut, selv i prinsippet.
Hvorfor kopiering av appdata vanligvis mislykkes
Den gamle oppskriften er å hente ut appens datamappe og lese konfigurasjonen derfra. På dagens Android har oppskriften to uavhengige problemer.
Det første er sikkerhetskopipolicy. Android 12 begrenset appdata eksportert via den gamle adb backup-banen for apper som retter seg mot API 31 eller nyere, og apper kan utelukke data fra sikkerhetskopi helt. En prosedyre skrevet for en eldre enhet er ikke en universell gjenopprettingsmetode for en nåværende.
Det andre er nøkkellageret. Nøkler som genereres der, kan være ikke-eksporterbare og maskinvarebundne, slik Android Keystore-dokumentasjonen beskriver. Å kopiere en kryptert blob kopierer ikke nøkkelen som dekrypterer den, så en gjenopprettet mappe kan inneholde en legitimasjon som den nye enheten aldri kan bruke.
Ingen av de to problemene er en feil som skal omgås. Begge er plattformen som gjør det den er laget for, og å behandle dem som hindringer ender vanligvis med en rootet telefon og ingen passord.
Bytt bevisst til en erstatningstelefon
Gjør først det som støttes. Hvis leverandøren tilbyr en eksport som uttrykkelig inkluderer legitimasjonen du trenger, bruk den, og kontroller resultatet på den nye enheten før du sletter den gamle. Hvis ikke, be om en ny profil eller registrering, som er den vanlige veien for sertifikatbaserte tjenester og vanligvis tar kortere tid enn omveien.
Rekkefølgen betyr noe. Registrer erstatningen, koble den til, send en testforespørsel gjennom tunnelen, og ta først deretter den opprinnelige ut av drift. Å beholde den fungerende telefonen til den nye er bevist, er den billigste forsikringen som finnes, og den koster bare tålmodighet.
Planlegg også bivirkningene av en nullstilling. Hvis kontopassordet nullstilles eller enhetsidentiteten tilbakekalles, kan andre sesjoner bli ugyldige, inkludert en laptopklient og et nettbrett som ingen husket. Håndter dem i samme tidsvindu i stedet for å oppdage dem én om gangen.
Hva du ikke bør gjøre
Ikke root den eneste fungerende enheten for å lete etter en klartekstfil. Du gjør et problem med tilgangsgjenoppretting om til et problem med enhetsintegritet, du kan ødelegge appens egne integritetskontroller, og du har fortsatt ingen garanti for at verdien du leter etter, finnes i lesbar form.
Ikke lim inn private nøkler, eksporterte profiler eller passord i en støttebillett for å bevise at problemet er reelt. Leverandøren trenger profilnavnet, appversjonen, kontoidentifikatoren og feilen, og ingen av dem er hemmelige.
Og ikke deaktiver sertifikatverifisering for å få en tilkobling mens du venter. Det bytter en midlertidig ulempe mot en varig svekkelse av den eneste kontrollen som forteller deg hvilken server du snakker med. Noter de fire fakta, still det konkrete spørsmålet, og bruk den utstedte veien.