Session Security

Communication Platforms

Authored by:

Jonathan Riss

CertiK

Summary

🔑 Key Takeaway: The Session recovery password is the account. Store it like a wallet seed phrase, verify Account IDs out of band, and never treat Communities as confidential: they are not end-to-end encrypted on the server.

Session is a messenger built on the Session Network, an onion-routing network of community-operated service nodes. It requires no phone number and no email address. Identity is a randomly generated Account ID (also called a Session ID), and the account exists only as a key pair the app holds.

That design removes the SIM-swap exposure that dominates Telegram and Signal threat models, but it moves the entire risk onto one secret: the recovery password. There is no support desk, no password reset, and no identity provider that can restore an account or lock an attacker out. The controls below reflect that trade-off.

For individuals

These settings apply to a personal Session account. Every team member and moderator should configure them on their own account. Menu labels differ slightly between the desktop, Android, and iOS clients; the official documentation holds current paths.

Account security checklist

Verifying who is on the other end

Session has no usernames tied to a directory and no verified-account badge. An Account ID is a long hexadecimal string, which makes lookalike IDs easy to produce and hard for members to spot.

Exchange Account IDs out of band
- Scan a QR code in person, or confirm the full Account ID over a channel already authenticated by other means (a verified Signal thread, a signed message, a video call).
Compare the entire string, not the ends
- Vanity generation makes matching prefixes and suffixes cheap. Checking only the first and last characters is not a verification.
Re-verify after any device change
- A contact who reinstalled and restored keeps the same Account ID; a contact who created a new account does not. Treat an unexplained new Account ID as an impersonation attempt until proven otherwise.
Enable disappearing messages for sensitive threads
- Set per conversation. This limits what a later device compromise can expose.

Best practices for safe use

Keep the operator Account ID out of public Communities
- Posting in a Community exposes the Account ID to every member. Use a separate account for public moderation and a private one for team communication where the threat model warrants it.
Never act on inbound message requests alone
- Requests from unknown Account IDs claiming to be team members, support, or partners are the standard phishing pattern. Confirm through an established channel before responding.
Do not use Communities for confidential coordination
- Community messages are not end-to-end encrypted while stored on the Community server. Use groups or one-to-one conversations for anything sensitive.
Back up the recovery password before it is needed
- Account restoration is impossible after device loss without it. Store a copy in the same place the organization keeps other high-value secrets.
Verify links before opening them
- Session does not scan or reputation-check URLs. Assume any link from an unverified contact is hostile.

For team members

Team members who help moderate but do not administer Community servers should:

Configure every setting in the checklists above on their own account.
Store their recovery password in the organization's password manager, not in personal cloud storage.
Publish their Account ID through one canonical, project-controlled location so members can verify it, and state publicly that moderators never initiate direct messages.
Report impersonating Account IDs to admins rather than engaging with them.

For admins

These practices apply to operators who run Session groups and Communities.

Choosing groups or Communities

Feature	Groups	Communities
Encryption	End-to-end encrypted through the Session protocol	Not end-to-end encrypted on the Community server
Hosting	No dedicated server; carried by the Session Network	Requires a Session Open Group Server (SOGS) run by an operator
Scale	Small teams, roughly 100 members	Hundreds to thousands of members
Correct use	Team coordination, incident response, anything confidential	Public announcements and open community discussion

The decision is a security decision, not a capacity one. Move any thread that would damage the project if published into a group or a one-to-one conversation.

Community and server checklist

Understand who can read Community traffic
- Whoever operates the SOGS instance can read message content stored on it. Self-hosting moves that trust to the project; using a third-party server extends it to that operator.
Grant moderator capabilities at the minimum level
- SOGS permissions are granular — read, write, upload, and access. Give moderators what their job requires and nothing more, and keep the list of server administrators short.
Keep the admin list auditable
- Record who holds admin rights on which room, when it was granted, and why. Revoke immediately when someone leaves the team.
Harden the SOGS host like production infrastructure
- A self-hosted Community server is an internet-facing service. Apply the same patching, access control, backup, and monitoring standards used for other project infrastructure.
Publish an official channel list
- Community rooms are trivially cloned. Members need one authoritative, project-controlled page listing the real invite URLs and Account IDs.
Pin a support policy
- State explicitly that moderators never send the first direct message and never ask for seed phrases, wallet connections, or payments.
Plan for moderator account compromise
- Because there is no central account provider, response is local: remove the compromised Account ID's permissions on the server, announce the compromise, and re-establish the moderator under a new Account ID.