I agree on your passion for this proposal.
I think it's more portable and secure
to provide common spec than to design security functions
in many app servers' own unique way.
Because password and encryption key management is difficult,
I think we need to discuss carefully.
(2012/03/10 4:02), 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.
>
> 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. If you think we should
> have password strength requirements for the keystore password, we could
> talk about that.
>
> 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.
>
> 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.
>
> 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".
>