Major
Nice to have
Bugfix
Major
Enhancement
Sorry, this is going to be a little novel, but I just want to put what I have learned somewhere:
TLDR;
In coordination with BHU, the current conclusion is to do without encryption, to store the passwords with salt+hash and to provide an opitonal "pepper" in the application configuration, with which one can restrict password hashes to the respective instance. The security gain of this option is questionable, so it would be disabled by default. Pwd hashes would thus be interchangeable among Top Logic instances, which would facilitate data sharing and infrastructure measures.
Lessons learned along the way:
Currently, user passwords of locally administered users are (hopefully) hashed and these hashes are then symmetrically encrypted with a key dynamically generated on the server (at first server startup). If the key is found in the file system at the next server start and successfully read, it will continue to be used, otherwise a new one will be generated.
So far so good - this makes Brutforce attacks or the use of Rainbow Tables more difficult. In particular, however, it is also not possible to simply copy the hash of a known password from one Top-Logic instance to another at database level in order to transfer the password. This additional encryption of the password hashes with a server-locally generated key can therefore possibly be used to argue for an additional security gain.
However, this is also kind of annoying, because you can't just deliver a root password or copy the data back and forth between different environments. Therefore this key was regularly delivered and deployed as "keyPair_signature.key". This destroys the previously described security gain, because now all instances use the same key again and the hashes become transferable.
Even worse: You *have* to deliver this keyfile, because a dynamically generated keyfile would be stored on the server in WEB-INF/database/keys and would be deleted with every new deployment and would have to be generated again: The stored password hashes would become invalid with every deployment.
This could also explain tickets about not working root passwords, if e.g. PROD data was copied to QS or simply redeployed.
Unfortunately, this (delivered) key is stored in the mentioned file as a serialized Java object. In the case of Prime / MPM, this no longer works with Websphere Liberty at the latest, because IBM JVM 8 cannot read in a key file serialized with Oracle/Sun.
So a problem arises now whenever the data (including stored password hashes) is to be transferred from one environment to another and the key we deliver does not work: The new environment would then use its own (new) key and thus could not decrypt the already stored password hashes. Therefore, the key of the previous instance would have to be transferred to the new installation:
- There is no standardized way to do this. This key is stored on the application server under web-inf/database/keys and cannot simply be read out. It would have to be copied manually to the new instance. This is difficult to organize for customer installations.
- Unfortunately, this key was stored as a serialized Java object, so even if you copy the file to the new environment, there is no guarantee that it can be deserialized with the new JVM.
Specifically, there is only one strategy for moving Prime and MPM to Websphere Liberty:
- We provide a key file (as a serialized Java object) for the target environment IBM JVM 8 and deliver a suitable hash for the root password as part of the data migration. With this you can log in as root after the migration and then you have to reset the passwords of all other database users. Disadvantage: If we include the key file, the same key is used on all instances, i.e. the password hashes would be interchangeable between instances.
The key file for this target environment must be supplied with all subsequent deliveries (as it was before).
The use of the previous key file is ruled out because IBM JVM 8 cannot read this file and the dynamic generation of new keys in the Liberty environments is ruled out because these would be deleted and regenerated with each deployment.
Future possible solutions for Top-Logic. How to do it right?:
Continue to encrypt password hashes? If you want to keep encrypting password hashes, you should at least persist such a key in a form that in principle allows it to be transferred to another environment. A simple text file is good enough. In the above scenario you could copy it into the new environment and the already stored password hashes would still be valid. Currently it's just the serialization of a Java object that can't be deserialized in the target environment (depending on the JVM used).
Password "switching"? And not encrypt them? But you can also do without encrypting the password hashes. Instead, passwords should (anyway) be hashed with a salt and the hashes should be stored together with the salt in the database.
Additionally "peppering" passwords? To prevent the successful transfer of such hashes to other Top-Logic instances, one could additionally "pepper" the passwords. Such a "pepper" would be valid for one server instance at a time and persisted in some way (preferably not in the same database as the password hashes). The application configuration would be a candidate. This "pepper" then goes into all PWD hashes of this instance. This prevents these hashes from being used on any other instance. This causes the same problems as described above, when moving to a new environment with transfer of previously stored password hashes. It would now have to be possible to ensure that the new environment uses the same "pepper" as the previous one, so that the stored hashes can continue to be used. The use of a "pepper" could be optional and simply disabled by default. Actually, the idea is quite nice: this way, password hashes could be interchangeable between multiple Prime instances of a customer (all using the same pepper), but not with other Top-Logic apps such as MPM, nor with instances of other customers.
Implementation
The ability was created to hash the password using the Argon2 algorithm(https://github.com/P-H-C/phc-winner-argon2). This uses a "salt" and a "pepper" can be configured in the application configuration.
Test
TestArgon2Hashing