Improving Web Application Security: Threats and - CGISecurity

334 Part III: Building Secure Web ApplicationsUser Name and PasswordYou can send user names and password credentials in the SOAP header. However,because these are sent in plaintext, this approach should only be used in conjunctionwith SSL due to the network eavesdropping threat. The credentials are sent as part ofthe element, in the SOAP header as follows.BobYourStr0ngPassWordUser Name and Password DigestInstead of sending a plaintext password, you can send a password digest. The digestis a Base64-encoded SHA1 hash value of the UTF8-encoded password. However,unless this approach is used over a secure channel, the data can still be intercepted byattackers armed with network monitoring software and reused to gain authenticatedaccess to your Web service. To help address this replay attack threat, a nonce and acreation timestamp can be combined with the digest.User Name and Password Digest with Nonce and TimestampWith this approach the digest is a SHA1 hash of a nonce value, a creation timestamp,and the password as follows.digest = SHA1(nonce + creation timestamp + password)With this approach, the Web service must maintain a table of nonce values and rejectany message that contains a duplicate nonce value. While the approach helps protectthe password and offers a basis for preventing replay attacks, it suffers from clocksynchronization issues between the consumer and provider when calculating anexpiration time, and it does not prevent an attacker capturing a message, modifyingthe nonce value, and then replaying the message to the Web service. To address thisthreat, the message must be digitally signed. With the WSE, you can sign a messageusing a custom token or an X.509 certificate. This provides tamperproofing andauthentication, based on a public, private key pair.