Add better password hash algorithm

[duracell]

Is your feature request related to a problem? Please describe. As already mentioned in #1019 the current used hashes are not really good. sha256 is not made for using with password hashes. And yes, the salt (ssha256) helps against rainbow tables but not against brute-force. Until now SoGo was the problem, but as mentioned in the #1019 there is a PR and they'll support new hashes soon.

Describe the solution you'd like I would love to see a state-of-the-art hash like argon2id (which is a good hybrid between argon2i and argon2d) in mailcow.

[andryyy]

If someone gained access to your sql and read password hashes, you have other problems to worry about.

It's like googling every possible "how to secure Apache" guide and implementing every single line of configuration found in 200 blogs. If you don't follow it, your setup is insecure. :/

I also don't see how you cannot brute force it either. It just takes much longer, yes. But is it impossible? No.

I will gladly implement other hashing methods in the future, I really support that. But saying the setup is insecure because of salted s256, hm, no. I don't see that. Attackers to gain access to your hashes have already found their way into your system. There are so many other ways like giving your mobile to another person, let someone "quickly" use your computer, manipulated usb sticks etc. - the hashes are not what we should primarily worry about.

[duracell]

Where do I say anything about insecure. It is a really bad thing to put other people words in their mouth and then argue against them. And security is not a defined status, every step towords more security is better. And brute-forcing an sha256 hash is so much faster and easier/cheaper to do in hardware than an argon2id hash, that's the reason why everyone using salt and no md5 anymore, improvement. Why now stop and say "it's enough" if the recommendation is to do better? And support it early is also better, because then more hashes in the database will be stored in a more secure way, even if sha256 is broken.

And sql dumps happen, to tell there are "other problems to worry about" then the security of your passwords is really bad (and btw. illegal in the EU -> GDPR Art. 32) and only because someone can read stuff from your database does not mean they can manipulate the data.

[LuckyWraptor]

I do believe we should be able to select whatever hashing algorithm we want to use on either an appliance-level or a domain-level.

SSHA is fine, but as @duracell says, we can do better. Having a dynamic (scaling) algorithm like bcrypt, scrypt or argon to be scaled when the required resources become more mainstream should be a choice left for the admin to decide.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[duracell]

Okay, what's the status of this issue? Is this going to be implemented?

[patschi]

I'm pretty sure it will be merged when you file a well-tested PR for that.

[duracell]

As there is no interest from the developer to change this and as I'm not a developer and can't fix it, I'll close this.