intertwingly

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.