# CloudSave User Login ## Goals - Cap number of emails received by the real user when an attacker brute-forces their login. - Reduce the possibility for unpreventable denial of service to under a minute. - Login confirmations should take under a minute. - Do not rely on IP scarcity because IPv6 will become the norm, and creating a new IP may be costless. ## Design Users can do local edits. But to persist, they must sign up, and potentially purchase the app from the app creator. Sign-up button instantly sets an httpOnly secure cookie with a new user ID = hash(email, key = appID), and a key = hash('userKey ' + userID, key = appID). Then we offer many recovery/login factors, from which they must pick two: - Email: mandatory first factor, variable-sized base32 OTP, 20 attempts, exponential cooldown up to 16 seconds without concurrent attempts. - Password (PBKDF2 server relief, hashed once server-side with userKey) - Other device (with OTP similar to email) - WebAuthn - Paper key (as 26-char base32 hashed server-side with userKey) ## Tradeoffs ### One-Time Passwords - Random 128-bit base64 OTP: - Pros: - Guaranteed un-brute-forceable. - Cons: - Copying visually more than 10 characters has a high risk of error. - Mitigation: make it part of a link. However, the link may be difficult to copy to a different device. - Mitigation: make it part of a QR code. - The user may not have a barcode scanner. Mitigation: make the barcode scanner part of the app. However, it increases the code size of the app. - The login device may be the OTP-email-device. Mitigation: also add a link. - The login device may not have a camera. - Mitigation: cut it in validated attempts by 22 ÷ 6 = 4 groups of 32÷log2(64) = 6 characters. - Copying letters that can be both uppercase or lowercase has a high risk of error. - Short base32 OTP: - Pros: - Can be copied visually, for instance from an email client on a laptop to a login on a phone. The phone may not have an email client logged in to receive the OTP email. - Cons: - Can be brute-forced. - Mitigation: Rate limit. 20 failed login attempts per day. (More sophisticated: Exponential cooldown: for a given email, a validation attempt request will only receive a response after $`2^F` ms, where F is the number of consecutive failed attempts without a success on that email, up to a maximum of $`2^{14}` ms (16 seconds). Concurrent attempts are denied.) The number of characters in the OTP is set so that a brute-force attack takes at least 10 years to succeed just once among all registered users. The probability of a single success among U users, using C characters in the OTP, with an alphabet of size A (eg. 32 for base32, or 36 for alnum), is $`1-(1-A^{-C})^U`; and each attempt can only be made R times for all users every day. Thus a single success would geometrically take $`\frac{1}{1-(1-A^{-C})^U} \times \frac{1}{R \times 365}` years. We can therefore parameterize the number of characters as $`\lceil{-\log_{A}(1 - \sqrt[U]{1 - \frac{1}{R \times 365 \times 10}})}\rceil`. That starts at 4 characters and goes to 9 characters at a billion users, with alnum. - Can spell words or profanities. - Mitigation: group by 2 or 3 characters. ### Attempts count The probability of success for any attempt should be negligible, ie. under 2^-32. The difference in probability between succeeding at doing that with even 20 attempts for the same OTP is: (1 - Π_{i∈{1,…,10}} (1 - 1÷(2³²-i+1))) - (1 - (1 - 2^-32)²⁰) < 1.1×10^-17. That is negligible.