Autentizace

Po ukonˇcen´ı TLS handshaku zaˇc´ın´a vlastn´ı komunikace pomoc´ı protokolu Verse a klient 30 sekund na to, aby poslal zpr´avu obsahuj´ıc´ı pˇr´ıkaz UserAu-thRequest. Jeho struktura je pops´ana na obr´azku 4.6. Pokud server tento pˇr´ıkaz do 30 sekund neobdrˇz´ı, server by mˇel spojen´ı s klientem automaticky ukonˇcit.

0 1 2

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3

+---+---+---+---...---+---+---| Op Code=7 | Length | String_Length | User_Name | Auth_Method | ...

+---+---+---+---...---+---+---Obr´azek 4.6: Struktura pˇr´ıkazu UserAauthRequest

Op Code tohoto pˇr´ıkazu je 7. Za d´elkou pˇr´ıkazu n´asleduje d´elka ˇretˇezce v nˇemˇz je uloˇzeno uˇzivatelsk´e jm´eno. Za uˇzivatelsk´ym jm´enem n´asleduje identifik´ator autentizaˇcn´ı metody. Cel´y pˇr´ıkaz je ukonˇcen vlastn´ımi auten-tizaˇcn´ımi daty. Seznam aktu´alnˇe navrhovan´ych autentizaˇcn´ıch metod je uve-den v tabulce 4.1. Cel´y autentizaˇcn´ı mechanismus byl navrˇzen flexibilnˇe, aby bylo moˇzn´e v budoucnu pˇridat dalˇs´ı autentizaˇcn´ı metody.

Pˇrestoˇze nen´ı doporuˇceno, aby server podporoval ovˇeˇrov´an´ı uˇzivatel˚u po-moc´ı metody NONE, klient by mˇel poslat prvn´ı pˇr´ıkaz UserAuthRequest pr´avˇe s touto metodou. Server mus´ı odpovˇedˇet na prvn´ı pˇr´ıkaz UserAu-thRequest obsahuj´ıc´ı nepodporovanou metodu pˇr´ıkazem UserAuthFailure se seznamem autentizaˇcn´ıch metod, kter´e server podporuje. Tento seznam mus´ı

RESERVED=0 Tato metoda by nemˇela b´yt nikdy pouˇzita NONE=1 Nen´ı doporuˇceno podporovat tuto metodu PASSWORD=3 Tato metoda je vyˇzadov´ana

HOSTBASED=4 Tato metoda je voliteln´a Tabulka 4.1: Metody autentizace

vˇzdy obsahovat metodu PASSWORD a jak server tak klient mus´ı tuto me-todu podporovat. Klient by si mˇel ze seznamu obdrˇzen´ych metod jednu vy-brat a pouˇz´ıt ji k odesl´an´ı platn´e kombinace uˇzivatelsk´eho jm´ena a auten-tizaˇcn´ıch dat. Pˇr´ıkaz UserAuthFailure je uveden na obr´azku 4.7.

0 1 1 2 2

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 ...

+---+---+---+---+---+

| Op Code=8 | Length | Auth_Method_1 | ... | Auth_Method_N | +---+---+---+---+---+

Obr´azek 4.7: Struktura pˇr´ıkazu UserAauthFailure se seznamem podporo-van´ych metod

Kdyˇz klient poˇsle neplatnou kombinaci uˇzivatelsk´eho jm´ena a auten-tizaˇcn´ıch dat, tak z´aleˇz´ı na tom, kolik ne´uspˇeˇsn´ych pˇr´ıkaz˚u UserAuthRequest jiˇz klient poslal. Pokud tento poˇcet pˇrekroˇcil stanoven´y limit, tak by mˇel ser-ver odpovˇedˇet pˇr´ıkazem UserAuthFailure uveden´ym na obr´azku 4.8. V opaˇ c-n´em pˇr´ıpadˇe by mˇel server odpovˇedˇet pˇr´ıkazem z obr´azku 4.7 a umoˇznit klientovi dalˇs´ı pˇrihlaˇsovac´ı pokus. Zpr´avu s t´ımto pˇr´ıkazem by server nemˇel pos´ılat ihned, ale odpovˇed’ by mˇel pozdrˇzet. ˇCasov´y rozestup by mˇel s kaˇzd´ym neplatn´ym pokusem nar˚ustat, aby se co nejv´ıce zkomplikovalo h´ad´an´ı kombi-nac´ı uˇzivatelsk´ych jmen a autentizaˇcn´ıch dat hrubou silou. D´ale server nesm´ı bˇehem jednoho spojen´ı mˇenit seznam navrhovan´ych autentizaˇcn´ıch metod ani jejich poˇrad´ı.

