Repository navigation
Replies: 1 comment 1 reply
|
@ahus1 while NIST 800-63B serves us as good reference for password security practices, fully implementing its specification sounds outside of scope from my point of view as it may overlap with features already provided by modern password managers, which handle tasks such as breach checks, dictionary-based password blocking, pattern detection, and filtering of context-specific terms. As an alternative Keycloak could provide built-in password policies by offering presets that encourage high-entropy passwords and guide administrators through best practices—without requiring deep security expertise. Inspiration for this can be found in Dropbox’s zxcvbn estimator. Instead of labeling policies after NIST standards, I'd recommend intuitive names such as: Average, Good, and Excellent. These tiers would reflect increasing levels of password entropy. For example:
cc @keycloak/security @keycloak/maintainers |
|
Thank you for your input. IMHO assuming that people use password managers on the client side is a very optimistic, and it can't be enforced by an administrator. The only thing an administrator can do is configure Keycloak on the server side. A strength indicator is asked by this standard: "Verifiers SHOULD offer guidance to the subscriber, such as a password-strength meter, to assist the user in choosing a strong memorized secret." I would still prefer for implementing the "5.1.1 Memorized Secrets" part of NIST 800-63B which is basically a password policy and label it "NIST 800-63B password policy", rather than trying to invent something new as it would skip me having an argument with people what "average", "good", and "excellent" could mean. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
TL;DR: I want to make it simple to run a secure-by-default Keycloak. While second factors or password-less authentication becomes more popular, there are a lot of installations that are still using passwords.
NIST defined some password guidelines as described in https://pages.nist.gov/800-63-3/sp800-63b.html
A digest is found in https://specopssoft.com/blog/nist-800-63b/:
While Keycloak supports all or most of that, it is tedious to configure, and a default Keycloak installation might not do it leaving it vulnerable to smurfing attacks and similar.
Therefore I suggest to have a password policy named "NIST 800-63b" that bundles all the rules, and even ship a (reasonably) medium sized denied password list that an admin later can replace.
We might go as far as enabling it by default for Keycloak production deployments.
Happy to hear your thoughts before we create an issue for that.
All reactions