> Correct me if I'm wrong on my understandings. My proposal was to not store hashes (or plaintext passwords) in b) type records.
As far as I can tell, you believe that "surviving records" and "operational records" are two fundamentally different things which is, in fact, not the case. As I noted in a previous email, the "data print" command simply lists the "surviving records" as a convenience for readability. The only kinds of records which *actually exist* in the journal are the "operational records." To use an analogy, surviving records are to operational records as net income is to gross income. > For example, there could be cases where the instance is migrated from plaintext to hashed passwords. You should never store passwords in plaintext in any environment where security matters. If that happens, for whatever reason, there's not much the broker can do. It's up to users to properly configure their brokers. > Assuming that my understandings above are correct, operational b) type records will still contain plain text passwords for some time. If that happens you can run the "data compact" command to remove any stale operational records that contain the plaintext password(s). > 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 **** Passwords are stripped from the output regardless because passwords can potentially be stored in plaintext. We do the same in broker logs as well. Justin On Mon, Apr 4, 2022 at 3:52 PM Vilius Šumskas <[email protected]> wrote: > >> 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 >
