It’s just data

More noncense

Tim Ewald makes an appearance back in the blogosphere, this time in a new home.  I've updated my blogroll.  Welcome back!

The occasion?  To defend the use of a standard UsernameToken header in an application where all the bells and whistles of WS-Security aren't needed.

To recap what happened, apparently MsComServices had a need for a developer's token not unlike the Google API's license key.  Instead of generating an unrememberable key which they pass in the clear, they used a standard algorithm for generating a unrememberable digest from a user's password which they then pass in the clear.

So far, so good, except for the fact that people are prone to emulate what Microsoft did in the creation of their own APIs.  Taking this into consideration, I would suggest the following two changes to the server implementation that should be both simple to implement that would make a big impact.

The first is to check that the Created time in the UsernameToken is within an hour either way of the current time on the server.  This would significantly limit the scope of replay attacks and only inconvenience those who's clocks on their clients were significantly skewed.  The implementation cost for this shouldn't be much more than a single if check and a raise statement.

The second involves adding a column to whatever table currently keeps track of the per-user usage of this service.  In this column, simply store the last used nonce for this user.  All I am suggesting here is that a check be added to ensure that nonces aren't reused consecutively.  Again, this significantly limits the usefulness of the most simplest replay attacks.  More importantly, it sends a message to the lazy clients who can't be bothered to get a random number.  As this particular row of the database needs to be read and written on a per service invokation basis anyway, the extra overhead of this check should be minimal.

Would either of these checks make the service absolutely secure?  No.  But these checks should be more than sufficient for protecting a free and readonly service IMHO.


RE: More noncense

<blockquote>
To recap what happened, apparently MsComServices had a need for a developer's token not unlike the Google API's license key.  Instead of generating an unrememberable key which they pass in the clear, they used a standard algorithm for generating a unrememberable digest from a user's password which they then pass in the clear.

So far, so good,
</blockquote>
Why so far, so good? With the technique the Google API uses any SOAP stack can talk to XML Web Service while with the WS-Security approach since so few stacks support it lots of people end up coding against it by hand. This would be "so far, so good" if WS-Security was actually used for security. It's not like using WS-Security actually saves lines of code in this instance over the Google approach even with WSE.

I said as much to Tim and the folks behind the Microsoft.com XML Web Service in email. They said the feedback will be taken into consideration when the next version of the sute comes out.

Bah, back to work. You XML Web Services people confound me.

Message from Dare Obasanjo at

XML Eye for the Object Guy

Sam notes that Tim Ewald is blogging again.  Tim is brilliant, passionate, and funny - and truthfully, the title alone makes his blog worth checking out.  Subscribed....

Excerpt from Glen Daniels at

Changes in the works...

More on WS-Security in Microsoft.com web services...

Excerpt from XML Eye for the Object Guy at

Changes in the works...

Sam welcomed me back to the blogosphere... Your points are well taken. People here are very aware of the fact that developers may well look to Microsoft.com's services as an example to emulate, so they try to make sure they do the right thing....

Excerpt from XML Eye for the Object Guy at

Changes in the works...

Sam welcomed me back to the blogosphere... Your points are well taken. People here are very aware of the fact that developers may well look to Microsoft.com's services as an example to emulate, so they try to make sure they do the right thing....

Excerpt from XML Eye for the Object Guy at

Changes in the works...

Sam welcomed me back to the blogosphere... Your points are well taken. People here are very aware of the fact that developers may well look to Microsoft.com’s services as an example to emulate, so they try to make sure they do the right thing....

Excerpt from XML Eye for the Object Guy at

Changes in the works...

Sam welcomed me back to the blogosphere... Your points are well taken. People here are very aware of the fact that developers may well look to Microsoft.com’s services as an example to emulate, so they try to make sure they do the right thing....

Excerpt from XML Eye for the Object Guy at

Add your comment