Puncte:2

Ce funcție de hashing este suficient de bună pentru ID-urile de sesiune?

drapel br

fundal

Creez un dispozitiv de scurtare a adreselor URL, iar adresa URL de scurtat poate conține a Sesiune ID.

Pentru ca dispozitivul de scurtare URL să nu compromită securitatea SessionId, trebuie să folosesc o strategie de scurtare care să îndeplinească aceleași cerințe ca SessionId.

OWASP precizează că:

  • Lungimea ID-ului sesiunii trebuie să fie de cel puțin 128 biți (16 octeți) Aici
  • Valoarea ID-ului sesiunii trebuie să furnizeze cel puțin 64 de biți de entropie Aici

Ce mă gândesc să fac

  • Aveți un magazin cheie-valoare, unde valoarea este adresa URL lungă (nescurtată), iar cheia este componenta URL scurtată.
  • Când utilizatorul navighează la o adresă URL scurtată, adresa URL lungă este căutată în magazinul cheie-valoare și returnată utilizatorului, care este apoi redirecționat.

Deci cheia trebuie să fie cel puțin 128 biți (16 octeți) lung și să ofere cel puțin 64 de biți de entropie, pentru a nu compromite SessionId.

Dacă cheia este un hash al valorii, pot garanta lungimea cheii și cunosc entropia (pe baza algoritmului de hashing utilizat).

Dar ce algoritm de hashing ar trebui să folosesc?

De exemplu, lungimea rezumatului MD5 este de exact 128 de biți. Dar nu știu care este entropia minimă.

Intrebarea

Ce algoritm de hashing produce un digest de cel puțin 128 de biți, cu cel puțin 64 de biți de entropie?

