cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Pell <>
Subject Re: CXF client send nonce and timestamp
Date Tue, 14 Oct 2014 10:27:13 GMT

Yes sorry I was thinking of man in the middle. I was not aware it was
possible to replay a TLS transaction. I think that is the only way a TLS
protected web service request could be compromised via replay is to attempt
to resend the TLS encrypted bytes.  However from some additional reading it
does look as though replaying TLS is not straight forward as TLS itself has
replay protection due to the way the hand shakes work.

Anyway I am not going to claim to be any kind of expert on TLS!

But nonce and digest username tokens are naturally replay resistent as the
nonce is part of the digested password valur .
 On 14/10/2014 6:09 PM, "Chris" <> wrote:

> Jason Pell wrote
> > As an aside having a timestamp and nonce with a username password does
> > notprevent replay attacks. Because attacker has all info to replay they
> > justneed to generate new timestamp and nonce and use existing
> > password.From what I read digest passwords are actually encoded with the
> > nonce valueso there is no way to reproduce the password as its one way.On
> > 13/10/2014 8:08 PM, "Chris" &lt;
> >
> > &gt; wrote:
> That's not the case with Oracle (or indeed CXF) servers. When you have a
> nonce and a timestamp the system will prevent the same nonec being used
> until the timestamp expires. See  Web Services Security 3 UsernameToken
> Profile 1.0
> <
> >
> :/103 Two optional elements are introduced in the  element to provide a 104
> countermeasure for replay attacks:  and . A nonce is a 105 random value
> that
> the sender creates to include in each UsernameToken that it sends. Although
> 106 using a nonce is an effective countermeasure against replay attacks, it
> requires a server to 107 maintain a cache of used nonces, consuming server
> resources. Combining a nonce with a 108 creation timestamp has the
> advantage
> of allowing a server to limit the cache of nonces to a 109 "freshness" time
> period, establishing an upper bound on resource requirements. If either or
> both 110 of  and  are present they MUST be included in the digest value 111
> as follows:  /
> --
> View this message in context:
> Sent from the cxf-user mailing list archive at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message