Pattern token crittografato CSRF: necessità di 'nonce'?

1

Per il modello di token crittografato anti-CSRF, la pagina OWASP descrive il token crittografato come composto da tre elementi: l'ID dell'utente, un valore di timestamp e un nonce.

La necessità programmatica per i primi due è ovvia, ma per quanto riguarda il terzo? Qual è l'effettiva necessità del componente di dati casuali?

Ho capito perché nel caso del normale Token Pattern di sincronizzazione.

Ma quale sarebbe il problema per il token pattern crittografato con l'implementazione di un token composto solo da UserId e timestamp, che successivamente sarà soggetto a encrypt-then-mac.

È ritenuto importante rendere il token crittografato più sicuro da crittografia (rendendo il testo in chiaro più lungo e meno prevedibile)?

    
posta Henry 12.11.2015 - 21:38
fonte

1 risposta

1

Non proprio. Il nonce è lì per scopi anti-collisione, non di sicurezza crittografica. Potresti anche memorizzarlo come contatore in un database, se lo desideri; è solo che il timestamp ha una risoluzione insufficiente per garantire l'assenza di collisioni.

Vorrei anche sottolineare che i modelli elencati nella pagina OWASP collegata sono suggerimenti e non sono garanzie di sicurezza. Ad esempio, il loro modello di token crittografato suggerito non menziona che è necessario utilizzare AEAD o Encrypt-then-MAC o si potrebbe anche perdere tempo. (E se vai con Encrypt-then-MAC, hai bisogno di crittografia e chiavi MAC separate.)

    
risposta data 13.11.2015 - 02:18
fonte

Leggi altre domande sui tag