Algorithmic address+password generation

[link2xt]

Currently the username (address) and password is generated by making a request to /new URL.

Server-side script then generates a new username and password:

relay/chatmaild/src/chatmaild/newemail.py

Lines 17 to 23 in d75321b

	def create_newemail_dict(config: Config):
	user = "".join(random.choices(ALPHANUMERIC, k=config.username_max_length))
	password = "".join(
	secrets.choice(ALPHANUMERIC_PUNCT)
	for _ in range(config.password_min_length + 3)
	)
	return dict(email=f"{user}@{config.mail_domain}", password=f"{password}")

There are multiple problems with this approach:

1. HTTPS request may fail even if IMAP and SMTP connection could work.
2. HTTPS requests are only made when the user registers a new account or manually visits the web page. So a passive observer can see when new user accounts are created.
3. If username expires because the user has not used it for a long time, it can be taken over.
4. If the server is reinstalled, username can be taken over.
5. This encourages users to manually select "nice" address with a weak password they somewhat randomly type on the keyboard (https://support.delta.chat/t/how-to-create-an-account-without-an-account-creation-qr-code/3911), but the password cannot be changed (https://support.delta.chat/t/changing-the-password-of-a-chatmail-account/4122)
   We don't want to support changing the password, this will be solved by having the ability to create a new address (with a new password) and migrate to it.

HTTPS requests exist for historical reasons. chatmail has evolved from mailadm scripts that started as Python scripts to create accounts on postfix+dovecot server and a request to an URL with a token actually created an account.

I propose to specify an algorithm for password and address generation so it can be implemented directly in the client.

Something like:

1. Generate a random password with 256 bits of randomness. base64-encode it.
2. Calculate the address by taking the "chatmail:" | domain | ':' | password string and hashing it. Concatenating with the domain makes sure that passwords cannot be reused between chatmail servers with different domains.
3. Truncate the hash to 32 byte (256 bit) output of the hash. Add 3 random bytes or remove the last two bytes to avoid padding and base32-encode it. Add @domain to get the address.

One downside of this scheme is that username now is not completely random, but depends on the password and we need to ensure that this scheme in secure.

We cannot have short addresses to make it impossible to bruteforce by running this procedure a lot of times and looking for collisions. We can still save the password hash when the user logs in for the first time so even if another password for the same login is somehow found, it will not be accepted as long as the user does not expire.

I also thought about having domain separation, but maybe there are other non-obvious changes that need to be done.

For backwards compatibility we will still support usernames that have a password file with a hash on the server, but will not create new ones. If they expire, they cannot be taken over because new one will not be created.

[hpk42]

• /newemail endpoint would then better also generate such algorithmic addresses and doveauth would need to learn authenticating the algorithmic login (and old chatmail relays will just store them).
• the client needs to fallback to https requests if the relay rejects the login

Besides, just generating a random address and a random password should suffice to avoid the https request even if it doesn't prevent the need for storing a password file (which is nice to avoid, agreed).

In any case, we need nine to allow longer addresses. sidenote: username_max_length defaults to 9 i think, and in retrospect it's questionable to have made address length be ini-customizable.

[link2xt]

and doveauth would need to learn authenticating the algorithmic login (and old chatmail relays will just store them).

Old chatmail relays will not accept long usernames, so we will need a new schema instead of dcaccount:https://example.og/new to tell that credentials should be generated instead of making an HTTPS request. Something like cmaccount:example.org. No fallback on the client needed.

[link2xt]

Prototype of this in Python:

#!/usr/bin/env python3
import hashlib
import base64
import secrets
import string

ALPHANUMERIC_PUNCT = string.ascii_letters + string.digits + string.punctuation


def generate_address(domain, password):
    m = hashlib.sha3_256()
    m.update(b"chatmail:")
    m.update(password.encode())
    digest = m.digest()
    localpart = base64.b32encode(digest[:30]).lower().decode()
    return f"{localpart}@{domain}"


def generate_credentials(domain):
    password = "".join(secrets.choice(ALPHANUMERIC_PUNCT) for _ in range(50))
    address = generate_address(domain, password)
    return address, password


def check_credentials(domain, address, password):
    return address == generate_address(domain, password)


def test():
    address, password = generate_credentials("example.org")

    print(address)
    print(password)

    assert check_credentials("example.org", address, password)
    assert not check_credentials("example.net", address, password)
    assert not check_credentials("example.org", address, "foobar")
    assert not check_credentials("example.org", "foobar@example.org", "foobar")


test()

[hpk42]

that script generates for example:

fqtp6nrlo3t4xgxpluhocqm5vo3ckr33qz4cbs4724lqao5p@example.org
Dd~[.Z"@tPrrV5^9TLi*4RLRnit[:ZLMVZo4RSX;|T5D}.\PM/

so a ~50 character local name, and 40 char password or so.
Do we need such a long address? Cracking the password of a transport address does not reveal any message content, and also does not reveal much metadata, if our efforts at reducing metadata come to fruition. There is also no risk of impersonation like there is with classic email. So without a material reason, i'd like them to be much shorter. What would be the computational costs of, say, cracking a 20-char address?

[link2xt]

Do we need such a long address?

Truncating 256-bit output of hash may be fine, but we need to check that it is secure.

The basic question is whether we need collision resistance. If we need it, then we need 256 bits. But we likely don't and then we need 128 bits. Less than 128 bits is probably not ok by any standard.

Truncating to 160 bits (20 bytes) results in 32 characters of base32 and the address will look like ul3a276ebtt2spci7fjc3nejaca5cwcf@example.org. This is what ETH does for addresses that are used to transfer money, there are discussions about not doing it but seems to be fine. Truncating to 128 bits means collisions are practically possible (64-bits of collision resistance). This may also be fine for us, finding a collision means you can get your own login with two passwords, but it still does not mean you will get a password for someone else's account. Session even uses 128 bits to derive the secret key similarly to BIP 39 scheme used for bitcoin (with 12 words, now doubled to 24) and it is fine, but resulted in session-foundation/session-android#880
.onion domains are 35 bytes or 56 base32 characters long, but this is because they directly put ed25519 key in there.

The other question is how to truncate hash output properly, SHA-3 is probably fine to truncate however you want (unlike SHA-256 which should be truncated to avoid length extension attacks which seems to be irrelevant here), but this also needs to be double checked. Maybe SHAKE-128 with 128 bits output is the proper way to do it instead of truncating manually: https://docs.python.org/3/library/hashlib.html#shake-variable-length-digests

For comparison of how the addresses look like:

• fqtp6nrlo3t4xgxpluhocqm5vo3ckr33qz4cbs4724lqao5p@example.org (240 bits, 30 bytes, 48 characters)
• ul3a276ebtt2spci7fjc3nejaca5cwcf@example.org (160 bits, 20 bytes, 32 characters)
• vu7gxi4g574kt5muj3bmi7v45b@example.org (130 bits, 16.25 bytes, 26 characters)
• deih2mgdsnphqm3nr3665kj6@example.org (120 bits, 15 bytes, 24 characters)

The length in bits needs to be divisible by 5 for base32 encoding.

130 bits is generated with localpart = base64.b32encode(digest)[:26].lower().decode()

Cracking the password of a transport address does not reveal any message content, and also does not reveal much metadata, if our efforts at reducing metadata come to fruition. There is also no risk of impersonation like there is with classic email. So without a material reason, i'd like them to be much shorter.

I don't think it's even worth discussing designing something insecure from the start regardless of how bad it is once it is broken.

[link2xt]

For now I made something simpler in the core, a new scheme that skips HTTPS request and configures nine-character username with long password: chatmail/core#7360
It is not configurable.

Chatmail operators that don't configure username length can use it, and I think we want to remove username length configuration. And especially password length configuration should be hardcoded.

[hpk42]

Do we need such a long address?

Truncating 256-bit output of hash may be fine, but we need to check that it is secure, I did not evaluate at all yet.

Truncating to 160 bits (20 bytes) results in 32 characters of base32 and the address will look like ul3a276ebtt2spci7fjc3nejaca5cwcf@example.org. This is what ETH does for addresses that are used to transfer money, there are discussions about not doing it but seems to be fine. Truncating to 128 bits means collisions are practically possible (64-bits of collision resistance). This may also be fine for us, finding a collision means you can get your own login with two passwords, but it still does not mean you will get a password for someone else's account. Session even uses 128 bits to derive the secret key similarly to BIP 39 scheme used for bitcoin (with 12 words, now doubled to 24) and it is fine, but resulted in session-foundation/session-android#880 .onion domains are 35 bytes or 56 base32 characters long, but this is because they directly put ed25519 key in there.

Truncating to 120 bits (15 bytes) looks like deih2mgdsnphqm3nr3665kj6@example.org.

For comparison:

* `fqtp6nrlo3t4xgxpluhocqm5vo3ckr33qz4cbs4724lqao5p@example.org` (240 bits, 30 bytes, 48 characters)

* `ul3a276ebtt2spci7fjc3nejaca5cwcf@example.org` (160 bits, 20 bytes, 32 characters)

* `vu7gxi4g574kt5muj3bmi7v45b@example.org` (130 bits, 16.25 bytes, 26 characters)

* `deih2mgdsnphqm3nr3665kj6@example.org` (120 bits, 15 bytes, 24 characters)

thanks for detailing this. I am unsure whether having a better after-server-loss-recovery is worth making all addresses longer with at least 26-9=17 characters.

[link2xt]

I think we better remove the settings for now and at least restrict all new accounts to the current default 9 characters and move to the new scheme from chatmail/core#7360