Hi, I created https://issues.apache.org/jira/browse/RAMPART-401 for this
Thanks, Nathan > Date: Sun, 17 Mar 2013 13:23:36 -0400 > Subject: Re: Rampart: UsernameToken with stale timestamps > From: [email protected] > To: [email protected] > > 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] >
