Domanda

Sto cercando un protocollo HTTP esistente per proteggere l'autenticazione ma non il payload che segue. Voglio che il server memorizzi il nome utente, la password con hash e il salt diverso per utente.

L'autenticazione Digest HTTP non soddisfa questi requisiti perché tutti gli account utilizzano lo stesso sale. SSL non riesce perché crittografa l'intera connessione.

Modificato per aggiungere:

Questo è per un client desktop che parla con un servizio web (nessun browser coinvolto)

È stato utile?

Soluzione

Perché non solo avere il tuo meccanismo di autenticazione protetto da SSL e quindi inoltrarlo al resto della tua applicazione che funziona con HTTP normale?

Altri suggerimenti

Lo schema popolare prevede che il modulo di accesso sia protetto da SSL, mentre il resto del sito non utilizza SSL. Vedi ad esempio i siti di social network più famosi.

Che ne dici di OpenID? C'è un motivo per cui è necessario memorizzare le informazioni di autenticazione?

Modificato per aggiungere

Siamo spiacenti ma non ho capito che si trattava di un'app desktop. Che ne dici di OAuth ?

Esiste un modo per strutturare l'URL della richiesta originale per indicare l'utente? Quindi, il server potrebbe rispondere con un diverso regno diverso (fungendo da "salt") per ogni utente nella risposta di autenticazione digest HTTP. Ad esempio, richiedere gli URL nel formato http://user.y.com/service o http://www.y.com/user/service comporterebbe una risposta alla sfida come:

WWW-Authenticate: Digest realm="user@y.com", nonce="oqa9hvq49krprkphtqc"

Puoi spiegarci cosa sta guidando & no; nessuna crittografia " mandato? Se sei soggetto ad attacchi man-in-the-middle, devi proteggere l'integrità dell'intera richiesta. Lì, SSL sarebbe molto utile. Se non puoi assolutamente avere la crittografia, sarebbe accettabile SSL che utilizza una suite di crittografia non crittografata?

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top