Puncte:2

Ar trebui să folosesc HMAC pentru a crea un token HASH cu mai multe părți

drapel jp

Am un API web cu un sistem de autentificare API personalizat pe care fiecare utilizator îl are Cheie secreta și un public ApiKey. Folosind aceste două chei, clientul (sau utilizatorul) poate genera un token pentru autentificare pe server.

Luați în considerare că această funcție generează un jeton de autentificare

șir public GetToken (șir apiKey, șir secretKey, șir expireTimestamp)
{
    folosind var hashAlgorithm = SHA256.Create();
    var byteValue = Encoding.UTF8.GetBytes(apiKey + secretKey + expireTimestamp)
    var byteHash = hashAlgorithm.ComputeHash(byteValue)
    return Convert.ToBase64String(byteHash) + expireTimestamp
}

Deci un token este o combinație de

$$token = SHA256(APIKey \mathbin\| SecretKey \mathbin\| expireTimestamp) \mathbin\| expireTimestamp$$

Folosind acest simbol, avem un sistem unic de autentificare expirabil pentru API-urile noastre,

întrebări:

  1. Ar trebui să concatenez cheile+expTime sau ar trebui să folosesc ceva de genul HMAC? este acest scenariu vulnerabil la atacuri precum atacuri de extensie de lungime fara HMAC?
  2. Care este vulnerabilitatea acestui sistem (dacă există)?
fgrieu avatar
drapel ng
Comentariile nu sunt pentru discuții extinse; au fost [mutate la chat](https://chat.stackexchange.com/rooms/132054/discussion-on-question-by-alireza-should-i-use-hmac-to-create-a-multiple-part -Ha).
Puncte:2
drapel in

Folosind $$token = SHA256(APIKey \mathbin\| SecretKey \mathbin\| expireTimestamp) \mathbin\| expireTimestamp$$

nu este sigur, deoarece poate provoca un atac de extensie de lungime ca;

$$token2 = SHA256(APIKey \mathbin\| SecretKey \mathbin\| expireTimestamp \| \color{red}{extension}) \mathbin\| (expireTimestamp \| \color{red}{extension}) $$

Acesta este un simbol valid pentru fals.

NIST la apel pentru candidații SHA3 trebuie să fie rezistent la prelungirea lungimii atacuri. Keccak l-a numit acum câștigător pe SHA3, iar Blake2 este încă o alternativă bună la competiție. Ambele sunt rezistente la atacurile de extensie de lungime, Keccak folosind capacitatea și Blake2 o folosește HAIFA construcție, sunt sigure la atacurile de extensie de lungime.

Pentru a reduce se poate folosi HMAC;

$$token = \operatorname{HMAC-SHA256}(privateKey, publicKey \mathbin\| expireTimestamp) \mathbin\| expireTimestamp$$ Rețineți că aceasta va apela SHA-256 de cel puțin două ori (de trei ori dacă cheia este mai mare decât dimensiunea blocului funcției hash, 512 biți pentru SHA-256).

În loc de HMAC, putem folosi BLAKE2. BLAKE2 este foarte rapid și chiar și noi avem o versiune paralelă BLAKE3 si folosind

$$token = \operatorname{BLAKE2}( publicKey \mathbin\| privateKey \mathbin\|expireTimestamp) \mathbin\| expireTimestamp$$ este sigur.

NIST a standardizat, de asemenea, un MAC pentru SHA3 numit KMAC(sau Aici).

Atât BLAKE2 cât și KMAC sunt de preferat HMAC.

Dacă insistați să utilizați SHA2 cu o dimensiune de ieșire de 256 de biți, atunci utilizați SHA-512/256, care este versiunea trunchiată a SHA-512/256 cu valori inițiale diferite pentru a separa domeniile. SHA-512/256 este imun la atacurile de extensie de lungime și este prietenos cu procesorul pe 64 de biți prin design.

AliReza Sabouri avatar
drapel jp
mulțumesc @kelalaka, asta chiar ajută. exemplul tău cu „extensia” a creat o altă întrebare pentru mine, ce se întâmplă dacă toate cele 3 părți au întotdeauna o lungime fixă. de exemplu (apikey=36, privateKey=44, expireTime=10). SHA256 este vulnerabil în acest caz sau nu. deoarece `expireTime` are o lungime fixă, nimeni nu îi poate adăuga o extensie
kelalaka avatar
drapel in
Dacă știți dimensiunile și le verificați, atunci nu mai există un atac de extensie atâta timp cât atacatorul nu păcălește și acea parte. Aș face un atac de extensie de lungime unul sigur pentru a elimina suprafețele de atac.
kelalaka avatar
drapel in
Notă; Am actualizat răspunsul pentru a include SHA-512/256 pe care poate doriți să îl utilizați.

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.