Server by mˇel po odesl´an´ı ukonˇcuj´ıc´ıho pˇr´ıkazu UserAuthFailure ukonˇcit i TLS a TCP spojen´ı. Server by mˇel spojen´ı automaticky ukonˇcit i v tom pˇr´ıpadˇe, ˇze neobdrˇz´ı dalˇs´ı pˇr´ıkaz UserAuthRequest do 30 sekund po odesl´an´ı pˇr´ıkazu UserAuthFailure s navrhovan´ymi metodami.

0 1 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+

| Op Code=8 | Length=2 | +---+---+

Obr´azek 4.8: Struktura pˇr´ıkazu UserAauthFailure ukonˇcuj´ıc´ı spojen´ı

Pokud server obdrˇz´ı od klienta prvn´ı pˇr´ıkaz UserAuthRequest obsahuj´ıc´ı uˇzivatelsk´e jm´eno, jeˇz nen´ı obsaˇzeno v jeho datab´azi uˇzivatel˚u, tak by server nemˇel odpov´ıdat pˇr´ıkazem z obr´azku 4.8, protoˇze ´utoˇcn´ık zjiˇst’uj´ıc´ı platn´e kombinace uˇzivatelsk´ych jmen a autentizaˇcn´ıch dat by mˇel ulehˇcenou pr´aci.

Takov´y pˇr´ıstup by umoˇzˇnoval pˇr´ıpadn´emu ´utoˇcn´ıkovi nejprve zjistit platn´a uˇzivatelsk´a jm´ena a t´ım v´yraznˇe ulehˇcil zjiˇstˇen´ı platn´e kombinace uˇzivatelsk´ e-ho jm´ena a autentizaˇcn´ıch dat.

Zat´ım jedinou navrhovanou autentizaˇcn´ı metodou, kter´a umoˇzˇnuje ovˇeˇrit uˇzivatele, je metoda PASSWORD. V t´eto metodˇe se uˇzivatel prokazuje hes-lem, kter´e by mˇel zn´at pouze on s´am. Na serveru by toto heslo mˇelo b´yt uloˇzeno v nˇejak´e zaˇsifrovan´e podobˇe. Struktura pˇr´ıkazu UserAuthRequest ob-sahuj´ıc´ı uˇzivatelsk´e jm´eno a heslo je uvedena na obr´azku 4.9.

0 1 1 2 2

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 ...

+---+---+---+---...---+

| Op Code=7 | Length | String_Length | User_Name |

+---+---+---+---...---+

...

+---+---+---...---+

| Meth=PASSWORD | String_Length | Password |

+---+---+---...---+

Obr´azek 4.9: Struktura pˇr´ıkazu UserAauthRequest obsahuj´ıc´ı heslo Kdyˇz se uˇzivatelsk´e jm´eno a autentizaˇcn´ı data (heslo) shoduj´ı s datab´az´ı na stranˇe serveru, server odeˇsle klientu zpr´avu s pˇr´ıkazem UserAuthSuccess jehoˇz struktura je uvedena na obr´azku 4.10.

0 1 2 3

Obr´azek 4.10: Struktura pˇr´ıkazu UserAauthSuccess

Tento pˇr´ıkaz obsahuje jedineˇcn´y identifik´ator uˇzivatele: User ID a ava-tara Avatar ID. User ID se pouˇz´ıv´a napˇr´ıklad pro nastaven´ı vlastnictv´ı a pˇr´ıstupov´ych pr´av ke sd´ılen´ym dat˚um. Po ´uspˇeˇsn´em ovˇeˇren´ı uˇzivatele server vytvoˇr´ı speci´aln´ı uzel, kter´y reprezentuje avatara dan´eho Verse klienta. Iden-tifik´ator tohoto uzlu je roven Avatar ID z pˇr´ıkazu UserAuthSuccess. Uzly reprezentuj´ıc´ı avatary budou detailnˇe pops´any v kapitole 5.

Pˇr´ıklad v´ymˇeny zpr´av a pˇr´ıkaz˚u bˇehem ´uspˇeˇsn´e a ne´uspˇeˇsn´e autentizace je uveden na obr´azc´ıch 4.11 a 4.12.

[client]:A [server]:B

| USER_AUTH_FAILURE count=1 auth_method=PASSWORD | | +----+<---+<---+

| | |

| | USER_AUTH_REQUEST user_name=joe |

+--->+---auth_method=PASSWORD password=QX9#amD1--->+----+

| | |

| USER_AUTH_SUCCESS user_id=3 avatar_id=10 | | +<---+<---+

| |

. .

Obr´azek 4.11: Pˇr´ıklad ´uspˇeˇsn´e autentizace

[client]:A [server]:B

| USER_AUTH_FAILURE count=1 auth_method=PASSWORD | | +----+<---+<---+

Obr´azek 4.12: Pˇr´ıklad ne´uspˇeˇsn´e autentizace Verifikace autentizace

Autentizaˇcn´ı ˇc´ast handshaku bylo nutn´e verifikovat, protoˇze je relativnˇe komplikovan´a a nezbytn´a pro n´aslednou komunikaci mezi klientem a serve-rem. Nejprve byly vytvoˇreny stavov´e modely autentizace pro klienta a server, kter´e jsou uvedeny na obr´azc´ıch 4.13, 4.14.

