[
https://issues.apache.org/jira/browse/BROOKLYN-15?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14090616#comment-14090616
]
ASF GitHub Bot commented on BROOKLYN-15:
----------------------------------------
Github user aledsage commented on the pull request:
https://github.com/apache/incubator-brooklyn/pull/112#issuecomment-51587152
Thanks @sjcorbett - great comments. Was not sure about the automation
case. A `--password` is bad practice because it is visible to anyone doing
`ps`, and ends up in bash history etc. Reading from stdin is a little less bad.
A great discussion of this at http://stackoverflow.com/a/715681/1393883.
I'll add support for stdin to help user "circumvent 35 years of Unix
security"!
> web-console authentication: store hashed passwords in brooklyn.properties
> -------------------------------------------------------------------------
>
> Key: BROOKLYN-15
> URL: https://issues.apache.org/jira/browse/BROOKLYN-15
> Project: Brooklyn
> Issue Type: New Feature
> Reporter: Aled Sage
> Assignee: 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/brooklyn.properties file.
> However, the passwords in brooklyn.properties 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 brooklyn.properties file could have:
> brooklyn.webconsole.security.users=aled
>
> brooklyn.webconsole.security.user.admin.sha256=0dfecb1ab5426c781ec42e1c7cc98468975aed0dd28f9d9668237a9c7996862d
>
> Much longer term, we could consider using https://shiro.apache.org/ or
> equivalent (but that is out of scope for this feature request).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
