I found the db.conf file and was poking around. I found a line like this:
DB='xxxx' DBUSER='xxxx' MD5='*xxxmd5sumxxx' HOST='localhost' TYPE='mysql' CHARSET='UTF8' U_DISK='3' SUSPENDED='no' TIME='12:34:56' DATE='2020-01-30'
I just wanted to confirm that Hestia is not hashing passwords with MD5, right? I’m not sure what else that would be, but definitely something that I think needs rectification if that’s the case.
Also just found an entry in user.conf that implies MD5 password hashing.
hey @mredig and thanks for your feedback 
about your concerns: Hestia does not do any hashing by itself for the mysql or user passwords, but relies on the recommended inbuilt mechanism of each service and merely copies and stores the hashes from those.
doing this is needed mainly to be able to backup the accounts and restore them later on including the credentials (because the hash can be put directly in to the correct place obviously)
so for the mysql hashes you found, these are queried from the mysql/mariadb server and therefore in the same format that these servers use (which by the way is not MD5 ;-))
essentially the same goes for the user passwords, these are taken from /etc/shadow which are just the normal system user pw hashes (format of these nowadays usually are sha512 - again no MD5)
of course the permissions to access these Hestia files which contain hashes are restricted accordingly.
also one might argue, that Hestia could only grab the hashes, while doing the backup or so and we might consider that later.
however from my point of view that would not improve security at all, because you still need privilege escalation in any kind of scenario to access these files. once a potential attacker gained access to that level, he can query everything from the sources anyway
interesting reads on hashing algorythms:
https://blog.pythian.com/hashing-algorithm-in-mysql-password-2
https://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils
PS: forgot to add, for the naming MD5= it’s simply that - a name for a variable. though it might be misleading, it’s just historical grown and a lot of work to change it in all places (esp. with backwards compatibility in mind), hence it’s left at it is
Aha! Sorry for the slow reply, but that totally makes sense. Just legacy variable names at play, but proper security kept up to date. That’s a relief! I was worried I found a seam in what seems like a nearly perfect server setup! 