Hi Nathan, Please create a JIRA and attach the patch.
Thanks, Ruchith On Wed, Mar 6, 2013 at 7:56 PM, Nathan Clement <[email protected]> wrote: > 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] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] -- http://ruchith.org --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
