Sicherheit

1The money

• Your card details never touch our servers. They live with Stripe (PCI-DSS Level 1 certified) or with Apple. We keep the amount and the transaction id, and nothing else.
• The amount is always decided by the server, never by the app. On none of the payment channels does the figure to credit come from the device: if it did, "pay €1 and credit myself €1,000" would be one HTTP request.
• Payment-provider notifications are signature-verified, and refused when in doubt. If the key to check a signature is missing, the notification is rejected — not accepted with an empty check. That is the difference between "I could not verify, so no" and "I could not verify, so yes".
• A refund really reverses. The credit and the leaderboard position are undone, once, even if the provider sends three notifications about the same refund.

2Deletion, and what survives it

When you delete your account you disappear from every public surface immediately and stay restorable for six months. After that the row is anonymised: unroutable e-mail, neutral name, emptied profile, messages and friendships deleted.

Payments are never deleted, not even then — and that is not an oversight, it is the right decision made twice. The first version deleted them, and it also deleted payments other people had made to groups founded by whoever was leaving. Today erasure happens on the user row, not on the ledger: the accounting record stays and no longer identifies anyone.

3Signing in

• Passwords are stored with bcrypt (cost factor 12) and are not readable, not even by us. They appear in no log.
• Password recovery does not reveal whether an address is registered. The answer is identical for an address that exists and one that does not: same text, same shape, and — the part that is usually missing — the same time. Every answer leaves at a fixed delay from the request, so the stopwatch cannot say what the words withhold.
• Resetting a password does not bypass two-step verification. If it is on, the reset asks for it anyway: otherwise access to a mailbox alone would defeat the second factor, and it would be theatre.
• Two-step verification secrets are encrypted at rest (AES-256-GCM), with different keys for users and for administrators: an administrator's secret cannot be decrypted with the users' key.
• A six-digit code works once. Reusing it within its thirty seconds does not work.
• Sessions are revoked instantly. A password change, switching off the second factor, "sign out everywhere" and deletion invalidate every session in progress and, at the same moment, close the real-time connections already open.

4Who can look inside

The administration panel lives on a separate subdomain and passes, in this order: Cloudflare's corporate access with a Google account, a closed list of permitted addresses, a dedicated password (bcrypt, unrelated to any user password) and a freshly generated six-digit code. Actions that write something ask for a new code every time, not once per session. A session lasts an hour.

Administrators are a separate table, with no link at all to the users' table. There is no "you are an administrator" column on your account: no vulnerability in the app can promote anyone, because there is nothing to promote. Administrator accounts are created only from the command line on the server.

Every administrative request goes into a log that is written and not deleted — including the refused ones, which today are most of them. Sensitive values in request bodies are redacted before being written.

5The infrastructure

• Everything is in Europe. Servers and database are in Germany, on machines dedicated to ImVIP and nothing else.
• The database is not exposed to the internet. It has no public port: it is reachable only from the inside.
• The server accepts connections only from Cloudflare's address ranges, IPv4 and IPv6, with the list refreshed automatically. Anyone trying to reach it directly gets no answer.
• Backups are encrypted before they leave the machine, with a public key: the server can make a backup and cannot read it back. Someone who broke into the server could not open yesterday's backups. The copies are then moved off the server.
• Encrypted connections everywhere, with HSTS for a year covering subdomains, plus the headers that stop a page loading third-party code or being framed inside somebody else's site.

6The code

• No query is built by pasting strings together. Database queries are always parameterised, and no system command is built as shell text.
• Uploaded images are rewritten. The filename is decided by the server (the one from the device is never used) and every image is re-encoded before it touches disk, so the original bytes are never stored or served.
• Privacy switches go through a single place. "Hide the amount" and "hide the country" are applied by one shared function: that is the fix to a defect this project genuinely had — a switch honoured on five screens and forgotten on the sixth.
• The tests run against the real code. The automated suites start the server's real routes and speak HTTP the way an app would, with hundreds of checks. One of them genuinely fails a payment halfway through its transaction, using a database trigger, to verify that half a credit can never be left behind.

7What we do NOT promise

This section exists because a security page that lists only the good parts is not a security page.

• Direct messages are not end-to-end encrypted by default. Unless a conversation has it switched on, the text is readable on our server. Why we have not switched it on is explained in the privacy policy.
• The leaderboard is public and copyable. The name, picture, bio, city and amount of the top thousand can be read without an account, and anyone can save them. That is the product, not a defect — but it is worth knowing before you write something in your bio.
• Search finds people on purpose. It exists to find a friend again, so it confirms that a display name exists. That is a choice, not an oversight.
• We do not yet run a vulnerability reward programme. If you find something, though, we would like to know straight away and we will answer: [email protected].

8Found a problem?

Write to [email protected] describing what you did and what you got. We answer, we tell you what we understood, and we let you know when it is fixed.

We ask only two things: do not touch other people's data, and do not degrade the service for people using it. Anyone who behaves that way will have no trouble from us.