(x-post de la StackOverflow: https://stackoverflow.com/q/71224441/6517320)

kelalaka avatar
drapel in
Ai putea păstra o copie a întrebării tale? Consultați [Este permisă postarea încrucișată a unei întrebări pe mai multe site-uri Stack Exchange dacă întrebarea este la subiect pentru fiecare site?](https://meta.stackexchange.com/q/64068/403350) pentru detalii.
kelalaka avatar
drapel in
Rețineți că entropia nu este proprietatea valorii/datelor, ci este proprietatea sursei.Obțineți aleatoriu uniform de dimensiunea de 64 de biți și hash-o și trunchiați la 128 de biți. Utilizați BLAKE2 ca cea mai rapidă hashing criptografic, deși nu aveți nevoie de...
Puncte:5
drapel cn

Răspunsul scurt la întrebarea dvs. de hashing este „utilizați SHA-256”. Acesta este răspunsul pentru aproape fiecare problemă de hashing securizat, cu excepția cazului în care răspunsul este „utilizați SHA-512”. Dacă doriți un hash de 128 de biți, atunci puteți trunchia SHA-256 (luați primele sau ultimele 128 de biți). Toți biții din SHA-256 sunt independenți, așa că puteți extrage oricare 128 dintre ei ca hash.

Acestea fiind spuse, IMO, vă gândiți incorect la această problemă. Ideea nu este de a proteja în mod specific SessionId.Problema este că adresele URL pot conține informații sensibile, dintre care SessionId este doar un exemplu (dacă este stocat în URL). Dacă cineva știe deja adresa URL scurtată, poate doar să ceară sistemului dvs. adresa URL completă, așa că este vorba despre oprirea atacatorilor să găsească chei prin ghicire. Trebuie să faceți spațiul de taste rar, adică „mult, mult mai mare decât numărul de chei stocat efectiv”.

Mențineți o bază de date cheie/valoare, așa că nu este deloc nevoie să utilizați un hash. Puteți genera doar o cheie aleatorie pentru fiecare URL. Acest lucru este mai bun decât un hash, deoarece nu există absolut nicio legătură între cheie și valoare.

Având în vedere designul dvs., atacatorii nu pot căuta offline. Ei trebuie să contacteze serverul dvs. Să presupunem că puteți servi 1.000 de solicitări/secundă și că vă măriți spațiul de taste total pentru a fi de un trilion de ori mai mare decât numărul planificat de adrese URL. Acest lucru i-ar lua unui atacator aproximativ 15.000 de ani (~1/2 din spațiul căutat) pentru a găsi o singură adresă URL dacă ar putea consuma toată lățimea de bandă disponibilă (pe care mă aștept să o observați...). Cu doar puțină limitare a ratei pe adresă IP, ați putea complica dramatic acest atac.

Având în vedere cele de mai sus, dacă doriți să stocați un miliard de adrese URL în sistemul dvs., veți avea nevoie de un spațiu de cheie de:

log2(1 miliard de adrese URL * 1 trilion multiplicator) = 80 de biți

În Base58 (care îmi place pentru acest tip de problemă, deoarece este prietenos cu oamenii), ar fi nevoie de aproximativ 14 caractere. Modificând valorile de mai sus pentru limitarea ratei, perioada de atac împotriva căruia doriți să vă protejați și numărul de adrese URL stocate, puteți alege cât de lungi sunt cheile.

În general, puteți calcula valori aleatorii pe această scară fără să vă faceți griji cu privire la coliziuni (ceea ce este bun pentru performanță). Din același motiv pentru care este extrem de greu pentru un atacator să găsească o coliziune, este extrem de puțin probabil să ai una accidental. Dar dacă vrei să verifici din nou doar Cum puțin probabil, uită-te la Atacul de ziua de nastere. Calculele pentru „care este probabilitatea ca vreo valoare să se ciocnească” sunt diferite de „cât timp va dura unui atacator să găsească o coliziune” și, în unele cazuri, vă vor forța să utilizați chei mai lungi.

IMO, nu este nevoie de hashes. Dar dacă aveți nevoie de unul, utilizați SHA-256, trunchiat la orice număr de biți doriți.

Ivan Rubinson avatar
drapel br
Cum garantează acest lucru cel puțin 64 de biți de entropie?
drapel cn
Asta depinde de PRNG-ul tău. Pe sistemele Linux, dacă utilizați /dev/random, cred că se va bloca dacă sistemul scade sub 160 de biți de entropie disponibilă, așa că ar trebui să fiți întotdeauna ok pe acest tip de sistem. M-aș aștepta ca orice sistem pe care îl utilizați un PRNG criptografic va depăși cu mult 64 de biți pentru fiecare valoare, dar va trebui să vă verificați documentația pentru a fi sigur. De exemplu, pe unele (dar nu toate) sistemele /dev/urandom va returna valori de entropie scăzută.
drapel cn
Dar nicio funcție de hashing nu poate crește entropia și, dacă sunt rezistente la coliziuni în spațiul în cauză, nu vor reduce (eficient) entropia. Entropia din SessionId-ul original va fi păstrată de orice hash criptografic. Dacă inițial a avut mai puțin de 64 de biți, atunci va avea și hash-ul, iar dacă a avut mai mult de 64 de biți, va avea și hash-ul (minus puțin). Pentru a crește entropia, trebuie să adăugați o sare aleatorie, ceea ce înseamnă că ești legat de entropia PRNG-ului tău (la fel ca și când folosești o cheie aleatorie). https://crypto.stackexchange.com/questions/12505/what-happens-to-entropy-after-hashing
Ivan Rubinson avatar
drapel br
Deci entropia hash = entropia textului simplu. Prin urmare, pentru a asigura o entropie suficientă, textul clar trebuie să aibă o entropie mare. URL-ul lung are entropie scăzută, spre deosebire de un șir de octeți pseudoaleatoriu puternic criptografic; motiv pentru care recomandați cheia să nu fie un hash al URL-ului lung.
drapel cn
Aproape, dar entropia unui hash nu este niciodată mai mare decât entropia textului simplu. Hashurile rezistente la coliziuni reduc doar entropia mai puțin (în general, cu o cantitate neimportantă). Restul comentariului tău este corect.
Ivan Rubinson avatar
drapel br
Scuzați notația confuză. Dacă `A = B` atunci este imposibil pentru `A > B`. Deoarece hashingul nu poate crește entropia, dar poate scădea entropia, nu avem de câștigat din hashing, ci doar pierdem
SAI Peregrinus avatar
drapel si
„Pe sistemele Linux, dacă utilizați /dev/random, cred că se va bloca dacă sistemul scade sub 160 de biți de entropie disponibilă” Acest lucru nu a fost adevărat de ceva vreme. Nu că ar conta, dar se blochează doar la pornirea timpurie și apoi niciodată. Entropia nu este „epuizată”, așa că blocarea după însămânțare nu a ajutat niciodată la nimic.
drapel cn
Mulțumesc @SAIPeregrinus. Nu am mai fost administrator de sistem pentru Linux de mult timp :D Aveți vreo legătură cu starea actuală a lucrurilor în Linux, ca să mă pot educa mai bine? (Creierul meu de criptografie înțelege absolut ce vrei să spui; vreau doar ca partea mea de administrator de sistem să înțeleagă ce se întâmplă în practică.)
kelalaka avatar
drapel in
[Ce probleme există atunci când utilizați /dev/urandom Linux pentru generarea cheilor criptografice?](https://crypto.stackexchange.com/q/85533/18298)
SAI Peregrinus avatar
drapel si
Consultați, de asemenea, [acest articol LWN](https://lwn.net/SubscriberLink/884875/650dde925be055a1/) despre un patch propus pentru a unifica comportamentul /dev/random și /dev/urandom și getrandom(flags=0).
Ivan Rubinson avatar
drapel br
Se vorbește mult despre modul în care Linux gestionează CSPRNG. Ce zici de Windows?

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.