Gdje ide kod statičkog izazova pri prijavi na OpenVPN

Klijent prikazuje drugo polje nakon polja za lozinku, unesete kod s hardverskog tokena, a prijava i dalje ne uspijeva s greškom provjere identiteta. To polje postoji, dakle profil ga je zatražio. Da li je server ikada dobio vrijednost u obliku koji razumije drugo je pitanje, i na njega prvo vrijedi odgovoriti.

Pođite od upita koji vaš klijent zaista prikazuje

Profil može nositi direktivu statičkog izazova s nizom upita i zastavicom koja kontrolira prikazuje li se odgovor dok tipkate. Upit je ono što vidite u dijalogu; zastavica je postavka prikaza za taj isti unos. Nijedno od njih ne govori serveru kako da bilo što provjeri.

Izbrojte polja koja ste zaista dobili. Jedno polje za korisničko ime plus jedno maskirano polje je uobičajena prijava lozinkom bez ikakvog izazova. Drugo polje koje se pojavi nakon lozinke, s vlastitom oznakom, je klijent koji provodi interakciju izazova.

Ako se drugo polje nikada ne pojavi u klijentu koji koristite, taj klijent možda ne provodi interakciju, ili je provodi samo kroz drugačije sučelje, poput sučelja za upravljanje. Provjeriti klijent je jeftinije od prepisivanja profila, i obično se nesklad upravo tu nalazi.

Što server već mora podržavati

Profil opisuje što klijent treba prikupiti. On ne uključuje provjeru na serveru, a server bez odgovarajuće integracije provjere identiteta jednostavno će dobiti lozinku koju ne prepoznaje. Zato neka postavljanja prikazuju upit i odbijaju svaki kod, i zato je odgovor operatera o tome koji mehanizam obavlja provjeru onaj koji je važan.

Pitajte operatera koji mehanizam obavlja provjeru. To može biti dodatak koji razgovara s PAM-om, skriptna kuka koja provjerava odgovor prema servisu tokena, ili integracija zasnovana na upravljanju koja sama raščlanjuje spakovanu vrijednost. Svaki od njih očekuje nešto drugačiji unos.

Ovdje treba i kalibrirati očekivanja. Drugi upit je mehanizam unosa, a ne dokaz da se drugi faktor primjenjuje, jer se primjena događa na strani servera i vidi se samo kad testirate pogrešan kod.

Kodirano polje koje šalje sučelje za upravljanje

Kada sučelje vodi vezu kroz sučelje za upravljanje, lozinka i odgovor na izazov pakuju se u jednu vrijednost prije slanja. Referenca sučelja za upravljanje opisuje format: prefiks, zatim lozinka i odgovor kao odvojene Base64 komponente.

Base64 je kodiranje, ne zaštita. Ne skriva ništa od onoga ko može pročitati polje, i ne pretvara jednokratni kod u nešto što se može ponovno koristiti. Spakovana vrijednost zaslužuje isti tretman kao lozinka: izvan dijeljenih profila, izvan naredbenih redaka i izvan dijagnostičkih zapisa.

To kodiranje je i najčešći izvor zabune, jer sada postoje tri oblika koji izgledaju slično i nisu zamjenjivi. Obična datoteka vjerodajnica sadrži lozinku. Doslovno spajanje lozinke i koda sadrži drugi niz. Spakovani odgovor klijenta za upravljanje sadrži treći. Potvrdite koji od njih očekuje vaš put provjere prije nego promijenite polje samo zato što je greška nestala.

Statično protiv dinamičkog: različito vrijeme

Statički izazov poznat je prije slanja prvih vjerodajnica, pa ga klijent može zatražiti unaprijed. Dinamički izazov stiže kasnije, šalje ga tok provjere identiteta nakon što je razmjena već počela, i treba mu klijent koji može obraditi zahtjev usred razgovora.

Podrška za jedno ne daje vam drugo. Direktiva profila koja postavlja statički upit ne provodi izazov koji pokreće server, a sučelje koje obrađuje dinamičke zahtjeve možda ipak neće prikazati statički. Čitanje koja je strana pokrenula zahtjev najbrži je način da ih razlikujete.

Rad bez nadzora mjesto je gdje to postaje pitanje dizajna, a ne sučelja. Sačuvani kod nije trajna vjerodajnica za podizanje sustava, a ponovno povezivanje satima kasnije trebat će svjež unos, osim ako postavljanje podržava raspored tokena koji je operater namjerno omogućio.

Testirajte uspjeh i neuspjeh, ne samo dijalog

Provedite obje polovine testa. Ispravne vjerodajnice s valjanim odgovorom trebale bi uspjeti; ispravne vjerodajnice s namjerno pogrešnim odgovorom trebale bi biti odbijene. Ako obje uspiju, klijent prikuplja unos koji ništa ne provjerava, a dijalog je zamijenjen za kontrolu. Taj jedan test uhvati više postavljanja od bilo kakvog pregleda profila.

Zatim ponovite vezu nakon ponovnog povezivanja, s računom koji nije upisan, i kroz koji god klijent vaši korisnici stvarno koriste. Pojava upita je ponašanje klijenta; odbijanje pogrešnog koda je server koji nešto primjenjuje.