Come posso proteggere l'autenticazione ma non il payload?
-
03-07-2019 - |
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)
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?