>> Yes, hashes should be stored somewhere, e.g. in surviving records, but >> my point was about operational journal. > > I don't understand what you mean. The "surviving records" are *in* the > "operational journal." The "data print" command simply lists the surviving > records as a convenience > for readability. > > Can you clarify exactly what you mean by "operational journal"? Is that > different in some way from just the "journal"?
Sorry if my English is not that great, I will try to explain. You said earlier that when a user is created there are two types of records: a) surviving records which I suppose is this line: recordID=314669421;userRecordType=47;isUpdate=false;compactCount=0;PersistedUser [storeId=314669421, username=admin, password=****] b) operational records which as I understood is this line: operation@AddRecord;recordID=314669421;userRecordType=47;isUpdate=false;compactCount=0;PersistedUser [storeId=314669421, username=admin, password=****] Operational record repeats every time a user is added, deleted or updated. So for me a) is like a database storage for credentials, and b) is like an audit log how credentials changed during time. Correct me if I'm wrong on my understandings. My proposal was to not store hashes (or plaintext passwords) in b) type records. >> If hash is stored for some time and hash changes during that time can >> be >seen, I'm sure some clever mind will find a way to exploit this. > > Are you talking about if the algorithm used to hash the password is changed > during this time or just if the user changes their password and the hash for > that new password > is therefore changed? In any case, secure hash algorithms > are designed specifically for this kind of use-case (i.e. > storing passwords) so I would expect reverse engineering the actual password > from the hash would be difficult. For example, there could be cases where the instance is migrated from plaintext to hashed passwords. Assuming that my understandings above are correct, operational b) type records will still contain plain text passwords for some time. >> Artemis CLI already masks these hashes for some reason, no? :) > > I'm not sure what you mean. The hashed password is the *result* of this > process. A hashed password isn't then masked. The "mask" command available > from the Artemis CLI can be used for two different reasons: > 1. To hash the password. This is done for user passwords and is considered a > "one-way" operation. In other words, the original password cannot be derived > from the hash by design. > 2. To mask the password. This is done for configuration-based passwords, and > it is considered a "two-way" operation. In other words, the broker can derive > the original password from the masked value so that it can actually use the > password (e.g. for opening an SSL keystore, connecting to a database, etc.). > > The hash stored in the journal is the first kind. Again, I've probably chosen wrong word here. By "mask" I've meant that password hashes are stripped from the "bin/artemis data print" output. As you can see in my example journal records above, they are replaced with **** -- Vilius
