brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aled Sage (JIRA)" <>
Subject [jira] [Commented] (BROOKLYN-15) web-console authentication: store hashed passwords in
Date Thu, 07 Aug 2014 13:36:11 GMT


Aled Sage commented on BROOKLYN-15:

To summarise conversation on

Best practice is always to have 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

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.

> web-console authentication: store hashed passwords in
> -------------------------------------------------------------------------
>                 Key: BROOKLYN-15
>                 URL:
>             Project: Brooklyn
>          Issue Type: New Feature
>            Reporter: Aled Sage
> The brooklyn web-console can do user authentication - this can point at an enterprise
LDAP server, or can use the quick-and-easy username:password defined in the ~/.brooklyn/
> However, the passwords in are currently stored in plain text. Instead,
it should be hashed (using the username as a salt).
> I suggest we use SHA 256 for now. One can generate the password from the (linux / OSX)
command line with:
>     echo -n aled:mypassword | shasum -a 256
> In our code, we can then use guava's Hashing with something like:
>     Hashing.sha256().hashBytes(Charsets.US_ASCII.encode("aled:mypassword").array())
> (but note that UTF_8 is appending an extra `0` to the bytes, so gives a different sha256!
Is using US_ASCII going to be a bad idea?!)
> The file could have:
> Much longer term, we could consider using or equivalent (but
that is out of scope for this feature request).

This message was sent by Atlassian JIRA

View raw message