How Skalara protects your account

Your phone number identifies the account, but it is deliberately not the only thing standing between an attacker and it — because on Iranian mobile networks SMS is both the least reliable channel and the weakest one.

1. 1

   A code by SMS

   Proves you hold the number. It is single-use, expires quickly, and is spent the moment it is accepted so it cannot be used twice.

2. 2

   A password

   Stored as an argon2id hash. We cannot read it, cannot recover it for you, and neither can anyone who steals the database. New passwords are checked against known-breached passwords, keyboard runs, and your own username and number.

3. 3

   A passkey, or an authenticator app

   Both optional, both stronger than SMS. A passkey keeps its private half on your device and never sends it. An authenticator secret lives on a device your mobile carrier has no part in — which matters, because a SIM swap defeats SMS entirely.

4. 4

   Backup codes

   For when the phone is gone. Stored hashed, so a copy of our database yields no working codes. Generating a new set invalidates the old one immediately.

Adding or removing a passkey requires your password, and removing one is recorded. The threat that guards against is a stolen session rather than a stolen password: someone riding a hijacked session should not be able to plant a credential that survives you changing your password, nor strip the credentials you would use to get back in.

• Every session token is stored as a hash, never in a form we could hand over intact.
• Tokens rotate on every refresh. Presenting a retired one revokes the whole family of sessions it came from — so a stolen token is detected rather than quietly enjoyed for a month.
• Settings lists your active sessions with the browser and system each reported, and you can sign out of all the others in one action.
• An open connection re-checks that its session is still valid on a timer. Without that, "sign out everywhere" only took effect the next time a tab reconnected, and the one already attached kept receiving messages.

Message text and attachments are encrypted with AES-256-GCM before anything is written to disk, under a key derived separately for each conversation. Our database holds ciphertext. The storage that keeps your files holds nothing readable. The connection between your device and our servers is encrypted in transit.

What that buys you is real, and it is worth being precise about: someone who obtains a copy of the database — a stolen backup, a misconfigured server, a disk that left the building — gets ciphertext and nothing else. What it does not protect against is us, or anyone who can compel us.

Deleting a message destroys its content, including the encrypted bytes of any attached file. There is no hidden flag and no copy we can restore for you.

Most of the work here is about what cannot be learned by guessing.

• Account numbers are eighteen digits and drawn at random, not from a clock or a counter. Short is not what makes an ID risky; ordered is. A timestamped ID hands out your signup date, an estimate of how many accounts exist, and a range somebody can walk.
• Your phone number is stored alongside a keyed hash, so we can check whether a number is registered without scanning the numbers themselves.
• Your IP address is kept as a keyed hash rather than in the clear, so the security log can recognise a repeat address without holding a list of addresses.
• Friend requests are addressed by username. The few routes that take an account ID answer a suspended or missing account identically, so neither can be identified by probing.
• Your account number is shown only if you turn on Developer Mode, and the internal database ID is not shown anywhere at all.

• Your browser reaches ArvanCloud, never our origin servers directly. The origins are not addressable from the public internet.
• Every response carries a strict content security policy, so a script injected into a page has nowhere to send anything.
• HTTP Strict Transport Security means a browser that has visited once will not make a plaintext request again, even if you follow an old http:// link.
• Rate limits apply per account and per address at once, because each one alone can be hidden behind the other.
• Every mutating request carries a token that a cross-site attacker cannot read, so another site cannot act as you.

Worth stating in the same place as everything above, because a security page that lists only strengths is describing a product nobody has built.

• A lawful order. Skalara operates in Iran and complies with orders that are lawful on their face and issued by an authority with jurisdiction. We disclose the narrowest set of records that answers the order and never volunteer more.
• Someone with your unlocked device. No amount of server-side work helps once an attacker is holding a signed-in phone.
• Someone you chose to talk to. Anything you send can be screenshotted, saved or forwarded by the person receiving it.
• Metadata. Even with content encrypted, the record that a conversation exists and when it was active is data we hold.

The privacy policy sets out exactly what is retained, for how long, and who else handles it.

If you have found a vulnerability, tell us before you tell anyone else and give us a reasonable chance to fix it. Reports sent in good faith are welcome and will not be met with legal threats. Write to support@skalara.ir.