Hot answers tagged

62

A nonce is a unique value chosen by an entity in a protocol, and it is used to protect that entity against attacks which fall under the very large umbrella of "replay". For instance, consider a password-based authentication protocol which goes like this: server sends a "challenge" (a supposedly random value c) to the client client shall respond by sending ...


24

From Wikipedia: An initialization vector has different security requirements than a key, so the IV usually does not need to be secret. However, in most cases, it is important that an initialization vector is never reused under the same key. For CBC and CFB, reusing an IV leaks some information about the first block of plaintext, and about any common ...


16

A 64-bit nonce is likely more than sufficient for most practical purposes, if the 64 bits are crypto-quality randomness. Why is 64 bits sufficient? Let me lay out the kind of reasoning you can use to answer this question. I'll assume this is a single-use time-limited URL; after it is used once, it is no longer valid, and after a little while (3 days, ...


15

From The First Few Milliseconds of an HTTPS Connection: The master secret is a function of the client and server randoms. master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) Both the client and the server need to be able to calculate the master secret. Generating a ...


14

You want to use a nonce when: you care deeply that a transmission not be submitted twice AND/OR you have reason to be afraid that re-transmission could occur by someone other than the authorized user, and that the ramifications of that will be bad Transactions where money changes hands is a good sample use case - I care deeply that I not buy the same ...


12

The "nonce" is better known as the Initialization Vector -- with "IV" being the universal short name for that concept. CTR mode works by encrypting the successive values of a counter (CTR stands for "CounTeR"), so the IV in CTR mode is merely the value at which the counter starts. CTR basically produces a long key-dependent pseudorandom stream, and ...


10

If the server uses the same nonce (called "server_random" in the SSL/TLS specification) and the same session ID than for a previous handshake, then an attacker can send the exact same packets than what the client sent during that previous session, and the server will accept the whole thing. At least if the server uses a RSA key exchange cipher suite (which ...


10

Within SSL/TLS, the nonces are used for generating symmetric keys, and as part of the signatures and checks during the handshake. For all those usages, the nonces are simply concatenated (with some other data) and hashed. Assuming that the hash functions behave like "random oracles" (the mythical perfect hash function), then unique nonces are sufficient. ...


7

Preventing form submissions from another source is a solved problem, and using a nonce is one of the recommended methods. For some background, there's a form of attack against web applicaitons known as Cross-Site Request Forgery (XSRF). A cross-site request forgery, in simplest terms, is when someone loads javascript on a malicious page that makes posts ...


7

To be effective, a salt should be random (unpredictable) and unique (thus, a nonce). It doesn't have to be very long (though that doesn't hurt). Your implementation is how a salt should be handled. However, bcrypt already includes a salt, so your efforts are a bit redundant. It definitely doesn't hurt anything, though.


6

If the server is stateless, whatever the clients sends to "get authenticated" can be replayed. An attacker only has to eavesdrop on a request by a client, and then can send his own request with the relevant header simply copied. An expiry date prevents the attacker from doing that indefinitely, but even if the attacker can wreck havoc within your server only ...


6

Normally, if I recall correctly, Bcrypt has it's own built in salt. So you don't need to define your own salt as Bcrypt generates salts when hashing and stores them with the output. From stackoverflow: Stored in the database, a bcrypt "hash" might look something like this: $2a$10$vI8aWBnW3fID.ZQ4/zo1G.q1lRps.9cGLcZEiGDMVr5yUP1KUOYTa 2a identifies ...


6

First, estimate the maximum amount of uses your system will get (the amount of times a random nonce will be generated). Next, decide on an acceptable security level, that is, how improbable it must be that a nonce is a duplicate of an old one. Calculate the amount of uses in bits, double that and add the improbability you need in bits and you have your nonce ...


5

As described in Thomas Pornin's answer cited in this question, the goal of the client nonce is to prevent a chosen plaintext attack in which the attacker impersonates the server and chooses the challenge. In such a situation the attacker can also choose the realm (since this comes from the server) so the fact that realm is hashed as part of the response ...


5

A random value. Usually as a hidden value in a form. Normally, we don't want the protocol that @Thomas described. What we want is for you to use SSL and hash the password on the server side. This prevents replay and blind submission (CSRF) attacks. If you've ever bought something online and seen a page at the end that says, "Don't refresh or resubmit this ...


