Hot answers tagged

436

I was one of the implementers of JScript and on the ECMA committee in the mid to late 1990s, so I can provide some historical perspective here. The JavaScript Math.random() function is designed to return a floating point value between 0 and 1. It is widely known (or at least should be) that the output is not cryptographically secure First off: the design ...


205

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


119

There's a quote for you in this crypto.SE answer, by Bruce Schneier in Applied Cryptography (1996), pp. 157–8. You can also find Bruce Schneier citing himself in his blog (2009), if you want an online citation. Here is the full quote, in case of the links breaking: One of the consequences of the second law of thermodynamics is that a certain amount of ...


116

Because there actually is a cryptographically secure alternative to Math.random(): window.crypto.getRandomValues(typedArray) This allows the developer to use the right tool for the job. If you want to generate pretty pictures or loot drops for your game, use the fast Math.random(). When you need cryptographically secure random numbers, use the more ...


76

Hardware vs software RNGs The first thing you mention is a hardware noise source. High-precision measurement of some metastable phenomenon is enough to generate unpredictable data. This can be done with a reverse-biased zener diode, with ring oscillators, with an ADC, or even with a Geiger counter. It can even be done my measuring nanosecond-level delays in ...


74

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


65

JavaScript (JS) was invented in 1995. Potentially illegal: cryptography was still under tight export control in 1995, so a good CSPRNG might not even have been legal to distribute in a browser. Performance: historically, CSPRNGs (cryptographically secure pseudo-random number generators) are much slower than PRNGs, so why use a CSPRNG by default? No security ...


55

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


53

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


46

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


45

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


41

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


39

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


38

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


35

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


35

First, there is no such concept as a cryptographically secure password. The aim of a password is to be hard to guess for an attacker and how hard it should be to guess depends on how the password is used: if the account is locked after three failed attempts the password can be more weak compared to when an attacker can try an unlimited number of passwords or ...


34

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


32

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


26

Let's take a different crack from a monetary perspective instead of a physics perspective. Skylar Nagao at Peerio stated that: In a 2014 research paper on password memorability, security researchers Joseph Bonneau (Stanford) and Stuart Schechter (Microsoft) estimated the cost of an attack based on the total annual payout to bitcoin miners in 2013. ...


25

General advice Any program written in Java Add -Djava.security.egd=file:///dev/urandom switch or -Djava.security.egd=file:/dev/./urandom to the command line invocation used to start the Java process. (Without this, Java uses /dev/random to seed its SecureRandom class, which can cause Java code to block unexpectedly.) Alternatively, in the $JAVA_HOME/...


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


24

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


24

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


24

Since you already brought up dropbox, I think we can give at least one reason why doing this is a bad idea: Dropbox disables old shared links after tax returns end up on Google The flaw, which is reportedly also present on Box, impacts shared files that contain hyperlinks. "Dropbox users can share links to any file or folder in their Dropbox," the ...


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


23

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

It's a hardware implementation that hasn't been tested formally, and it's proprietary. The potential worry is that Intel could have backdoored the implementation at the NSA's demand. The current way of mixing the rdrand output into the Linux kernel PRNG is that it's xor'ed into the pool, which mathematically means that there's no possible way for a weak ...


22

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

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


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


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