Ask HN: Save, Public Password Vaults?
14 comments
> So there is no possibility to brute force.
Brute force is the one option that is always available to an attacker.
What makes brute force untenable in most instances is the amount of time the attacker may need to wait for brute force to find the decryption key. And that amount of time is dependent upon the algorithms used and the amount of hardware an attacker is willing to devote to the brute force option.
An attacker that does not have access to your vault and token can try neither brute force nor look for cracks in the method you use to encrypt the token that might allow for decryption.
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.
State 1 (attacker does not have the vault or token) is lower risk than state 2 (attacker has access to the vault and token).
By storing your vault, and this token, in a public repository you have increased your risk. Whether the increased risk means your "locks" will be picked is unknown, but you are more at risk of having them picked than if you did not have your vault and token in a public repository.
Brute force is the one option that is always available to an attacker.
What makes brute force untenable in most instances is the amount of time the attacker may need to wait for brute force to find the decryption key. And that amount of time is dependent upon the algorithms used and the amount of hardware an attacker is willing to devote to the brute force option.
An attacker that does not have access to your vault and token can try neither brute force nor look for cracks in the method you use to encrypt the token that might allow for decryption.
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.
State 1 (attacker does not have the vault or token) is lower risk than state 2 (attacker has access to the vault and token).
By storing your vault, and this token, in a public repository you have increased your risk. Whether the increased risk means your "locks" will be picked is unknown, but you are more at risk of having them picked than if you did not have your vault and token in a public repository.
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.
> to look for cracks
Is not possible afaik.
> 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.
> to look for cracks
Is not possible afaik.
> I am not a cryptographer, so please keep that in mind.
What that says to someone who is a cryptographer is that there is almost a 100% chance there are "cracks" somewhere to exploit.
How does the token relate to the vault?
What that says to someone who is a cryptographer is that there is almost a 100% chance there are "cracks" somewhere to exploit.
How does the token relate to the vault?
> So there is no possibility to brute force.
Yet. The cost of copying it is negligable, which suggests there's probably someone collecting these from GitHub repos with the intention of cracking them someday.
So sure, you're "fine" for now. Maybe 3 years from now you'll log onto Hacker News and see the Chinese Shor's algorithm accelerator on the frontpage, though.
Yet. The cost of copying it is negligable, which suggests there's probably someone collecting these from GitHub repos with the intention of cracking them someday.
So sure, you're "fine" for now. Maybe 3 years from now you'll log onto Hacker News and see the Chinese Shor's algorithm accelerator on the frontpage, though.
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.
I am aware that future hardware or algorithms could bring down the cost of brute forcing it, thats why ive choose several kb size.
I am aware that future hardware or algorithms could bring down the cost of brute forcing it, thats why ive choose several kb size.
> 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.
None of which matters.
What matters as to whether an attacker can decrypt it is the algorithms used to encrypt the token.
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.
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.
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.
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.
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.
> 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.
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.
>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.
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.
> 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.
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.
And, just today, this floats across the HN front page:
https://news.ycombinator.com/item?id=34545010
Click through to the CVE and you will find this:
> 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.
https://news.ycombinator.com/item?id=34545010
Click through to the CVE and you will find this:
> 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.
[deleted]
What I should have told too, was that there is also a token file in place, that needs to get decrypted whenever I clone the repo to new a maschine. The file is encrypted in a way what no, eg. PGPs HMAC, makes the failure of decryption transparent. So there is no possibility to brute force.
To crack the entire thing, an attacks need to correctly guess my token password, which is not distinguishable from a failure. And once the attack got the correct one, crack the vaults password. But this stage is practically impossible to reach.
In public is my vault and the encrypted token file.
What I need to access my identities is the vault, the decrypted token, which has to be private at all costs and of course my password.
Should I be concerned? Should I add something or kill it instantly?
Its quite convinient, not tied to a provider and hopefully save. Yes, its also a big basket of eggs.