Qual è l'alternativa a PasswordDigest quando la password in chiaro non è memorizzata sul produttore web-service?

Question

Scenario:

produttore

Web-service hanno solo hash SHA-1 di password memorizzate nel database. Abbiamo bisogno di autenticare gli utenti Web-service utilizzando combinazione di Nome utente / password.

---

Web Services Security UsernameToken Profilo ci permette di aggiungere intestazioni sOAP per questo scopo:

  

L'elemento è   introdotto nel WSS: SOAP Message   documenti di sicurezza come un modo di   fornendo un nome utente.

     

In elemento, un    elemento può essere   specificato. Le password di tipo   PasswordText e PasswordDigest sono   non limitato alle password attuali,   anche se questo è un caso comune.    (146-151)

mezzi PasswordText tipo password password viene inviata sul filo come testo normale, che è un problema di sicurezza se non stiamo usando meccanismi Transport Level Security. PasswordDigest evita l'invio di password in chiaro e invia un hash. Ma per evitare l'attacco di replay (i-e attaccante utilizzando intercettazione telefonica per catturare l'hash della password e inviarlo nuovamente con un'altra richiesta) il PasswordDigest aggiunge un timestamp e un numero casuale per la password prima di calcolare l'hash. Questa aggiunta comporta seguente limitazione:

  

Si noti che solo può PasswordDigest   essere utilizzato se la password di testo normale (o   Password equivalente) è disponibile   sia per il richiedente e la   destinatario. (196-197)

---

Ma nel nostro caso non abbiamo la password di testo normale. La mia domanda è: che alterna dobbiamo altro che rendere password in chiaro disponibile sul server

Answer 1

L'SHA-1 può essere perfettamente utilizzata come password "in chiaro".

• Chiedere all'utente la password
• convertirlo in SHA-1
• eseguirlo ATTRAVERSO la PasswordDigest cosa
• il server farà lo stesso con l'SHA-1 nel database
• il server troverà che esse corrispondano e consentono l'accesso