Puncte:3

Atacul de uzurpare a identității asupra parolei unice a lui Lamport

drapel in

Așa că iată-mă, cautând pe Google pe Google posibilitățile de tentative de uzurpare a identității de către un atacator MITM pe Schema de parole unice de la Lampport.

Iată scenariul meu:

Să presupunem că avem o configurare pentru client și server. Dat un nonce $n$, și o funcție hash $h()$, un client calculează hash-ul lui $n$ de mai multe ori (să zicem $100$) și trimite în primă instanță $H^{(100)}$ Unde $H^{(100)}=h^{(100)}(n)$. În primul rând, cum autentifică serverul identitatea clientului pentru prima valoare furnizată de client, $H^{(100)}$? Semnături digitale/certificate?

Pentru o autentificare ulterioară, clientul trimite $H^{(99)}$ iar serverul calculează $h(H^{(100)})$ și dacă calculul se potrivește cu valoarea deținută de server (adică $H^{(100)}$), serverul autentifică clientul.

Acum presupunând că există un atacator în mijlocul comunicării, atacatorul nu poate pur și simplu să intercepteze $H^{(99)}$ de la client și trimite $H^{(99)}$ la server, uzurpând astfel identitatea clientului numai pentru această sesiune specială în care $i$ este $99$. Aceasta ar însemna că serverul autentifică atacatorul în loc de client. Nu este posibilă această uzurpare a identității? Și dacă da, cum protejează OTP-ul Lamport împotriva acestui lucru.

Utilizarea semnăturilor digitale sau a criptării cu chei publice pentru fiecare sesiune de autentificare nu pare să fie ideea lui Lamport pentru utilizarea schemei sale OTP. Înțelegerea mea despre OTP-ul Lamport este că folosește NUMAI funcții hash.

