Imagine if you will...

IBM claims that Websphere has 35% market share. Let's assume you are one of the 2 million Websphere developers in the world, and you want to build some Web services to connect up your apps and data. Since you probably didn't take any secure coding training, where do you go to learn about how to secure your spanking new Websphere 6.1 Web service? Why the IBM Redbook of course. In there, here are some things you will find (emphasis added):

In the username token profile, the digest of the password is specified as a password type, but the password digest is not supported in WebSphere Application Server 6.1. Only the clear-text password can be inserted in a username token and should not be transferred over a non-secure network. Basic authentication should be used over the secure network, such as HTTPS or  intranet, or encryption should be applied to hide the user information. 

Clear-text password over the wire in the message - say it ain't so! One of the exercises we do in training is to examine 8 different SOAP messages with various security properties. We start with no security, just vanilla SOAP, then we do Username token with password hash, then Username token with cleartext password, then message encryption, and so on. The trend is that each message is stronger than the last but there is a trick the third message username token with cleartext password is less secure than the previous one Username token with password hash and arguably less secure than the first one vanilla SOAP with no token at all. 

let's look at the XML

Example 1. vanilla SOAP

<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<param0>Hello world</param0>

...

Example 2.  SOAP + WS-Security Username token password hash

<?xml version='1.0' encoding='UTF-8'?>
   <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
      <soapenv:Header>
         <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soapenv:mustUnderstand="1">
            <wsu:Timestamp xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="Timestamp-8533528">
               <wsu:Created>2008-03-18T19:01:21.710Z</wsu:Created>
               <wsu:Expires>2008-03-18T19:06:21.710Z</wsu:Expires>
            </wsu:Timestamp>
            <wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="UsernameToken-3692614">
               <wsse:Username>bob</wsse:Username>
               <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">E9rKWg/JSBzmaQufwyf0BRjcu3w=</wsse:Password>
               <wsse:Nonce>hpfLxX/d+VxD0qxfyX2uIA==</wsse:Nonce>
               <wsu:Created>2008-03-18T19:01:21.705Z</wsu:Created>
            </wsse:UsernameToken>
         </wsse:Security>
      </soapenv:Header>
      <soapenv:Body>

...

Example 3. SOAP + WS-Security USername token with cleartext password

<?xml version='1.0' encoding='UTF-8'?>
   <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
      <soapenv:Header>
         <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soapenv:mustUnderstand="1">
            <wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="UsernameToken-15828664">
               <wsse:Username>bob</wsse:Username>
               <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">bobpassword</wsse:Password>
            </wsse:UsernameToken>
         </wsse:Security>
      </soapenv:Header>
      <soapenv:Body>

...

In example 1, we have a payload but really no way to offer AAA services, in example 2, we have a shot at authN, in example 3 we pass the password in cleartext, in effect shipping the dynamite and detonator in the same truck! Now we are not only vulnerable to replay attacks as in the previous 2, but have introduced a spoofing risk for anyone who can read the message to impersonate the service identity that was used throughout the system and at best we gain a very weak authN method username/password. That's why in my view its worse than example 1, vanilla SOAP doesn't give you much for AAA but at least its not adding huge identity risks in your system through non-protection of both the credential and the secret!

But the Websphere story doesn't stop there.

As described in “Authentication” on page596, identity assertion (IDAssertion) is available in WebSphere Application Server 6.1. In a secure environment, such as an intranet or SSL, it is useful to only send the client (caller) identity without credentials (such as password) together with other trusted credentials (such as the intermediary server identity). 

Inranet and SSL - Ladies and Gentlemen - your 2009 Security Architecture! I really don't want to bash IBM, and in fairness WAS supports X.509 and other strong standards if you are serious, no question that in certain areas they have done excellent work, but come on people this 2009, this kind of guidance has got to stop.

Hacking things together to work is fine and all, developers have been doing it forever, but let's not do it under the rubric of "security" and oh while we are at it, let's revisit our risk assumptions about tokens, identity, SSL and the "intranet" (which seems a whole lot more like the Internet to me these days). Misuse of Web services security standards was precisely the focus of the talk Brian Chess and I gave at RSA last year.  

Comments

[Alex]

face-palm.

[Davanum Srinivas]

Gunnar,

AFAIK, Redbooks exist to show all the possibilities.

If you see infocenter for WAS7, you will see one more reason why we don't support password digests.

http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/cwbs_usernametokenv6.html

"WebSphere® Application Server supports the default PasswordText type. However, it does not support password digest because most user registry security policies do not expose the password to the application software."

Yes, there could/should be warnings added to avoid certain things.

But that's why we need folks like you to preach the best practices :)