Following article describes how the passwords in JBoss can be secured:

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.

• 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

• 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

• But what's the reason to use it then?

  • 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?

  • 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

  • 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

• 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.