WSS (WSS4J): password in chiaro in UsernameToken vs hash della password salata nel database

Question

WSS (WSS4J): password in chiaro in UsernameToken vs hash della password salata nel database

#1 da (2 voti)

3

Attualmente sto combattendo un po 'con il livello di sicurezza di un servizio web che sto scrivendo usando WSS4J e CXF.

Ovviamente non desideriamo archiviare password in chiaro nel nostro back-end, ma preferiremmo mantenere solo gli hash salati.

Le specifiche del servizio, tuttavia, sono preimpostate dal nostro client (che utilizzerà il servizio per spingere un sacco di dati sulla nostra strada), fino all'uso di UsernameTokens con password in chiaro (tutte le comunicazioni sono crittografate con SSL)

Ora il problema che sto affrontando è che non riesco a trovare un modo per cancellare la password in chiaro dall'intestazione di sicurezza richiesta da parte nostra, abbinarla ai nostri record insieme al nome utente e autorizzare o rifiutare la richiesta.

Ogni singola guida, tutorial o progetto di esempio che ho trovato finora si basa su un CallbackHandler configurato come intercettore di input, che richiede il recupero della password in chiaro in chiaro, che viene quindi confrontata direttamente con le credenziali fornite. Non un'opzione se archiviamo solo l'hash. Un paio di fonti che ho trovato che cercavano di risolvere problemi simili si sono semplicemente raccomandati di costringere il cliente a fare l'hashing. Ma come ho detto sopra, questo non è possibile nel nostro caso. Le specifiche del servizio sono chiare sull'argomento ed è fuori dalle nostre mani.

Questo thread dal suono particolarmente interessante purtroppo non mi ha aiutato neanche: Come implementare UsernameToken WSS quando la password sul server è salata e hash?

Sicuramente ci deve essere un altro modo rispetto a un WSS4JInIncepceptor / CallbackHandler, uno che mi permetterà di digerire la password in chiaro ricevuta e di controllarla con l'hash salato nel nostro database.

Qualsiasi suggerimento sarebbe davvero molto apprezzato. Grazie.

authentication authorization web-service

posta Andreas Klein 24.06.2013 - 09:41

fonte

1 risposta

Leggi altre domande sui tag authentication authorization web-service

XSS Database MySQL accessibile? SYN scan, che determina la scansione rispetto al caricamento di file di grandi dimensioni

score 2 · Accepted Answer

Grazie a Ivan Brencsics della mailing list CXF per aver fornito questo suggerimento. Scrive:

Se comprendo correttamente la tua domanda, il tuo problema è che tu ~~dont~~ [can not] accedi alla password in CallbackHandler, quindi non puoi cancellarla e confrontalo con il database.

Mi sono imbattuto recentemente nello stesso problema e l'ho risolto registrando un org.apache.ws.security.validate.Validator anziché CallbackHandler.

Quindi ad esempio:

<jaxws:endpoint ...>
  <jaxws:properties>
    <entry key="ws-security.ut.validator" value-ref="sqlTokenValidator"/>
  </jaxws:properties>
</jaxws:endpoint>
...
<bean id="sqlTokenValidator" class="org.my.SqlTokenValidator"/>

e infine SqlTokenValidator:

public class SqlTokenValidator implements org.apache.ws.security.validate.Validator {

@Override
public Credential validate(Credential credential, RequestData data) 
throws WSSecurityException {
    ...
    UsernameToken usernameToken = credential.getUsernametoken();

    String username = usernameToken.getName();
    String password = usernameToken.getPassword();

   ... hash the password
   ... sql_auth(username, hash password)
   ... if failed throw new WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION);

    return credential;
}

Oh e grazie a Polynomial per avermi suggerito di controllare la mailing list CXF. Non riesci ancora a vedere il fascino delle mailing list su un forum appropriato;)