Z tˇechto dvou stavov´ych model˚u byl vytvoˇren verifikaˇcn´ı program v pro-gramovac´ım jazyku Promela, kter´y je uveden v pˇr´ıloze na stranˇe 124. Pˇri tvorbˇe stavov´ych model˚u byl p˚uvodn´ı form´at pˇred´avan´ych zpr´av a pˇr´ıkaz˚u velmi zjednoduˇsen. Proces reprezentuj´ıc´ı klienta m˚uˇze pos´ılat skrz synchronn´ı kan´al pouze zjednoduˇsen´y pˇr´ıkaz UserAuthRequest. Poloˇzky username a data mohou nab´yvat pouze hodnoty platn´a nebo neplatn´a data. Toto m˚uˇze p˚usobit

Obr´azek 4.13: Stavov´y model autentizace na stranˇe klienta

jako pˇr´ıliˇs velk´e zjednoduˇsen´ı, ale je potˇreba si uvˇedomit, ˇze ´ukolem tohoto programu je verifikovat pr˚ubˇeh jednoho konkr´etn´ıho spojen´ı, kdy autentizace uˇzivatele na jednom spojen´ı neovlivn´ı autentizaci na kter´emkoliv dalˇs´ım spo-jen´ı. D´ıky tomu m˚uˇze b´yt zavedeno zjednoduˇsen´ı, kdy uˇzivatel m˚uˇze zadat bud’ platn´e nebo neplatn´e uˇzivatelsk´e jm´eno a platn´a nebo neplatn´a auten-tizaˇcn´ı data.

Server m˚uˇze skrz druh´y synchronn´ı kan´al pos´ılat zjednoduˇsen´e pˇr´ıkazy UserAuthFailure a UserAuthSuccess:

chan q1 = [ 0 ] o f { bit , byte , b i t } ; /∗ user name , a u t h t y p e , a u t h d a t a ∗/

chan q2 = [ 0 ] o f { bit , byte } ; /∗ cmd type , a u t h m e t h ∗/

C´ılem verifikace t´eto ˇc´asti protokolu bylo ovˇeˇrit, ˇze n´avrh neobsahuje ˇ

z´adn´e deadlocky, nevyv´ıjej´ıc´ı se cykly a ˇze oba procesy neskonˇc´ı v neko-rektn´ıch stavech. Na autentizaci nebyla kladena ˇz´adn´a dalˇs´ı krit´eria, kter´a by ˇslo vyj´adˇrit pomoc´ı LTL logiky. Verifikace, jej´ıˇz v´ysledky lze nal´ezt v pˇr´ıloze na stranˇe 129 prok´azala, ˇze tato ˇc´ast protokolu byla navrˇzena korektnˇe a neobsahuje ˇz´adn´e chyby.

Bezpeˇcnostn´ı rizika autentizace

Navrˇzen´y autentizaˇcn´ı mechanismus m˚uˇze b´yt zraniteln´y v˚uˇci DoS a DDoS ´utoku, protoˇze server ˇcek´a 30 sekund od ukonˇcen´ı TLS handshaku na prvn´ı pˇr´ıkaz UserAuthRequest a stejnou dobu ˇcek´a od odesl´an´ı pˇr´ıkazu UserAuthFailure obsahuj´ıc´ı seznam podporovan´ych metod na dalˇs´ı pˇr´ıkaz UserAuthRequest. Pˇr´ıpadn´y ´utoˇcn´ık se m˚uˇze pokusit otevˇr´ıt velk´e mnoˇzstv´ı spojen´ı a snaˇzit se vyˇcerpat syst´emov´e prostˇredky serveru ˇci dos´ahnout ma-xim´aln´ı povolen´e mnoˇzstv´ı spojen´ı na serveru.

Pˇri n´avrhu protokolu se poˇc´ıtalo, ˇze tento probl´em bude pˇrenech´an r˚uzn´ym

LISTEN

RESPOND user_auth

END failure

END authenticated timeout

auth_req:user,none

attempt++;

attemtp<MAX

auth_req,user=valid,data!=valid auth_req:user!=valid

auth_req:user=valid,data=valid

attempt>=MAX /timeout

Obr´azek 4.14: Stavov´y model autentizace na serveru

packet filtr˚um jako je napˇr´ıklad iptables [4], kter´e umoˇzˇnuj´ı efektivnˇe filtro-vat poˇcet pokus˚u o nov´e spojen´ı podle r˚uzn´ych krit´eri´ı. Nˇekter´e packet filtry (vˇcetnˇe iptables) nav´ıc umoˇzˇnuj´ı spolupracovat se serverov´ymi aplikacemi a prov´adˇet dalˇs´ı penalizaci nov´ych spojen´ı poch´azej´ıc´ıch z IP adresy ´utoˇcn´ıka.