I am not a cryptographer, so please keep that in mind.
> An attacker that does have access to vault and token is given the ability to try brute force and to look for cracks that might allow decrypting the vault.
My reasoning for the token is, that an attack has to brute force both, the token and _after success,_ the vault. But the token is just a random blob with no HMAC and in my public repo is a script that directly tells you, that you will always get a random blob – correct password or not.
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.
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.
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.
> 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.
> NOTE: the vendor's position is that the password database is not intended to be secure against an attacker who has that level of access to the local PC.
By storing your keepassxc file in a public repository you are providing an attacker access that is equivalent to a level of access for which the database is "not intended to be secure against".
This is why doing what you are doing is a very bad idea.
Unfortunately HN crowd is more and more resembling reddit communities, where emotional downvoting is a way to express themselves instead of maintaining well argumentative discussion. Doesn't surprise me anymore
Sure, it's possible but there are plenty of gaps where its random noise - but even a very very weak signal would be swamped with noise if the radio is in FM mode.
Pure radio static is the sound of the universe! Very frequency dependent - the higher up in frequency (or shorter the wavelength) the more of it is cosmic in nature - point a microwave radio dish towards/away from the sun and hear the difference, or even down towards the ground to hear the sky/earth noise. [1]
I personally find a clear spot between military submarine stations in the low frequency 10-60 KHz range quite relaxing to listen to as it's a mix of random noise and thunder static.
Wouldn't it be feasible to replace this "get your own domain" part just by letting tor doing the lookup for some introduced .onion site. My reasoning is, that this could get much faster adoption rates and/but is also self hosted on a single client device.
