Koncepti

Kako deluje wkidentity: kaj paket vodi in zakaj so poteki tako zarezani. Kaj želite narediti, piše na Identity; kaj želite poiskati, v Tehnični referenci.

Slovenska referenca je krajša in starejša od nemške. Razdelki o pogodbi Identity Plugin Contract v1, o zagotovilu seje in o pravilniku obstajajo samo v nemščini: Konzepte (de).

Definicija

wkidentity ponuja dvofaktorsko overjanje TOTP po RFC 6238 (združljivo z Microsoft Authenticator, Google Authenticator in drugimi standardnimi aplikacijami) kot samopostrežno funkcijo na strani profila (do=profile). Poleg tega doda interno testno stran, ki preveri poljubno skrivnost Base32 proti lastni implementaciji TOTP, ne da bi skrivnost kadar koli zapustila brskalnik.

Potek dela (vpis)

Vpis je namerno dvokoračni postopek, ne takojšnji vklop, da uporabnik nikoli ne more „aktivirati“ 2FA s skrivnostjo, ki je njegova aplikacija authenticator dejansko nikoli ni skenirala:

Začetek — gumb „Nastavi“ na do=profile (viden le, če še ni vpisan). Ustvari novo

naključno skrivnost (auth_randombytes(), 160 bitov) in jo shrani le v sejo — na disk

  se še **nič** ne zapiše.
- **Potrditev** — stran izriše kodo QR + ročno skrivnost + vnosno polje za 6-mestno kodo. Šele
  **pravilna** koda (preverjena proti čakajoči skrivnosti, toleranca ±1 časovni korak) trajno
  shrani šifrirano skrivnost (''saveSecret()'') in počisti čakajoč vnos iz seje. Napačna koda
  pusti čakajočo skrivnost nedotaknjeno — uporabnik lahko znova skenira/vnese isto kodo QR.
- **Stanje/onemogočitev** — ko je vpisan, stran profila prikaže le stanje "aktivno" + potrditveno
  polje "Onemogoči", ki skupaj z običajnim gumbom profila "Shrani" odstrani skrivnost
  (''removeSecret()'').

Znana past DokuWiki, tu rešena: doku.php pokliče session_write_close() pred act_dispatch(). Naiven zapis $_SESSION[…] = … v kljuki ACTION_ACT_PREPROCESS zato posodobi le polje v pomnilniku trenutne zahteve in nikoli ne pristane na disku — naslednja zahteva (oddaja potrditve) ne vidi več čakajoče skrivnosti, vsaka koda bi bila „napačna“. Popravek: vsak zapis seje za čakajočo skrivnost se znova sam ovije v @session_start(); …; session_write_close(); (enak idiom, ki ga jedro DokuWiki uporablja v updateprofile() datoteke auth.php in send_redirect() datoteke common.php). Brez tega idioma ponovnega odpiranja se potrditev podre ne glede na okolje — simptom se je enako pojavil na MicroApache in IIS.

Interna testna stran (do=wkidentity_debug, v profilu neobvezno povezana prek nastavitve show_debug_link) je popolnoma ločena od dejanskega vpisa: izračuna kode TOTP za poljubno prilepljeno skrivnost izključno v brskalniku (Web Crypto HMAC-SHA1) in nikoli ničesar ne pošlje strežniku — namenjena preverjanju združljivosti z aplikacijami authenticator, ne prikazu resničnih uporabniških skrivnosti.

Potek dela (vpis po e-pošti)

Drugi zavihek v istem območju 2FA, viden le, ko je aktivna nastavitev allow_email_method (privzeto izklopljeno, glejte „Konfiguracija“). Enako dvokoračno načelo kot pri TOTP: „Nastavi po e-pošti“ pošlje 6-mestno kodo na naslov, trenutno shranjen v profilu (sendEmailChallenge(), zgoščena vrednost kode shranjena na strežniški strani z iztekom 10 minut, nikoli v golem besedilu); šele pravilno vnesena koda aktivira metodo (saveEmailMethod()). Uporabnik ima vedno natanko eno aktivno metodo (totp ali email), nikoli obeh hkrati.

Uveljavljanje prijave

Implementirano prek LoginGate.php in jedrne kljuke AUTH_LOGIN_CHECK (inc/auth.php, pred dokončanjem seje) — edina točka v celotnem ciklu zahteve, kjer je mogoče dodatni faktor vriniti pred dokončano prijavo, saj jedrna auth_login() sicer preverjanje gesla in vzpostavitev seje opravi v enem koraku.

Potek: pravilno geslo + uporabnik vpisan + nastavitev enforce_login aktivna → prijava se ustavi, čakajoče stanje (uporabnik, geslo, metoda, iztek, števec neuspelih poskusov) pristane v seji za največ login_attempt_window sekund (idiom ponovnega odpiranja, glejte zgoraj), stran do=wkidentity_verify pa zahteva ustrezno kodo. Ob uspehu se sproži prava jedrna prijava (auth_login()) sama — brez lastne logike seje/piškotkov, polna ponovna uporaba. Po login_max_attempts neuspelih poskusih se čakajoče stanje zavrže; uporabnik mora znova začeti z geslom.

Nevpisani uporabniki ostanejo popolnoma nedotaknjeni — gateLogin() poseže le pri že vpisanih uporabnikih; kdor 2FA nikoli ni nastavil, se prijavi nespremenjeno v enem koraku, tudi pri aktivnem enforce_login.

enforce_login preglasi jedrno vedenje funkcije auth_login() — najtvegan del kode v tem vtičniku. Zato je privzeto izklopljeno in dosegljivo kot preprosto stikalo onoff v običajnem Config Managerju (ne le v lastni skrbniški plošči) — napako tu bi sicer v najslabšem primeru ne bilo mogoče dovolj hitro izklopiti.

Varnost

Šifriranje v mirovanju — skrivnosti nikoli ne ležijo v golem besedilu na disku (glejte Tehnično referenco: Shranjevanje); kode e-pošte so shranjene le zgoščene (SHA-256).
CSRF — vsaka oddaja na do=profile, v skrbniški plošči in na do=wkidentity_verify preveri checkSecurityToken() (CWE-352).
XSS — vse izpisane vrednosti (skrivnost, URI, prijava) gredo skozi hsc() (CWE-79).
Dvokoračni vpis — preprečuje „aktivacijo“ brez dokazanega skeniranja/prejema (glejte Potek dela (vpis)), za obe metodi.
Uveljavljanje prijave kot stikalo za zasilni izklop — enforce_login je preprosto stikalo onoff, neodvisno od lastne skrbniške plošče, takoj izklopljivo.
Omejevanje hitrosti — števec neuspelih poskusov, vezan na sejo, na do=wkidentity_verify (brez sledenja IP, namerno preprosto).
Orodje za razhroščevanje — dosegljivo le prijavljenim uporabnikom; izračun skrivnosti izključno na strani odjemalca, nič se nikoli ne pošlje strežniku.
Prvi vtičnik AUTH_ACL_CHECK v tem repozitoriju — le dodatno zaostri, nikoli ne spremeni conf/acl.auth.php.

Sorodne teme

Identity — vstop in pogosta opravila
Tehnična referenca — shranjevanje, skrbniška plošča, konfiguracija, razredi
Diagnostika — simptomi z vzrokom in odpravo
Zaslon za poziv (de)
Workbench Plugin Contract v1 (de)