C'è un vantaggio nell'applicare pbkdf2 a una chiave usata per generare un MAC?

1

Abbiamo bisogno di generare URL resistenti alle manomissioni per accedere a un servizio, che vengono poi condivisi con l'utente finale. Gli URL non contengono dati riservati, ma dobbiamo assicurarci che non siano stati manomessi poiché sono stati generati. Spetta all'utente finale mantenere questi dati confidenziali.

Sembra che un MAC (come HMACSha256) sia appropriato per l'autenticazione degli URL. Mi piacerebbe anche includere un salt e timestamp per rendere la chiave MAC meno probabile e in modo che gli URL firmati possano naturalmente scadere.

Stavo pensando che PBKDF2 potrebbe essere un buon modo per generare la chiave MAC, ad esempio:

pepper = "xyzzy"
importantFullUrl = "https://....."

salt = secureRandomBits(256)
url = importantFullUrl + "&ts=987654321&salt=" + base62(salt)

signingKey = PBKDF2(pepper, salt, 10000 /*iterations*/, 256 /*bits*/)
mac = hmacSha256(url, signingKey)
signedUrl = url + "&sig=" + base62(mac)

Un approccio alternativo che ho visto ignora il passaggio PBKDF2 e genera semplicemente il MAC in base ai valori url e pepper sopra, cioè:

mac = hmacSha256(url, pepper)

Un approccio offre molti più vantaggi di sicurezza rispetto all'altro? Dato che gli URL scadranno dopo un periodo (ad esempio, 24-48 ore), è importante in questo caso? Come faccio a scegliere un conteggio iterativo adatto per un determinato timeout?

Esiste un approccio descritto in questa domanda che coinvolge una password fornita dall'utente. Gli utenti del nostro servizio sono autenticati utilizzando un meccanismo diverso e non hanno una password esplicita. Anche questo non è per un servizio web, e tutti questi URL firmati verranno generati dal lato server e ricontrollati sul lato server.

    
posta Jonathan 08.12.2013 - 15:38
fonte

1 risposta

1

La crittografia dovrebbe essere utilizzata solo quando non ci sono altre opzioni (SSL / TLS è un buon esempio in cui è richiesta la crittografia). Un HMAC introduce sempre la possibilità di un attacco banale (forza bruta). Inoltre, un HMAC può anche essere uno spreco di sforzo computazionale, se confrontato con altre soluzioni come una semplice nonce crittografica utilizzata per fare riferimento ai dati.

PBKDF2 viene utilizzato per estendere input a bassa entropia, come le password generate dall'uomo, da utilizzare come chiavi crittografiche. Affinché PBKDF2 sia utile, esso comporterà uno sforzo computazionale significativo per produrre l'hash risultante. Un'applicazione che espone questo tipo di funzionalità è vulnerabile a un Algorithmic Complexity Attack (ACA), e questa sarebbe una vulnerabilità molto seria se si trattasse di un software finanziario, perché gli attacchi DoS provocano danni economici.

PBKDF2 è utile, specialmente per le password, ma esponendo questa funzione a un utente malintenzionato senza alcuna forma di limitazione della velocità, crea una potenziale condizione di DoS. SHA256 va bene per l'uso come HMAC, infatti SHA1 sarebbe una scelta migliore per un'applicazione web perché più veloce e gli attacchi di prefisso contro SHA1 non indeboliscono l'HMAC risultante. La chiave segreta è l'importante, e devi ancora preoccuparti degli attacchi brute-force offline. Ma questo può essere risolto rendendo la chiave segreta di 128 byte, che risolve il problema per la vita del nostro sistema solare (con qualche stanza di comfort!).

    
risposta data 08.12.2013 - 19:11
fonte

Leggi altre domande sui tag