Tag Info

Hot answers tagged

42

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 ...


15

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 ...


13

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, ...


12

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 ...


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. ...


8

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 ...


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

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

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 ...


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 ...


5

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

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

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 ...


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

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" ...


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

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

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

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 ...


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 ...


2

the username and the realm (supposedly unique per server) This is not correct. The realm is a value specified by the service provider to describe the protection realm, so it's only a name, not a global identifier. In your second quote I think they refer to the "one-way-ness" of MD5 not being broken. The most effective way to find a preimage (i.e. go ...


2

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 ...


2

For this your main concern is making sure that the information is only accessible to the intended recipient; which sounds a lot like what public cryptography / PGP tries to achieve. Unless you want to see if the target non-user has a PGP key published, or if you can get his certificate to encrypt the email with his public key; I think you'd just need to ...


2

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 ...


1

A nonce is a "number used once". This is question is asking "should I use a the same value for my nonce each time". The answer is no. Start with a number which is not predictable, e.g. from a good random source. Edit 2: You gave the answer yourself. The nonce need not be kept secret. But the DH shared key must be. If you use the key for the nonce you ...


1

Yes, this is possible. There are two algorithms described here which both avoids the need to store plaintext-equivalents on the server (while making it possible to authenticate without the need to send plaintext password over the wire).



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