On 3/9/12 1:02 PM, Bill Shannon wrote:
> Jason T. Greene wrote on 03/08/12 22:42:
>> On 3/8/12 6:09 PM, Bill Shannon wrote:
>>> I've uploaded another proposal from our security team. Please review
>>> and give us your feedback.
>>>
>>> http://java.net/projects/javaee-spec/downloads/download/credential-ssl-config-ee7-proposal.pdf
>>>
>>>
>>>
>>
>> Frankly the whole idea of sticking private keys and password databases in
>> deployments seems like a major hazard. Developers are used to copying
>> these
>> around everywhere. I could easily see someone forgetting they have
>> sensitive
>> information in here. People also tend to use short and bad passwords in
>> keystores which makes bruteforcing a PKCS12 file not that difficult.
>
> Note that we *already* allow you to include clear text passwords in your
> code.
> That's nothing new. As always, you have to apply judgment when using these
> mechanisms.
Right but that is for development, quickstarts and tutorials. We are
talking about a mechanism intended for production credentials/secrets,
and *encouraging* it (the way to build a PAAS application).
>
> The point of this proposal is to allow you to include passwords in a more
> secure manner. The passwords would be encrypted, not clear, and the
> encryption password would be supplied separately.
It's not just passwords, we are also talking about private keys. If this
is being used for say SSL on a website, then an application is now
vulnerable to impersonation, which is far worse than credentials only
useful once the network has been breached.
> If you think we should
> have password strength requirements for the keystore password, we could
> talk about that.
That's certainly the minimum that should be done.
>
> Developers already complain that portability of their application suffers
> greatly once they have to deal with security. Every product provides a
> different mechanism for configuring securing, setting passwords, etc.
> It's impossible to write a tutorial that tells people how to write
> portable and secure *Java EE* applications because you quickly have to
> delve into the intricacies of configuring security for GlassFish or
> WebLogic or JBoss or WebSphere or ... Because of that, too many people
> just ignore security, or suffer from poor and inconsistent advice for how
> to secure their applications. We should be making it easier for people
> to write secure applications for the Java EE *platform*.
>
> Also, remember that we're targeting PaaS with Java EE 7. In a PaaS
> environment it's much less likely that you'll have direct control over
> the admin capabilities of the underlying app server. And there's
> probably not a system administrator that you can appeal to to set this
> up for you.
I am not sure this really improves usability. Let's say I am a developer
and I need to change a password to a database (recurring schedule,
reaction to a breach etc). Now I have to rebuild (including using a
burdensome toolchain) and redeploy my entire application?
Now contrast that to the PAAS provider doing a typical security
management web page, where you just edit the password to a known
alias/reference in the deployment, quickly generate a certificate
(perhaps even automate the process with a Root CA),
>
> Remember also that we're trying to create a platform that is both easy
> for developers to use when getting started *and* scales to enterprise
> deployments. If we *only* allowed things in the platform that made
> sense for large enterprise deployments, we would lose lots of developers.
> That's why we allow passwords to be included in applications at all.
> It's not because we expect large enterprise deployments to have
> applications
> with clear text passwords embedded all over them.
I certainly agree with the sentiment to make security easy. It just
seems like there is a better way than further encouraging packaging
within the deployment. Like for example, if a common transmission
mechanism is desired between PAAS providers, we could define a standard
for a *separate* security bundle file, which could be generated either
via tools, or the provider, and then then it becomes clear, that this
file needs to be kept safe.
>
> This new proposal tries to bridge the gap between developers and enterprise
> deployers by providing the convenience of bundling passwords with
> applications
> but doing so in a way that provides some security for those passwords.
> Rather than telling developers "don't include passwords in your
> application,
> you figure out what to do instead", we can tell them "here's a secure and
> convenient way to include passwords in your application".
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat