Bakit Nabigo ang mga TOTP Code Kapag Nag-drift ang Orasan ng Device

Ang mga one-time code ay maaaring ganap na tama sa iyong telepono at tanggihan pa rin ng server sa parehong segundo. Kinakalkula ng magkabilang panig ang parehong function mula sa isang shared secret at sa kasalukuyang time step, kaya ang hindi pagkakasundo tungkol sa oras ay lumilikha ng hindi pagkakasundo tungkol sa code. Ginagawa nitong isang depektong may kaugnayan sa seguridad ang pag-drift ng orasan, hindi lamang isang abala.

Dalawang orasan ang mahalaga dito, at ang pag-aayos sa nakikitang isa ang bahaging unang ginagawa ng mga tao. Ang karaniwang nangangailangan ng pansin ay ang isa pa.

Ang code ay isang function ng oras, hindi password

Kinukuha ng TOTP ang shared secret at isang counter na hinango sa kasalukuyang oras, pinaparaan ang dalawa sa isang hash na may key at pinuputol ang resulta sa isang maikling decimal string, ayon sa tinukoy sa RFC 6238. Sumusulong ang counter sa bawat time step, karaniwang tatlumpung segundo, kaya ang parehong sikreto ay gumagawa ng bagong halaga kapag nagbago ang step. Kinukuwenta muli ng verifier ang inaasahang halaga para sa kasalukuyang step at inihahambing, na nangangailangan ng parehong sikreto at parehong pag-unawa sa ngayon. Nananatiling magagamit muli ang password hanggang sa ito ay palitan, samantalang ang halagang ito ay nag-expire sa isang hangganang hindi nakikita ng client.

Kaya gumagana ang isang code at nabigo ang susunod makalipas ang ilang sandali. Ipinapaliwanag din nito kung bakit napaka hindi mapagkakatiwalaan ng paggawa ng kopya ng code mula sa isang chat message.

Dapat magtugma ang dalawang orasan, hindi isa

Ang enrollment material ang unang bagay na ibinabahagi, at ang oras ang pangalawa. Kung tama ang sikreto habang ang mga orasan ay nagkakaiba nang higit sa tinatanggap na window, ang bawat nabuong halaga ay nahuhulog sa maling step at tinatanggihan. Kung magkatugma ang mga orasan habang mali ang sikreto, tinatanggihan din ang bawat halaga, at magkapareho ang hitsura ng dalawang pagkabigo mula sa login screen. Ang paghihiwalay sa kanila ay nangangahulugan ng pagsuri sa account entry at sa oras nang hiwalay, sa ganoong pagkakasunod-sunod.

Ang orasan ng verifier ay karapat-dapat sa parehong pagsusuri gaya ng sa device. Ang server na sira ang pinagmumulan ng oras ay tinatanggihan ang mga tamang code ng lahat ng user nang sabay, at ilalarawan ng mga ulat ang biglaang pagkaantala sa halip na pag-drift. Sulit na makilala ang pattern na ito, dahil sa server nakasalalay ang pagwawasto at hindi sa isandaang telepono.

Ano ang halaga ng pagpapalawak ng window

Maaaring tanggapin ng mga implementasyon ang code mula sa katabing step upang sumipsip ng maliliit na pagkakaiba, at ang pagpapahintulot na iyon ay desisyon sa disenyo, hindi libreng pagsasaayos. Ang bawat karagdagang step ay nagpaparami sa bilang ng mga halagang wasto sa anumang sandali, na siyang eksaktong gusto ng umaatakeng naghuhula. Mahalaga rin ang panuntunan laban sa pag-ulit sa parehong dahilan, dahil ang code na tinanggap nang dalawang beses ay code na tumagas nang kapaki-pakinabang. Ang administrator na nagpapalawak ng window upang patahimikin ang mga reklamo ay nagpapalit ng tunay na katangian para sa kosmetikong pagpapabuti.

Ang pag-aayos ng orasan ang pagwawasto, samantalang ang pagpapalawak ng window ay pampakalma. Inaalis ng una ang sanhi at itinatago ito ng pangalawa.

Suriin ang dalawang orasan bago subukang muli

Basahin ang oras sa device at sa server, at ihambing ang mga offset sa halip na ang ipinapakitang lokal na oras. Ipinapakita ng mga command sa ibaba ang estado ng synchronization at ang raw na UTC moment sa isang Linux host o server. Patakbuhin ang mga ito sa magkabilang dulo bago baguhin ang anumang setting ng authentication.

timedatectl
date -u +'%Y-%m-%dT%H:%M:%SZ'
chronyc tracking
timedatectl timesync-status

Ang offset na sinusukat sa segundo ay walang pinsala, ang sinusukat sa minuto ay nagpapaliwanag ng pagtanggi, at ang sistemang walang iniuulat na pinagmumulan ng synchronization ay kandidato sa pareho. Ihambing nang direkta ang dalawang UTC timestamp, dahil kasama sa lokal na oras ang time zone na hindi kailanman nakikita ng algorithm. Kung maliit ang mga offset at nabigo pa rin ang mga code, itigil ang pag-aayos ng orasan at suriin sa halip ang enrollment entry. Ang paulit-ulit na pagtatangka laban sa naka-lock na account ay nagpapahirap obserbahan ang orihinal na depekto.

Itala ang oras ng pagtanggi, ang offset at ang teksto ng error, at ilabas ang shared secret doon. Maaaring magtrabaho ang suporta sa unang tatlo at hindi dapat kailanman makita ang pang-apat.