Often in smaller setups where a central authentication server is not used, organizations may wish to use "Check Point Passwords" to authenticate users (also called Internal Password or FireWall-1 Password).
These passwords are limited to 8 characters or less.
This is by design as it's best practice to use a centrally managed authentication source (like RADIUS/TACACS+ or even AD) and "Internal Password" is more meant for demos/testing.
However, some organizations do not want to maintain a central authentication server.
However, there is a little known feature that you can use to support longer, stronger passwords without resorting to a centrally managed authentication server.
That is to define users using "OS Password" authentication.
What that tells the gateway is to authenticate to the underlying OS (in this case Gaia), which supports longer, stronger passwords.
See screenshot below:
Obviously, you don't want to give typical users access to the WebUI of Gaia to review or change the configuration.
This is where Gaia's robust Role-Based Access comes in.
You should create a role that only allows them to do one thing: change their user account password.
Which is actually an enhancement compared to Check Point Passwords
Assign that new role to users as you create them.
Screenshot of what the role looks like in the Gaia WebUI below:
The main caveat to this approach is each (physical) gateway will need to have the user defined in Gaia.
This means in a cluster, both members will need to have the user defined (unless you're using Cloning Groups).
This also means, if you have multiple gateways/clusters, end users will need to change their passwords on each gateway/cluster.
NOTE: I've only done perfunctory testing of this, and it may have some other caveats that I haven't outlined here.
I recommend thoroughly testing this before you deploy in production.
Feedback is welcome.