Wêrom in jildige ienmalige koade by VPN-ynloggen dochs mislearret

Jo iepenje de VPN-klant, typen it wachtwurd, en de seis sifers fan jo autentikator komme werom as ûnjildich — twa kear, dan in tredde kear. Der is sûnt juster neat feroare oan it akkount, dus it ynsinst is om de ynfiering yn de autentikator te wiskjen en opnij te skennen — meastentiids de ferkearde reparaasje. In ienmalige koade is net in twadde wachtwurd: de poarte moat him yn in beskaat stap freegje, út in beskaat ynskreaun ynfiering, binnen in beskaat finster, en de measte wegere barre foardat de sifers ferlike wurde. Fêststelle yn hokker stap jo binne foardat jo de ynskriuwing oanreitsje.

De folchoarder fan de fragen fertelt yn hokker stream jo binne

Trije foarmen dekke hast elke VPN-ynloggen mei in koade. Yn de twastapfoarm stjoert de klant it wachtwurd, de tsjinner jout in útdaging, en de klant freget opnij. Yn de kombinearre foarm wol de poarte wachtwurd en koade yn ien yntsjinning — soms oaninoar, soms nei in skiedingsteken dat allinnich de operator dokumintearret. Yn de browserfoarm hat de klant hielendal gjin fjild: de koade giet yn in webside, of in pushbefêstiging ferfangt him, en de desktopklant wachtet op it resultaat.

De ferkearde foarm liket op in minne koade. Plak in farske koade yn in fjild dat allinnich foar it wachtwurd is, en de tsjinner lêst him as part fan it wachtwurd. Oan de klantkant meitsje OpenVPN 2.4 en letter it ferskil sichtber: in tsjinner dy't antwurdet mei AUTH_FAILED,CRV1: ferwachtet in útdagingsantwurd, dus it profyl hat static-challenge nedich of in wachtwurdbestân yn SCRV1:-foarm. In âlder profyl mei allinnich auth-user-pass ferifiearret it wachtwurd en stiet dan stil, wat yn it logboek as in OTP-mislearring liket, ek al is der gjin koade stjoerd.

WireGuard is it neamen wurdich as de útsûndering: it ferifiearret kaaipetten yn stee fan minsken, dus der is gjin fjild foar in koade. As in leveransier ien oankundiget, is it wat bûten de tunnel dat him akseptearret.

Wat de tsjinner mei de seis sifers docht

Tiidbasearre koades folgje RFC 6238, dat de âldere tellerbasearre konstruksje út RFC 4226 ynpakt: in HMAC oer in beweegjende faktor, standert ta seis sifers ôfkoarte. Foar TOTP is de beweegjende faktor de hjoeddeiske Unix-tiid dield troch in stap, 30 sekonden útsein as de operator dy feroare hat. De ferifiearder fergeliket jo sifers nea mei in bewarre wearde; hy berekkent de ferwachte koade opnij út it dielde sied en akseptearret meastentiids ek de neistlizzende stappen, sadat in stadige rûnreis de oanmelding net mislearje lit.

Twa gefolgen wurde mist. De tiidsône fan 'e telefoan is net fan belang, want it sied sjocht nea in pleatslike klok — allinnich de ôfwiking fan 'e echte UTC telt, en in apparaat dat twa minuten foar rint mislearret elke koade wylst it in skjinne ôftelling sjen lit. En in koade is fan ûntwerp ienmalich: de ferifiearder ûnthâldt de lêste tellerwearde dy't er foar dat sied akseptearre hat, dus deselde sifers dy't opnij stjoerd wurde, wurde sels binnen itselde finster wegere. In klant dy't nei in tiidferrin opnij besiket, kin de koade dy't er krekt stjoerd hat, ferbaarnje.

Tellerbasearre tokens bewege har teller by elke druk, dus se reitsje út 'e syngroanisaasje nei't koades oanmakke binne mar nea stjoerd; de gewoane reparaasje is in wersyngroanisaasjefinster dy't in pear wearden foarút akseptearret. As de operator HOTP ynskreaun hat en jo applikaasje toant TOTP, is elke wearde ferkeard op in manier dy't as in klokprobleem liket. It URI foar levering efter de QR-koade neamt it type, de sifers, de perioade en de hash.

Mislearrings dy't as in ferkearde koade lykje

