mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-24 02:02:16 -05:00
307 lines
15 KiB
XML
307 lines
15 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 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: PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application ProtocolePRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocolsration, 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>xxxx</number>
|
|
<status>ProtoXEP</status>
|
|
<type>Informational</type>
|
|
<sig>Standards</sig>
|
|
<approver>Council</approver>
|
|
<dependencies/>
|
|
<supersedes/>
|
|
<supersededby/>
|
|
<shortname>passwords</shortname>
|
|
&sam;
|
|
<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>
|
|
Many terms used in this document are defined in &nistsp800-63-3; Appendix
|
|
A.1 and in &nistsp800-132; §3.1.
|
|
Throughout this document the term "password" is used to mean any password,
|
|
passphrase, PIN, or other memorized secret.
|
|
</p>
|
|
<dl>
|
|
<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>
|
|
</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 (RFC 6120 §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>
|
|
</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.
|
|
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>
|
|
</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 iterations</dt>
|
|
<dd>10,000 (100,000 for higher security environments)</dd>
|
|
</di>
|
|
<di>
|
|
<dt>Minimum salt length</dt>
|
|
<dd>16 bytes</dd>
|
|
</di>
|
|
<di>
|
|
<dt>Minimum pepper length</dt>
|
|
<dd>32 bytes</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>
|
|
Clients and servers 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.
|
|
Passwords SHOULD be required to conform to the Opaque String profile of
|
|
&rfc8265;.
|
|
No other password restrictions should be applied.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='Security Considerations' anchor='security'>
|
|
<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>
|
|
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>
|
|
This document contains recommendations that are likely to change over time.
|
|
It should be reviewed yearly to ensure that it remains accurate and up to
|
|
date.
|
|
Many of the recommendations in this document were taken from the
|
|
&owasppasswords;, which can be used as a reference when making updates.
|
|
</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>
|