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" :)
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 microsoft.com webservices "login" is the reason for your confusion?
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.
Suggestions?
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 http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-security-addendum.asp 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.
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 Microsoft.com 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.
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?
Dare, you get it. Since the MSFT.com 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.
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.
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.
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.
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.
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.
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.
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.
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.
rich
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.
Replays?
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
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?
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?
I really loved reading your blog. It was very well authored and easy to understand. Unlike other blogs I have read which are really not that good.Thanks alot!
https://funnywifipuns.wordpress.com/2020/05/29/10-tips-for-making-your-wifi-broadband-faster/
https://tococadsmith.doodlekit.com/blog/entry/9207158/wifi-technology
https://getfunnywifinames.weebly.com/home/how-wifi-works
http://wifinamespuns.mystrikingly.com/blog/wifi-hotspot
http://rokayah874.simplesite.com/
https://5ee781837a912.site123.me/blog/wifi-optimize-your-wireless-network-in-five-simple-steps
https://funnywifinamess.yolasite.com/
https://getwifinames.hatenablog.com/entry/2020/05/30/120340
https://hercupcakementality.tumblr.com/post/619508551586643968/wifi-technology
http://coolssidname.over-blog.com/2020/05/improve-your-wifi-network-s-security.html