De ynskreaune ynfiering is de meast foarkommende skuldige. Autentikatorapplikaasjes labelje ynfieringen op útjouwer en akkount, dus wa't twa identiteiten op itselde VPN hat, kin twa ynfieringen krije wêrfan de labels yn ien teken ferskille. In koade jildt foar it sied dat him makke hat en foar neat oars. Fergelykje it label op 'e telefoan mei de brûkersnamme dy't de tsjinner fêstleit, net mei wat jo jo yn 't ûnthâld hawwe dat jo typt hawwe.

Twadde is in set parameters dy't net past. In sied dat ynskreaun is mei acht sifers, in perioade fan 60 sekonden of SHA-256 jout koades dy't in ferifiearder dy't seis sifers, 30 sekonden en SHA-1 ferwachtet wegert, en by de klant is dat net te ûnderskieden fan in ferkearde koade. It ferskynt nei migraasjes wêrby't de ynfiering opnij tafoege is út in foto fan 'e QR-koade, of wêrby't it tokenrekord mei standertwearden werboud is.

Tredde giet net oer de koade. Poarten jouwe meastentiids ien algemiene autentikaasjeflater foar in ferkeard wachtwurd, in ferrûne koade en in útskeakele akkount, opsetlik, sadat nimmen ûndersykje kin hokker faktor mislearre is. Lês it logboek fan 'e poarte of RADIUS yn stee fan 'e banner fan 'e klant: in útdaging dy't nea útjûn is, in tagongswegering sûnder OTP-attribút en in beliedswegering sjogge der itselde út op it skerm en liede ta ferskillende folgjende stappen.

In koarte folchoarder dy't it ferkringt

Begjin mei de goedkeapste kontrôle en stop by de earste stap dy't net hâldt.

1. Wachtsje op in farske koade, stjoer him ien kear, en notearje oft de útdaging foar of nei it akseptearjen fan it wachtwurd ferskynt.
2. Koppelje it label yn 'e autentikator oan de brûkersnamme dy't de tsjinner bewarret.
3. Befêstigje dat it profyl hielendal op in útdaging antwurdzje kin, lykas yn it gefal CRV1 hjirboppe.
4. Fergelykje de klok fan it apparaat mei in bekende tiidboarne; in ôfwiking fan mear as in pear tsientallen sekonden brekt TOTP op himsels.
5. Freegje de operator oft it token TOTP of HOTP is, en hokker sifers, perioade en hash ynskreaun binne.

Twa regels foarkomme dat dit it slimmer makket. Besykje net in protte kearen: in protte poarten telle flaters per akkount en slute it dan ôf of begjinne antwurden te fertragjen, sadat in útbarsting in lytse ferkearde konfiguraasje yn in stipekaartsje feroaret. En skriuw it token net opnij yn as diagnoaze, want dat makket it âlde sied ûnjildich; as de echte flater in útdaging wie dy't de klant nea stjoerd hat, hawwe jo no twa feroarings om te ferklearjen yn stee fan ien.

Hâld it sied en de werstelkoades bûten it sirkwy

De seis sifers en it geheim dêrefter binne net útwikselber. In QR-koade foar levering of in Base32-sied makket elke takomstige koade foar it akkount, dus it heart yn deselde kategory as it wachtwurd: net yn in skermôfdruk, net yn in kommentaar by in kaartsje, net yn in petear mei immen dy't earst kontakt mei jo socht hat. Werstelkoades binne in apart meganisme — ienmalich, slaan de koadefraach faak hielendal oer, en ien besteegje om it akkount te testen hellet in efterheaksel fuort dat jo letter nedich wêze kinne.

In koade makket ek gjin oanmeldside betrouber: in OTP-fraach op in ferlykber domein sammelt in jildige koade en spilet dy binnen it finster ôf, en it sertifikaat is noch altyd wat jo fertelt wêr't jo type.

As de folchoarder by in profyl útkomt dat gjin útdaging beantwurdzje kin, reparearje it profyl en test opnij mei ien farske koade. As it by parameters foar ynskriuwing útkomt dy't net passe, lit de operator it tokenrekord lêze foardat immen wat skennet. As it by in beskoatteling útkomt, wachtsje dy ôf yn stee fan fan klant te feroarjen — de tastân fan it akkount is de obstakel, net de applikaasje.