Sicherheit

1. Das Modell in einem Absatz

Qint ist die Softwareschicht: Dashboard, Checkout, Rechnungen, API und Webhooks. Qint hält nie Kryptowerte und nie private Schlüssel. Einzahlungsadressen werden von unserer Execution Partnerin 24crypto ausgegeben, die eingehende Gelder verwahrt, umwandelt und auf das Bankkonto des Merchants auszahlt. Eine Kompromittierung von Qint kann keine Gelder bewegen; sie könnte höchstens die in der Datenschutzerklärung beschriebenen Daten offenlegen — darum geht es auf dieser Seite.

Die API läuft bei Fly.io in Frankfurt, die Datenbank ist eine Postgres-Instanz bei Neon in der EU (Frankfurt), und die Webanwendungen werden von Vercel ausgeliefert. Geheimnisse werden beim Deployment aus einem Secrets-Manager eingespielt und nicht im Code gespeichert.

2. Konten und Anmeldung

• Passwörter werden mit Argon2id gehasht (speicherintensiv, mit individuellem Salt) und in konstanter Zeit verglichen. Das Passwort selbst speichern oder protokollieren wir nie.
• E-Mail-Verifizierung ist vor der ersten Anmeldung Pflicht. Links sind einmalig und laufen nach 24 Stunden ab, Passwort-Reset-Links nach einer Stunde. Antworten verraten nicht, ob zu einer Adresse ein Konto besteht.
• Zwei-Faktor-Authentifizierung (TOTP, RFC 6238) steht allen Nutzerinnen und Nutzern optional zur Verfügung. Der Seed wird verschlüsselt gespeichert, Codes können nicht wiederverwendet werden, und zehn einmalige Wiederherstellungscodes werden einmal angezeigt und als Hash gespeichert. Das Deaktivieren von 2FA verlangt erneut das Passwort.
• Schutz vor Brute-Force. Anmeldeendpunkte sind auf 10 Anfragen pro Minute und IP-Adresse begrenzt. Fehlgeschlagene Anmeldungen werden mit IP-Adresse im Audit-Protokoll festgehalten.

3. Sitzungen

• Die Anmeldung setzt ein einziges Cookie, qint_session: HttpOnly, Secure, SameSite=Lax. Der Server speichert nur einen SHA-256-Hash des Sitzungstokens.
• Sitzungen verlängern sich bei Aktivität um 30 Tage und enden spätestens 90 Tage nach der Anmeldung. Abmelden widerruft die Sitzung; eine Passwortänderung widerruft alle anderen Sitzungen; ein Passwort-Reset widerruft alle Sitzungen.
• Jede Sitzung hält IP-Adresse und User-Agent fest, damit ungewöhnliche Aktivitäten geprüft werden können.

4. Rollen und Zugriffskontrolle

Jedes Teammitglied hat pro Merchant eine Rolle; die API setzt sie bei jeder Anfrage durch.

Teameinladungen sind an eine E-Mail-Adresse gebunden, einmalig und laufen nach sieben Tagen ab; nur ein Owner kann die Owner-Rolle vergeben. Unsere eigene Staff-Konsole kennt zwei Rollen, Admin und einen rein lesenden Moderator, und ist vom Merchant-Dashboard getrennt.

5. API-Schlüssel

• Schlüssel beginnen mit qk_live_, gefolgt von 32 zufälligen Zeichen. Sie werden genau einmal angezeigt.
• Gespeichert wird nur ein SHA-256-Hash, zusammen mit Präfix, Bezeichnung, Berechtigungen (Lesen, Schreiben), erstellender Person und Zeitpunkt der letzten Nutzung.
• Ein Widerruf wirkt sofort und wird im Audit-Protokoll festgehalten. Ein Schlüssel kann nicht von einem Merchant genutzt werden, der nicht für Zahlungen freigegeben ist.
• Die öffentliche API ist auf 120 Anfragen pro Minute und Schlüssel begrenzt.

6. Webhooks

• Jede Zustellung ist signiert: X-Qint-Signature: sha256=<HMAC-SHA256 des rohen Bodys>, berechnet mit dem Geheimnis des Endpunkts, plus eine X-Qint-Event-Id zur Deduplizierung.
• Signiergeheimnisse (whsec_…) werden einmal angezeigt und mit AES-256-GCM verschlüsselt gespeichert.
• Endpunkte müssen HTTPS verwenden und auf öffentliche IP-Adressen auflösen; Weiterleitungen werden nicht gefolgt, damit der Zustelldienst nicht auf interne Dienste gelenkt werden kann.
• Fehlgeschlagene Zustellungen werden nach 30 s, 2 min, 10 min, 30 min und 2 h wiederholt (insgesamt sechs Versuche) mit einem Timeout von 10 Sekunden, danach als «dead-lettered» markiert und im Zustellprotokoll des Dashboards angezeigt.

