mentallurg [
https://community.jboss.org/people/mentallurg] modified the document:
"JBoss Passwords - not secure, but recommended"
To view the document, visit:
https://community.jboss.org/docs/DOC-48166
--------------------------------------------------------------
Following article describes how the passwords in JBoss can be secured:
https://community.jboss.org/docs/DOC-17248
https://community.jboss.org/wiki/JBossAS7SecuringPasswords
The key point is however missing there: What benefits it gives?
*It is not secure! But why it is still recommended?*
We should clearly understand, that the eventual level of security provided by JBoss vault
is absolutely the same as in case of plain text passwords. First we will consider why
(because it may be not obvious). Then we will see why in spite of this there are some
benefits.
* h5. What is the purpose of the JBoss vault?
* The purpose is to prevent easy revealing of passwords used in JBoss configuration files.
Actually not only passwords, but any sensitive data
* h5. Why is it not secure?
* JBoss needs to be able to restore passwords without user input. If JBoss asked user for
password each time it starts, it would be secure, but not maintainable. It would be
impossible to guarantie high availability of servers
* It means JBoss should be able to restore passwords based only on resources available on
server, i.e. vault and key store
* If somebody obtains access to these files on server, he can easily restore encrypted
passwords, even without knowing any secret information
* Don't believe? See decryptor in the attachment. Start the application and provide
the data that you used in the <vault> section of JBoss config
* h5. But what's the reason to use it then?
* h6. Without vault
* Configuration of your application changes time to time. Sometimes you wish to restore
the state that was "10 changes before" the current. That's why you wish to
keep track of all changes. Where do you keep all previous versions? In an archive with a
secret password? Or in some secret repository? Not bad
* Then what you do if developers request your configs to analyze some problem? Do you
thoroughly check the configs and remove all passwords before sending files to devs? Have
you replaced all passwords? In all files you send? Ahh, OK, you use scripts. But are you
sure you have adjusted the scripts after one more datasource was added last month? OK,
you've done it
* Are you sure it was on this environment, for this staging server? Not different config
structure for another branch or stage?
* Are you sure each time? Of course this can work. But what is the price? How much headake
do you have each time?
* h6. With vault
* All passwords in your configs are encrypted
* You replace the original passwords in configs only once and dont't care any more
* You can share the configs with devs
* You can keep all versions of configs in a normal non-secret repository (svn, git). Many
people can access them (your devs, ops, admins, customer, your repo hoster like github or
bitbucket) without compromising security
* You "disclose" your configs AS IS. No need to remove passwords. No need to
warry each time if you have have overlooked any sensitive info
* You can automate backing up of all configs without compromising security
* The only thing you should care about is the key store. You should keep it apart from
your configs. But it is much easier. It is just a single file
* h6. Idea
* Basically we split the secret. One part is stored in config file. It is public. Another
part is the key store. Keep it secretly. Of course, everyone who has access to the key
store on your server can restore all the encrypted secrets. But you avoid the headake with
maintenance of your configs
* h5. Alternatives
* If you have a non-JEE application, e.g. based on Spring, you may want to use Jasypt. But
the level of security remains the same as with plain text passwords and the same as with
vault. It is only kind of mirror to the vault approach:* In the vault case the password
(for the key store) is public. It is masked, but actually is public. The actual secret is
being kept on server (the key store)
* In the case of Jasypt the public part (configs) is encrypted and cannot be restored
without a password. The secret is the password used to decrypt the configs. And this
secret is being kept on server (e.g. as an environment variable in a JBoss start script)
* In both cases configs can be made public and maintained easily, without compromising
security
* In both cases if someone has access to the server, the secrets can be decrypted without
much affort
*Conclusion*
With vault you don't get more security. There is no magic. But you get easily
maintanable configs, that can be disclosed without any risks.
--------------------------------------------------------------
Comment by going to Community
[
https://community.jboss.org/docs/DOC-48166]
Create a new document in JBoss AS 7 Development at Community
[
https://community.jboss.org/choose-container!input.jspa?contentType=102&a...]