Tehnica de generare a cheilor API

Proiectez o API web care trebuie să acorde acces la diverse aplicații client printr-o cheie API trimisă ca antet http. Știu, nu chiar cum ar trebui făcut, dar nu am control asupra acestei părți.

Designul meu actual pentru cheia api: au 16 octeți pentru id-ul aplicației (un ghid) în baza de date + 16 octeți generați aleatoriu (keybytes). Datorită politicii companiei, mi s-a cerut să nu stochez cheile API în db, așa că stochez un hash sha256 de (clientid + keybytes + salt) și sarea în baza de date.

Ori de câte ori vine o solicitare, împart cheia API în (id, keybytes), caut clientul în baza de date după id, apoi calculez sha256 (id + keybytes + salt-from-db) și verific dacă se potrivește cu hash-ul stocat în baza de date. . Cerințele echipei de securitate corporativă au fost să nu stocheze cheia API în db, ci să stocheze un hash al acesteia (la fel ca o parolă de utilizator). De asemenea, am luat în considerare PBKDF2 (folosesc .net 5), dar s-ar putea să fie prea lent pentru a o face la fiecare solicitare primită (trebuie să ruleze pentru fiecare solicitare, deoarece nu pot schimba aplicațiile client pentru a se autentifica printr-un apel lent, apoi trimite un simbol, ar trebui să trimită cheia la fiecare cerere).

Practic, aceasta este la fel ca și stocarea sha256 (parolă+sare) în DB pentru un utilizator, așa că nu sunt sigur dacă este „destul de bun” (având în vedere că parola este aleatorie de 16 octeți și ID-ul utilizatorului este alți 16 octeți aleatoriu - ghidul aplicației și db-ul este teoretic nu este accesibil).

O alternativă pe care o am pentru cheile API este să utilizez AES-GCM: generați nonce aleatoriu (iv) și criptați id-ul aplicației (ghid) cu o cheie secretă (stocată numai în setările webapi, nu db) și folosiți octeții (nonce , encryptedid, tag) ca cheie API. Acest lucru ar însemna nicio căutare a bazei de date în cazul cheilor api greșite. Cu toate acestea, nu sunt sigur cât de sigură este această soluție (la urma urmei, criptez doar un singur bloc de date de 128 de biți - ghidul appid - cu o cheie, printre toți apiclienții).

Care este „acceptabil” (dacă sunt ambele, o voi lua pe prima, deoarece este deja implementată) în cazul unei „încălcări de securitate (baza de date este furată de exemplu)?

Știu, dacă ajung la db, cheia api este cea mai mică dintre preocupările mele, dar tot aș vrea să aud o părere....

De fiecare dată când vine o solicitare, împart cheia API în (id, keybytes), caut clientul în baza de date după id, apoi calculez sha256 (id + keybytes + salt-from-db) și verific dacă se potrivește cu hash-ul stocat în baza de date . Cerințele echipei de securitate corporativă au fost să nu stocheze cheia API în db, ci să stocheze un hash al acesteia (la fel ca o parolă de utilizator). De asemenea, am luat în considerare PBKDF2 (folosesc .net 5), dar s-ar putea să fie prea lent pentru a o face la fiecare solicitare primită (trebuie să ruleze pentru fiecare solicitare, deoarece nu pot schimba aplicațiile client pentru a se autentifica printr-un apel lent, apoi trimite un simbol, ar trebui să trimită cheia la fiecare cerere).

Dacă cheia rămâne secretă și constă din 16 octeți complet randomizati, atunci nu este nevoie de PBKDF2; un hash securizat este deja un singur mod și nu este posibil să forțați o cheie de 128 de biți. Ceilalți 16 octeți aleatoriu din UID adaugă cireașă pe tort, deoarece evită problema zilei de naștere.

Practic, aceasta este la fel ca și stocarea sha256 (parolă+sare) în DB pentru un utilizator, așa că nu sunt sigur dacă este „destul de bun” (având în vedere că parola este aleatorie de 16 octeți și ID-ul utilizatorului este alți 16 octeți aleatoriu - ghidul aplicației și db-ul nu este teoretic accesibil).

Cu o cheie de 128 de biți, nu contează cât de multe alte informații aleatorii sunt acolo. Poate fi mai bine să utilizați un adevărat KBKDF (funcție de derivare a tastei bazate pe chei) sau HMAC, totuși, acolo cheia este folosită ca material de introducere a tastelor. De asemenea, ar trebui să vă asigurați că intrările sunt într-o codificare canonică - dar dacă toate câmpurile au dimensiuni predefinite, atunci puteți doar să le concatenați.

O alternativă pe care o am pentru cheile API este să utilizez AES-GCM: generați nonce aleatoriu (iv) și criptați id-ul aplicației (ghid) cu o cheie secretă (stocată numai în setările webapi, nu db) și folosiți octeții (nonce , encryptedid, tag) ca cheie API. Acest lucru ar însemna nicio căutare a bazei de date în cazul cheilor api greșite. Cu toate acestea, nu sunt sigur cât de sigură este această soluție (la urma urmei, criptez doar un singur bloc de date de 128 de biți - ghidul appid - cu o cheie, printre toți apiclienții).

Nu aveți nevoie de confidențialitate aici, doar de verificarea intrării. Deci criptarea pare a fi o complicație inutilă. Cu toate acestea, am o întrebare mai presantă: cum protejați cheia și cum vă protejați împotriva atacurilor de reluare?

Destul de des puteți doar să stocați un UID aleatoriu ca simbol și să lăsați restul să fie gestionat de TLS. Asta pare să fie ceea ce fac majoritatea oamenilor, dar nu sunt familiarizat cu cazul tău de utilizare. Asta înseamnă, de asemenea, că ar trebui să iei toate aceste sfaturi cu un sâmbure de sare. Aș recomanda să apelați la un profesionist în securitate care să o examineze și să înceapă prin a defini de ce aveți nevoie și de cine și de ce trebuie să vă protejați.