kelalaka avatar
drapel in
[OTP](https://en.wikipedia.org/wiki/One-time_password) nu este semnătură digitală. Vezi de la NIST [Recomandation for Stateful Scheme de semnătură bazate pe hash](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-208.pdf). Ce se întâmplă dacă clientul trimite $(H^{(i)},i)$ și a scăzut $i$ pentru fiecare sesiune, desigur, serverul trebuie să țină evidența $i$ ca [Wiki menționat](https:/ /en.wikipedia.org/wiki/One-time_password#Hash_chains)?
Puncte:2
drapel in
  • Pe partea scurtă

    O parte a securității Parolei unice (LOTP) Lamport se bazează pe faptul că serverul stochează ultimul hash și, pentru data viitoare, necesită hash-ul anterior și îl hash pentru a se compara cu ultimul stocat. Prin urmare, atacatorul nu îl poate folosi pentru a uzurpa identitatea utilizatorului atâta timp cât funcția hash are rezistență înainte de imagine.

Ideea lui Lamport se bazează pe securitatea Hash-Chain după cum urmează;

  • Inițializarea sistemului

    1. O sămânță inițială $s$ e ales.
    2. Hașișul $H$ este aplicat $n$- ori în cascadă $$h_n = H^{(n)} = \underbrace{H(H(\cdots H(s) \cdots ))}_{n-ori}$$ la sămânța inițială $s$ Unde $n$ poate fi 1000,10000 sau ..
    3. Serverul stochează inițial $h_n$ (și eventual $n$, de asemenea)
    4. Utilizatorul stochează $s$ și $n$
  • Mecanism de conectare

    • Pentru prima autentificare

      1. Utilizatorul calculează $h_{n-1}$
      2. În procesul de conectare utilizatorul trimite $h_{n-1}$ la server.
      3. Verificări de server $H(h_{n-1}) = h_n$
      4. Pe un server de conectare reușit
        1. incrementa un contor $inc(c)$
        2. magazine $h_{n-1}$
      5. La conectare cu succes, setarea utilizatorului $n = n-1$ (sau posibil alta variabila)
    • Pentru $i$-a autentificare

      1. Utilizatorul calculează $h_{n-i}$
      2. La procesul de conectare utilizatorul trimite $h_{n-i}$ la server.
      3. Verificări de server $H(h_{n-i}) = h_{n-i+1}$
      4. Pe un server de conectare reușit
        1. incrementa un contor $inc(c)$
        2. magazine $h_{n-1}$
      5. La conectare cu succes, setarea utilizatorului $n = n-1$ (sau posibil alta variabila)

Acestea sunt elementele de bază și unele detalii sunt omise pentru claritate; de exemplu; din anumite motive, sistemul poate fi nesincronizat, adică numărul utilizatorului poate să nu fie sincronizat cu serverul. Pentru a gestiona acest lucru, serverul poate păstra un parametru privind privirea înainte $t$, deci pe $i$-a-a încercare de conectare dacă nu există egalitate $H(h_{n-i}) \neq h_{n-i+1}$, serverul se uită înainte dacă există o potrivire de la $h_{n-i+1}$ la $h_{n-i-t+1}$.

Acum ce dacă o terță persoană vede jetonul LOTP și încearcă să-și uzurpare identitatea utilizatorului.

  1. Pentru o nouă autentificare nu o pot folosi deoarece au nevoie $H_{n-i-1}$. Pentru a avea acest lucru, trebuie să găsească o imagine prealabilă. Toate funcțiile hash criptografice și-au menținut garanțiile pre-imagine, inclusiv rezistența la coliziune ruptă un MD5 și SHA-1. Acest lucru nu înseamnă că ar trebui să le folosiți, preferați-le pe cele moderne precum SHA-256, SHA-512, SHA-3, BLAKE2 etc.

    Dacă sistemul permite cumva utilizatorului să folosească același token LOTP în timpul unei sesiuni, atacatorul poate uzurpa identitatea utilizatorului pentru această sesiune. Raza de atac nu poate depăși această sesiune din cauza rezistenței pre-imagine.

    Pe scurt, securitatea LTOP se bazează pe securitatea pre-imagine a $H$

  2. Privirea înainte poate cauza o problemă? Nu. Serverul își actualizează valorile hash stocate la fiecare conectare. Dacă l-au stocat doar pe cea inițială și hashuri $i$-de ori pentru a verifica OTP, apoi privirea înainte este un punct de atac. Acesta este unul dintre motivele pentru a păstra ultimul hash, iar celălalt este performanța.

  3. Secretul $\mathbf{s}$ mărimea, pe de altă parte, ar trebui să aibă cel puțin 128 de biți uniformi și generați aleatoriu pentru a preveni forța brută a $s$.

Jake avatar
drapel in
Vă mulțumesc pentru explicația dumneavoastră detaliată. Iubește ideea parametrului look-ahead. Un lucru însă este că punctul meu încă nu pare să fie înțeles. Luați de exemplu o sesiune în care utilizatorul trimite hn-1. Un atacator poate intercepta hn-1 și trimite-l la server. La urma urmei, serverul nu validează niciodată unde hn-1 vine de la. Tot ce face serverul este să verifice dacă hn-1 hashes la hn. Deci, dacă se întâmplă acest lucru, nu ar însemna că serverul autentifică atacatorul în loc de utilizator? Sau ar putea fi ceva ce îmi lipsește.
Jake avatar
drapel in
Mi-a luat ceva timp să vin cu comentariul meu anterior, sper doar să înțelegi punctul meu. În plus, ce se întâmplă când utilizatorul trimite inițial un hash de n ori al secretului s. Mă refer la prima dată când un utilizator trimite hash-ul său de n ori cu care serverul începe să lucreze. Cum asigură serverul identitatea utilizatorului în primă instanță? Sau putem presupune un scenariu în care serverul oferă de fapt secretele utilizatorului într-un mod sigur, făcând ca utilizatorul să trimită secretul furnizat de server. În opinia mea, aceasta poate fi o modalitate prin care serverul verifică identitatea utilizatorului.
kelalaka avatar
drapel in
1) După cum am spus, răspunsul nu include toate detaliile. Ce se întâmplă dacă serverul crește hash-ul de îndată ce validează utilizatorul și a uitat valoarea anterioară? Același atac de sesiune se poate întâmpla numai datorită alegerii designerului. Dacă doresc să prevină acest lucru, atunci pot solicita un nou token.
kelalaka avatar
drapel in
2) Ați auzit vreodată procesul de înregistrare? Secretul ar trebui să fie generat de utilizator și trebuie să fie dat utilizatorului într-un mod sigur, precum jetoanele băncilor. Odată ce utilizatorul și serverul sunt de acord cu privire la înregistrare, utilizatorul își poate da $h_s$ în acest moment. validarea utilizatorului ar trebui să necesite cel puțin doi factori precum cel pe care ar trebui să-l cunoașteți (o parolă), cel pe care ar trebui să-l aveți (telefon/token) etc. LOTP este un factor.
Jake avatar
drapel in
+1 pentru feedback, mulțumesc

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.