HOTP

Den aktuella versionen av sidan har ännu inte granskats av erfarna bidragsgivare och kan skilja sig väsentligt från versionen som granskades den 4 januari 2017; verifiering kräver 31 redigeringar .

HOTP ( HMAC -Based One-Time Password Algorithm ) är en säker autentiseringsalgoritm som använder ett engångslösenord (One Time Password, OTP). Baserat på HMAC (SHA-1). Det är en enkelriktad autentiseringsalgoritm, nämligen: servern autentiserar klienten .

En händelse används som en parameter som är ansvarig för dynamiken i lösenordsgenereringen, det vill säga själva genereringens faktum [1] : varje gång ett nytt lösenord skapas, ökar händelseräknaren sitt värde med ett, och det är denna monotona ökning värde som används som huvudparameter för algoritmen. Den andra parametern för att beräkna engångslösenord är en symmetrisk nyckel, som måste vara unik för varje generator (klient) och privat för alla utom servern och själva generatorn (klienten).

Historik

Algoritmen beskrevs först formellt av IETF -teamet i december 2005. [2] [3] Det var det första riktigt framgångsrika projektet för Initiative for Open Authentication ( OATH ). [4] Algoritmer för att generera engångslösenord fick stor popularitet vid den tiden på grund av den snabba utvecklingen av mobilindustrin. Krävde en pålitlig algoritm, enkel vad gäller implementering.

2008 födde HOTP en starkare tidsbaserad engångslösenordsalgoritm (TOTP), som till stor del ärver egenskaperna från sin förälder. I september 2010 utvecklades en kraftfull OATH Challenge-Response Algorithm ( OCRA ) autentiseringsalgoritm baserad på TOTP. [fyra]

HOTP-algoritmen introducerade också innovationer inom tekniken för att generera engångslösenord. SHA-1- hashfunktionen, som var stabil vid den tiden, kombinerades med en icke-trivial lösning för att ha en händelseräknare. Dessa funktioner har höjt HOTP till samma nivå som tidstestade algoritmer som S/KEY . [fyra]

Räknare i HOTP och TOTP

Huvudskillnaden mellan de två algoritmerna är lösenordsgenereringen baserat på tidsstämpeln som TOTP- algoritmen använder som parameter. I det här fallet används inte det exakta tidsvärdet, utan det aktuella intervallet, vars gränser har ställts in i förväg (till exempel 30 sekunder) [5]

HOTP genererar en nyckel baserad på en delad hemlighet och en tidsoberoende räknare. Modellen för denna algoritm är baserad på händelser - till exempel, varje gång nästa engångslösenord genereras kommer räknaren att öka. Därför måste senare genererade lösenord vara olika varje gång.

På grund av detta är grunden för räknaren i HOTP-algoritmen, till skillnad från andra algoritmer som använder en timer, skyddad från desynkronisering av sändande enheter eller för stort avstånd mellan dem (sådant avstånd att svaret från mottagaren kommer senare än lösenordets giltighetstid löper ut) [2] . Detta gör att HOTP-lösenord förblir giltiga under en obegränsad tid, medan TOTP- lösenord inte längre kommer att vara giltiga efter en viss tid.

Som ett resultat, förutsatt att samma hash-funktion används som i HOTP, gör denna skillnad i algoritmens funktion TOTP till en säkrare och mer föredragen lösning för engångslösenord [6]

Beskrivning av algoritmen

Notation

$K$ - En hemlig nyckel som är unik för varje klient och endast känd för honom och servern. Längd — 160 bitar (rekommenderas) eller 128 bitar (minst) [1]
$C$ — Aktuellt tillstånd för 8-byte händelseräknaren
$D$ — Antalet siffror i det genererade lösenordet
$T$ - Antalet misslyckade auktoriseringsförsök, varefter servern blockerar anslutningen till klienten
$s$ — Avsynkroniseringsparameter. Definierar den maximala avvikelsen mellan serverns räknare och klienten, vid vilken engångslösenordet kommer att accepteras.

Allmän beskrivning

Algoritmen måste returnera minst 6 siffror för att säkerställa tillräcklig lösenordssäkerhet. Beroende på nivån på säkerhetskraven kan du använda högre siffror för HOTP för att göra lösenordet mer motståndskraftigt mot attacker. Funktionen av algoritmen kan beskrivas med följande formel [1] :

H O T P ( K , C ) = T r u n c a t e ( H M A C − S H A − ett ( K , C ) ) {\displaystyle HOTP(K,C)=Truncate(HMAC-SHA-1(K,C))}

