MeldID nagdagdag ng mode ng panic: Ano ang nangyayari kapag hindi na mapagkakatiwalaan ang access sa account

Sa nakaraang artikulo tungkol sa MeldID, isinalaysay ko kung paano gumagana ang sistema sa normal na mode: nag-iimbak ito ng managed profile, tumutulong sa pag-log in sa mga konektadong serbisyo, nagsi-synchronize ng TOTP records sa pagitan ng mga device, at nagbibigay-daan sa pag-verify ng mga bagong authorization via mobile app.

Ngunit bawat sistema ng pagkakakilanlan ay may isang scenario na karaniwang naaalala lamang kapag huli na: ano ang gagawin kapag hindi na nagtitiwala ang user sa kasalukuyang access sa kanyang account?

Hindi kailangang alam na may nangyaring hacking. Minsan, sapat na ang isang hindi inaasahang email tungkol sa password recovery, session na hindi kilala, o login gamit ang device na hindi kilala ng owner.

Para sa ganitong mga sitwasyon, nagdagdag ang MeldID ng dalawang bagong mekanismo: delayed password change at mode ng panic.

Una, mahalagang maunawaan kung paano nakalapat ang password sa MeldID

Sa MeldID, hindi nagsasabi ang user ng password nang sarili — ito ay awtomatikong nililikha ng sistema. Ito ang nagsisiguro na agad na maiiwasan ang mahina o predictable na mga kumbinasyon, paulit-ulit na gamit ng isang password, at iba pang mga problema na nauugnay sa manual na pagpili.

At, ang kasalukuyang password ay hindi ipinapadala sa user via email. Hindi maaaring makuha ang aktuwal na password ng MeldID mula sa email inbox.

Ang proseso ng recovery ay hindi rin inilalantad ang lumang password. Pinapayagan nito ang pagsimula ng paggawa ng bago.

Kaya, ang pagkaka-kompromiso ng email ay nagdudulot ng ibang banta: isang taong nakakakuha ng access sa email ay hindi malalaman ang kasalukuyang password ng MeldID, ngunit maaaring subukang gamitin ang recovery process at mag-set ng bago.

Isa ito sa mga dahilan kung bakit binago ang logging logic ng recovery.

Ang password ay hindi naagad na mababago

Sa karaniwang recovery scenario, halos agad nang nangyayari ang lahat: naghihingi ang user ng bagong password, nakakatanggap ng email, at nagtatapos sa proseso.

Ito ay maginhawa, hangga't kontrolado lamang ng owner ang email. Ngunit, kung may isang tao na nakakuha ng access dito, ang instant recovery ay nagiging daan para makuha niya ang account through email.

Sa MeldID, ang request para sa bagong password ay nagiging isang babala, hindi isang agad-agad na pagpapalit. Nakakatanggap ang user ng notification ng recovery attempt, at may nakatakdang waiting period na sumusunod.

Maaaring mag-iba ang haba ng panahong ito, ngunit nananatili ang pangunahing prinsipyo: may oras para suriin ang sitwasyon sa pagitan ng request at aktwal na activation ng bagong password.

Sa panahong ito, nananatiling valid ang lumang password. Ibig sabihin, ang pagsimula ng recovery ay hindi pa nangangahulugang ang control ay naglipat na sa ibang tao.

Kapag walang access sa app

May isang mahalagang scenario na madaling mapalampas: maaaring mag-recover ang user ng password, ngunit walang access sa MeldID app: nawawala, nasira, low-batt, o pansamantalang unavailable ang device.

Sa ganitong kaso, maaari pa ring matapos ang recovery. Matapos ang itinakdang period, awtomatikong magiging epektibo ang bagong password. Hindi kailangang may mobile app para sa standard recovery process.

Samakatuwid, kung nag-umpisa ang user ng password change at hindi ma-open ang app, hindi niya kailangang magsimula muli. Maghintay lamang hanggang matapos ang proseso at mag-login gamit ang bagong password.

Kung available ang app, mas marami ang options: maaari niyang agad i-activate ang bagong password, o i-cancel ang suspicious request. Kung walang access, magpapatuloy ang delayed recovery.

Panghuhusga ng user kung ano ang susunod

Kung ang recovery ay aktwal na sinimulan ng owner at nasa kamay ang device, maaari niyang buksan ang MeldID at i-activate ang bagong password agad, hindi na hinihintay ang end ng waiting period.

Kung ang request ay nakabigla, pwedeng i-cancel ito sa app. Sa ganitong paraan, hindi magiging valid ang bagong password at mananatili ang lumang password.

Importante ito sa akin bilang isang pagbabago sa logic ng recovery: hindi itinuturing ng sistema na valid ang anumang request basta ito ay na-trigger sa pamamagitan ng email. May kalayaang gawin ito ng owner sa pamamagitan ng trusted device.

Isipin na lang ang isang ordinaryong sitwasyon: nakatanggap ang user ng notification tungkol sa password change kahit hindi niya ito hiningi. Kinukontra niya ito sa app, at saka niya maaaring suriin ang email, devices, at hanapin ang dahilan ng kahina-hinalang activity.

Hindi kayang i-recover ng MeldID ang control sa compromised email. Ngunit maaari nitong mapigilan na ang kompromiso ng email ay agad na magresulta sa pag-set ng panibagong password para sa pangunahing account.

Mode ng panic na nagre-revoke ng access

Ang delayed password change ay nakakakuha ng sandaling oras. Ang mode ng panic ay idinisenyo para sa sitwasyon na hindi na sapat ang isang delay, at gustong gawing mas mabilis ang pagwawakas ng mga naibigay nang access.

Na-activate ito sa app sa isang click lang.

Pagkatapos i-activate, ang sistema ay magre-revoke ng mga active tokens — mga access keys na ginagamit ng apps at websites upang ipakita na ang user ay authorized na. Kasabay nito, itinitigil ang mga session sa mobile clients at web apps na konektado sa account.

Ibig sabihin, hindi lang ang kasalukuyang session sa telepono ang apektado. Ipinarerevoke din ang access sa ibang devices, browsers, at apps na naka-log in na dati.

Gumana ito sa loob ng nakatakdang period, na maaaring i-adjust. Mahalaga rito hindi ang eksaktong haba, kundi ang pangunahing konsepto: ang mga access ay pinuputol, at may oras ang user upang suriin ang sitwasyon.

Ang panic mode ay hindi nagbubura ng data

Maaaring magsalita ang pangalan ng mode na parang radical, ngunit mahalagang linawin kung ano ang hindi nito ginagawa.

Hindi nito tinatanggal ang TOTP records, naka-save na profile, setting, o iba pang data ng user. Hindi nito nililinis ang laman ng account; hindi ito ginagawang isang empty account.

Nagbabago lang ang access state: nawawala ang mga valid tokens at natatigil ang mga open session. Pagkatapos bumalik sa normal na estado, nananatili ang mga dati nitong data at hindi kailangang i-reconfigure.

Ito ay isang pangunahing pagkakaiba sa pagitan ng emergency access termination at ang total data wipe. Maaari makipag-ugnayan ang user sa mga existing connection nang hindi natatakot na mawawala ang kanyang data o settings.

Ano ang nangyayari sa pagbabago ng password sa panahon ng panic

May isa pang mahalagang rule ang mode ng panic: ito ay nagtatapos sa lahat ng hindi pa tapos na proseso ng pagbabago ng password.

Hindi na mahalaga kung kailan ito ni-request — bago pa man ang activation ng panic mode o habang itong nangyayari. Hindi ito puwedeng awtomatikong matapos kapag lumabas ang account sa mode na ito.

Matapos ang panic, nananatiling aktibo ang password na ginagamit bago itigil ang mode.

This was done intentionally.

Ang karaniwang recovery process ay nakatuon sa pag-asa na may kakayahan ang owner na makita ang kahina-hinalang request sa MeldID at i-cancel ito bago pa man maging epektibo ang bagong password.

Sa panahon ng panic, hindi na pwede ang ganitong scenario.

I-alam na lang natin na nakakita ang user ng kahina-hinalang activities, at i-on ang security mode. Kung papayagan pa ang recovery timer na magpatuloy, may pagkakataon na makapag-request ang attacker ng bagong password habang nasa panic, at kung matapos ang waiting period bago magbalik sa normal ang account, maaaring ma-activate ang bagong password bago pa makabalik ang control sa user.

Maaari itong magdulot ng kakila-kilabot na paradox: nag-activate ang user ng mas mahigpit na proteksyon, ngunit sa panahong ito, pinahihintulutan ang pagbabago ng password na hindi makontrol ng owner sa pamamagitan ng karaniwang paraan.

Kaya hindi winawari ng panic mode ang recovery; ito ay pinutol ang proseso nito para di na magpatuloy.

