WTH: Protect content of secrets.yaml (or make it unnecessary at all)

:grinning::grinning::grinning::grinning::grinning::grinning: lol

1 Like

what about those salted hashes?

okay unhash this sha256 hash has for me, since you know how its hashed (its even unsalted):
967399e44eb8a89fce1bce833169137cd6b18a47f078c857f913199437437288

I mean seriously? Everyone knows that this is secure. Oh yea but sure lets keep storing our passwords in plaintext…

3 Likes

… if you know the ‘salt’ because you can read HA’s open source code, then you can crack the it. It’s not security, it’s fake security. Remember, HA is open source and the code is available for anyone to view.

the salt will be randomly generated. It can not be read.

But sadly hashing is only a method if you provide your password to check if its correct.

Another option would be to have the secrets encrypted, but the secret not stored anywhere. Enter it after a server restart and it will be kept in RAM.

Right, and those credentials are needed to log into whatever service you are using. An un-decryptable hash does not help in that situation. I.e. It needs a static known to HA “salt”.

And do you want to enter that info every restart? It’s the same issue. It’s all fake security at the expense of the user experience.

oh so if you knew the salt you could easily unhash a password? lmao i wanna see that.

Tbh i don’t need it, since i enter my LUKS password every restart.

:grimacing:

1 Like

Then why is this even a conversation? If you’re here just to troll, you can kindly stop.

FYI, we’d have to use encryption, not a hash. When I say hash, I’m referring to the output encrypted value, sorry if I wasn’t clear. We can’t use a hash because of what you’ve already pointed out.