Odprite stran za spremembo gesla in jo preberite tako, kot bi jo bral uporabnik, nato vprašajte, katera storitev dejansko ima poverilnico. Stran je obrazec; shramba identitet je oblast. Če se oba ne ujemata, uporabnik naleti na zavrnjeno geslo, ponastavitev, ki ničesar ne ponastavi, ali sporočilo o uspehu, ki ničesar ne spremeni. Prehod toka od zaslona do backenda je edini način, da to ujamete.

Začnite s klasifikacijo operacije: običajna sprememba, tok s poteklim geslom ali obnovitev po pozabljenem geslu.

Tri operacije, tri delovni tokovi

Običajna sprememba predpostavlja, da uporabnik pozna trenutno geslo in to lahko dokaže. Tok s poteklim geslom lahko dovoli omejeno sejo, v kateri je dovoljena le sprememba. Obnovitev po pozabljenem geslu zahteva povsem drugačen dokaz identitete in se lahko prenese na ponudnika identitete, namesto da bi se obravnavala na prehodu VPN. Vsaka ima svojo končno točko, podporo v backendu in pravila seje, en obrazec pa ne more pravilno oskrbovati vseh treh.

V federirani namestitvi prehod morda sploh ne zbira novega gesla. Preverite, ali tok preusmeri k ponudniku identitete in ali besedilo strani še opisuje lokalni obrazec.

Od kod politika dejansko prihaja

Vprašajte lastnika identitete o dovoljeni dolžini, naboru znakov in morebitnih veljavnih omejitvah, nato napišite navodila, ki se s tem ujemajo. Izmišljanje pravil sestave v besedilu pomoči ali obljubljanje sprejetja, ki ga backend zavrne, oboje ustvarja zahtevke za podporo. Smernice NIST o digitalni identiteti se nagibajo k jasnim navodilom in koristnim povratnim informacijam namesto samovoljnih pravil, medtem ko dejanska politika organizacije še vedno velja. Objava ni dokaz, da se določen imenik že obnaša tako.

Naj bodo sporočila o napakah koristna, ne da bi razkrila skrivnosti. Sporočilo, ki ponovi delno vneseno geslo, ali posnetek zaslona v zahtevku, ki ga vsebuje, spremenita artefakt podpore v razkritje poverilnic.

Besedilo, skladno z backendom

Stran bi morala poimenovati delovni tok, namesto da politiko opisuje abstraktno. Povejte, kje se sprememba zgodi, kakšen dokaz je potreben in kaj se zgodi z drugimi sejami. Če sprememba uporabnika odjavi povsod, povejte to; če druge naprave ostanejo aktivne, povejte tudi to. Zmeden uporabnik, ki ponavlja uspešno spremembo, je strošek podpore, ki se mu boljše besedilo izogne.

Lokalizacija lahko spremeni ton navodil; ne more spremeniti tega, kar backend sprejme.

Preizkusite tok, ne strani

Uporabite dovoljen testni račun in pojdite skozi dokumentirano spremembo, primer zavrnitve, primer poteklega gesla in poznejšo prijavo. Kjer je MFA ali federirana preusmeritev del odobrenega toka, pojdite tudi skozi to. Stran, ki se pravilno izriše, je preverila predstavitev in nič drugega, ker o dokončanju operacije s poverilnico odloča storitev identitete.

Zabeležite izid vsakega primera z uporabljenim računom in časom. Tok, ki enkrat deluje pri skrbniku in ne uspe pri običajnem uporabniku, je pogost izid, in prav zapis ga naredi vidnega.

Nato posodobite stran, da opisuje, kaj se je v resnici zgodilo. To je celotna naloga.

Sorodni članki