views:

15

answers:

1

Scenario:

Web-service producer have only SHA-1 hash of passwords stored in database. We need to authenticate Web-service users using User Name/Password combination.


Web Services Security UsernameToken Profile allows us to add soap headers for this purpose:

The element is introduced in the WSS: SOAP Message Security documents as a way of providing a username.

Within element, a element may be specified. Passwords of type PasswordText and PasswordDigest are not limited to actual passwords, although this is a common case. (146-151)

PasswordText password type means that password is sent over the wire as plain text which is a security issue if we are not using Transport Level Security mechanisms. PasswordDigest avoids sending plain text passwords and sends a hash. But to avoid replay attack (i-e attacker using wiretap to capture the hashed password and resend it with another request) the PasswordDigest adds a timestamp and a random number to password before computing the hash. This addition results in following restriction:

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


But in our case we do not have plain text password. My question is: what alternates do we have other that to make plain text passwords available on the server?

+2  A: 

The SHA-1 can be perfectly used as a "plaintext" password.

  • Ask the user the password
  • convert it to SHA-1
  • run it throught the PasswordDigest thing
  • the server will do the same with the SHA-1 in the database
  • the server will find that they match and allow access
Peter Tillemans
I guess you are right. Perhaps this is what they meant with "password equivalent" in the specs
Tahir Akhtar
That's exactly what "password equivalent" is used to mean in these contexts - same uniqueness, same (or better) level of inscrutability.
ParanoidMike