[
https://issues.apache.org/jira/browse/HADOOP-12942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15202320#comment-15202320
]
Mike Yoder commented on HADOOP-12942:
-------------------------------------
{quote}
Otherwise, we just keep moving the problem.
{quote}
Oh, I agree. It's turtles all the way down. And you're right - as part of this
work I'm looking at where this is used (in the use case we saw, at least) and
how we can protect the password. I'm not sure we will be able to solve that
problem, though.
{quote}
more or less obfuscated
{quote}
I don't know if encrypting with the same hardcoded password meets the level of
even "obfuscation". :-) Of course, you could probably direct the same charge
against using a password that's easy to find.
{quote}
I would love it if you have an idea for something else.
{quote}
Yeah, me too.
I think that one of the problems I want to call out here is that the command,
as is, gives the user a false sense of security. Since there's no way to
obviously specify the credential provider password, it's easy for the user to
believe that whatever is going on behind the scenes is secure, because hey we
must know what we're doing. If our position is that the security of that jceks
file is no better than that of a plaintext file then I think we've done the
user a disservice.
I mean, let's imagine that the command outputted a warning saying "hey, that
provider you just used encrypted the file with a hardcoded default password".
Of course that will prompt the user to not be happy and demand a patch or
something. But at least we'd be up front about the issue. :-)
Better, I think, to do the right thing from the perspective of this command,
and then work on making the later consumers of the provider do "something". But
you're right, we have to think hard about end to end security with the
password. I don't know if we will have a really good answer, though.
> hadoop credential commands non-obviously use password of "none"
> ---------------------------------------------------------------
>
> Key: HADOOP-12942
> URL: https://issues.apache.org/jira/browse/HADOOP-12942
> Project: Hadoop Common
> Issue Type: Bug
> Components: security
> Reporter: Mike Yoder
>
> The "hadoop credential create" command, when using a jceks provider, defaults
> to using the value of "none" for the password that protects the jceks file.
> This is not obvious in the command or in documentation - to users or to other
> hadoop developers - and leads to jceks files that essentially are not
> protected.
> In this example, I'm adding a credential entry with name of "foo" and a value
> specified by the password entered:
> {noformat}
> # hadoop credential create foo -provider localjceks://file/bar.jceks
> Enter password:
> Enter password again:
> foo has been successfully created.
> org.apache.hadoop.security.alias.LocalJavaKeyStoreProvider has been updated.
> {noformat}
> However, the password that protects the file bar.jceks is "none", and there
> is no obvious way to change that. The practical way of supplying the password
> at this time is something akin to
> {noformat}
> HADOOP_CREDSTORE_PASSWORD=credpass hadoop credential create --provider ...
> {noformat}
> That is, stuffing HADOOP_CREDSTORE_PASSWORD into the environment of the
> command.
> This is more than a documentation issue. I believe that the password ought to
> be _required_. We have three implementations at this point, the two
> JavaKeystore ones and the UserCredential. The latter is "transient" which
> does not make sense to use in this context. The former need some sort of
> password, and it's relatively easy to envision that any non-transient
> implementation would need a mechanism by which to protect the store that it's
> creating.
> The implementation gets interesting because the password in the
> AbstractJavaKeyStoreProvider is determined in the constructor, and changing
> it after the fact would get messy. So this probably means that the
> CredentialProviderFactory should have another factory method like the first
> that additionally takes the password, and an additional constructor exist in
> all the implementations that takes the password.
> Then we just ask for the password in getCredentialProvider() and that gets
> passed down to via the factory to the implementation. The code does have
> logic in the factory to try multiple providers, but I don't really see how
> multiple providers would be rationaly be used in the command shell context.
> This issue was brought to light when a user stored credentials for a Sqoop
> action in Oozie; upon trying to figure out where the password was coming from
> we discovered it to be the default value of "none".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
