Miksi kelvollinen kertakäyttökoodi epäonnistuu silti VPN-kirjautumisessa

Avaat VPN-asiakasohjelman, kirjoitat salasanan, ja autentikaattorista tulevat kuusi numeroa palaavat virheellisinä — kahdesti, sitten kolmannen kerran. Tilillä ei ole muuttunut mitään eilisestä, joten vaisto kehottaa poistamaan autentikaattorin merkinnän ja skannaamaan sen uudelleen — yleensä väärä korjaus. Kertakäyttökoodi ei ole toinen salasana: yhdyskäytävän on pyydettävä se tietyssä vaiheessa, tietystä rekisteröidystä merkinnästä, tietyn aikaikkunan sisällä, ja useimmat hylkäykset tapahtuvat ennen kuin numeroita verrataan. Selvitä, missä vaiheessa olet, ennen kuin kosket rekisteröintiin.

Pyyntöjen järjestys kertoo, missä virrassa olet

Kolme muotoa kattaa lähes jokaisen VPN-kirjautumisen, johon liittyy koodi. Kaksivaiheisessa muodossa asiakasohjelma lähettää salasanan, palvelin antaa haasteen ja asiakasohjelma kysyy uudelleen. Yhdistetyssä muodossa yhdyskäytävä haluaa salasanan ja koodin yhdessä lähetyksessä — joskus yhteenliitettyinä, joskus erottimen jälkeen, jonka vain operaattori dokumentoi. Selainmuodossa asiakasohjelmalla ei ole kenttää lainkaan: koodi syötetään verkkosivulle tai push-hyväksyntä korvaa sen, ja työpöytäasiakas odottaa tulosta.

Väärä muoto näyttää huonolta koodilta. Liitä tuore koodi vain salasanan kenttään, ja palvelin lukee sen osana salasanaa. Asiakaspäässä OpenVPN 2.4 ja uudemmat tekevät eron näkyväksi: palvelin, joka vastaa AUTH_FAILED,CRV1:, odottaa haastevastausta, joten profiili tarvitsee static-challenge-asetuksen tai salasanatiedoston SCRV1:-muodossa. Vanhempi profiili, jossa on vain auth-user-pass, vahvistaa salasanan ja pysähtyy sitten, mikä näyttää lokissa OTP-virheeltä, vaikka koodia ei lähetetty.

WireGuard kannattaa mainita poikkeuksena: se todentaa avainpareja eikä ihmisiä, joten koodille ei ole kenttää. Jos palveluntarjoaja mainostaa sellaista, jokin tunnelin ulkopuolinen hyväksyy sen.

Mitä palvelin tekee kuudella numerolla

Aikapohjaiset koodit noudattavat RFC 6238-standardia, joka käärii RFC 4226:n vanhemman laskuripohjaisen rakenteen: HMAC liikkuvan tekijän yli, oletuksena kuuteen numeroon katkaistuna. TOTP:ssä liikkuva tekijä on nykyinen Unix-aika jaettuna askeleella, 30 sekuntia, ellei operaattori ole muuttanut sitä. Todentaja ei koskaan vertaa numeroitasi tallennettuun arvoon; se laskee odotetun koodin jaetusta siemenestä uudelleen ja hyväksyy yleensä myös viereiset askeleet, joten hidas edestakainen matka ei kaada kirjautumista.

Kaksi seurausta jää huomaamatta. Puhelimen aikavyöhyke on merkityksetön, koska siemen ei näe koskaan paikallista kelloa — vain poikkeama todellisesta UTC:stä ratkaisee, ja kaksi minuuttia edellä käyvä laite epäonnistuu jokaisessa koodissa näyttäen samalla siistiä laskuria. Ja koodi on suunnittelultaan kertakäyttöinen: todentaja muistaa viimeisen laskurin arvon, jonka se hyväksyi kyseiselle siemenelle, joten samat numerot uudelleen lähetettyinä hylätään jopa saman ikkunan sisällä. Asiakasohjelma, joka yrittää uudelleen aikakatkaisun jälkeen, voi polttaa juuri lähettämänsä koodin.

Laskuripohjaiset tokenit siirtävät laskuriaan joka painalluksella, joten ne ajautuvat epäsynkroniin sen jälkeen kun koodeja on luotu mutta ei koskaan lähetetty; tavallinen korjaus on uudelleensynkronointi-ikkuna, joka hyväksyy muutaman arvon eteenpäin. Jos operaattori rekisteröi HOTP:n ja sovelluksesi näyttää TOTP:tä, jokainen arvo on väärä tavalla, joka näyttää kello-ongelmalta. QR-koodin takana oleva provisiointi-URI nimeää tyypin, numerot, jakson ja tiivisteen.

Epäonnistumiset, jotka näyttävät väärältä koodilta

