[pwg]

> I should have said that the token file is several kb in size, about 1/20 of my vault size, and of course random noise.

None of which matters.

What matters as to whether an attacker can decrypt it is the algorithms used to encrypt the token.

[throwaway15908]

But an attacker can never tell if the current guess to crack the token is the right one. Its just random noise in the end.

[pwg]

You have not explained how the token relates to decrypting the vault.

You have also not explained how the vault is encrypted (I'm assuming it is encrypted somehow, otherwise an attacker simply downloads the vault and has your credentials).

You can't expect us to give you anything but generic statements if you don't explain how your system works.

[throwaway15908]

Ok, fine. I still dont feel comfortable, but here is the link.

https://github.com/proxemy/dotfiles/blob/master/scripts/toke...

The vault is regular kdbx with an additional password file.

Thank you for your time btw.

[pwg]

> I still don't feel comfortable,

No loss pointing out that you also publicly show the decryption script. If your system is not resilient against an attacker that knows everything, except the key, then your system would violate Kerckhoffs's principle (https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle).

But you still do not explain how this token relates to the vault, nor how decrypting the token is a necessary dependency to decrypting the vault.

[throwaway15908]

>how this token relates to the vault, nor how decrypting the token is a necessary dependency to decrypting the vault.

That is actually a good point i didnt fully understand myself, let me check ...

The only thing i could find quickly is https://keepass.info/help/base/keys.html

I dont know how these factors are combined. Damn. Ill keep digging. Thanks.

> Kerckhoffs's principle

An attacker from the outside needs to know 2 passwords, one for the one time decryption of the token and my master password for the vault every time.

EDIT:

Hashed. If a key file does not match any of the formats above, its content is hashed using a cryptographic hash function in order to build a key (typically a 256-bit key with SHA-256). This allows to use arbitrary files as key files.

From the link above. So my 8kb keyfile gets reduced to sha256 and used as an additional key. So this is not really a gain. A attacker does not need to guess all the random 8kb blobs, possible, just all sha256 hashes, just.

Any suggestions to overcome this reduction?

EDIT2:

There is no overcoming. When the additional key file is fixed length in the end, size of the token does not matter, its not that future proof is my conclusion.

I have to rethink this approach. Thank you so much.

[pwg]

> and my master password for the vault every time.

Are you using both a master password and the key file?

> Any suggestions to overcome this reduction?

Not and continue to use KeePassXC, as this is inherent in KeePassXC.

Ultimately, your method here relies on:

1) the security of the KeePassXC dbx file's encryption

2) whether there are any known exploits of KeePassXC files

3) whether there are any unknown (except to the attacker) exploits of KeePassXC files

4) the complexity of your 'master password' (if you use one)

5) the complexity of whatever password is used to unlock this 'token' (which is just a KeePassXC "key file").

If, by chance, you used "Password1!" as both your master password and token password, then an attacker is all but 100% certain to open your vault.

If your "password" is available in any of the breech lists, or can be deduced by a hashcat "try variations" run, then an attacker with the hardware, time, and desire would be able to open your vault.

If there is a known, or unknown (except to the attacker), CVE for KeePassXC that results in opening the vault, then you are at risk of having your vault opened.

Ultimately your resistance to attack here comes down to how resistant the KeePassXC vault is to attack.