Ang mga request na nauna nang ginawa bago i-on ang panic ay hindi na puwedeng baguhin ang password pagkatapos nito, gayundin ‘yung mga kasabay na request habang nangyayari ang mode.

Sapagkat, walang itinagong proseso ng recovery ang lalampas sa boundary ng panic.

Kung nais ng user na baguhin muna ang password

Hindi nililimitahan ng panic mode ang owner sa pagkakasunod-sunod ng mga actions.

Kung may access siya sa MeldID app at sa palagay ay kailangang palitan ang password, maaari niyang i-umpisa muna ang password change at i-verify agad ang bagong password sa app.

Sa ganitong paraan, natatapos ang pagbabago bago pa man i-activate ang panic mode.

Pagkatapos nito, maaaring i-activate ang security mode gamit ang bagong password. Ito ang mananatiling password matapos ang panic.

May isa pang paraan: una, i-activate ang panic, ayusin ang ugat ng kahina-hinalang activities, at pagkatapos nito, kung kinakailangan, mag-initiate ng bagong password change.

Hindi layunin ng mekanismo na pigilan ang user na mag-aksiyon sa isang naayon na sequence; ang pangunahing prinsipyo ay: ang hindi tapos na password change ay hindi dapat makalampas sa panic period.

Panahon ng panic bilang pagkakataon na muling makuha ang control sa email

May isang scenario kung saan espesyal na mahalaga ang mekanismong ito: ang user ay naniniwala na ang problema ay hindi sa MeldID at sa kanyang telepono, ngunit nasa email.

Ginagamit ang email bilang isa sa mga recovery channels. Kung makompromiso ito, kahit na nananatiling hindi alam ang password ng MeldID, delikado pa rin ito.

Sa ganitong sitwasyon, maaaring i-on ng user ang panic mode at imbestigahan ang root cause: i-recover ang access sa email account, palitan ang password nito, i-close ang mga open sessions, at suriin ang security settings.

Habang ang panic mode ay naka-on, hindi pinapayagan ang recovery na magdulot ng bagong aktuwal na password.

Kung may nakasubmit na recovery bago pa ang panic, hindi ito magtatagal sa mode. Kung may bagong request habang ang mode ay aktibo, pareho ang epekto.

Naipipinta dito ang isang naka-temporary na protective window: na-revoke ang access sa MeldID, ang kompromitadong email ay hindi magagamit para bumuo ng panibagong password, at may oras ang owner na ibalik ang control sa email mismo.

Pagkatapos ng panandaliang proteksyon, ang password ng MeldID na bago bago pa ang mode ang mananatili. Kung naibalik na ang control sa email at walang ibang komplikasyon, maaaring gamitin muli ang account sa normal na paraan.

Kung kailangang palitan ang password ng MeldID pagkatapos nito, maaari itong gawin nang hiwalay.

Maraming dahilan upang i-activate ang panic

Hindi kailangan ng patunay na nagkaroon ng hacked na may pagsisimula. Pwedeng naaalala lamang ang isang device na nakarating sa ibang tao, isang session na hindi kilala, isang unexpected na notification o login recovery.

Sa ganitong mga kalagayan, hindi palaging kailangang magsagawa ng malalim na imbestigasyon bago gumawa ng first line of defense. Minsan, mas mahinahon na muna ang mag-terminate ng active access, at saka magsagawa ng pagsusuri.

Sumusunod ang MeldID sa simpleng logika: kung tinitingnan ng owner ang sitwasyon bilang delikado at may trusted app access, dapat niyang makontrol agad ang hakbang na pangseguridad; walang kailangang patunayan muna ang atake bago mag-react.

Kung bakit hindi sapat ang isang password change

Ang password ay isa lamang sa mga elemento ng authorization. Kung may aktibong session o access token na na-issue, ang pagbabago ng isang password lang ay hindi kapareho ng revocation ng lahat ng dating mga access.

Kaya, ang panic mode ay mas malawak ang saklaw. Hindi lang nito binabago ang isang parameter; pinapalagay nito ang buong account sa isang hiwalay na state na protektado.

Ang proseso ay ganito:

1. Nawawala ang aktibong session at tokens;

2. Nag-titigil ang mga hindi tapos na password changes bago pa man ang panic;

3. Ang mga recovery requests sa panahon ng panic ay hindi magbabago ng password kapag natapos ang mode;

4. Mananatili ang password na ginamit bago pa bumi sa panic;

5. May oras ang user na suriin ang email, devices, at iba pang posibleng sources ng problema;

