Ask HN: Save, Public Password Vaults?

1 points by throwaway15908 3 years ago | 13 comments

I once got downvoted a lot by stating, that i have put my password vault in my public dotfiles repository.

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.

pwg 3 years ago |

> 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.

throwaway15908 3 years ago | |

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.

pwg 3 years ago | | |

> 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?

smoldesu 3 years ago |

> 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.

throwaway15908 3 years ago | |

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.

pwg 3 years ago | | |

> 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.