question about kdb5_util dump format

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

question about kdb5_util dump format

Jerry Shipman
Hello,
I am trying to investigate a report from a user that he could change his password to the same value, despite password history being enabled.

I can an old copy of the users' principal (before he changed his password) from a backup.
I can dump both the old and new principals using kdb5_util.
The ciphers are the same. The kvno is incremented by one on the new principal. Realm is the same, master key version is the same, etc.
But the file sizes are different, and the encrypted key blob field is different and a different length.

If the key blob is different (for the same ciphers), does it for sure mean that the passwords are different? Or is it maybe salted with the kvno or something? (I thought the salt was predictable -- realm, or principal name, or nothing -- which would be the same for the different keys. And it would almost have to be the same, in order for the history to work?)

I don't understand this at all, but I sort of naively expected that all keys of a certain cipher type would be the same size. Why is the one larger? Maybe does it contain the old key history in there? or something else? (I know the key history is stored somewhere...)

Is there something reasonable I can do to definitively find out whether the user's old and new passwords are the same?

Thank you for the help,
Jerry




________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: question about kdb5_util dump format

Greg Hudson
On 10/26/2017 10:57 AM, Jerry Shipman wrote:
> If the key blob is different (for the same ciphers), does it for sure mean that the passwords are different? Or is it maybe salted with the kvno or something? (I thought the salt was predictable -- realm, or principal name, or nothing -- which would be the same for the different keys. And it would almost have to be the same, in order for the history to work?)

The key blob in the dump file is encrypted with the master key.  This
encryption is non-deterministic (it uses a random confounder), so the
key blobs in the dump file should pretty much always be different when
the key changes, even to the same password.  The size should generally
be the same, though, even if the passwords were different.  If the key
blobs are really of different sizes, I would be interested in knowing
the enctype

The salt is normally deterministic, unless the "special" salt type is
used.  The kvno is never included in the salt.

> I don't understand this at all, but I sort of naively expected that all keys of a certain cipher type would be the same size. Why is the one larger? Maybe does it contain the old key history in there? or something else? (I know the key history is stored somewhere...)

The key history is stored within a tl_data entry of type 3 (aka
KRB5_TL_KADM_DATA).  tl-data comes before key data in a dump record, so
you might be looking at that.

> Is there something reasonable I can do to definitively find out whether the user's old and new passwords are the same?

In principle one could (or could determine why kadmind can't tell
whether they are different), but we don't have the tooling to make it easy.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: question about kdb5_util dump format

Jerry Shipman
Hello,

Thank you for the help.

> The key history is stored within a tl_data entry of type 3 (aka
> KRB5_TL_KADM_DATA).  tl-data comes before key data in a dump record, so
> you might be looking at that.

Yes, that's what I was doing. The other blobs in there are the same size, just the first one isn't. Sorry for the misinformation.

I think it's not very important, and I can drop it.

Thanks again,
Jerry



________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos