It’s just data


Nonce is a funny word that plays a serious role in a number of security implementations.  Generating a nonce is easy - a random number or the current time or a combination of the two is sufficient.

However, the key to preventing replay attacks is for the recipient to ensure that no nonce is ever reused.  On face value, this is quite a serious obligation - forever is a long time.  In any case, requiring servers to manage application state is something that is generally to be avoided whenever possible.

One way to mitigate this cost is to institute expiration policies for nonces.  This does get you into the mess of requiring clocks to be synchronized.  Luckily, effective compromises can generally be found which allow most legitimate traffic through and prevent nearly all of the rest.

Here is a simple implementation that implements expiration and uniqueness using the file system.  There are timing problems whereby a single nonce issued simultaneously on two concurrent requests could conceivably be accepted.  However, this is relatively unlikely, and my design point was to err slightly on the side of permissiveness.  Engineering trade-offs and all that.

There are two, more serious, issues with nonces as a part of a security policy.

One is that the server obligation mentioned above can be exploited in a Denial of Service (DoS) attack.  Challenge based systems that involve issuing a nonce mean that unauthenticated users can cause nonces to be generated at will.  The storage and computational requirements of uniqueness checking are clearly related to the number of outstanding nonces.  Solutions which only track nonces after all the other authentication and uniqueness checking is complete limit the DoS exposure to authenticated users.

More serious is the requirement that the server and client both have access to a common secret, generally a password.  If you have an existing application which does not retain passwords in their original form, then either a new password is required, or some process or algorithm for generating a key based on the original password needs to be published.

On the plus side, nonces allow solutions to be deployed that can be as paranoid as they want to be.  Solutions with servers which chose to outright ignore the requirement to validate the uniqueness nonces they receive are still more secure than solutions that involve passing passwords in the clear.  Furthermore, implementations of policies to check for uniqueness and acceptable expiration periods can be added later without requiring clients to change one bit.

You know the first thing I thought of (even though I'm conversant in crypto protocols) when I saw nonce was in-fact the British sex-offender connotation.

I'm reminded of a sketch I saw about how perfectly innocent English words are being corrupted ... "Why in my day, a faggot was bundle of sticks - 'Throw another faggot on the fire' we would say" :)

Posted by Aaron Brady at

Your definition of nonce is a bit off. The intent is to prevent someone capturing a server's reply and re-using it. It is a means for a client to ensure that it got a "fresh reply" to its question.  Given that, there is no need for a server to store anything about a nonce -- i.e.,. no server state necessary.  Instead, the server just has to make sure that if there's a nonce in the request, the same nonce shows up in its reply; cf Kerberos and OCSP.

You seem to be conflating nonce with a security session token.

Perhaps the broken and insecure webservices "login" is the reason for your confusion?

Posted by Rich Salz at

One Time Password Generation

Sam Ruby started a discussion about what a nonce is – a topic particularly relevant to an idea I conceived just last night.... [more]

Trackback from Robert Hahn: Inspired by Integration


One Time Password Generation

Holy cow. I was just last night/this morning conceiving in my mind a web service for generating one time passwords (OTP's) that anyone can use. The way it would work is as follows: You need an OTP. You visit this site, which is running under https,...

Excerpt from Robert Hahn: inspired by integration at

Rich, from RFC 2617:

For applications where no possibility of replay attack can be tolerated the server can use one-time nonce values which will not be honored for a second use. This requires the overhead of the server remembering which nonce values have been used until the nonce time-stamp (and hence the digest built with it) has expired, but it effectively protects against replay attacks.

There undoubtedly are many other uses for nonces that I am not aware of.  As to brokenness, what I am interested in at the moment is easy to implement security mechanisms that are resistant to replay attacks.  Both the RFC 2617 inspired Atom API prototype and the Web Services Security UsernameToken seem to fit these requirements and are based on nonces.


Posted by Sam Ruby at

RE: Nonce

Actually I suspect it is the poor description of the purpose of wsse:Nonce in the WS-Security Addendum spec that may be misleading. I read and I found it fairly confusing to make head or tails of what they expect the purpose of the element to be. Quote

That is, concatenate the nonce, creation timestamp, and the password (or shared secret or password equivalent) and pass the digest of the combination. This helps obscure the password and offers a basis for preventing replay attacks. It is RECOMMENDED that timestamps and nonces be cached for a minimum of five minutes to detect replays, and that timestamps older than five minutes be rejected.

I get the bit about obscuring the password howver I don't see how anything in the above text or other text of the spec shows  how this is a basis for preventing replay attacks unless the server is expected to cache the wsse:Nonce values which just seems terribly infeasible.

Bah, what do I know about security I'm just an XML geek.

Message from Dare Obasanjo at

On second thought I guess it depends on what exactly is meant by caching the nonce values. If the client generates the same nonce values and the server just accepts them (which is what the XML Web Service currently does since the init string is hard coded in my version of the app) then I don't see how this prevents replay attacks. In fact, it seems to encourage them because you get this false sense of security.

Like I said, it isn't like I know much about XML Web Services or security but I am curious as to how it is supposed to work.

Posted by Dare Obasanjo at

The system can be improved by only storing successful nonces.

Server: nonce = (time.time(), hash(time.time() + privatesecret))
Client: nonce, hash(nonce, password)
[Server validates by recalculating the nonce, then the password-hash. Then it stores that this nonce has been used to prevent replay attacks.]

Does that make sense?

Posted by Aaron Swartz at

If you don't want to store anything at all, you can set a short time limit (e.g. 30 seconds) on nonce responses (validate by checking the time value) and while replay attacks can happen, the damage is minimized because they can only occur for 30 seconds minus the time it takes the user to send a response.

Posted by Aaron Swartz at

RE: Nonce

I think I get it. But doesn't this then depend on the fact that clients can generate cryptographically random nonce values? The problem I was seeing with the system is that lazy clients [such as mine that converts the XML Web Service to an RSS feed] are still vulnerable to replay attacks since they don't generate random nonces.

Message from Dare Obasanjo at

re: "they can only occur for 30 seconds"... wouldn't this depend on the assumption that the clients and server's clocks are sufficiently synchonized?

Posted by Sam Ruby at

Dare, you get it.  Since the WS stuff doesn't let you change the nonce it is a false sense of security.  (But cryptographically random is probably too strong; plain ole random is good enough.)

Sam as for the server side, why not just keep a map of known-good-digests-->expiration ?  When you get a digest, see if its tehre, and then check expiration.  Flush it or accept it.  If not in the cache, do your own calculation and then add to cache.

BTW, WS-Security got it wrong: password should be first to increase the cost of dictionary attacks and avoid SHA precomputation on the plaintext nonce/created.

Posted by Rich Salz at

Sam, no. The timestamp is issued by the server and validated by the server. It only requires the server's clock to stay coherent.

Dare, no, it only requires them to get fresh nonces from the server.

Posted by Aaron Swartz at

Rich and Aaron, unless I'm mistaken, with the current MsComServices implementation, it is the client that determines the nonce.  It is also the client that determines the timestamp.  It's not merely that the server allows you to change either... the server doesn't provide either.

Take a look at the implementation if you don't believe me.

Given that the digests that the server is receiving will be formed using an as of yet here-to-fore unknown nonce, I don't see how the server can cache what it doesn't know.

The changes that I see the MSCOM server having to make in order to prevent replay attacks:

All of these could be implemented without changes to the client.

Posted by Sam Ruby at

Ah! The reason these issues come up is because HTTP is stateless. The usual nonce protocol issues a nonce then waits for an immediate response with it. But since the client talks first in HTTP, that can't easily happen.

The MS protocol is clever in using the server-must-remember requirement to eliminate the server-speaks-first requirement. And it only requires valid nonces to remembered. I didn't realize this until Sam pointed it out; I was still thinking server-talks-first.

Ideally, there'd be some way to work a nonce exchange into HTTP somehow, but I don't see how to do it.

Posted by Aaron Swartz at

As a kid studying some older security literature, I learned that nonce meant "Number used ONCE". I wonder how that explanation evolved. I've seen it repeated since. It's too bad that I can't remember that old paper's name.

Posted by steve jenson at

Cookies show how to make HTTP non-stateless, as does the HTTP unauthorized code -- the server could respond with a nonce as the realm name, e.g.  The current scheme MSFT scheme is lame because it provides no security to the client while giving the illusion that it does. From a security perspective, the client might as well use a fixed string and most probably will. :( 

Sam, waht do you think of the second paragraph in my 16:12 comment?

BTW, the term for what the MSFT is using is really a salt, not a nonce.  Also note HTTP-Digest uses challenge/response with the server providing the nonce.

Posted by Rich Salz at

Rich, It is my expectation that clients that provide a fixed string will get a rude awakening at some point in the future when the server implements stricter policies than what are enforced at the moment.  Generating a "plain ole random" salt/nonce is not a very high bar, so I see no excuse for using a fixed string.

The second paragraph (server map of known digests) continues to make no sense to me in the context of a client originated salt or nonce.

Posted by Sam Ruby at

One more thing...

A point about my previous post......

Excerpt from XML Eye for the Object Guy at

The most unintentionally funny post I’ve rea ...

The most unintentionally funny post I’ve read on a blog for a long long time: Generating a nonce is easy I’m sure cryptologists are stony-faced. :)...

Excerpt from phil.wilson - a geek commodity at

More noncense

Tim Ewald makes an appearance back in the blogosphere, this time in a new home.  I've updated my blogroll.  Welcome back! The occasion?  To defend the use of a standard UsernameToken header in an application where all the bells and ...

Pingback from Sam Ruby: More noncense


Talking about "one time password generation" -- Has anyone heard of The Liberty Alliance? This alliance is AFAIK a group of companies that have created a project to make "single sign on" possible.

The idea is that companies join "circle of trust" where each company in the circle trusts every other company, and therefore give out their user database. They then of course get all the other companies' user databases in return. This way, users can sign into one application (not necessarily a web-application) in the circle, and are automatically signed into all applications belonging to the circle.

I've not read or heard much about this, but I think the idea sounds great, and if we could use this in technologies like Atom, it would be really neat.

I hate log-ons.

Posted by Asbjørn Ulsberg at

Isn't there some inherent dependency that the clocks between client and server have to been sync'ed up.  Since the client is responsible for the <Created> timestamp.

What happens if the timestamp is many 'x' hours forward in time?  Will the nonce live until 'x' hours + 5 minutes? It seems to me that client timestamp is only relevant to the digest and the server should control the definition of '5 minutes.'  I would hate to think that security of a server against a reply attack is dependent of on the client's ability to furnish a reliable timestamp.

Posted by Matt Long at

Could somebody clarify the distintion between a 'nonce' and a 'salt'? I'm afraid I don't understand. (I know this is an old discussion, but it is still the #1 result if I Google for 'nonce'.)

Posted by Robert Lowe at

I am not an expert (despite what Google may think), but here is what I understand.

What makes a hash function strong is it's one way nature... you can fairly straightforwardly compute a hash of a password, but given a hash, it is difficult to find the password which corresponds to it.

Such hash functions, however, can be vulnerable to a dictionary attack.  Precompute the hashes for every word in a dictionary, then if you get a passwd file containing hashes, you simply have to see if any of them match.  One match, and you are in.

Salts complicate this a bit.  This is a random string which is prepended to the password prior to hashing.  If you know the salt, you can still compute a dictionary, but by necessity you can't do this until you get the salt, and such computations would be specific to that salt value.

Nonces are values which are created and used exactly once.  Such values can make ideal salts, but can be used for other purposes.

Posted by Sam Ruby at

Stepping Stones to a Safer Blog

In the last few weeks, I've been hit not only by comment spammers, but a new player who doesn't seem to like our party: the crapflooders, people who use automated applications (you may have heard of MTFlood or some variation) to literally flood comments or trackbacks. At one point I was hit with over 1000 comments in one of my posts, another time over 500 trackbacks. If you add in rebuilds and email, this can be a stress on the web server. Not to mention...... [more]

Trackback from Burningbird


Sam, good explanation, thanks!

Posted by Robert Lowe at

One more thing...

Someone pointed out that signing a message wouldn't actually solve the all the issues Simon raised. It would stop someone from tampering with a message, but it wouldn't stop someone from replaying a message. You need to take additional steps to...

Excerpt from XML Eye for the Object Guy at

What's a Nonce?

The WS-Security standard defines the nonce. It is used to prevent replay attacks... [more]

Trackback from Ken Brubaker


One more thing...

Someone pointed out that signing a message wouldn't actually solve the all the issues Simon raised. It would stop someone from tampering with a message, but it wouldn't stop someone from replaying a message. You need to take additional steps to...

Excerpt from XML Eye for the Object Guy at

hi, i've thoroughly devoured your discussion of nonces and one time passwords. however, i'd like to know what u guys think : in terms of providing security for online payments for instance, how exactly could one use a nonce??
i ask this cuz one needs to both avoid replay attacks but as well authenticate the parties (mercant and customer) and also ensure non repudiation of the transaction. any information about how nonces have been used with regard to this?? plz let me know.


Posted by richard asiimwe at

Nonces can help ensure that transactions occur exactly once.  Non-repudiation typically requires digital certificates and digital signatures.

Posted by Sam Ruby at

The way I see things, it seems there's a pattern of needs (mainly security related) that never get addressed fully by using only one method of protection.

RFC 2617  3.1.4 (Limitations) says: "..The Digest authentication scheme described in this document suffers from many known limitations.  It is intended as a replacement for Basic authentication and nothing more.  It is a password-based system and (on the server side) suffers from all the same problems of any password system.  In particular, no provision is made in this protocol for the <u>initial secure arrangement between user and server to establish the user's password.</u>

Users and implementors should be aware that this protocol is not as secure as Kerberos, and not as secure as any client-side private-key scheme.  Nevertheless it is better than nothing, better than what is commonly used with telnet and ftp, and better than Basic authentication."

That's all you get folks, with Digest authentication... Better!.  Do you want best?  If so, then you need to use some other mechanism or system.

As for my own needs and whatnot, since I am in the process of developing a new-styled Web Server, I can do other things inside of the server that say Web Developers in general don't get to do using any one of the major Web Servers out there.

How I am addressing this replay problem is by joining my own Server-side Sessioning system (complete with its dynamic paths capabilities) with the Basic AND Digest authentication schema.

Nobody but the original client can do a replay in my web server because my sessioning system uses a dynamic path, and upon receipt of a request, the server checks the portion of the path that is unique to a particular session and verifies if that session is available to both the IP address of the client as well as its cached DNS entry that I store upon the first hit from that client and release after a period of inactivity.

There are very creative ways to shore up the inabilities of one system or another by combining the functionality along with other mechanisms.


Sure, if there's some hacker out there getting his jollies off on attacking a system, sure, that hacker than send as many requests as he/she wants to.  None of the replays will work for the hacker... Ahh, but you say that system performance is degradated by these requests?

Perhaps so.

Perhaps this is why I also have a mechanism that is checking for known methods of hacking a web server.  If I detect the possibilities of a compromisation underway, I lock that client's IP address and no other requests are responded to with Status 200 (ok).  :)  Instead I send out a 404 (not found) for any request thereafter.

Perhaps someone out there will scoff at this - denying service to a client, but it makes sense to me.  I have toyed with the idea of adding a Sleep(30000) or higher before actually responding with that 404, that, plus adding a feature that any subsequent hit from that client must wait for the hits in front of it to be sent first before the current hit in question is responded to.  This addresses the issue of the client opening a new connection to the web server due to client-side Keep-Alive mechanisms.

Perry Way

Posted by Perry Way at

WSE 2.0 generated policy and derived keys

While playing with the WSE Security Settings Wizard I discovered that the generated policy requires a DerivedKeyToken to be used to sign the messages rather than the original security tokens.  This is a good thing, but isn't obvious from...

Excerpt from benjaminm's blog at

NONCE : Web Services Security is Nothing BUT a whole lot of NONCEnse

Nonce is an interesting word. I have been seeing this word so much with WSE works that I swear I dream about it sometimes... I came across this: It’s recorded right back into medieval times but was originally created by mistake. It was at...

Excerpt from Softwaremaker at

Regardless of what one might (ab-)use it for, a NONCE is simply a Number that can only be used ONCE... hence: NONCE

Posted by AJ at

"Nonce" doesn't come from Number ONCE, but from the English expression "nonce word". The English word "nonce" means "now, in this moment", and the expression "nonce word" is for words that are unique in a language.  A synonym, "hapax legomenon", is used for Biblical studies -- words that only show up once in the Bible. Nonce words are problematic for translators since it's hard to know exactly what the word means -- you can't compare against other contexts, because there aren't any.

Posted by Evan Prodromou at

Blogger changed the API again

Sam Ruby talks more about nonce values and security.... [more]

Trackback from Lewies Blogs


Web Services and Propagating User Identity

Oftentimes, business critical web service interactions happen within the context of a user. User interactions with a web app might initiate communication (either synchronously or asynchronously) with web services deployed elsewhere. In such cases,...

Excerpt from at

Sam Ruby: Nonce


Excerpt from at

[linkfarm] Nonce is a funny word that plays a serious role in a number of security implementations

Nonce is a funny word that plays a serious role in a number of security implementations. - appears to be prey to bots - hopefully this will provide an answer[Add a comment]...

Excerpt from The Coffee Grounds at

One more thing...

Someone pointed out that signing a message wouldn’t actually solve the all the issues Simon raised. It would stop someone from tampering with a message, but it wouldn’t stop someone from replaying a message. You need to take additional steps to...

Excerpt from XML Eye for the Object Guy at

One more thing...

Someone pointed out that signing a message wouldn’t actually solve the all the issues Simon raised. It would stop someone from tampering with a message, but it wouldn’t stop someone from replaying a message. You need to take additional steps to...

Excerpt from XML Eye for the Object Guy at

HMAC Digest Update

A preliminary HMAC Digest draft is available as HTML, txt, and a diff. I’m not finished with this draft yet,......

Excerpt from at

Automatic Preview

Jacques Distler:  My required preview is a part of my spam prevention strategy, and is intertwined with my issuances of nonces and captchas; neither of which are typically seen... [more]

Trackback from Sam Ruby


Nonces are echoed back and forth to prevent reply attacks, but at the same time, they are only needed when synchronized clocks are not available. Why is this?

Can you help me explain the advantages and disadvantages of nonces to timestamps?

Posted by OD at

Nonces are echoed back and forth to prevent reply attacks, but at the same time, they are only needed when synchronized clocks are not available. Why is this?

Can you help me explain the advantages and disadvantages of nonces to timestamps?

Posted by OD at

In information technology, a nonce is a parameter that varies with time. A nonce can be a time stamp, a visit counter on a Web page, or a special marker intended to limit or prevent the unauthorized replay or reproduction of a file.
Because a nonce changes with time, it is easy to tell whether or not an attempt at replay or reproduction of a file is legitimate; the current time can be compared with the nonce. If it does not exceed it or if no nonce exists, then the attempt is authorized. Otherwise, the attempt is not authorized.

Posted by Majed at

well what is the method to validate the nonce. for example if
1- client is sending the request with nonce1 and
2- server is relpying the client with nonce2 along with nonce1. and then again in response
3- client is sending the nonce2.
what actually in these messages are happening? preventing from replay?
how in 2d step server is validating that nonce1 is coming from the legitimate user. cant it also come from an attacker??
please add comments

Posted by Ayesha at

Answer by Ethan Post for How do I prevent replay attacks?

I am new to some aspects of web programming but I was reading up on this the other day. I believe you need to use a Nonce ....

Excerpt from How do I prevent replay attacks? - Stack Overflow at

Answer by Ethan Post for How do I prevent replay attacks?

I am new to some aspects of web programming but I was reading up on this the other day. I believe you need to use a Nonce ....

Excerpt from How do I prevent replay attacks? - Stack Overflow at

We’ve recently released an opensource nonce library for PHP developers here: We would love testing and feedback if anyone is interested:
Thanks for the article.

Posted by Glenn Ansley at

Add your comment