Salut,

Folosesc TCP, am o aplicatie gen client/server. Payload-ul e mereu in binar, mi se pare mai usor de facut parsing. Intreb despre hashing la packete. Pe moment, am asa:

* Header (packet length + informatii gen "channel" etc. --chestii application-level)
* Hash pt payload
* Payload

Folosesc SHA1 pt hash, dar revizuiam codul de retea ca sa adaug niste feature-uri, si mi-am zis sa vad ce e acest "HMAC" de care vag am auzit.

Mi-a venit idee sa fac asa:

* HMAC hash pt tot restul pachetului
* Header (la fel ca mai sus)
* Payload

Cum e normal, sa includ headerul cand hashuiesc, sau sa hashuiesc numai payloadul? Eu as include headerul in hash, dar ce stiu eu de securitate...

In alta ordine de idei, stii cineva vre-o sursa decenta (articol?) care descrie cum sa te porti cu parolele userului? Momentam le trimit plaintext... mi-e lene, si oricum sistemul nu e in productie.
Parca am citit pe undeva ca trebuie sa trimit ceva gen "hash(salt + password)".

Presupun ca daca cineva se uita in codul programului sa vada care e cheia pt HMAC, HMAC-ul ala devine in principiu un SHA/MD5 obisnuit, deci e mai mult asa pt buzzword in programul meu client/server. (nu e joc din pacate )

Cu parolele e simplu:

1. serverul trimite un cookie generat aleator (un string)
2. clientul adauga parola la sfirsitul cookie-ului, calculeaza un hash pentru ce rezulta (de exemplu SHA1) si-l trimite spre server
3. serverul, care stie parola plaintext a utilizatorului, face aceeasi operatie si compara hash-ul rezultat cu hash-ul trimis de client

In felul asta parola nu se plimba niciodata pe fir in clar si chiar daca cineva asculta toata conversatia, nu poate impersona utilizatorul, pentru ca nu poate extrage parola stiind doar hash-ul si cookie-ul. E important ca cookie-ul sa fie aleatoriu, pentru ca daca utilizezi unul fix (sau nu utilizezi deloc), hash-ul pe care trebuie sa-l trimita clientul va fi tot timpul acelasi, deci cineva trebuie sa asculte o singura data ca sa afle cuvintul magic care deschide usa (e echivalent cu a trimite parola in plaintext).

Referitor la HMAC, e mai sigur sa incluzi si header-ul in hash. Nu stiu ce informatii se gasesc acolo, dar daca le folosesti inainte de a autentifica payload-ul, poti introduce vulnerabilitati. Daca si header-ul e in hash, esti sigur ca nu s-a trezit nimeni neautorizat sa-ti umble la el. In teorie exista si un dezavantaj: probabil header-ul ala contine cimpuri usor de prezis, cum ar fi sequence numbers, identificatori de operatii etc. Asta ar inlesni intr-o oarecare masura atacurile de tip "known plaintext", dar pentru orice functie criptografica din mileniul asta, riscul este irelevant. In plus, pentru ca cineva sa injecteze pachete neautentificate in conversatia ta cu un client ar trebui sa poata face TCP spoofing, ceea ce e destul de complicat in general.

Cheia (salt-ul) pentru HMAC ar trebui negociata intr-un mod sigur, de exemplu asa cum se negociaza cheile de sesiune in SSL. Pe scurt, folosesti o schema de criptare cu cheie publica. Serverul trimite cheia lui publica, clientul genereaza salt-ul pentru HMAC, il cripteaza cu cheia publica a serverului si il trimite. Serverul e singurul care poate decripta mesajul cu salt-ul, pentru ca e singurul care are cheia privata. E mai sigur asa decit sa folosesti un salt fix pentru HMAC, deoarece imi imaginez ca este posibil ca un atacator sa puna mina pe un executabil al clientului, deci daca folosesti un salt hardcodat, se poate extrage. Pentru a ajunge la cheia privata a serverului in schimb, atacatorul ar trebui sa compromita calculatorul pe care ruleaza serverul, iar daca face asta oricum ai probleme mai mari decit ca-ti fura cheia aia. In orice caz, securitatea unei scheme de criptare depinde de securitatea cheii folosite. Chiar daca algoritmul e infailibil, daca n-ai grija de cheie, e degeaba.

