As the new password reset flow will be appearing in 2.1 and not 2.0.5 as originally planned, I have updated our password generation to use SecureRandom.

I have also updated xs:ID generation to use SecureRandom.

For xs:ID generation, it's quite simple:

SecureRandom r = SecureRandom.getInstance("SHA1PRNG");
r.setSeed(SecureRandom().generateSeed(20));

(You might have to catch NoSuchAlgorithmException and choose a suitable fallback.)

Let's quote:

A user could potentially reset their own password a few times in order to get some samples of the obfuscated Random output. It's probably computationally feasible to take the obfuscated output and work out the Random seed.

Thank you for noticing the attack I've described. It takes less than a day to run on an Atom 270.

The Crowd authentication layer should be responsible for preventing brute force attacks on login, thus there is no reason for this random password to be cryptographically secure

There is no reason for passwords to be insecure. If the intention is to disable login until the user clicks "reset password", the traditional way is to store an invalid password hash (in /etc/password this is "x" or "*"). Alternatively, 160 bits of /dev/urandom is probably "good enough".

If the crowd.properties file is not secure then you have bigger problems than guessing a user's password as you have total access to Crowd at that stage

The password is guessable from System.nanoTime() at which the XML backup was imported; on OSX this is actually gettimeofday() which has microsecond resolution. It seems unfeasible to prevent brute-force attacks on applications, so if I know the minute in which the XML backup was restored, I can hit the server with 60M requests and recover the Crowd password.

There is no reason for a "master password" to only have 48 bits of entropy.

... sets the token seed (really a salt) for use when producing Crowd SSO token values. The value is only accessible to Crowd administrators ...

You haven't said how secure it needs to be, so I'll assume that it would allow anyone to log in as anyone else.

The question is what else is hashed in the Crowd SSO token. My guess (I haven't looked at the code) is that it's used as MAC key, i.e. the user knows "user-visible data" and H(token seed, "user-visible data"). This lets the user brute-force the token seed. 48 bits is not secure.

As above, it is also guessable from System.nanoTime() at install time.

saml.Util: there is no need for cryptographically secure IDs. This requirement is specified in the SAML specs as referenced in the javadoc.

I didn't say it needed to be cryptographically secure. Let's quote SAML 2.0 Core §1.3.4: "In the case that a random or pseudorandom technique is employed, the probability of two randomly chosen identifiers being identical MUST be less than or equal to 2^-128 and SHOULD be less than or equal to 2^-160. This requirement MAY be met by encoding a randomly chosen value between 128 and 160 bits in length. The encoding must conform to the rules defining the xs:ID datatype. A pseudorandom generator MUST be seeded with unique material in order to ensure the desired uniqueness properties between different systems."

java.util.Random only has 48 bits of state. It cannot generate more than 2⁴⁸ outputs. You can expect a collision after about 2²⁴ (16.7 million is tiny!) outputs. It is seeded with System.nanoTime(), which is not guaranteed to be "unique" (Java 1.5 only tries to guarantee uniqueness within the same VM, i.e. if you write Random a = new Random(), b = new Random();, a and b should generate different values); it's probably feasible that different instances will be seeded with the same input.

There are no usages of RandomGenerator in Crowd. Without looking at actual usages in other products, it's hard to tell whether having a little less entropy breaks the implied security of the usage. If you do find something of concern then please raise a bug with the relevant product.

A "little less entropy" is not the problem; RandomGenerator has "password-generating" functions which generate guessable passwords. I'd remove it and see what builds broke; obviously you are in a better position to do this than I am.

We do treat security seriously at Atlassian and also with Crowd, and if a security vulnerability is found, (and they have been found), we will analyse that attack vector and protect against it accordingly.

If you do have a specific attack vector against Crowd, please let us know, e.g. you have found a way to programatically guess the next token used by Crowd.

You have raised an issue concerning the use of java.util.Random with password generation, and we agree that this is an issue. Shihab has spent considerable time over the last day looking at each specific usage of java.util.Random, and importantly where it used with regards to auto-generated 'random' passwords.

We agree that its use for password generation for user credentials is incorrect and in the upcoming release of Crowd (2.0.5) we are removing this ability (see: CWD-1875).

However, just removing all usages of java.util.Random from every part of every Atlassian products code base is both impractical and unnecessary. Each usage must be looked at on its own merits and analysed accordingly, and as noted Shihab has provided this analysis in detail. If a piece of code needs to be cryptographically more secure we will use SecureRandom.

Cheers,

Justin