Password
Last updated
Last updated
At Quasr we do believe in a passwordless future as we feel passwords are impractical for users and have various security challenges. Nonetheless we do offer a password factor as we understand our customers may still need it for the time being. Though we want to challenge our customers to think and plan for a passwordless future. Hence users can enroll in various factors allowing passwords to be phased out over time without implications.
The password is a knowledge-based authentication factor and requires input by the user. NIST categorizes it a “Memorized Secret”, which is defined as:
A Memorized Secret authenticator — commonly referred to as a password or, if numeric, a PIN — is a secret value intended to be chosen and memorized by the user. Memorized secrets need to be of sufficient complexity and secrecy that it would be impractical for an attacker to guess or otherwise discover the correct secret value. A memorized secret is something you know.
The password is a non-unique factor, meaning that it’s possible that multiple users pick the same password by coincidence. A password requires an additional identifier upfront to be used for authentication (such as a username).
Quasr follows a best-practice implementation according to and recommendations (as minimum) with a default password policy of:
minimum 15 characters length
maximum 100 characters length
no password expiration / no required password change
Passwords are case-sensitive.
The default maximum failed attempts before the factor gets temporarily disabled is 5. The factor will auto-unlock after 300 seconds (5 minutes). The counter resets to 0 on each successful login.
Passwords are stored hashed (Argon2id).
Below is a sample screenshot to give an idea of a potential login / registration page asking for a OTP factor. It's just an example, as Quasr does not currently offer a hosted login page.
On a registration page, the password input field is usually represented by a single-line text field, often combined with an additional password confirmation fields (matching of password and confirmation to be checked client-side) to avoid typos.
On a login page, the password input field is usually represented by a single-line password field, which by default hides the input, but allows to toggle its visibility and also allows for copy/pasting values into it (i.e. from a password manager).
To enroll a password factor, the actual password (input
parameter) and optionally a label (label
parameter) is provided.
POST
https://{tenant_id}.api.quasr.io/factors/signup
input
String
Password
label
String
Label
id*
String
Factor ID
To validate a password factor, the actual password (input
parameter) is provided.
POST
https://{tenant_id}.api.quasr.io/factors/login
input*
String
Password
id*
String
Enrollment ID
The Password Factor allows for the following parameters and config options:
subtype
"secret:password"
label
<string>
"Password"
status
"ENABLED" | "DISABLED"
"DISABLED"
score
<positive int>
1
config.unique
true | false
false
config.case_sensitive
true | false
true
config.require_validation_for_enablement
true | false
false
config.regex
regex
"^.{15,100}$"
config.threshold
0-4
2
The following API sample calls create an Password factor labelled "Another Password" with a score of 2.
Passwords should be long and complex, which makes them hard or impossible to remember. The use of a password manager is recommended to keep them safe. Here is a list of password managers that we can recommend (Quasr has no affiliation with these vendors).
A Password factor is already available for all newly created tenants by default, however, if you want to add additional password factors, you can do so via Tenant Administration UI or .
The Quasr Access Token used in the Authorization
header in the examples below must contain the scope https://api.quasr.io/scopes/admin
in order to be authorized. See
(Open Source)
(Open Source)