HOTP(K,C)=Truncate(HMAC-SHA-1(K,C))

Processen för algoritmen kan delas in i följande steg:

En sträng på 20 byte skapas med hjälp av hash-funktionen initierad med parametrarna och : ${\textstyle HS}$ $HMAC-SHA-1$ $K$ $C$ $HS=HMAC-SHA-1(K,C)$
4 byte väljs på ett visst sätt från : $HS$ $S_{bits}=Truncate(HS)$
1. De sista fyra bitarna av den sista byten av resultatet omvandlas till ett tal $S_{bitar}[19]$ $offset\in (0,15)$
2. Sekvens av byte konverteras till en variabel $HS[offset]..HS[offset+3]$ $P$
3. $Truncate(HS)$ returnerar de senaste 31 bitarna Anledningen till att den mest signifikanta biten ignoreras beror på olika implementeringar av heltalsberäkningar i olika processorer [1] $P$ $P$
Resultatet av arbetet omvandlas till en talföljd : $Truncate()$ $D$ ${\displaystyle HOTP=toNumber(Truncate(HS))\,\,mod\,10^{D))$

Ett exempel på beräkning av ett sexsiffrigt HOTP-värde

Det här exemplet [1] visar funktionen hos en algoritm som genererar ett sexsiffrigt numeriskt lösenord från en 160-bitars autentiseringskod. Låt vid ett visst steg värdet på strängen från $hmac\_result[0]..hmac\_result[19]$ $HMAC-SHA-1$

int offset = hmac_result[19] & 0xf; int bin_code = (hmac_result[offset] & 0x7f) << 24 | (hmac_result[offset+1] & 0xff) << 16 | (hmac_result[offset+2] & 0xff) << 8 | (hmac_result[offset+3] & 0xff);

Då kommer resultatet att se ut så här:

Byte index	0	ett	2	3	fyra	5	6	7	åtta	9	tio	elva	12	13	fjorton	femton	16	17	arton	19
Menande	1f	86	98	69	0e	02	ca	16	61	85	femtio	ef	7f	19	da	8e	94	5b	55	5a

Den sista byten är 0x5a
Skiftvärdet som erhålls från de lägre 4 bitarna är 0xa, detta ger oss talet 10
Värdet på 4 på varandra följande byte från den 10:e positionen är 0x50ef7f19, som konverteras till DBC1 [7] binär kod (dynamisk binär kod)
MSB som tas emot från DBC1 är 0x50. Därför DBC2 [8] = DBC1 = 0x50ef7f19
Vidare behandlas binära värden som ett positivt tal, skrivet i ordning från högt till lågt, med den första byten maskerad av värdet 0x7f.
För att få ett sexsiffrigt nummer för HOTP måste du ta numret som erhölls i föregående steg modulo 10 6 − $HOTP=DBC2{\pmod {10^{6))}=872921$

Kontrollerar engångslösenord

Kontrollerar räknarvärden

När ett nytt engångslösenord skapas av generatorn (klienten), ökas värdet på klientens räknare med ett. I framtiden matas värdet på räknaren till ingången för hashfunktionen tillsammans med nyckeln . Därefter skickas den till autentiseringsservern, där den jämförs med det värde som beräknats av servern. Om värdena matchar, med hänsyn till avvikelsen inte mer än desynkroniseringsparametern , ökar servern värdet på sin räknare med en. Om data inte stämmer överens, startar servern omsynkroniseringen och upprepar den i händelse av fel tills gränsen för misslyckade autentiseringsförsök nås . Därefter blockerar servern användarkontot [1] . $C$ $HMAC-SHA-1$ $K$ $C$ $s$ $T$

Osynkroniserad mellan klient och server

Som tidigare nämnts uppdaterar klienten värdet på händelseräknaren varje gång engångslösenordet genereras. I sin tur ökas värdet på räknaren på servern först efter framgångsrik autentisering. Baserat på dessa uttalanden är det möjligt att beskriva anledningarna till att implementeringen av omsynkroniseringsprocessen är nödvändig:

Autentisering misslyckades. Klienten uppdaterade värdet på räknaren efter att ha skapat lösenordet, men värdet på servern ändrades inte
Kommunikationsproblem. Klienten ökade räknarvärdet efter att ha skickat lösenordet, men lösenordet nådde inte servern

Detta leder till behovet av att använda parametern out of sync , som kommer att vara ansvarig för storleken på fönstret inom vilket klient- och serverräknarvärdena kommer att betraktas som synkroniserade. $s$