Rekisteröity merkintä on yleisin syyllinen. Autentikaattorisovellukset nimeävät merkinnät myöntäjän ja tilin mukaan, joten kenellä on kaksi identiteettiä samassa VPN:ssä, voi päätyä kahteen merkintään, joiden nimet eroavat yhdellä merkillä. Koodi on kelvollinen vain siemenelle, joka sen loi, eikä millekään muulle. Vertaa puhelimen nimeä palvelimen tallentamaan käyttäjänimeen, älä siihen, mitä muistat kirjoittaneesi.

Toinen on yhteensopimaton parametrijoukko. Kahdeksalla numerolla, 60 sekunnin jaksolla tai SHA-256:lla rekisteröity siemen tuottaa koodeja, jotka kuutta numeroa, 30 sekuntia ja SHA-1:tä odottava todentaja hylkää, eikä asiakaspäässä sitä voi erottaa väärästä koodista. Se ilmenee migraatioiden jälkeen, joissa merkintä lisättiin uudelleen QR-koodin valokuvasta tai joissa token-tietue rakennettiin uudelleen oletusarvoilla.

Kolmas ei koske koodia. Yhdyskäytävät palauttavat yleensä yhden yleisen todennusvirheen väärälle salasanalle, vanhentuneelle koodille ja poistetulle tilille, tarkoituksella, jotta kukaan ei voi selvittää, mikä tekijä epäonnistui. Lue yhdyskäytävän tai RADIUS:n loki asiakasohjelman bannerin sijaan: haaste, jota ei koskaan annettu, pääsyn hylkäys ilman OTP-attribuuttia ja käytännön hylkäys näyttävät ruudulla samalta ja johtavat erilaisiin seuraaviin vaiheisiin.

Lyhyt järjestys, joka rajaa sitä

Aloita halvimmasta tarkistuksesta ja pysähdy ensimmäiseen vaiheeseen, joka ei pidä.

1. Odota tuoretta koodia, lähetä se kerran ja pane merkille, ilmestyykö haaste ennen salasanan hyväksymistä vai sen jälkeen.
2. Sovita autentikaattorin nimi palvelimen tallentamaan käyttäjänimeen.
3. Varmista, että profiili ylipäätään pystyy vastaamaan haasteeseen, kuten yllä CRV1-tapauksessa.
4. Vertaa laitteen kelloa tunnettuun aikalähteeseen; yli muutaman kymmenen sekunnin poikkeama rikkoo TOTP:n itsestään.
5. Kysy operaattorilta, onko token TOTP vai HOTP, ja mitkä numerot, jakso ja tiiviste rekisteröitiin.

Kaksi sääntöä estää tätä pahentumasta. Älä yritä monta kertaa: monet yhdyskäytävät laskevat epäonnistumisia tiliä kohti ja joko lukitsevat sen tai alkavat viivyttää vastauksia, joten purske muuttaa pienen asetusvirheen tukipyynnöksi. Äläkä rekisteröi tokenia uudelleen diagnoosiksi, koska se mitätöi vanhan siemenen; jos varsinainen vika oli haaste, jota asiakasohjelma ei koskaan lähettänyt, sinulla on nyt kaksi muutosta selitettävänä yhden sijaan.

Pidä siemen ja palautuskoodit poissa kierrosta

Kuusi numeroa ja niiden takana oleva salaisuus eivät ole vaihdettavissa. Provisiointi-QR-koodi tai Base32-siemen luo jokaisen tilin tulevan koodin, joten se kuuluu samaan luokkaan kuin salasana: ei kuvakaappaukseen, ei tiketin kommenttiin, ei keskusteluun jonkun kanssa, joka otti sinuun yhteyttä ensin. Palautuskoodit ovat erillinen mekanismi — kertakäyttöisiä, usein ohittavat koodipyynnön kokonaan, ja yhden kuluttaminen tilin testaamiseen poistaa varareitin, jota saatat myöhemmin tarvita.

Koodi ei myöskään tee kirjautumissivusta luotettavaa: OTP-pyyntö samannäköisellä verkkotunnuksella kerää kelvollisen koodin ja toistaa sen ikkunan sisällä, ja sertifikaatti on edelleen se, mikä kertoo, mihin kirjoitat.

Jos järjestys päätyy profiiliin, joka ei pysty vastaamaan haasteeseen, korjaa profiili ja testaa uudelleen yhdellä tuoreella koodilla. Jos se päätyy yhteensopimattomiin rekisteröintiparametreihin, pyydä operaattoria lukemaan token-tietue ennen kuin kukaan skannaa mitään. Jos se päätyy lukitukseen, odota se pois sen sijaan että vaihtaisit asiakasohjelmaa — tilin tila on este, ei sovellus.