From 0814ac2bb42823a4b628a18552ab405c17c4614f Mon Sep 17 00:00:00 2001 From: Charles Wright Date: Fri, 2 Jul 2021 14:42:02 -0500 Subject: [PATCH 1/2] Added a proposal for doing login and SSSS with a single password Signed-off-by: Charles Wright --- ...xxx-login-and-ssss-with-single-password.md | 126 ++++++++++++++++++ 1 file changed, 126 insertions(+) create mode 100644 proposals/xxxx-login-and-ssss-with-single-password.md diff --git a/proposals/xxxx-login-and-ssss-with-single-password.md b/proposals/xxxx-login-and-ssss-with-single-password.md new file mode 100644 index 00000000000..2a35eb5607f --- /dev/null +++ b/proposals/xxxx-login-and-ssss-with-single-password.md @@ -0,0 +1,126 @@ +# Login and SSSS with a Single Password + +The current approach for secure server-side storage (SSSS) requires that users +create and remember two different passwords for each account. Unfortunately, +humans are not very good at creating and remembering even one strong password +per account. Requiring the use of two passwords increases the risk that users +will choose at least one weak password, or that they will re-use the same +password for both purposes. + +The case where a user uses a single password for both login and SSSS is +particularly dangerous. Even though the homeserver should not store the +password in long-term storage, it does learn the password whenever a user +logs in or authenticates through the user-interactive authentication API. +At that point, a malicious or compromised homeserver could easily decrypt +all of the lazy user's server-side storage. + +This proposal describes a new scheme that clients can use to better protect +their users' secrets. It does not require any changes on the server side. + +The general idea is to use hash functions with the user's human-memorable +("raw") password to generate two different secrets. We use the first secret +as the new login password, and we use the second secret as the symmetric +encryption/decryption key for SSSS. + +## Security Requirements + +The scheme should satisfy the following requirements: + +1. Given the login password, it should be computationally infeasible to +recover the user's original "raw" password. + +2. Given the login password, it should be computationally infeasible to +recover the user's SSSS key. + +3. Given no special information about the user's "raw" password, it should +be computationally impractical for an adversary to recover either the login +password or the SSSS key. This requirement applies even to adversaries +who can build or buy specialized hardware, including GPUs, FPGAs, and +ASICs in order to accelerate a brute-force search for the password. + +## High-Level Description of the Scheme + +The proposed construction is very simple. It relies on two cryptographic hash +functions. + +1. `H()` - a standard cryptographic hash function, such as SHA256. + +2. `PHF()` - a password hashing function, such as bcrypt, scrypt, argon2, or +(if necessary) PBKDF2. + +First we pass the user's "raw" password through the password hashing function +to generate a "root" secret known only to the client. We use a salt derived +from the user's ID to thwart precomputation attacks using rainbow tables or +other time-memory tradeoffs. + +``` + salt = H(user_part) + root_secret = PHF(raw_password, salt) +``` + +This protects against adversaries that want to recover the raw password. +The PHF parameters should be chosen such that brute force password guessing +attacks are not practical. For example, the beta version of Circles uses +Bcrypt with work factor 14. With this setting, computing a single hash is +very fast -- probably under 500ms on mid-range Apple hardware like the +iPhone X, iPhone XR, and the 2018 iPad. However, a brute-force search for +a non-trivial password would be extremely expensive. + +Second, we hash the root secret with the hash function, using two different +prefixes to produce two hash digests, very similar to the way a chain key is +hashed in the double ratchet to produce a message key and a new chain key. +This gives us the two seemingly independent secrets that we require. + +We use the first derived secret to create the user's new login password, by +encoding it as an ASCII/UTF8 hex string and taking the first 32 characters. + +We take the second derived secret as the symmetric key for SSSS. + +``` + login_password = H('LoginPassword'|root_secret)[:16].utf8() + ssss_key = H('S4Key'|root_secret) +``` + +## Security Analysis + +An adversary who can temporarily take over the homeserver can observe the +login password submitted in requests for password login or user-interactive +authentication. Our security requirements above state that this adversary +must not be able to learn the SSSS key or the user's human-memorable "raw" +password. + +### Protecting the SSSS key +If the attacker can recover the root secret, then it can easily compute the +SSSS key. The proposed construction protects against this line of attack. +If the hash function is preimage resistant, then the login password gives +the attacker no real information about the root secret. + +### Protecting the user's "raw" password +As noted above, the preimage resistance property of the hash function +prevents the attacker working backwards to obtain the root secret. +Furthermore, even if the attacker did know the root secret, the password +hashing function should also offer preimage resistance. Therefore the +attacker cannot invert the password hash to recover the password. + +The attacker's best strategy then is to attempt a brute-force search for +the password, using the latest password dictionaries and guessing rules, +plus possibly specialized hardware to accelerate the computation of the +hash. + +If the user uses a reasonable password (ie, not in the password dictionaries, +and not a simple derivation from a word that is), and the password hashing +function resists acceleration, then the brute force guessing attack is also +not practically feasible. + +Regardless of the user's choice of password, the proposed scheme is no +weaker than the current approach, where the user has separate passwords +for login and for SSSS. Under the current approach, the adversary who +temporarily compromises the homeserver learns the login password immediately, +and must brute-force search for the SSSS password. A clever adversary would +prioritize use of the login password in its brute-force search for the SSSS +password, since many users might re-use their login password, or a closely +related password, for SSSS. + + + + From 27473710be3c1ccffd8dfc02fce5dd5fe4941d40 Mon Sep 17 00:00:00 2001 From: Charles Wright Date: Fri, 2 Jul 2021 14:53:55 -0500 Subject: [PATCH 2/2] Use MSC number in the filename --- ...le-password.md => 3265-login-and-ssss-with-single-password.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename proposals/{xxxx-login-and-ssss-with-single-password.md => 3265-login-and-ssss-with-single-password.md} (100%) diff --git a/proposals/xxxx-login-and-ssss-with-single-password.md b/proposals/3265-login-and-ssss-with-single-password.md similarity index 100% rename from proposals/xxxx-login-and-ssss-with-single-password.md rename to proposals/3265-login-and-ssss-with-single-password.md