Naka-save na VPN sa Android: aling sikreto ang maaari mong mabawi?
Ang teleponong muling kumokonekta nang hindi nagtatanong ng password ay hindi nag-iimbak ng password na maaari mong kopyahin. Ihambing ang apat na kredensyal at ang pagbawi na kailangan ng bawat isa.
Ang telepono ay muling kumokonekta sa VPN tuwing umaga nang hindi nagtatanong ng kahit ano. Ibig sabihin nito, ang kredensyal ay nasa loob sa isang lugar. Karaniwang wala, hindi bababa sa hindi sa anyo na mababasa mo at maipapasok sa bagong device.
Ang mayroon ang telepono ay awtoridad na kumonekta. Ang gusto mo ay isang sikretong maaari mong dalhin, at ito ay magkaibang katangian na nagkataong gumagawa ng parehong pag-uugali sa screen.
Bago mag-reset ng kahit ano, tukuyin kung alin sa apat na uri ng sikreto ang talagang nawawala, dahil bawat isa ay may ibang may-ari at ibang pagbawi.
Ang gumaganang koneksyon ay hindi naka-save na password
Ang app na tahimik na muling kumokonekta ay maaaring may hawak na password, session token, sanggunian sa sertipiko, o wala nang iba pa kundi key na nakatali sa device na hindi nito maaaring i-export. Lahat ng apat ay gumagawa ng parehong karanasan ng user at wala sa kanila ang mapagpapalit.
Ang hilera ng mga tuldok sa isang field ng settings ay desisyon sa pagpapakita, hindi ebidensya. Ang ilang app ay talagang nag-iimbak ng password na maaaring mabawi at nag-aalok na ipakita o i-export ito; ang iba ay kumukuha ng token mula sa daloy ng iisang pag-sign in at hindi kailanman nakikita ang password.
Kaya ang unang tanong ay hindi kung nasaan ang file. Ito ay kung anong uri ng awtoridad ang natanggap ng app, at ang sagot na iyon ay galing sa provider, hindi sa device.
Apat na sikreto, apat na pagbawi
Itugma ang iyong sitwasyon sa isang hilera bago makipag-ugnayan sa kahit sino, dahil ganap na nagbabago ang kahilingan depende sa kung alin ito.
| 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 |
Ang ikalawang hilera ang pinakamadalas makahuli ng mga tao. Ang password ng pag-import ng PKCS#12 ay nagpoprotekta sa materyal ng key at walang kaugnayan sa pag-log in sa account, kaya walang nababawi kapag ni-reset ang password ng account. Kung talagang nawala ang password ng package, ang solusyon ay muling pag-isyu.
Ang ikaapat na hilera ay nagpapaliwanag ng maraming nakakalitong thread ng suporta. Maaaring sumangguni ang profile sa isang kredensyal sa key store ng platform sa halip na maglaman ng portableng kopya, at sa ganoong kaso wala nang makukuha sa profile kahit sa prinsipyo.
Bakit karaniwang nabibigo ang pagkopya ng app data
Ang lumang paraan ay hilahin ang data directory ng app at basahin ang configuration mula roon. Sa kasalukuyang Android, may dalawang independiyenteng problema ang paraan.
Ang una ay patakaran sa backup. Nilimitahan ng Android 12 ang app data na iniluluwas sa lumang landas na adb backup para sa mga app na nagta-target ng API 31 o mas bago, at maaaring ganap na ibukod ng mga app ang data sa backup. Ang pamamaraang isinulat para sa lumang device ay hindi unibersal na paraan ng pagbawi para sa kasalukuyan.
Ang pangalawa ay ang key store. Ang mga key na nabuo roon ay maaaring hindi ma-export at nakatali sa hardware, gaya ng inilalarawan ng dokumentasyon ng Android Keystore. Ang pagkopya ng naka-encrypt na blob ay hindi kumokopya ng key na nagde-decrypt nito, kaya ang naibalik na directory ay maaaring maglaman ng kredensyal na hindi kailanman magagamit ng bagong device.
Wala sa dalawang problemang ito ang bug na dapat iwasan. Pareho silang platform na ginagawa ang para saan ito dinisenyo, at ang pagtrato sa kanila bilang sagabal ay karaniwang nagtatapos sa naka-root na telepono at walang password.
Sadyang lumipat sa kapalit na telepono
Gawin muna ang sinusuportahan. Kung ang provider ay nag-aalok ng export na malinaw na kinabibilangan ng mga kredensyal na kailangan mo, gamitin ito at i-verify ang resulta sa bagong device bago burahin ang luma. Kung wala, humiling ng bagong profile o enrollment, na siyang normal na landas para sa mga serbisyong nakabatay sa sertipiko at karaniwang mas mabilis kaysa sa paraan ng pag-iwas.
Mahalaga ang pagkakasunod-sunod. I-enroll ang kapalit, ikonekta ito, magpadala ng test request sa tunnel, at pagkatapos lamang i-retire ang orihinal. Ang pagpapanatili ng gumaganang telepono hanggang mapatunayan ang bago ay ang pinakamurang insurance na available, at ang halaga lamang ay pasensya.
Planuhin din ang mga side effect ng reset. Kung ma-reset ang password ng account o mabawi ang pagkakakilanlan ng device, maaaring mawalan ng bisa ang ibang session, kabilang ang client sa laptop at tablet na walang nakakaalala. Harapin ang mga ito sa parehong window sa halip na isa-isang matuklasan.
Ano ang hindi dapat gawin
Huwag i-root ang nag-iisang gumaganang device para maghanap ng plaintext file. Ginagawa mong problema sa integridad ng device ang problema sa pagbawi ng access, maaaring masira ang sariling mga pagsusuri sa integridad ng app, at wala ka pa ring garantiya na ang halagang hinahanap mo ay umiiral sa nababasang anyo.
Huwag i-paste ang mga pribadong key, na-export na profile o password sa isang support ticket para patunayan na totoo ang problema. Kailangan ng provider ang pangalan ng profile, bersyon ng app, identifier ng account at ang error, na wala sa mga ito ang lihim.
At huwag i-disable ang pag-verify ng sertipiko para makakuha ng koneksyon habang naghihintay. Ipinagpapalit nito ang pansamantalang abala sa permanenteng paghina ng nag-iisang tseke na nagsasabi kung aling server ang kausap mo. Itala ang apat na katotohanan, itanong ang partikular na tanong at gamitin ang inilabas na landas.