6. Pagkatapos bumalik sa normal, maaari siyang mag-iba muli ng password o magpatuloy sa trabaho.

Ito ay isang hakbang na hindi kapalit ng pangkaraniwang security mechanisms, kundi isang emergency scenario kapag pansamantalang nawawala ang tiwala sa kasalukuyang access.

Mobile app bilang trusted point

Ang mga bagong function ay matatagpuan sa MeldID apps para sa iPhone at Android. Sa arkitekturang ito, nagiging hindi na isang device lang ang telepono: ito ay isang trusted security control point ng account.

Maaari nitong gawin ang mga sumusunod:

• Mag-verify ng delayed password change;

• I-cancel ang suspicious request;

• I-activate ang mode ng panic;

• I-terminate ang active sessions sa iba't ibang devices;

• Magdesisyon kung ano ang susunod na mangyayari sa account.

Hypothetically, hindi nito pinapalitan ang TOTP o mga iba pang pamamaraan ng security. Nagdangagdag lang ito ng isang hiwalay na security channel para sa mga sitwasyong hindi na sapat ang standard na authorization upang mapanatili ang confidence sa security ng account.

Saan nagkakaroon ng hangganan ang proteksyon ng MeldID

Mahalagang maintindihan na may pagkakaiba sa seguridad ng mismong MeldID mechanism at ng security ng environment kung saan ito ginagamit.

Design ang MeldID na walang regular na channel para makuha ang aktuwal na password ang serbisyo. Ang password ay nililikha ng sistema, hindi pinipili ng user, at hindi dinadalhan sa email. Ang recovery ay hindi inilalantad ang existing na password, ngunit nagsisimula ng proseso para gumawa ng bago.

Pero maaaring pa ring ilantad ng user ang kanyang credentials sa pamamagitan ng pag-share o pag-enter sa hindi nararapat na lugar.

Ang isang mas mataas na antas ay ang seguridad ng device mismo at ang operating system nito. Ang mobile app ay may interoperability sa security features ng iOS at Android, ngunit hindi nito mapapalitan ang seguridad ng platform.

Dahil dito, nakatuon ang MeldID sa mga risks na maaring mapangasiwaan nito: credential generation, authorization, tokens, sessions, recovery, at ang pag-react sa posibleng compromise ng recovery channel.

Mula sa pag-login hanggang sa pagtugon

Nung una kong nakilala ang MeldID, maaari ko itong ilarawan bilang isang integrated identification and profile management system. Ngunit, sa paglabas ng mga mobile apps at mga bagong mekanismo ng proteksyon, naging mas malawak ang pananaw.

Ngayon, sumasagot na ang sistema hindi lang sa tanong na “paano mag-log in?”, kundi pati na sa mas komplikadong mga tanong:

• Anong gagawin kung may kahina-hinalang recovery attempt;

• Paano mag-recover nang walang access sa app;

• Paano humingi ng oras bago mag-activate ng bagong password;

• Paano i-cancel ang recovery na hindi sinang-ayunan ng owner;

• Paano i-revoke ang active sessions;

• Paano pigilan ang sadyang breach ng email sa panahon ng emergency;

• Paano maibalik ang control sa outside recovery channel;

• Paano panatilihin ang data ng user kapag tinigil ang lahat ng active access;

• Paano bumalik sa normal na operasyon matapos suriin ang sitwasyon.

Sa pangkalahatan, isang sequential security model ang nai-establish.

Hindi na ipinapadala ang active password ng MeldID sa recovery channel. Ang pag-access sa email ay hindi direktang naglalantad ng password, ngunit maaari nitong paandarin ang proseso ng paggawa ng bago. Kaya, ang recovery ay may delay at maaaring i-cancel sa trusted app.

Kung kulang pa ito, ang mode ng panic ay nag-er-revoke ng mga session, tokens, at hindi pinapayagan ang hindi pa natapos na recovery na magpatuloy sa loob ng protective window.

Makakakuha ang user ng napakahalagang resource sa isang aktwal na insidente: oras.

Oras upang ibalik ang kontrol sa email, suriin ang mga device, ayusin ang sitwasyon, at bumalik sa normal na access lamang kapag handa na.

Kaya, ang panic mode sa MeldID ay hindi lang isang button na “log out everywhere”. Ito ay isang emergency scenario na nagbabalik ng control kapag hindi na sapat ang karaniwang authorization, at kailangang i-recover muna ang tiwala sa account environment.

Para sa karagdagang impormasyon tungkol sa proyekto: meldid.de.