Totusi, daca te preocupa chestiile astea, de ce nu folosesti ceva gen OpenSSL, care-ti ofera autentificare si criptare intr-un mod care se stie ca merge? E foarte usor sa introduci probleme de securitate daca te apuci sa scrii tu de la 0 chestiile astea si nu esti expert, si e si mai greu sa-ti dai seama cind ai gresit ceva.

/scrap

Bleh, prea complicat! Folosesc cookie hash pt parola, e de ajuns pe moment... Encryption mai incolo. (sunt putin confuz despre toate metodele de securitate)

Multumesc de sfat!

asta e si ideea, sa fie cat mai complicat

Macar scapi de script kiddies sub 5 anisori...

Daca tot faci o treaba fa-o ca lumea.. Hash de parola nu e suficient decat daca vrei sa ascunzi ce carti nu ai adus la timp la biblioteca...

Las plaintext pe moment. Nu e nevoie de securitate cand nu e deployed nicaieri inca. Defapt parola mea e 'x', sa nu pierd timp cand ma loghez de 100 de ori pe zi Evident, nu pot sa vand chestia asta pana nu rezolv securitatea. (rezolv? lol, mai degraba sa o fac )

Ma gandesc la ceva de genul: clientul stie public key-ul serverului (si IPul desigur), si serverul cunoaste public key-urile de la toti clientii autorizati. (diferit pt fiecare calculator/instalare). Fiecare "pachet" (pachet 'logic', nu tehnic) e encriptat cu cheia publica e 'celuilalt', si semnat cu propria cheie privata.

Din cate inteleg, asta ar trebui sa fie un pic secur. Il "spargi" daca ai acces la fisierele calculatorului clientului, SI ii stii parola. Iar daca ai acces, pui un keylogger si aflii si parola. Dar mai mult de atat nu imi imaginez cum sa-l fac mai secur. Daca ai doar o copie "blank" a softului client, user+parola si IPul serverului, dar nu ai cele 3 chei (S PbK, C PbK, C PvK) atunci nu te poti conecta. Si daca stii S PbK, si generezi tu un set de client keys, tot nu merge pt ca numai anumite chei sunt autorizate per server.

O sa pun si restrictii optionale de IP (+per user), dar default nu o sa fie utilizate, pt ca eu le consider contra-productive, insa optiunea o sa fie acolo...

Nu vreu sa folosesc ceva gen OpenSSL, am mai mult control, si -in cele din urma- inteleg securitatea aplicatiei mai bine asa...

E un pic mai mult hassle cand instalezi pe un calculator nou, dar nimic groaznic, ca dupa ce instalezi, update-urile si le face programul singur, intern, fara instalator sau alte balarii intermediare. (cum face WoW, daca nu ai ultima versiune, o downloadeaza si o instaleaza pt tine, altfel nu ai voie sa te loghezi; numai ca intr-o versiune viitoare o sa aiba background downloading care chiar merge, fata de WoW)

In principiu, instalezi clientul "blank" pe calculator, te loghezi ca admin/root de altundeva, generezi si adaugi o pereche de chei noi, si le pui pe calculatorul nou, impreuna cu IPul serverului.

O nota tehnica importanta e ca si clientul si serverul ruleaza direct din codul sursa, nu e compilat binar. (btw nu exista copy/license protection, si nici nu o sa pun, pt ca modelul de business e diferit)

Ah, ma zgarie pe creier cand ma gandesc la overhead-ul ala in pachete... dar asta e. Vreau sa fie cat mai putin overhead, de aia am stat cateva zile ca sa fac chestii gen: compresez int-ul care tine lungimi, de ex pt stringuri si liste, similar cu de ex. UTF8/multibyte. Eu am:
0 - 2^7 = 1b
0 - 2^14 = 2b
0 - 2^30 = 4b
Majoritatea stringurilor o sa fie sub 127 caractere, si cand schimbi 1000 stringuri pe secunda, te scapa de 3KB/s numai in overhead.

E mai mult o obsesie/pasiune personala, decat ceva practic, sincer.

Anyway, am VRUT sa fac securitatea asa... dar las deocamdata pana gasesc o librarie de encriptie decenta pt Python. Ceva pt RCA/AES/ce-se-foloseste. Daca nu gasesc nimic... nasol, trebuie sa gasesc atunci o librarie C, si sa-i scriu wrapper.

/edit: se pare ca OpenSSL, libraria in C, imi da tot ce am nevoie, dar nu am gasit inca un wrapper care nu e retardat.