Clarkybox Hi there and welcome! There are many question combined here. I will try to go through it step by step:
- Putting a website including its content under version control is a very good strategy and this strategy is one reason why flat-file CMSs are so popular. However, in such a scenario, the public server is only serving and no one is supposed to edit content there since the content is pulled from GitHub. Therefore nobody should need to log in there hence the accounts file should be excluded from version control.
- Automad is designed to run also on cheap shared hosting servers where it is not possible to change the document root. Therefore the root of the repository is the document root and hence there are only public folders.
- There is no security risk for putting the accounts file into the public config folder because of the following reasons:
- The accounts file is a PHP file that will only return a blank page when accessed directly. Note that it is assumed that the web server is fully functional.
- In the very, very unlikely case that the web server is not functioning properly and for some obscure reason PHP files are treated as HTML files, the content will be visible. However, the file doesn't contain passwords. Only hashes are saved to that file. I will elaborate more below.
Saved Hashes and Algorithms
It is important to understand here how hashing algorithms work and what the differences between the different existing ones are. Some algorithms are optimized to be fast such as MD5 and therefore completely unsuitable for security related tasks. On the other hand, others, such as bcrypt, are as costly as possible in terms of time in order to simply slow down hashing to prevent brute force attacks. The ones in the account file are salted bcrypt hashes. In that sense it is practically impossible to brute force such a hash.
Rainbow Tables
Additional to a strong algorithm, the hashes are generated using a random and unique salt which is common practice today. Due to that fact, there is simply no chance that there is already somewhere a generated hash that would match your account out there. So the only chance to crack an account would be brute forcing it which is not possible as described before.
Conclusion
I understand that it seems to be a possible risk and for sure you shouldn't check in your accounts file to GitHub. But in order to steal your credentials from the accounts file that is hosted on your site, you have to be really unlucky to hit the 0.000001% where a web server serves randomly PHP files as plain text, which practically never happens, and the attacker needs a super computer additional to a couple of houndreds of years.
In the end there is never a 100.0% secure solution. It is about a balance between maintainability, the actual value of the target, security and comfort. If you want to improve the security of your dashboard beyond that, you should consider changing the dashboard URL as described in the docs.
I hope that helps answering your questions a bit.
Cheers!