Counter omsynkronisering

Omsynkronisering utförs uteslutande av servern. Det består i att beräkna ett nytt värde för dess händelseräknare så att dess värde matchar värdet som mottas från klienten inom skillnaden mellan värdena högst . Om detta villkor är uppfyllt uppdaterar servern värdet på sin egen räknare [1] . $s$

Annars räknar servern om räknarens tillstånd. Under denna process kan servern begära flera OTP-värden flera gånger. Detta görs för att öka säkerhetsnivån, eftersom lösenordsjämförelser i detta fall utförs för två eller tre par. Om gränsen för återförsök nås kommer servern att låsa användarkontot. Parametern definierar också fönstret inom vilket servern ökar räknaren under omsynkroniseringsprocessen. Denna gränsparameter tjänar till: $s$

Begränsningar för chansen att gissa rätt lösenord
Förhindra att värdeberäkning går i loop inom en enda kontroll

Säkerhet

Algoritmens tillförlitlighet

Säkerhetssystem byggda med HOTP har en hög grad av tillförlitlighet. De är för det mesta resistenta mot utbredda kryptografiska attacker, till exempel:

Attack av typen " man i mitten " ( Man-in-the-middle ). En angripare kan inte förfalska det vidarebefordrade meddelandet, eftersom lösenordet ändras ganska ofta. Många metoder för kryptografisk analys blir till liten användning i detta fall. I vissa implementeringar ändras räknaren som används för att generera lösenordet efter varje överföring. Om meddelandena krypteras med ett tillräckligt starkt chiffer, gör HOTP det nästan omöjligt att gissa lösenordet. [3]

Replay attack . Här beror framgången på konfigurationen av själva systemet. I det fall, till exempel, när en autentiseringsserver används för att ge inloggningsrättigheter till en användare, har angriparen ett antal problem. Servern ökar räknaren med en efter varje meddelandemottagning. Därför kommer den elementära sändningen av ett duplicerat meddelande inte att klara kontrollen - meddelandet skapades med ett värde och kontrollen utförs av ett annat. [3]

Om nyckeln består av godtyckliga siffror, beräknas sannolikheten för framgång för en brute-force-attack i närvaro av autentiseringsförsök före blockering med formeln . Till exempel, med 5 tillåtna försök att ange ett sexsiffrigt lösenord och en giltig fönsterstorlek är chansen att lyckas med en attack 0,015 %. $D$ $T$ ${\displaystyle p=sT/10^{D))$ $s=30$

Ofta lyckas en angripare stjäla ett hashat användarlösenord från autentiseringsservern, som används för autentisering. Algoritmen för att skapa lösenord använder dock också en händelseräknare. Eftersom startvärdet på räknaren väljs av servern är det vanligtvis slumpmässigt, vilket gör det svårt att hacka kommunikationskanalen även om angriparen har en delad hemlighet. [3]

Sätt att öka skyddet

Dessa ändringar är inte obligatoriska eller tillägg som rekommenderas av algoritmens författare. Men för att öka säkerhetsnivån för din egen implementering kan du använda följande alternativ [1] :

Öka längden på HOTP - värdet .

Att extrahera varje ny karaktär från resultatet minskar drastiskt chanserna för en lyckad attack. Tack vare detta kan du göra processen att arbeta med lösenord mer bekväm. Öka till exempel antalet inmatningsförsök eller utöka intervallet där server- och klienträknevärden jämförs. $HMAC-SHA-1$

Alfanumeriska värden .

Meningen med denna idé är att inte bara använda siffror för lösenordet, utan också tecknen A-Ö. Snarare talar vi om en uppsättning av 32 tecken från en alfanumerisk uppsättning. Du kan omedelbart se hur nivån på lösenordssäkerheten har växt, för nu är sannolikheten för framgång för en brute-force-sökning efter lösenord som består av 6 tecken. $sT/32^{6}$

Räknarbaserad omsynkronisering .

Om villkoren tillåter klienten att skicka inte bara HOTP-värdet utan även andra data, kan du göra omsynkroniseringsprocessen mycket bekvämare och säkrare om klienten tillsammans med HOTP-värdet skickar statusen för händelseräknaren till server. I det här fallet kommer värdet på klientens HOTP att fungera som en skeninsats för räknartillståndet.

