mirror of https://github.com/moparisthebest/xeps
443 lines
20 KiB
XML
443 lines
20 KiB
XML
<?xml version='1.0' encoding='UTF-8'?>
|
|
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
|
<!ENTITY OWASP "the <span class='ref'><link url='https://owasp.org/'>Open Web Application Security Project (OWASP)</link></span> <note>The Open Web Application Security Project (OWASP, or OWASP Foundation) is a nonprofit foundation that works to improve the security of software. For further information, see <<link url='https://owasp.org/'>https://owasp.org/</link>>.</note>" >
|
|
<!ENTITY owasppasswords "<span class='ref'><link url='https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html'>OWASP Password Storage Cheat Sheet</link></span> <note>OWASP Cheat Sheet Series for password storage <<link url='https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html'>https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html</link>>.</note>" >
|
|
<!ENTITY rfc2195 "<span class='ref'><link url='http://tools.ietf.org/html/rfc2195'>RFC 2195</link></span> <note>RFC 2195: IMAP/POP AUTHorize Extension for Simple Challenge/Response <<link url='http://tools.ietf.org/html/rfc2195'>http://tools.ietf.org/html/rfc2195</link>>.</note>" >
|
|
<!ENTITY rfc5746 "<span class='ref'><link url='http://tools.ietf.org/html/rfc5746'>RFC 5746</link></span> <note>RFC 5746: Transport Layer Security (TLS) Renegotiation Indication Extension <<link url='http://tools.ietf.org/html/rfc5746'>http://tools.ietf.org/html/rfc5746</link>>.</note>" >
|
|
<!ENTITY rfc7677 "<span class='ref'><link url='http://tools.ietf.org/html/rfc7677'>RFC 7677</link></span> <note>RFC 7677: SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms <<link url='http://tools.ietf.org/html/rfc7677'>http://tools.ietf.org/html/rfc7677</link>>.</note>" >
|
|
<!ENTITY rfc8018 "<span class='ref'><link url='http://tools.ietf.org/html/rfc8018'>RFC 8018</link></span> <note>RFC 8018: PKCS #5: Password-Based Cryptography Specification Version 2.1 <<link url='http://tools.ietf.org/html/rfc8018'>http://tools.ietf.org/html/rfc8018</link>>.</note>" >
|
|
<!ENTITY rfc8265 "<span class='ref'><link url='http://tools.ietf.org/html/rfc8265'>RFC 8265</link></span> <note>RFC 8265: Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords <<link url='http://tools.ietf.org/html/rfc8265'>http://tools.ietf.org/html/rfc8265</link>>.</note>" >
|
|
<!ENTITY nistsp800-63-3 "<span class='ref'><link url='https://doi.org/10.6028/NIST.SP.800-63-3'>Digital Identity Guidelines</link></span> <note>Digital Identity Guidelines, NIST Special Publication 800-63-3 <<link url='https://doi.org/10.6028/NIST.SP.800-63-3'>https://doi.org/10.6028/NIST.SP.800-63-3</link>>.</note>" >
|
|
<!ENTITY nistsp800-63b "<span class='ref'><link url='https://doi.org/10.6028/NIST.SP.800-63b'>Digital Identity Guidelines: Authentication and Lifecycle Management</link></span> <note>Digital Identity Guidelines: Authentication and Lifecycle Management, NIST Special Publication 800-63B <<link url='https://doi.org/10.6028/NIST.SP.800-63b'>https://doi.org/10.6028/NIST.SP.800-63b</link>>.</note>" >
|
|
<!ENTITY nistsp800-132 "<span class='ref'><link url='https://doi.org/10.6028/NIST.SP.800-132'>Recommendation for Password-Based Key Derivation, Part 1: Storage Applications</link></span> <note>Recommendation for Password-Based Key Derivation, Part 1: Storage Applications, NIST Special Publication 800-132 <<link url='https://doi.org/10.6028/NIST.SP.800-132'>https://doi.org/10.6028/NIST.SP.800-132</link>>.</note>" >
|
|
<!ENTITY % ents SYSTEM 'xep.ent'>
|
|
%ents;
|
|
]>
|
|
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
|
<xep>
|
|
<header>
|
|
<title>Best practices for password hashing and storage</title>
|
|
<abstract>
|
|
This document outlines best practices for handling user passwords on the
|
|
public Jabber network for both clients and servers.
|
|
</abstract>
|
|
&LEGALNOTICE;
|
|
<number>0438</number>
|
|
<status>Experimental</status>
|
|
<type>Informational</type>
|
|
<sig>Standards</sig>
|
|
<approver>Council</approver>
|
|
<dependencies/>
|
|
<supersedes/>
|
|
<supersededby/>
|
|
<shortname>passwords</shortname>
|
|
&sam;
|
|
<revision>
|
|
<version>0.2.0</version>
|
|
<date>2020-10-30</date>
|
|
<initials>ssw</initials>
|
|
<remark><p>Update to match draft-ietf-kitten-password-storage-01.</p></remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.1.1</version>
|
|
<date>2020-05-05</date>
|
|
<initials>ssw</initials>
|
|
<remark><p>Fix reference to external document.</p></remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.1.0</version>
|
|
<date>2020-05-05</date>
|
|
<initials>XEP Editor (jsc)</initials>
|
|
<remark>Accepted by vote of Council on 2020-04-22.</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.0.1</version>
|
|
<date>2020-04-19</date>
|
|
<initials>ssw</initials>
|
|
<remark><p>First draft.</p></remark>
|
|
</revision>
|
|
</header>
|
|
<section1 topic='Introduction' anchor='intro'>
|
|
<p>
|
|
Following best practices when hashing and storing passwords and other
|
|
authenticator secrets impacts a great deal more than just a users identity.
|
|
It also effects usability, and backwards compatibility by determining what
|
|
authentication and authorization mechanisms can be used.
|
|
Unfortunately, aside from mandating the use of SCRAM-SHA-1 in &rfc6120;, and
|
|
recommending at least 4096 rounds of PBKDF2 in &rfc5802; (a
|
|
number which is now woefully inadequate), no general recommendations for
|
|
best practices in password storage, transmission, or key derivation function
|
|
tuning exist in the XMPP ecosystem.
|
|
</p>
|
|
<p>
|
|
Many of the recommendations in this document were taken from
|
|
&nistsp800-63b; and &nistsp800-132;.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='Requirements' anchor='reqs'>
|
|
<p>
|
|
This document makes specific recommendations for best practices on the
|
|
public Jabber network for both clients and servers.
|
|
It does not attempt to address private networks or proprietary services
|
|
which may have different requirements, use cases, and security models.
|
|
These recommendations include the hashing and storage of memorized secrets
|
|
and other authenticators, authentication, and compatibility between clients
|
|
and servers with respect to authentication.
|
|
</p>
|
|
<p>
|
|
To keep the length of this document manageable, we assume basic familiarity
|
|
with password storage and handling, common terms, and cryptographic
|
|
operations.
|
|
For an overview of basic password security see the &owasppasswords;
|
|
maintained by &OWASP;.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='Glossary' anchor='glossary'>
|
|
<p>
|
|
Various security-related terms are to be understood in the sense
|
|
defined in &rfc4949;
|
|
Some may also be defined in defined in &nistsp800-63-3; Appendix A.1 and in
|
|
&nistsp800-132; §3.1.
|
|
</p>
|
|
<p>
|
|
Throughout this document the term "password" is used to mean any password,
|
|
passphrase, PIN, or other memorized secret.
|
|
</p>
|
|
<p>
|
|
Other common terms used throughout this document include:
|
|
</p>
|
|
<dl>
|
|
<di>
|
|
<dt>Mechanism Pinning</dt>
|
|
<dd>
|
|
Mechanism pinning A security mechanism which allows SASL clients to
|
|
resist downgrade attacks.
|
|
Clients that implement mechanism pinning remember the perceived strength
|
|
of the SASL mechanism used in a previous successful authentication
|
|
attempt and thereafter only authenticate using mechanisms of equal or
|
|
higher perceived strength.
|
|
</dd>
|
|
</di>
|
|
<di>
|
|
<dt>Pepper</dt>
|
|
<dd>
|
|
A secret added to a password hash like a salt.
|
|
Unlike a salt, peppers are secret and not unique.
|
|
They must not be stored alongside the hashed password.
|
|
</dd>
|
|
</di>
|
|
<di>
|
|
<dt>Salt</dt>
|
|
<dd>
|
|
In this document salt is used as defined in &rfc4949;.
|
|
</dd>
|
|
</di>
|
|
</dl>
|
|
</section1>
|
|
<section1 topic='SASL Mechanisms' anchor='required'>
|
|
<p>
|
|
Clients and servers must already implement the SASL mechanisms listed in RFC
|
|
6120 §13.8.1 For Authentication Only.
|
|
These mechanisms are:
|
|
</p>
|
|
<ul>
|
|
<li>SCRAM-SHA-1</li>
|
|
<li>SCRAM-SHA-1-PLUS</li>
|
|
</ul>
|
|
<p>
|
|
In addition, clients and servers SHOULD support the following SCRAM variants
|
|
defined in &rfc7677;:
|
|
</p>
|
|
<ul>
|
|
<li>SCRAM-SHA-256</li>
|
|
<li>SCRAM-SHA-256-PLUS</li>
|
|
</ul>
|
|
<p>
|
|
Clients SHOULD NOT invent their own mechanisms that have not been
|
|
standardized by the IETF, the XSF, or another reputable standards body.
|
|
</p>
|
|
<p>
|
|
Clients MUST NOT implement any mechanism with a usage status of "OBSOLETE",
|
|
"MUST NOT be used", or "LIMITED" in the &ianasasl;.
|
|
Similarly, any mechanism that depends on a hash function listed as "MUST
|
|
NOT" in &xep0414; MUST NOT be used.
|
|
This means that the following mechanisms which were commonly used with XMPP
|
|
in the past MUST NOT be supported:
|
|
</p>
|
|
<ul>
|
|
<li>CRAM-MD5 (&rfc2195;)</li>
|
|
<li>DIGEST-MD5 (&rfc6331;)</li>
|
|
</ul>
|
|
</section1>
|
|
<section1 topic='Client Best Practices' anchor='client'>
|
|
<section2 topic='Mechanism Pinning' anchor='pinning'>
|
|
<p>
|
|
Clients maintain a list of preferred SASL mechanisms, generally ordered by
|
|
perceived strength to enable strong authentication (&rfc6120; §6.3.3
|
|
Mechanism Preferences).
|
|
To prevent downgrade attacks by a malicious actor that has successfully
|
|
man in the middled a connection, or compromised a trusted server's
|
|
configuration, clients SHOULD implement "mechanism pinning".
|
|
That is, after the first successful authentication with a strong
|
|
mechanism, clients SHOULD make a record of the authentication and
|
|
thereafter only advertise and use mechanisms of equal or higher perceived
|
|
strength.
|
|
</p>
|
|
<p>
|
|
For reference, the following mechanisms are ordered by their perceived
|
|
strength from strongest to weakest with mechanisms of equal strength on
|
|
the same line.
|
|
This list is a non-normative example and does not indicate that these
|
|
mechanisms should or should not be supported:
|
|
</p>
|
|
<ol>
|
|
<li>EXTERNAL</li>
|
|
<li>SCRAM-SHA-1-PLUS, SCRAM-SHA-256-PLUS</li>
|
|
<li>SCRAM-SHA-1, SCRAM-SHA-256</li>
|
|
<li>PLAIN</li>
|
|
<li>DIGEST-MD5, CRAM-MD5</li>
|
|
</ol>
|
|
<p>
|
|
The EXTERNAL mechanism defined in &rfc4422; appendix A is placed at
|
|
the top of the list.
|
|
However, its perceived strength depends on the underlying authentication
|
|
protocol.
|
|
In this example, we assume that TLS (&rfc8446;) services are being used.
|
|
</p>
|
|
<p>
|
|
The channel binding ("-PLUS") variants of SCRAM (&rfc5802;) are listed
|
|
above their non-channel binding cousins, but may not always be
|
|
available depending on the type of channel binding data available to
|
|
the SASL negotiator.
|
|
</p>
|
|
<p>
|
|
The PLAIN mechanism sends the username and password in plain text,
|
|
but does allow for the use of a strong key derivation function (KDF)
|
|
for the stored version of the password on the server.
|
|
</p>
|
|
<p>
|
|
Finally, the DIGEST-MD5 and CRAM-MD5 mechanisms are listed last
|
|
because they use weak hashes and ciphers and prevent the server from
|
|
storing passwords using a KDF. For a list of problems with DIGEST-
|
|
MD5 see &rfc6331;.
|
|
</p>
|
|
</section2>
|
|
<section2 topic='Storage' anchor='client-storage'>
|
|
<p>
|
|
Clients SHOULD always store authenticators in a trusted and encrypted
|
|
keystore such as the system keystore, or an encrypted store created
|
|
specifically for the clients use.
|
|
They SHOULD NOT store authenticators as plain text.
|
|
</p>
|
|
<p>
|
|
If clients know that they will only ever authenticate using a mechanism
|
|
such as SCRAM where the original password is not needed (for example if
|
|
the mechanism has been pinned) they SHOULD store the SCRAM bits or the
|
|
hashed and salted password instead of the original password.
|
|
However, if backwards compatibility with servers that only support the
|
|
PLAIN mechanism or other mechanisms that require using the original
|
|
password is required, clients MAY choose to store the original password
|
|
so long as an appropriate keystore is used.
|
|
</p>
|
|
</section2>
|
|
</section1>
|
|
<section1 topic='Server Best Practices' anchor='server'>
|
|
<section2 topic='Additional SASL Requirements' anchor='server-required'>
|
|
<p>
|
|
Servers MUST NOT support any mechanism that would require authenticators
|
|
to be stored in such a way that they could be recovered in plain text from
|
|
the stored information.
|
|
This includes mechanisms that store authenticators using reversable
|
|
encryption, obsolete hashing mechanisms such as MD5, and hashes that are
|
|
unsuitable for use with authenticators such as SHA256.
|
|
</p>
|
|
</section2>
|
|
<section2 topic='Storage' anchor='server-storage'>
|
|
<p>
|
|
Servers MUST always store passwords only after they have been salted and
|
|
hashed using a strong KDF.
|
|
If multiple hashes are supported for use with SCRAM, for example
|
|
SCRAM-SHA-1 and SCRAM-SHA-256, separate salted and hashed passwords SHOULD
|
|
be calculated and stored for each mechanism so that users can log in with
|
|
multiple clients that support only some of the mechanisms.
|
|
</p>
|
|
<p>
|
|
A distinct salt SHOULD be used for each user, and each SCRAM family
|
|
supported.
|
|
Salts MUST be generated using a cryptographically secure random number
|
|
generator.
|
|
The salt MAY be stored in the same datastore as the password.
|
|
If it is stored alongside the password, it SHOULD be combined with a
|
|
pepper stored in the application configuration, an environment variable,
|
|
or some other location other than the datastore containing the salts.
|
|
</p>
|
|
<p>
|
|
The following minimum restrictions MUST be observed when generating salts
|
|
and peppers.
|
|
More up to date numbers may be found in &owasppasswords;
|
|
</p>
|
|
<dl>
|
|
<di>
|
|
<dt>Minimum Salt Length</dt>
|
|
<dd>
|
|
16 bytes
|
|
</dd>
|
|
</di>
|
|
<di>
|
|
<dt>Minimum Pepper Length</dt>
|
|
<dd>
|
|
32 bytes
|
|
</dd>
|
|
</di>
|
|
</dl>
|
|
</section2>
|
|
<section2 topic='Authentication and Rotation' anchor='auth'>
|
|
<p>
|
|
When authenticating using PLAIN or similar mechanisms that involve
|
|
transmitting the original password to the server the password MUST
|
|
be hashed and compared against the salted and hashed password in the
|
|
database using a constant time comparison.
|
|
</p>
|
|
<p>
|
|
Each time a password is changed or reset, a new random salt should be
|
|
created and the iteration count and pepper (if applicable) should be
|
|
updated to the latest value required by server policy.
|
|
</p>
|
|
<p>
|
|
If a pepper is used, consideration should be taken to ensure that it can
|
|
be easily rotated.
|
|
For example, multiple peppers could be stored with new passwords and
|
|
reset passwords using the latest pepper.
|
|
A hash of the pepper using a cryptographically secure hash function such
|
|
as SHA256 could then be stored in the database next to the salt so that
|
|
future logins can identify which pepper in the list was used.
|
|
This is just one example, pepper rotation schemes are outside the scope of
|
|
this document.
|
|
</p>
|
|
</section2>
|
|
</section1>
|
|
<section1 topic='PBKDF2 Parameters' anchor='pbkdf2'>
|
|
<p>
|
|
Because the PBKDF2 key derivation function (&rfc8018;) is used by
|
|
SCRAM-SHA-1 which is mandated for use in XMPP, this document recommends it
|
|
for password storage.
|
|
Servers SHOULD use the following parameters when applying PBKDF2:
|
|
</p>
|
|
<dl>
|
|
<di>
|
|
<dt>Minimum iteration count (c)</dt>
|
|
<dd>10,000 (100,000 for higher security environments)</dd>
|
|
</di>
|
|
<di>
|
|
<dt>Hash</dt>
|
|
<dd>SHA256</dd>
|
|
</di>
|
|
<di>
|
|
<dt>Output length (dkLen)</dt>
|
|
<dd>hLen (length of the chosen hash)</dd>
|
|
</di>
|
|
</dl>
|
|
<p>
|
|
The minimum iteration count may be tuned to the specific system on which
|
|
password hashing is taking place.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='Password Complexity Requirements' anchor='passwordcomplexity'>
|
|
<p>
|
|
Before any other password complexity requirements are checked, the
|
|
preparation and enforcement steps of the OpaqueString profile of &rfc8265;
|
|
SHOULD be applied (for more information see the Internationalization
|
|
Considerations section).
|
|
Entities SHOULD enforce a minimum length of 8 characters for user passwords.
|
|
If using a mechanism such as PLAIN where the server performs hashing on the
|
|
original password, a maximum length between 64 and 128 characters MAY be
|
|
imposed to prevent denial of service (DoS) attacks.
|
|
Entities SHOULD NOT apply any other password restrictions.
|
|
</p>
|
|
<p>
|
|
In addition to these password complexity requirements, servers SHOULD
|
|
maintain a password blocklist and reject attempts by a claimant to use
|
|
passwords on the blocklist during registration or password reset.
|
|
The contents of this blocklist are a matter of server policy.
|
|
Some common recommendations include lists of common passwords that are not
|
|
otherwise prevented by length requirements, and passwords present in known
|
|
breaches.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='Security Considerations' anchor='security'>
|
|
<p>
|
|
This document contains recommendations that are likely to change over time.
|
|
It should be reviewed regularly to ensure that it remains accurate and up to
|
|
date.
|
|
Many of the recommendations in this document were taken from
|
|
&owasppasswords;, &nistsp800-63b;, and &nistsp800-132;.
|
|
</p>
|
|
<p>
|
|
The SCRAM suite of SASL mechanisms are recommended in this document,
|
|
however, there is currently no way to force a password reset.
|
|
This reduces upgrade agility if a weakness is discovered in SCRAM and means
|
|
that new, untested, SCRAM-based or SCRAM-like mechanisms should be added
|
|
with caution.
|
|
</p>
|
|
<p>
|
|
The "-PLUS" variants of SCRAM support channel binding to their underlying
|
|
security layer, but lack a mechanism for negotiating what type of channel
|
|
binding to use.
|
|
In &rfc5802; the tls-unique (&rfc5929;) channel
|
|
binding mechanism is specified as the default, and it is therefore likely to
|
|
be used in most applications that support channel binding.
|
|
However, in the absence of the TLS extended master secret fix (&rfc7627;)
|
|
and the renegotiation indication TLS extension (&rfc5746;) the tls-unique
|
|
and tls-server-endpoint channel binding data can be forged by an attacker
|
|
that can MITM the connection.
|
|
Before advertising a channel binding SASL mechanism, entities MUST ensure
|
|
that both the TLS extended master secret fix and the renegotiation
|
|
indication extension are in place and that the connection has not been
|
|
renegotiated.
|
|
</p>
|
|
<p>
|
|
This document mentions many hash functions that are already in
|
|
use in the XMPP ecosystem, or that have been used in the past.
|
|
It does not make recommendations for what functions should or should not be
|
|
used in new applications.
|
|
For recommendations about the use of hash functions and their security
|
|
implications, see &xep0414;
|
|
</p>
|
|
<p>
|
|
For TLS 1.3 no channel binding types are currently defined. Channel binding
|
|
SASL mechanisms MUST NOT be advertised or negotiated over a TLS 1.3 channel
|
|
until such types are defined.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='Internationalization Considerations' anchor='security'>
|
|
<p>
|
|
The PRECIS framework (Preparation, Enforcement, and Comparison of
|
|
Internationalized Strings) defined in &rfc8264; is used to enforce
|
|
internationalization rules on strings and to prevent common application
|
|
security issues arrising from allowing the full range of Unicode codepoints
|
|
in usernames, passwords, and other identifiers.
|
|
The OpaqueString profile of &rfc8265; is used in this document to ensure
|
|
that codepoints in passwords are treated carefully and consistently.
|
|
This ensures that users typing certain characters on different keyboards
|
|
that may provide different versions of the same character will still be able
|
|
to log in.
|
|
For example, some keyboards may output the full-width version of a character
|
|
while other keyboards output the half-width version of the same character.
|
|
The Width Mapping rule of the OpaqueString profile addresses this and
|
|
ensures that comparison succeeds and the claimant is able to be
|
|
authenticated.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='IANA Considerations' anchor='iana'>
|
|
<p>
|
|
This document requires no interaction with &IANA;.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
|
<p>
|
|
No namespaces or parameters need to be registered with the ®ISTRAR; as a
|
|
result of this document.
|
|
</p>
|
|
</section1>
|
|
</xep>
|