clarkwinkelmann Well if you make a general security page with links where to report issues and mention bug bounty through huntr.dev etc. Then later on when you get an audit you can add it - but there should be no hurry there. Just start with what you have and where you are.
Passwords
I'm concerned with getting the password security right as well, so I'll have to see if I can extend Flarum to make it do what I want in accordance with NIST's guidelines (that's just a simple 3rd-party summary the real guidelines are here) and general best practise. A quick summary of the guidelines and status:
1. Set minimum length.
status: X ' This should be enabled in core.
2. Do not enforce complexity.
status: ☑
3. Allow password paste-in.
status: ☑
4. Do not enforce periodic password changes.
status: ☑
5. Salt and hash passwords.
status: ☑ Bcrypt
6. Allow to display password.
status: X ' This should be enabled in core.
7. Scrutinise passwords against a breached password database.
status: ☑ Pwned Passwords extension.
' This belongs in an extension as some people may wish to use
' a different breached password database
8. Do not use password hints.
status: ☑
9. Limit login attempts.
status: X ' This should be enabled in core.
10. Use Multi-Factor Authentication.
status: X
11. Encourage the use of a password manager.
status: X
12. Secure the database.
status: ☑
Flarum implementation
I think we're not far off from having great password security in core. Obviously you can't just slavishly follow NIST's guidelines, you have to strike a balance. Encouraging the use of password managers for example isn't the job of the forum software.
The problem with password security, or for that matter security of any kind, is that it isn't very intuitive to the average user (including the average forum administrator). This is why I feel it's import to get as may of the points above right as is reasonably possible in core so that on the default settings you're starting with very good password security and you make it easy for a forum admin to have great security following most of the best practise guidelines.
Points 1, 6, and 9 are the only ones I feel are missing in core. On point 1 you would set the absolute minimum length to 8 and then probably set the default setting to 12 characters. Why 12? Well most people are not going to implement breached password protection because as mentioned the benefit is not intuitive to them, and they probably think that the passwords are being shared with a 3rd-party with a risk to privacy (which is not the case). Point 6 merely requires a toggle button be added to password fields - it's not difficult and even Discourse has this in theirs. Point 9 - similar to point 1 a good default setting will assist the admins. If you make it too restrictive then people will get locked out after 5 attempts or something (I've experienced this many times when trying to cycle through different variations of what I think my password is for a particular site), so a good setting might be something like 20 failed attempts per hour per IP address. After the first 5 or so failed log-in attempts you should display the number of remaining attempts.
An even better way to implement point 9 in my opinion is rather than locking the IP address out, just enable the use of hCapture after 10 failed login attempts. But admittedly that would extension territory.
Email by login link is also a good idea, and customising the Passwordless extension enables this perfectly fine (though I don't like the default wording I prefer to use my own). In may not be in accordance with NIST's guidelines, but at the end of the day the security of a user's account lies with their email account - if someone hacks their email then they can potentially then hack any of their online accounts that are registered with that email address.
