brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aled Sage <>
Subject Re: BROOKLYN-15: web-console authentication: store hashed passwords in
Date Tue, 01 Jul 2014 11:34:01 GMT
Hi Richard,

To summarise off-line conversation...

Best practice is always to have as permissions 600.

Therefore no-one can read this to find the username to create a rainbow 
The salt needs to be stored somewhere - e.g. as the first two characters 
of the user's password in the /etc/shadow when using a shadow passwords 
Therefore the salt of "aled:" is a reasonable salt, but could certainly 
be improved.

Given the problems of choosing the best character encoding, we probably 
want a Brooklyn utility to generate the passwords so that we *always* 
use the same character encoding.

We could support:

    brooklyn generate-password aled

Which could then output the text one would paste into the

The `brooklyn generate-password` could also complain if the permissions 
on were not 600.

Note the addition of the `.salt=...`, which means we can generate a 
random salt.

If moving to apache shiro, we could see whether this file format is 
consistent enough with that approach.
And if it's not, then we'd deprecate these options and 
delete them after two releases.


On 01/07/2014 10:49, Richard Downer wrote:
> Aled recently opened this Jira:
> While I agree with Aled's reason for opening a ticket for this
> feature, I think that the suggested way of doing it has weak security.
> The Jira ticket's suggestion is to generate a hash like this:
>      echo -n aled:mypassword | shasum -a 256
> and then add it to
> The problem is that the hash is unsalted. The "aled:" prefix is weak,
> because by inspecting I can deduce that the SHA256
> string will begin with "aled:" and generate rainbow tables using that
> prefix.
> I appreciate the intention to do something appropriate, fast, and then
> build in a more sophisticated system later; however I believe that
> unsalted hashes will not pass muster with a security audit, and once
> it has been added to Brooklyn, it will be troublesome to remove for
> fear of breaking existing installations.
> How about using the bcrypt password hasing algorithm instead? There's
> a Java implementation here:
> ...which is on Maven and ISC/BSD licensed, and appears to be pretty
> simple to use. It should be straightforward to integrate this.
> Any further thoughts? grkvlt, with your security auditing experience,
> do you have any comments?
> Richard.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message