Hot answers tagged

140

The short answer is yes. The long answer is also yes. /dev/urandom yields data which is indistinguishable from true randomness, given existing technology. Getting "better" randomness than what /dev/urandom provides is meaningless, unless you are using one of the few "information theoretic" cryptographic algorithm, which is not your case (you would know it). ...


56

It depends entirely on what you mean by "safe". If your only concern is an attacker guessing URLs, then 16 alphanumerics gives roughly 8,000,000,000,000,000,000,000,000 possible addresses, which is plenty to stop random guessing -- in order for an attacker to have a 50% chance of finding even one picture on a site with a thousand users in a year, they'd ...


49

It depends on what you mean by "readable". If you want to use only hexadecimal characters, you will need 32 of them to reach 128 bits of entropy; this line will work (using only commands from the coreutils package): head -c16 /dev/urandom | md5sum This variant produces passwords with only lowercase letters, from 'a' to 'p' (this is what you will want if ...


39

You should use /dev/urandom, not /dev/random. The two differences between /dev/random and /dev/urandom are (I am talking about Linux here): /dev/random might be theoretically better in the context of an information-theoretically secure algorithm. This is the kind of algorithm which is secure against today's technology, and also tomorrow's technology, and ...


39

Human brains are poor RNG. People are bad at generating random values in the privacy of their heads. They just cannot think randomly; though they can convince themselves that they do. Physical process, on the other hand, are rather good sources of entropy. Take your mouse movements. A few dozen times per second, the mouse measures how far it has moved since ...


32

Both OpenJDK and Sun read from /dev/urandom, not /dev/random, at least on the machine where I tested (OpenJDK JRE 6b27 and Sun JRE 6.26 on Debian squeeze amd64). For some reason, they both open /dev/random as well but never read from it. So the blog articles you read either were mistaken or applied to a different version from mine (and, apparently, yours). ...


32

Using a camera as random source is a good idea (not a new one, but still a good one). However, you should do it correctly: take the photo, then hash it with a cryptographic hash function, e.g. SHA-256. Then use the output as a seed for a cryptograhically secure PRNG to generate as many random bytes as you need. Using the file size will yield only very few ...


27

Are they safe enough for the purposes you described? In my opinion, generally yes. Are they safe enough in applications where security is a significant concern? No. They're generated using a non-random algorithm, so they are not in any way cryptographically random or secure. So for an unsubscribe or subscription verification function, I really don't ...


26

A salt and an initialization vector are mostly the same thing in the following sense: they are public data, which should be generated anew for each instance (each hashed password, each encrypted message). A salt is about being able to use the same password several times without opening weaknesses; or, if you prefer, preventing an attacker from sharing ...


25

The UUID specification details several "versions" which are methods for generating the UUID. Most are aimed at ensuring uniqueness (that's the main point of UUID) by using, e.g., the current date. This is efficient but means that while the generated UUID are unique, they are also predictable, which makes them inadequate for some security usages. The "...


25

So is the concatenated random number better than a single random number? If the random generator really produces random data then it will not matter. ... it would be harder to predict the next number in case there was an issue with the random number generator. If the issue is that the random generator is not that random at all then it might even be ...


23

Yes. There are extremely efficient ways to break a linear congruential generator. A linear congruential generator is defined by sn+1 = a sn + b mod m, where m is the modulus. In its simplest form, the generator just outputs sn as the nth pseudorandom number. If m is known to the attacker and a, b are not known, then Thomas described how to break it. If ...


23

You are creating something called "entropy". Random number generators within computers can, if implemented within software, only be at best pseudo-random. Pseudo-random number generators (PRNG) start with a seed. If the seed is well-known, then anyone with knowledge of the PRNG algorithm can derive the same values you derived (this is actually really good ...


22

If there is no real need for security, then here is a very fast serial number generator, with a checker: User a counter. Initialize it at 0. When you want a new serial number, increment your counter by 1000; the new counter value is the serial number. The checker works like this: a serial number is valid if it ends with three zeros. Only one of every 1000 ...


22

Here is the cryptographer's point of view. The person you quote says: "you don't need a cryptographically secure PRNG", but what he actually claims is "when I use MT 19937 and do some mumbo-jumbo such as throwing away a large part of the output, it somehow becomes a cryptographically secure PRNG". His comment about storing "(219337-1)*4 bytes for lookup" is ...


22

Maybe not the answer to your question, but if you would like to "hide" the location of your profile pictures on a website, you could just embed the image as data URIs. You can base64 encode the image on your server and embed the string on your website, instead of exposing any image paths. see http://css-tricks.com/data-uris/ and http://css-tricks.com/...


21

Some fab suggestions in the other answers. I find that makepasswd is not available everywhere, and using tr is (slightly) tricky, so there's another option using OpenSSL: openssl rand -base64 16 The number is the number of bytes of randomness - so 16 bytes for 128-bits of entropy.


21

"Random" means: "that which the attacker does not know". The important point to understand is that attack costs are always on average. They don't make sense on a single data point. An attacker may always get lucky and find the right password on his first try. This is merely improbable. If you generate passwords as sequences of purely random characters, ...


20

You can feed it with white noise from your sound chip, if present. See this article: http://www.linuxfromscratch.org/hints/downloads/files/entropy.txt


20

(Caveat: I certainly don't claim that HAVEGE lives up to its claims. I have not checked their theory or implementation.) To get randomness, HAVEGE and similar systems feed on "physical events", and in particular on the timing of physical events. Such events include occurrences of hardware interrupts (which, in turn, gathers data about key strokes, mouse ...


20

Indeed, Math.random() is not cryptographically secure. Definition of Math.random() The definition of Math.random() in the ES6 specification left a lot of freedom about the implementation of the function in JavaScript engines: Returns a Number value with positive sign, greater than or equal to 0 but less than 1, chosen randomly or pseudo randomly with ...


18

It does add one significant thing. If they steal the database, they have the username, per-user random salt, and hashed password. But they still don't have the original password. To reverse the hash, they will generally have to do a significant amount of separate work for each user. Without any salt (a very bad idea, as LinkedIn learned), attackers can ...


17

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


17

"Entropy" is a measure of what some data element could have been. We say that we have n bits of entropy in a bunch of bits if those bits could have, collectively, assumed 2n distinct values with uniform probability (there is a whole lot of complexity which hides under the "uniform" term). To make a cryptographically secure PRNG, you have to: Gather enough ...


16

What SecurID tokens do is not completely public knowledge; RSA (the company) is quite wont on releasing details. What can be inferred is the following: Each device embeds a seed. Each seed is specific to a device. The seed of a device can be deterministically computed from a master seed and the device serial number. The serial number is printed on the ...


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

Yes, it's a great way. @Thomas's explanation nails it. And he is completely right to criticize the /dev/urandom man page. Spot on. But skip "checking if it already exists". That check is pointless. It ain't gonna happen. (The chances of that happening are lower than the probability of being struck by lightning -- multiple times -- in the same day.)


15

The point of randomness is to gather entropy. Let's take an example: I choose my password from the 4 first digits of the website plus the character ! and a number consisting of the ASCII number of the first letter. Example: PayPal -> payp!70 ; amazon -> amaz!65 The entropy of this password is 0. Because the method is always supposed to be known, and ...


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


15

Entropy is required in the following sense: if a PRNG has only n bits of entropy, then this means that it has (conceptually) only 2n possible internal states, and thus could be broken through brutal enumeration of these 2n states, provided that n is low enough for such a brute force attack to be feasible. Then things become complex, because the "entropy ...



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