AbterCMS Team is aware of the problem with passwords, Zero Knowledge Proof, and Prof Bill Buchanan OBE’s post on the subject. We’re also aware of Vault by Hashicorp, Argond2 and Chacha20-Poly1305. These technologies may be incorporated before the first stable release of AbterCMS, but for the time being we will prefer a more traditional stack.
As hopefully everybody knows by now, the time of storing raw passwords is long gone. However, there are still billion dollar companies found guilty of this in 2019. (e.g Google, Facebook)
Hashing passwords with checksum algorithms like md5 or sha1 is also long gone, but both are still widely used. Many open source systems also base their security on them to this day.
Storing secrets in databases is one thing, but the list of companies that were found guilty in having raw passwords in logs is also staggering. (e.g. Github, Twitter)
Telling users to use various character categories is also close to useless in the age of password guessing tools.
Not all hope is lost though! Here’s our solution, heavily and proudly inspired by Florian Harwoeck’s “Password and Credential Management in 2018”.
Secrets and passwords are similar, but secrets are generated automatically and passwords are provided by the user. Passwords may also be generated automatically, but no AbterCMS implementations support this out of the box at the moment.
Secrets are generated with CSPRNG and passwords are checked with zxcvbn. Both have implementations for many languages to ensure that these choices do not limit AbterCMS implementations too much. Note also that both password generation and checking should happen on the client side, meaning that the JavaScript implementations should be generally enough.
Since secret generation happens on the client side, all clients must enable displaying the secret generated, and / or copying it to clipboard.
To encourage the use of password managers, AbterCMS implementations must play well with them.
Passwords and secrets must be salted and hashed on the client-side. In theory, any 512-bit hashing algorithm could be used on the frontend, but AbterPHP currently ships with SHA3-512 and that’s also our current recommendation. This means that the raw password never reaches the server, therefore it can not be logged by accident. It also means that the backend is not able to check password rules, that’s why those must be enforced on the client side.
To ensure that no default values are used, AbterCMS checks the frontend salt when run in a production environment.
To ensure that stored password and secret hashes can not be extracted, the backend spices the received hash with the backend pepper and hashes it with a KDF, PBKDF2 to be precise. Our current implementations use bcrypt as that is considered safe and widely available.
Before the derived key is stored however, we also encrypt it using a Symmetric Encryption. Our current implementations use AES256-GCM as that is also considered safe and widely available.
To ensure that no default values are used, AbterCMS checks the backend pepper when run in a production environment.