See this is where I don't see nonce as useful if connection is protected. TLS should be immune to replay attacks.
http://security.stackexchange.com/questions/23607/replaying-ssl-traffic-in-an-active-connection So this is why I was suggesting that a nonce is not useful if you are using username password My logic is that if you are using username password I am assuming you are also using TLS. If you are not using TLS then the username and password are in clear text and an attacker can use them to submit additional web service requests. So not classic replay. Whereas if you use digest and nonce even on a non TLS connection there is no way for an attacker to acquire your password and a replay wont work because of the replay protection. Perhaps someone like Colm can tell me if I have missed something obvious about nonce for non TLS non digest username tokens. And also how a nonce adds additional protection to a TLS connection which already has replay protection at the protocol level On 14/10/2014 9:27 PM, "Jason Pell" <[email protected]> wrote: > Hi, > > 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" <[email protected]> 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" < >> >> > [email protected] >> >> > > 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 >> < >> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf >> > >> :/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: >> http://cxf.547215.n5.nabble.com/CXF-client-send-nonce-and-timestamp-tp5749743p5749843.html >> Sent from the cxf-user mailing list archive at Nabble.com. >> >
