Tag Info

Hot answers tagged

16

Short answer: To prevent brute forcing the CSRF token. Let's take a trivial example: let's say your token is a single digit, accepting values from 0 to 9. Now sure, an attacker cannot read this value from the cookie or header, but she does not have to - she can just have the attack send 10 CSRF requests, one with each possible value. One of them will be ...


15

Reading bytes from a device can be troublesome (you have to account for syscall specificities, e.g. interrupted system calls) and can potentially be inefficient if reading many small chunks (a syscall has a non-negligible overhead). A custom software PRNG, seeded with bytes from /dev/urandom, gives more control over performance. (Also, there might be a bit ...


9

If you're asking why openssl rand or RAND_bytes() do not simply regurgitate /dev/random or /dev/urandom, it's because their function is to serve only as a PRNG, and they do exactly that: The rand command outputs num pseudo-random bytes after seeding the random number generator once. A correctly compiled and operating OpenSSL will read 32 bytes from ...


8

If the PRNG is cryptographically strong, then, by definition, its output cannot be distinguished from random bytes. That's the thought experiment by which a PRNG is supposed to be tested: two black boxes are given to the attacker, one implementing the PRNG, the other producing really random bytes (that one contains a gnome who throws dice real quick). The ...


7

A PRNG can be insecure for several reasons, but one of them is using as seed some data which can have only a limited number of distinct values. For instance, if you use the current time as seed, then that value is known to the attacker, or at least potentially known with a not-so-hard effort: even if you have an internal clock with microsecond precision, and ...


7

Hashing the output of a RNG is typically a component of making a cryptographically secure RNG, but it's not magic. It can't make a crappy RNG suddenly secure. A key component in a cryptographically secure RNG is absolute unpredictability. If you can predict the output, then you can use that prediction as part of your attack. Running the output through a ...


6

Unfortunately the previous answers given to this question, are not only wrong, but also quite dangerous. While it is certainly true that digital signatures usually involve hash functions, which by its nature are inherently deterministic, you should note that digital signatures are more than just a simple hash. They involve public key cryptography, which is ...


5

Hashing has no effect at all in increasing the security of a PRNG like rand(). In fact, if the output of the PRNG is larger than the output of the hashing function, it will decrease its security. sha(rand()) is, basically, security by obscurity. You're assuming that by making the PRNG output appear more random it will make it more secure, which is ...


4

Signing with RSA in OpenPGP is deterministic and thus does not require a source for randomness as you described correctly. Hashing the data to be signed is deterministic as long not padded with a random seed (see @Karol Babioch's answer for details why one might want to do so), signing the hash also is. Detailed discussion of the parts involved: RSA ...


3

It doesn't It just has to be pseudo random. CSRF is not compatible with brute force attacks. Consider the attack vector: Malicious user crafts a special email or web page with HTML that posts to the site of interest User is logged on to the site of interest, and the session ID is passed passively (it's a cookie) User is tricked into clicking the link in ...


3

A PRNG which lacks reseeding, prediction resistance, or whatever these people mean by "continuous testing", is not a PRNG. Not in cryptographic terms. Conversely, a good PRNG, like HMAC_DRBG, will be as good as Dual_EC_DRBG, actually better since Dual_EC_DRBG exhibits measurable biases, and is awfully slow. The only good point of Dual_EC_DRBG is the ...


2

(Note: I am not a cryptographer, I might be completely off-based with this answer. :P) I would take anything Sam Curry said with a bucket of salt. He has proven that he knows absolutely nothing about cryptopgrahy. Here is the full quote. The length of time that Dual_EC_DRBG takes can be seen as a virtue: it also slows down an attacker trying to guess ...


2

Technically, you improve the security a little, but to no useful end. Random numbers usually come from a pseudo-random number generator (PRNG) that is itself seeded with a random value. The purpose of the PRNG is to stretch the original seed to produce a very long output. Random numbers are usually invoked for two reasons: To create random-looking data ...


2

Part 1 No this is not secure, it would not be Semantically Secure (because Random() isn't secure) I would argue that it wouldn't be secure because a hash function reduces the entropy of its input. In other words a hash function usually has less than a 1:1 mapping of results to input, and it has a greater chance of colliding with prior inputs than the raw ...


2

The key should be the same size as the hash output. In your case you are using SHA-256 so you should use a 256-bit key (which equals 32-bytes that you mention). The HMAC algorithm is really quite flexible, so you could use a key of any size. However, if you only use a 128-bit key then there is no point using a 256-bit hash; you might as well use a 128-bit ...


2

The best way to generate random tokens for security purposes in PHP is using openssl_random_pseudo_bytes() to obtain some random bytes, and then bin2hex to make them printable. $token = bin2hex(openssl_random_pseudo_bytes(16)); You can safely use $token for your session identifier, CSRF tokens, etc.


2

This certainly looks like premature optimization. A fast CSPRNG on a modern Intel CPU will output between 500 MB and 2 GB per second. Even if you have a quite random game which requires 100 random bytes per second per player (I can't think of a typical casino game anywhere near that) a single core will be able to generate random numbers for ten million ...


2

In general, reasons to not use the random source directly as presented include: You may not require as many bits of entropy as you need bits. In this case, you can use the random bits to seed a pseudorandom number generator. This is most important when entropy is scarce (this constraint is becoming less relevant over time as dedicated hardware entropy ...


2

Combining the best of both answers: The token length needs to be proportional to the number of victims and the number of requests per victim. If an attacker convinces X victims to navigate to his page (by way of spam or phishing attacks) and each such page attempts Y different tokens then you need to protect yourself against 2x*y attacks. For example, if ...


2

Python provides the function os.urandom() to read bytes from the OS CSPRNG mentioned by Stephen Touset above. For the more appealing random module API, it also provides the class random.SystemRandom() that uses the same source. There's no reason to do anything more complicated. I already heard of ideas like reading allocated memory (if it was just ...


1

This depends on the platform. As a general case, you should consider using the OpenSSL bindings to use OpenSSL's RAND_* API. Do make sure to seed it correctly. Not reading the OpenSSL documentation will cause a security compromise on virtually all operating systems due to improper RNG seed. Even “big ones” have been bitten by this. On Unix-like operating ...


1

I accept this statement as true: Therefore if I have an AES-256 cipher and I know the key was generated using SHA-1 PRNG I only have to test 2^165 possible combinations, not 2^256. However, I question the assumption derived from it: This would appear to significantly weaken the cipher. It is not now, nor will it ever be physically possible to test 2^165 ...


1

Now that other PRNGs will be used... It's worth noting that with the exception of a few niche products, Dual EC DRBG wasn't previously used by anyone. At it's inception, independent researchers pointed out that this was a horrifically inefficient algorithm which produced an output that could be poisoned by a malicious actor. But for some hefty ...


1

What you miss by switching away from Dual_EC_DBRG for a deterministic random bit generator are Bias. The actual output is biased so there is an extra layer added to debias it. (Bias is a bad thing) Inefficiency. Dual_EC_DBRG is slow compared to alternatives. There are some very specific cases where you want something to be slow, but a DBRG is not one of ...


1

If the reason the functions are insecure is because you can exhaust the seed space after seeing a very small number of values, then this approach might give the sum of the number of seed bits of security, assuming the seeds were perfectly random. If the problem is that they have a short period, if the functions have pairwise co-prime periods then the period ...



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