-
Sub-task
-
Resolution: Delivered
-
P4
-
10
-
Verified
The clear passwords present in the `jmxremote.password` file are now being over-written with their SHA3-512 hash by the JMX agent. Each line for the role follows the format:
*role_name W hashedPassword*
Where:
* *role_name* is any string that does not itself contain spaces or tabs.
* *W* = spaces or tabs
The hashed password follows the format:
*hashedPassword = base64_encoded_64_byte_salt W base64_encoded_hash W hash_algorithm*
Where:
* *base64_encoded_64_byte_salt* = 64 byte random salt
* *base64_encoded_hash* = Hash_algorithm(password + salt)
* *W* = spaces or tabs
* *hash_algorithm* = Algorithm string specified using a format in
https://docs.oracle.com/javase/10/docs/specs/security/standard-names.html#messagedigest-algorithms
This is an optional field. If not specified, SHA3-512 is assumed to be the algorithm string.
If passwords are in the clear, they are overwritten by their hash if all of the following criteria are met:
1. `com.sun.management.jmxremote.password.toHashes` property is set to true in the `management.properties` file.
2. The password file is writable.
3. The system security policy allows writing into the password file if a security manager is configured.
In order to change the password for a role, replace the hashed password entry with a new clear-text password or a new hashed password. If the new password is in the clear, it will be replaced with its hash when a new login attempt is made.
A given role should have at least one entry in this file. If a role has no entry, it has no access. If multiple entries are found for the same role name, then the last one is used.
A user generated hashed password file can also be used instead of a clear-text password file. If generated by the user, hashed passwords must follow the format specified above.
This file must be made accessible by ONLY the owner, otherwise the program will exit with an error.
In order to prevent inadvertent edits to the password file in a production environment, it is recommended that a read-only hashed password file be deployed. The hashed entries for clear passwords can be generated in advance by running the JMX agent.
It is recommended that the password file not be edited while the agent is running. Edits could be lost if a client connection triggers the hashing of the password file at the same time that the file is externally modified. The integrity of the file is guaranteed, but any external edits made to the file during the short period between the time that the agent reads the file and the time that it writes it back might be lost.
*role_name W hashedPassword*
Where:
* *role_name* is any string that does not itself contain spaces or tabs.
* *W* = spaces or tabs
The hashed password follows the format:
*hashedPassword = base64_encoded_64_byte_salt W base64_encoded_hash W hash_algorithm*
Where:
* *base64_encoded_64_byte_salt* = 64 byte random salt
* *base64_encoded_hash* = Hash_algorithm(password + salt)
* *W* = spaces or tabs
* *hash_algorithm* = Algorithm string specified using a format in
https://docs.oracle.com/javase/10/docs/specs/security/standard-names.html#messagedigest-algorithms
This is an optional field. If not specified, SHA3-512 is assumed to be the algorithm string.
If passwords are in the clear, they are overwritten by their hash if all of the following criteria are met:
1. `com.sun.management.jmxremote.password.toHashes` property is set to true in the `management.properties` file.
2. The password file is writable.
3. The system security policy allows writing into the password file if a security manager is configured.
In order to change the password for a role, replace the hashed password entry with a new clear-text password or a new hashed password. If the new password is in the clear, it will be replaced with its hash when a new login attempt is made.
A given role should have at least one entry in this file. If a role has no entry, it has no access. If multiple entries are found for the same role name, then the last one is used.
A user generated hashed password file can also be used instead of a clear-text password file. If generated by the user, hashed passwords must follow the format specified above.
This file must be made accessible by ONLY the owner, otherwise the program will exit with an error.
In order to prevent inadvertent edits to the password file in a production environment, it is recommended that a read-only hashed password file be deployed. The hashed entries for clear passwords can be generated in advance by running the JMX agent.
It is recommended that the password file not be edited while the agent is running. Edits could be lost if a client connection triggers the hashing of the password file at the same time that the file is externally modified. The integrity of the file is guaranteed, but any external edits made to the file during the short period between the time that the agent reads the file and the time that it writes it back might be lost.