E 'possibile avere server non stateless nonces in HTTP Digest

9

Quando si implementa un server HTTP Digest, c'è il problema di nonces.

Server nonces (al contrario di client nonces)

  • deve essere emesso dal server
  • può essere riutilizzato dai client fino a quando il server lo consente
  • non sa nulla su quale utente userà il nonce più tardi

Un'implementazione ingenua è quella di ricordare tutti i nonces emessi in memoria, ma questo introduce lo stato: O un client deve parlare con lo stesso server, oi server devono condividere l'elenco dei non validi validi, che diventa un problema di scalabilità.

La mia domanda è: È possibile fornire nonces protetti e senza stato ? Credo di sì, e vorrei che fosse (in) validato:

Rendi il nonce un messaggio firmato crittograficamente dal server :

  1. un timestamp di scadenza (ad esempio 86400 secondi nel futuro)
  2. un numero casuale (forse?)
  3. una firma crittografica (sha o hmac forse?)

Questo potrebbe essere raggruppato insieme nel nonce che è fornito nell'intestazione dell'autenticazione Www 401. Quando un server lo vede, può verificare l'integrità del messaggio (ricalcolando la firma). Quindi il timestamp può essere controllato, e se è così allora il nonce è buono.

  • Questa tecnica è descritta altrove?
  • Questo modo di fornire nonces sconfigge lo scopo di nonces?
  • Esiste un altro modo per fornire l'autenticazione Digest HTTP stateless?
posta mogsie 28.01.2012 - 01:49
fonte

1 risposta

8

Se il server è stateless, qualunque cosa i client invii a "get authenticated" può essere riprodotto. Un utente malintenzionato deve solo intercettare una richiesta da un client e quindi inviare la propria richiesta con l'intestazione pertinente semplicemente copiata. Una data di scadenza impedisce all'aggressore di farlo a tempo indeterminato, ma anche se l'autore dell'attacco può distruggere il caos all'interno del server solo durante un giorno, ciò non è ancora soddisfacente. La possibilità di attacchi di replay è consustanziale all'apolidia; è inevitabile.

E HTTP Digest non è comunque un ottimo protocollo. HTTP Digest garantisce un servizio di sicurezza solo in un modello in cui gli aggressori possono potenzialmente spiare dati scambiati, ma non alterarlo; questo non è un modello molto realistico. In pratica, hai bisogno di qualcosa di più approfondito, come SSL, a quel punto puoi inviare la password così com'è (HTTP Basic) e dimenticarti di HTTP Digest.

    
risposta data 28.01.2012 - 04:50
fonte

Leggi altre domande sui tag