Come implementare UsernameToken WSS quando la password sul server è salata e hash?

Question

Come implementare UsernameToken WSS quando la password sul server è salata e hash?

#1 da (2 voti)

4

Attualmente sto cercando di scrivere un servizio Web per i clienti e il requisito è usare WS Security. Sul lato server, hanno le password archiviate come SHA-1 (salt + password).

Secondo le specifiche WSS, l'intestazione di sicurezza conterrà nonce, timestamp e password digest come SHA-1 (nonce + timestamp + password_user_entered). Quindi sul server fai SHA-1 (nonce_from_header + timestamp_from_header + password_from_database) e confrontalo con il digest della password dall'intestazione. Questo tipo di implica che le password sul back-end devono essere in chiaro. Immagino che funzionerebbe se le password sul back-end fossero solo SHA-1 (password) perché puoi istruire i clienti a costruire il digest come SHA-1 (nonce + timestamp + SHA-1 (password)) ma non riesco a fare funziona con password salate.

Nel mio caso, dal momento che le password sul back-end sono hash e salate, non sarò in grado di autenticare l'utente dal momento che sul server potrò fare solo SHA-1 (nonce_from_request + timestamp_from_request + hashed_salted_password_from_database) che non combacerà con il digest dalla richiesta. Quindi, sembra che salt debba in qualche modo trovare il modo al cliente per poter creare un digest di password che sia utilizzabile sul server.

Sembra che una soluzione sia quella di avere un servizio Web che chiami per primo e di inviare username e che tu riceva il sale per quell'utente. Quindi crei il digest di password come SHA-1 (nonce + timestamp + SHA-1 (salt_from_server + password)) e lo usi nell'intestazione per il web principale svc. Questa è una buona soluzione o esiste un modo migliore di standard industriale per gestire scenari simili?

Grazie.

passwords hash web-service

posta Michail 23.02.2012 - 20:17

fonte

1 risposta

Leggi altre domande sui tag passwords hash web-service

Il difetto di sicurezza del cuneo è stato corretto per le carte di credito? Firefox Flash plugin malware?

score 2 · Answer 1

Non sono sicuro di quale particolare specifica WS-Security ti riferisci. Tuttavia, per quanto vedo, questa specifica (grazie a @logicalscope) fornisce solo un suggerimento per quanto riguarda l'hash della password. Inoltre, la specifica afferma che:

Note that PasswordDigest can only be used if the plain text password (or password equivalent) is available to both the requestor and the recipient.

Quindi nel tuo caso, la password NON è disponibile per il destinatario. Solo la password già cancellata.

Un altro punto importante da notare è questo commento sulle specifiche:

However, unless this digested password is sent on a secured channel or the token is encrypted, the digest offers no real additional security over use of wsse:PasswordText.

Suggerirei di utilizzare testo in chiaro PasswordText ma assicurati che il canale sia, ad es. SSL protetto (se non lo hai ancora fatto). In questo modo non è necessario modificare il modo in cui le password vengono memorizzate, puoi cancellarle come desideri e la password viene comunque trasportata in modo sicuro dall'utente alla tua app.