Devo allungare la chiave segreta in un'implementazione sicura del protocollo dei cookie?

Question

Devo allungare la chiave segreta in un'implementazione sicura del protocollo dei cookie?

#1 da (2 voti)

0

Sto costruendo un livello di autenticazione api che funziona fondamentalmente come il protocollo del cookie sicuro, dove invece di un cookie do al toi client un token che devono fornire nelle richieste successive. Tale token è firmato tramite HMAC utilizzando una chiave segreta mantenuta in memoria sul server. La chiave è una stringa esadecimale casuale di 64 caratteri. Attualmente sto firmando i token con la chiave direttamente, ma sulla base di ciò che ho visto nel codice sorgente per ruby on rails, firmano i loro cookie con una chiave segreta derivata allungando la base della chiave segreta con pbkdf2. Quale vettore di minacce sta difendendo questa difesa? Come ho capito, lo stretching chiave dovrebbe aiutare a prevenire attacchi brute force offline contro password memorizzate. Non sono chiaro quale sia lo scopo è qui e se è qualcosa che dovrei implementare.

authentication hmac key-stretching

posta AndrewSwerlick 02.06.2015 - 16:47

fonte

1 risposta

Leggi altre domande sui tag authentication hmac key-stretching

E 'possibile FDE a VPS / VMS C'è un modo per attaccare il blocco del certificato STARTTLS + sondato da più posti?

score 2 · Accepted Answer

Lo stretching chiave fornisce fondamentalmente una chiave con un'entropia bassa più forza, ricavando un hash da esso creato da più iterazioni.

Una stringa esadecimale di 64 caratteri, supponendo che sia generata in modo completamente casuale, avrà 256 bit di entropia. Quando si autentica una stringa con un HMAC, qualsiasi cosa a 128 bit o superiore è considerata "indistruttibile".

Lo stretching chiave attenua il rischio di avere una chiave debole, perché l'unico modo in cui un utente malintenzionato può trovare la chiave è tramite un attacco indovinatore di password offline. Con lo stretching delle parole con 1024 iterazioni, questo rende la password 10 più "strong" perché per ogni password l'attaccante cerca di eseguire la funzione di hash 1024 volte (l'equivalente di avere più entropia nella stessa password - compensa lo spazio delle chiavi in più avrebbe una password più strong).

Quindi con Ruby on Rails, questo protegge il proprietario del sito scegliendo una chiave debole (< 128 bit). Se riesci a controllare la tua chiave e la rendi abbastanza strong, non è necessario alcun allungamento della chiave.