Genom att kontrollera räknevärdena för äkthet och efterlevnad på detta sätt kan du vägra att använda desynkroniseringsparametern, vilket också kommer att öka skyddsnivån för algoritmen, eftersom sannolikheten för framgång för en brute-force i det uppdaterade systemet attacken kommer att vara endast . $T/10^{6}$

Applikation

OATH - fusionen , efter att ha standardiserat HOTP, gav ingen vägledning om implementeringen av algoritmen. Tvärtom tillåter utvecklarnas frihet att hitta nya lösningar, sträva efter att möta kundens behov och göra ett innovativt bidrag till OTP-teknik. [2] [3] [9]

En vanlig implementering av HOTP i Java finns i paketet org.jboss.security.otp, som ingår i standardbiblioteken för Apache Jboss freeware webbserver.

En annan implementering i Java-språket tillhandahålls direkt av OATH-facket i paketet org.openauthentication.otp.

Du kan också nämna implementeringen - OATH Toolkit-projektet, vars liboath-bibliotek låter dig skapa lösenord i HOTP- och TOTP-läge. [tio]

Ett stort antal lågintelligenta enheter är specifikt utformade för att generera lösenord eller överföra data med hjälp av HOTP och TOTP (Feitian, SecuTech, SmartDisplayer, Vasco, Yubico, Protectimus [11] ). Algoritmen används även i hemnätverk för att styra kringutrustning med hjälp av en fjärrkontroll eller mobiltelefon. [3]

Krav för implementering av algoritmen

Tvåfaktorsautentisering måste stödjas. I det här fallet antas det att den första faktorn är engångslösenordsgeneratorn, och den andra är någon ytterligare hemlighet som läggs till engångslösenordet [3]
Servern måste skyddas från brute-force-attacker, det vill säga att användarkontot måste blockeras efter ett visst antal misslyckade autentiseringsförsök [1]
Du måste använda en säker kanal

Dessutom

HOTP är baserad på SHA-1 , som inte längre anses vara tillräckligt kollisionsbeständig. Men HOTP-algoritmen använder bara det faktum att antalet beräknade på grundval av det är slumpmässigt, så närvaron av kollisioner påverkar inte direkt dess funktion. [2] [9]

Envägsautentisering innebär att klienten försöker upprätta en anslutning på begäran. Servern skickar sedan begäran tillbaka till klienten och validerar dess svar för äkthet. Modifiering av OCRA- algoritmen tillåter också användaren att autentisera servern. [fyra]

Se även

Tidsbaserad engångslösenordsalgoritm

Anteckningar

↑ 1 2 3 4 5 6 7 8 9 Hoornaert, Frank, Naccache, David, Bellare, Mihir, Ranen, Ohad. HOTP : En HMAC-baserad engångslösenordsalgoritm . tools.ietf.org. Hämtad 26 mars 2017. Arkiverad från originalet 6 april 2019.
↑ 1 2 3 4 "Algorithm agility and OATH" av Burt Kaliski, RSA Laboratories. 19 maj 2005.
↑ 1 2 3 4 5 6 7 "HOTP-baserat användarautentiseringsschema i hemnätverk" av Binod Vaidya, Jong Hyuk Park och Joel JPC Rodrigues. 2009
↑ 1 2 3 4 "ED: igår, idag och imorgon" av Nathan Willis, 15 december 2010.
↑ Nathan Schmidt. Nathan Schmidt - Uppdelning: HMAC-baserade engångslösenord (engelska) (nedlänk) . nathschmidt.net. Hämtad 27 mars 2017. Arkiverad från originalet 3 april 2016.
↑ Engångslösenord – HOTP och TOTP , aldaris blogg ( 28 februari 2014). Arkiverad från originalet den 11 juni 2018. Hämtad 22 mars 2017.
↑ M. Bellare, R. Canetti och H. Krawczyk. Keyed Hash-funktioner och meddelandeautentisering // Proceedings of Crypto'96, LNCS Vol. 1109, sid. 1-15..
↑ Krawczyk, H., Bellare, M. och R. Canetti. HMAC: Keyed-Hashing för meddelandeautentisering // RFC 2104 . - 1997. - Februari.
↑ 1 2 "Attacker på SHA-1" av Initiative for Open AuTHentication, 2 mars 2005.
↑ "Introducing the OATH Toolkit" av Simon Josefsson, 2011.
↑ Protectimus . Hämtad 21 augusti 2015. Arkiverad från originalet 20 april 2018. (obestämd)

Länkar

RFC 4226
HOTP-baserat användarautentiseringsschema i hemnätverk