5

Nonces do not require secrecy. The virtue of a nonce is to occur only once, not to be unknown to outsiders. The fact that the client random and server random are sent as cleartext does not prevent them from being "nonce". The actual "nonce" is the concatenation of the client and server random. This is explicit in several places, especially in section 6.3 of ...


5

The server should never allow a duplicate nonce. This is what protects from a replay attack. Someone can capture and try to re-send your message but it will be denied because that nonce has been recorded and can't be used again. If you have a timestamp and deny requests older than say 5 minutes, then you can clear cache of used nonces every 5 minutes. You ...


5

From the question: "because the request should not occur twice." No storage means no sense of history which is necessary for your requirement that something shouldn't occur twice. So the answer is no. If you want your server app to remember what happened in the past it has to be able to store that somewhere. You could implement a nonce that was ...


4

The goal of the attacker is to guess the password. By observing the authentication message, the attacker already learns enough to "try" passwords at home (i.e. an "offline dictionary attack"), but that's not what RFC 2617 is talking about at that point. Rather, it concentrates on the idea of an attacker who impersonates the server, and thus feeds "server" ...


4

What you want is format-preserving encryption. There is unfortunately no ready-to-use standard for that, but some reasonable constructions are known. I would recommend the Thorp shuffle which is an extremely unbalanced Feistel scheme; given enough rounds, this can implement a permutation which is close to the optimal (except that a Feistel scheme is ...


4

First things first. Your "hash" is actually a MAC, and a poor one because it fails to ensure security with usual hash functions (SHA-1, SHA-256...). Lookup the length extension attack for details. Basically, if you want a MAC then use a proper MAC, e.g. HMAC. Each HMAC call requires a couple invocations of the underlying hash function, one of them being on ...


3

Take a look at the Secure Remote Password protocol (wikipedia, Stanford). It uses a hash of the password (pick your favorite slow, salted hash) on the client side, but the server only gets a "verifier" derived from that hash by discrete exponentiation. The actual authentication takes place by an asymmetric key exchange using two random numbers (one ...


3

A salt must be unique. It does not have to be anything else (some password hashing algorithms have specific requirements on the length of the salt, but, in general, it is free-form). Uniqueness should be understood worldwide and for all centuries. Ideally. Being unique to your server is not totally sufficient (an attacker could try to attack several servers ...


3

Let me try to respond to the meat of your question: "Assuming for a second that the attacker doesn't want to engage in a man-in-the-middle attack and wants to recover the authentication details, how does a cnonce provide additional protection?" Typically a client not only includes a nonce with the request, but signs the entire request, including the nonce. ...


3

Although in your case the IV should be okay in plaintext in the DB, there is a severe vulnerability if you allow the user to control the IV. The IV in decryption is used (and only used) to XOR the first block into the final plaintext - so if an attacker can control the IV they can arbitrarily control the first block of data, and the rest of the plaintext ...


3

That section of the RFC is making some dubious claims, and isn't written all that well. Here's what I think it should have said. If you allow the attacker to control part of the input to a hash function, then you have to think about whether this enables chosen-plaintext attacks on the hash function. If the client didn't provide any nonce, then one might ...


3

The sentence you quote is about replay attacks. If two systems A and B run the protocol and B proves its identity by signing some data element x, then that value x must change in some way every time the protocol is played. Otherwise, if x is reused, then an attacker C may impersonate B, by first observing the protocol once (to get a copy of B's signature on ...


3

Am I right to say that this won't work if the password is not stored in plain text on the server? I fail to see how the server could verify the hash if the password is already hashed (with salt and pepper) on the server. This scheme does require the password to be stored in clear-text. Very bad. Can this scheme be extended to work with hashed ...


2

Your requirement is not very clear, I don't know what you mean by “A authenticating itself to B” (What does B know a priori about A? How do you test a successful authentication?), nor by encrypted challenge (encrypted by what). But the answer is probably no. Neither of these protocols guarantee that A sends the last message. Assuming that only A can produce ...


2

So A ----- says wants to contact B -----------------------> B A <---- encrypt some challenge with his private key ---- B A ----- decrypt the challange with B public key encrypt the challange with A private key encrypt the challange with B public key send both to B ------------------------------------> B decrypt the challange ...



Only top voted, non community-wiki answers of a minimum length are eligible