The process of encrypting a password is one-way, meaning that given an encrypted password you can’t run a process to get the original.
For an attacker to guess your password, they need to run a bunch of guesses through the same encryption process, and only when they get the same encrypted result they’ll know they have the correct unencrypted one. This is time consuming, so attackers may use rainbow tables[1] — essentially a list with a ton of precomputed passwords they can check. To counteract this you salt[2] a password, essentially adding random data to it. So now even if we have the same password, since our salt (random data) will be different, the resulting encrypted version will also be different.
Even if the attacker gets your vault and secret key, they’ll still need to brute-force[3] the password.
Ars Technica’s has an excellent explanation of all this[4].
For an attacker to guess your password, they need to run a bunch of guesses through the same encryption process, and only when they get the same encrypted result they’ll know they have the correct unencrypted one. This is time consuming, so attackers may use rainbow tables[1] — essentially a list with a ton of precomputed passwords they can check. To counteract this you salt[2] a password, essentially adding random data to it. So now even if we have the same password, since our salt (random data) will be different, the resulting encrypted version will also be different.
Even if the attacker gets your vault and secret key, they’ll still need to brute-force[3] the password.
Ars Technica’s has an excellent explanation of all this[4].
[1]: https://en.wikipedia.org/wiki/Rainbow_table
[2]: https://en.wikipedia.org/wiki/Salt_(cryptography)
[3]: https://en.wikipedia.org/wiki/Brute-force_attack
[4]: https://arstechnica.com/information-technology/2013/05/how-c...