Si tratta di uno schema di cookie sicuro valido?

Question

Si tratta di uno schema di cookie sicuro valido?

#1 da (1 voti)

3

Ho uno schema per un cookie con riservatezza di informazioni ad alto livello. Le informazioni da nascondere al client sono i tempi di scadenza del cookie. Mi chiedo quali insicurezze mi sto aprendo a questo schema.

Nota sotto che | denota concatenazione e (text)k è testo crittografato usando la chiave k.

cookie = creation_time | (expiration_time)k | HMAC(creation_time|expiration_time|server_key , k) where k = HMAC(creation_time, server_key)

I passaggi per la convalida della chiave sono:

Assicurati che creation_time sia un timestamp valido
crea k = HMAC (creation_time, server_key)
decrittografare (expiration_time) k usando k.
assicurati (expiration_time - creation_time <= T) & & current_time < expiration_time dove T è un server consentito TTL per un cookie.
calcola HMAC (creation_time | expiration_time | server_key, k) e confronta con il valore del cookie. se sono uguali, il cookie è valido.

L'intero punto di questo cookie è quello di consentire che un cookie venga ricevuto dall'utente in un punto e inviato di nuovo il comando ajax entro un tempo T .

cookies confidentiality custom-scheme

posta lluisrojass 18.08.2017 - 21:39

fonte

1 risposta

Leggi altre domande sui tag cookies confidentiality custom-scheme

Esempio di attacco a freddo nel mondo reale Windows 10's (Protezione per Windows Defender Application) VS Browser Sandboxing

score 1 · Answer 1

Ci sono alcune cose che non vanno in questa costruzione.

Non hai definito quale algoritmo di crittografia stai utilizzando. Se si dovesse utilizzare una modalità di cifratura a blocchi con padding, come CBC, la progettazione potrebbe essere potenzialmente vulnerabile a un attacco oracle di riempimento, poiché il server deve decrittografare il valore expiration_time crittografato prima di convalidare il record di autenticità rispetto al testo in chiaro. Dovresti applicare verifiche di autenticità rispetto al testo cifrato laddove possibile.

Inoltre non è chiaro come i delimitatori funzionino tra i campi. Devi definire come ogni singolo campo viene prodotto separatamente per evitare qualsiasi confusione sul processo di decodifica.

Anche se non è critico, è anche una cattiva pratica avere una singola chiave condivisa sia per la crittografia / decrittografia che per l'autenticità (HMAC). Dovresti sempre mirare ad avere chiavi indipendenti per questi.

Nel complesso questo è un design troppo complesso.

Un modo più semplice è quello di memorizzare il tempo di scadenza come variabile di sessione, come in PHP:

session_start();
$_SESSION['expiry'] = time() + 60 * 60 * 24; // now +24 hours

E poi in ogni richiesta:

session_start();
if (!isset($_SESSION['expiry']) || !is_int($_SESSION['expiry']))
{
    // expiry time has been unset or corrupted somewhere, log and fail
}
if ($_SESSION['expiry'] < time())
{
    // session expired, do whatever you need to do about this
}

Salva il complesso schema crittografico e l'accesso lato client al token.