Hi, I've attached the patch against trunk that shows what I'm talking about here. Should I raise a JIRA issue for this, or would you want to implement it differently?
Thanks, Nathan From: [email protected] To: [email protected] Subject: RE: Rampart: UsernameToken with stale timestamps Date: Wed, 6 Mar 2013 11:54:43 +1100 Hi, Thanks for your responses. I'm aware of the Timestamp element in the wsse:Security header, however my understanding is that it's only of value if it is signed (the blog post below confirms this). In the case where only a UsernameToken is provided and no signing is done, the Timestamp element doesn't stop replay attacks since an attacker could just change the Timestamp value freely. The UsernameToken profile gets around this problem by using a PasswordDigest along with the Created element in the UsernameToken. The Created timestamp is included in the digest with the password, which effectively makes the PasswordDigest a MAC on the UsernameToken element. An attacker cannot change the Created timestamp without knowing the password because the PasswordDigest would be incorrect. Therefore, I think that Rampart should perform the same validation on UsernameToken/Created as it does on the Timestamp. I'm happy to experiment with a patch to PolicyBasedResultsValidator to implement this. Note that I'm still new to WS-Security, so please feel free to correct me if my understanding is wrong. Thanks, Nathan > Date: Tue, 5 Mar 2013 11:14:55 -0500 > Subject: Re: Rampart: UsernameToken with stale timestamps > From: [email protected] > To: [email protected] > > Hi Nathan, > > I believe we already have this in Rampart. > Please see: > http://hasini-gunasinghe.blogspot.com.au/2012_02_01_archive.html > > Thanks, > Ruchith > > On Tue, Mar 5, 2013 at 1:22 AM, Nathan Clement > <[email protected]> wrote: > > Hi, > > > > I was wondering if there is any code in Rampart (or WSS4J) that rejects > > stale timestamps in UsernameToken elements? The WS-Security UsernameToken > > Profile says the following: > > > > It is RECOMMENDED that web service producers provide a timestamp “freshness” > > limitation, and that any UsernameToken with “stale” timestamps be rejected. > > As a guideline, a value of five minutes can be used as a minimum to detect, > > and thus reject, replays. > > > > > > If there's nothing existing to implement this recommendation, I can write a > > patch to implement this. I thought this could be done in RampartEngine > > after the "nonceLifeTimeInSeconds" is checked. I could use the same timeout > > period and reject any request with a Created timestamp older that this > > value. Is that the best place to implement this feature? > > > > Thanks, > > > > Nathan > > > > -- > http://ruchith.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
check_username_token_timestamp.patch
Description: Binary data
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
