BROOKLYN-15: web-console authentication: store hashed passwords in brooklyn.properties

[Richard Downer <ri...@apache.org>]

Aled recently opened this Jira:
https://issues.apache.org/jira/browse/BROOKLYN-15

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 brooklyn.properties:
    brooklyn.webconsole.security.user.aled.sha256=0dfecb1...

The problem is that the hash is unsalted. The "aled:" prefix is weak,
because by inspecting brooklyn.properties 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:
http://www.mindrot.org/projects/jBCrypt/
...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.

Re: BROOKLYN-15: web-console authentication: store hashed passwords in brooklyn.properties

[Aled Sage <al...@gmail.com>]

Hi Richard,

To summarise off-line conversation...

Best practice is always to have brooklyn.properties as permissions 600.

Therefore no-one can read this to find the username to create a rainbow 
table.
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 
file.
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 
brooklyn.properties.

    brooklyn.webconsole.security.users=aled
    brooklyn.webconsole.security.user.aled.salt=FWd
    brooklyn.webconsole.security.user.aled.sha256=0dfecb1...

The `brooklyn generate-password` could also complain if the permissions 
on brooklyn.properties 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 brooklyn.property options and 
delete them after two releases.

Aled


On 01/07/2014 10:49, Richard Downer wrote:
> Aled recently opened this Jira:
> https://issues.apache.org/jira/browse/BROOKLYN-15
>
> 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 brooklyn.properties:
>      brooklyn.webconsole.security.user.aled.sha256=0dfecb1...
>
> The problem is that the hash is unsalted. The "aled:" prefix is weak,
> because by inspecting brooklyn.properties 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:
> http://www.mindrot.org/projects/jBCrypt/
> ...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.