WSS (WSS4J): contraseña de texto claro en UsernameToken vs hash de contraseña con sal en la base de datos

Question

WSS (WSS4J): contraseña de texto claro en UsernameToken vs hash de contraseña con sal en la base de datos

#1 de Andreas Klein (2 votos)

3

Actualmente estoy luchando un poco con la capa de seguridad de un servicio web que estoy escribiendo usando WSS4J y CXF.

Obviamente, no deseamos almacenar contraseñas de texto simple en nuestro backend, pero preferiríamos persistir solo los hashes con sal.

Sin embargo, las especificaciones del servicio están predeterminadas por nuestro cliente (quien utilizará el servicio para enviar un montón de datos a nuestra manera), hasta el uso de UsernameTokens con contraseña de texto simple (todas las comunicaciones están cifradas con SSL)

Ahora, el problema al que me enfrento es que parece que no puedo encontrar una manera de eliminar la contraseña de texto sin formato del encabezado de seguridad de la solicitud en nuestro extremo, compararla con nuestros registros junto con el nombre de usuario y autorizar o rechazar la solicitud.

Cada guía, tutorial o proyecto de ejemplo que he encontrado hasta ahora se basa en un CallbackHandler configurado como interceptor de entrada, que requiere la recuperación de la contraseña de texto sin formato correcta, que luego se compara directamente con las credenciales proporcionadas. No es una opción si solo almacenamos el hash. Me encontré con un par de fuentes que intentaban resolver problemas similares simplemente recomendadas para forzar al cliente a hacer el hash. Pero como dije antes, esto no es posible en nuestro caso. Las especificaciones del servicio son claras al respecto y está fuera de nuestras manos.

Este hilo que suena particularmente interesante, lamentablemente, tampoco me ayudó: Cómo ¿Implementar WSS UsernameToken cuando la contraseña en el servidor está incluida y hash?

Seguramente debe haber otra forma que no sea WSS4JInInterceptor / CallbackHandler, una que me permita digerir la contraseña de texto sin formato recibida y compararla con el hash salado en nuestra base de datos.

Cualquier puntero sería realmente apreciado. Gracias.

authentication authorization web-service

pregunta Andreas Klein 24.06.2013 - 09:41

fuente

1 respuesta

Lea otras preguntas en las etiquetas authentication authorization web-service

¿Cómo evitar que CAS filtre la identidad del usuario a sitios web visitados arbitrariamente? escaneo SYN, determinando escaneo vs carga de archivos grandes

score 2 · Accepted Answer

Gracias a Ivan Brencsics de la lista de correo de CXF por proporcionar esta sugerencia. El escribe:

Si entiendo correctamente su pregunta, su problema es que usted no [no puede] acceder a la contraseña en el CallbackHandler, por lo que no puede hacer hash y compararlo con la base de datos.

Me encontré con el mismo problema recientemente, y lo resolví registrando un org.apache.ws.security.validate.Validator en lugar de un CallbackHandler.

Entonces, por ejemplo:

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

y finalmente 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;
}

Ah, y gracias a Polynomial por sugerirme que revise la lista de correo de CXF. Aún no veo el atractivo de las listas de correo en un foro adecuado;)