Forum Discussion

MrC's avatar
MrC
Super Contributor
3 years ago

1PUX uuid values

In comparing a 1PUX export from a few weeks ago, to one today generated by the latest Mac beta, it appears the uuid values are in transition.

It seems you are now generally writing 26 lowercase alpha-numeric character values (the accounts->attrs->uuid is still uppercase). Even a TOTP "id" string which used to include a 32 char uppercase hex value is now using the newer uuid value.

My questions....

How is 1Password generating / tracking these 26 char alpha-nums within a vault, and how should I generate them in the converter suite to ensure no collisions when a user creates new items in a vault created by the suite?

I can certainly maintain a table to ensure uniqueness if these are truly random - but does 1Password also track these / vault to avoid collisions?

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Browser:_ Not Provided

betas

2 Replies

Sort By
  • MrC's avatar
    MrC
    Super Contributor
    3 years ago

    @Savanni

    That's what I needed to know, regarding import and the IDs. This tells me I'm safe doing the same thing, generating a random UUID.

    I've also already discovered that (all of?) the account->attrs and the "uuid" and "desc" attributes of the vaults->attrs are ignored, and can be empty strings. And this makes sense.

    As an example of the changes in recent betas, previously, a TOTP id used to look like:

    TOTP_A52DD85453964186AF69747BAB83E183

    Now, it looks like:

    TOTP_mctcwehrqryafn3opmyqkijrai

    So for I've discovered that all "id" and "uuid" values now use the 26-alphanum char scheme, including the prefixed the "id" for a totp (which includes the prefix "TOTP_"). The exception for me is accounts->atrrs->uuid, which was created a while ago, so retains the previous UUID format.

    The converter suite's UUID style has always been version 4 (RANDOM) UUIDs - 32 hex char values (like that shown in the TOTP_####) string above. That seemed to be correct when I implemented the UUID generator; only later did 1Password start generating new UUID's upon import (it used to be possible to update entries via 1PIF import, as the UUID value was retained - this was actually pretty handy, but I understand the reason for the change).

    Reviewing JSON and exports has shown that 1Password has been moving away from the 32 hex char to 26 char alphanums. Here you can see a portion of a somewhat recent record, that includes both versions:

    Thanks for your time and continued support.

  • Former Member's avatar
    Former Member
    3 years ago

    Hi, MrC. I'm not sure I understand your questions, but I'll answer the parts that I do understand so far.

    I am not aware of any transition in the UUID style, but it is not impossible. What I do know for sure is that every vault UUID must be unique within your account, and every item UUID must be unique within a vault. When we import from a file, we basically ignore the UUIDs. Brand new vaults get created, and then brand new items get created within those vaults, all with new randomly generate UUIDs. Internally, I believe that all we do is generate a random UUID, verify that it is in fact unique (within the necessary context), and regenerate if needed.

    I don't know what your suite does, though. Could you explain your questions?