producteur-service Web ont seulement hachage des mots de passe SHA-1 stockés dans la base de données. Nous devons authentifier les utilisateurs du service Web en utilisant la combinaison nom d'utilisateur/mot de passe.
Web Services Security UsernameToken Profile nous permet d'ajouter des en-têtes de savon à cet effet:
L'élément est introduit dans le WSS: SOAP message documents de sécurité comme un moyen de fournir un nom d'utilisateur. Au sein de l'élément, un élément peut être spécifié. Les mots de passe de type PasswordText et PasswordDigest sont non limité aux mots de passe réels, bien que ce soit un cas courant. (146-151)
type de mot de passe PasswordText signifie que le mot de passe est envoyé sur le fil en texte brut qui est un problème de sécurité si nous ne l'utilisons au niveau du transport des mécanismes de sécurité. PasswordDigest évite d'envoyer des mots de passe en texte brut et envoie un hachage. Mais pour éviter une attaque par rejeu (l'attaquant i-e utilisant l'écoute électronique pour capturer le mot de passe haché et le renvoyer avec une autre requête), le PasswordDigest ajoute un horodatage et un nombre aléatoire au mot de passe avant de calculer le hachage. Il en résulte d'addition à restriction suivante:
Notez que passwordDigest ne peut être utilisé si le mot de passe de texte brut (ou équivalent mot de passe) est disponible à la fois le demandeur et le destinataire . (196-197)
Mais dans notre cas, nous n'ont pas le mot de passe de texte brut. Ma question est la suivante: quelles alternatives avons-nous pour que les mots de passe en texte clair soient disponibles sur le serveur?
Je suppose que vous avez raison. C'est peut-être ce qu'ils voulaient dire par «mot de passe équivalent» dans les spécifications –
C'est exactement ce que «équivalent mot de passe» signifie dans ces contextes - même unicité, même (ou mieux) niveau d'impénétrabilité. – ParanoidMike