7. Integrität der Zahlungen

• Eine Zahlung durchläuft einen festen Zustandsautomaten — Initiated → Pending → Confirmed → Settled, mit Failed, Expired und Cancelled als Endzuständen — und die API weist jeden nicht erlaubten Übergang zurück. Unter- und Überzahlungen werden markiert, nicht stillschweigend akzeptiert.
• Das Erstellen einer Zahlung über die API ist idempotent: Ein Idempotenzschlüssel ist pro Merchant eindeutig, und eine wiederholte Anfrage liefert die ursprüngliche Zahlung zurück, statt eine zweite zu erzeugen. Anfragen an die Execution Partnerin tragen eigene Idempotenzschlüssel.
• Hintergrunddienste lassen veraltete Zahlungen ablaufen, gleichen den Zustand mit der Execution Partnerin ab und halten den Auszahlungsstatus synchron.

8. Audit-Protokoll

Sicherheitsrelevante Ereignisse — Anmeldungen und Fehlversuche, 2FA-Änderungen, Passwortänderungen und -Resets, Teamänderungen, Erstellen und Widerrufen von API-Schlüsseln, Exporte, Quittungs-E-Mails — werden mit handelnder Person, IP-Adresse und Zeitpunkt in ein Audit-Protokoll geschrieben. Die Anwendung verweigert das Ändern oder Löschen von Audit-Einträgen und AGB-Annahmen; sie können nur ergänzt werden.

9. Verschlüsselung und Härtung

• Übertragung: überall TLS. Die API sendet Strict-Transport-Security (ein Jahr, inklusive Subdomains).
• Ruhezustand: Die Datenbank wird vom Anbieter verschlüsselt. Zusätzlich verschlüsselt die Anwendung 2FA-Seeds, Webhook-Signiergeheimnisse, Zugangsdaten zur Execution Partnerin und Verifizierungs-Einladungs-E-Mails mit AES-256-GCM und speichert Passwörter, Sitzungstoken, API-Schlüssel, Wiederherstellungscodes sowie Einladungs- und Reset-Tokens nur als Hash.
• Header: X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: no-referrer. Eine Content Security Policy ist im Report-only-Modus ausgerollt, während sie feinjustiert wird.
• Ratenbegrenzung: 10 Anfragen pro Minute und IP für die Anmeldung, 120 pro Minute und IP für den Checkout, 120 pro Minute und Schlüssel für die API. Anfragekörper sind auf 1 MiB begrenzt.
• Origins: Dashboard und Checkout haben je eine eigene CORS-Freigabeliste; das Sitzungscookie wird nie seitenübergreifend gesendet.
• Client-IP-Verarbeitung: Weitergeleitete IP-Header werden nur akzeptiert, wenn sie ein gemeinsames Proxy-Geheimnis tragen, sodass Adressen im Audit-Protokoll nicht gefälscht werden können.

10. Überwachung

Anwendungsfehler werden, falls aktiviert, an Sentry gemeldet — so konfiguriert, dass standardmässig keine Personendaten und keine Performance-Traces gesendet werden. Webhook-Zustand, fehlgeschlagene Zustellungen und Abgleichdifferenzen sind in der Staff-Konsole sichtbar, und das Dashboard benachrichtigt Owner und Admins eines Merchants per E-Mail über Zahlungsprüfungen, Rückbuchungen, Verifizierungsstatus und Sperrungen.

11. Verwahrung und Auszahlungen

Gelder werden von 24crypto gehalten, einer der Selbstregulierungsorganisation VQF angeschlossenen Schweizer Finanzintermediärin. Qint speichert die Auszahlungs-IBAN des Merchants zur Kontoeinrichtung; Auszahlungsanfragen an die Execution Partnerin verweisen auf das dortige Konto des Merchants, und die Staff-Konsole zeigt die IBAN maskiert. Qint hat keine Wallet-Software, keine Signierschlüssel und keine Möglichkeit, Kryptowerte zu bewegen.

12. Eine Sicherheitslücke melden

Wenn Sie ein Sicherheitsproblem in Qint gefunden haben, schreiben Sie bitte an info@qint.ch. Beschreiben Sie, was Sie gefunden haben, wie es sich reproduzieren lässt und welcher Teil des Dienstes betroffen ist. Wir bestätigen Meldungen innerhalb von zwei Arbeitstagen, halten Sie während der Behebung auf dem Laufenden und nennen Sie auf Wunsch als Finder. Ein Bug-Bounty-Programm führen wir nicht.

Bitte testen Sie nur gegen Ihr eigenes Konto, greifen Sie nicht auf fremde Daten zu und verändern Sie keine, führen Sie keine Denial-of-Service-Tests durch und geben Sie uns angemessen Zeit zur Behebung, bevor Sie etwas veröffentlichen. Dieselben Angaben stehen unter /.well-known/security.txt.