Sicherheit
Wie der Tresor gebaut ist und was man bei einem Einbruch vorfinden würde.
Letzte Aktualisierung: 21. September 2026 · AssuredAuth, von CircleRoll LLC
Dies ist die öffentliche Beschreibung, wie AssuredAuth Ihre Zwei-Faktor-Geheimnisse, Passwörter und Karten schützt. Sie ist so verfasst, dass sicherheitsbewusste Leser jede Aussage anhand der App und der veröffentlichten Testmethoden (auf Anfrage unter hello@assuredauth.com erhältlich) überprüfen können. Sie beschreibt die Fakten und nichts weiter: Nichts wird als unangreifbar dargestellt, und es werden keine prozentualen Sicherheitsversprechen gemacht.
Die Kurzfassung: Ihr Datenspeicher befindet sich an einem einzigen Ort – auf Ihrem Smartphone. Jeder darin gespeicherte Wert ist mit einem Schlüssel verschlüsselt, den die Sicherheitshardware Ihres Smartphones verwaltet und nicht weitergeben kann. Wir betreiben keinen Datenspeicher-Server, speichern keine Kopien und bewahren keinen Schlüssel auf. Eine Sicherungsdatei verlässt Ihr Smartphone erst, nachdem sie mit einer Passphrase verschlüsselt wurde, die niemals irgendwo gespeichert wird.
Ein Problem melden: hello@assuredauth.com. Siehe „Melden einer Schwäche“ am Ende.
1. Was wird verschlüsselt, womit?
| Daten | Am Telefon | Schlüssel |
|---|---|---|
| Zwei-Faktor-Geheimnisse (TOTP/HOTP/Steam-Samen) | Am TelefonKeychain (iOS) / Android Keystore-gestützter Shop | SchlüsselDer hardwaregebundene Schlüssel der Plattform; die Datenbankzeile enthält lediglich eine Referenz (secretRef), niemals den Seed. |
| Passwörter (der Passwortwert, Notizen) | Am TelefonVersiegelte Zeile: AES-256-GCM, eine zufällige 96-Bit-Nonce pro Wert | SchlüsselEin zufälliger 256-Bit-Datenschlüssel, der selbst vom Hardware-Schlüssel in §2 umschlossen ist. |
| Karten (Nummer, Ablaufdatum, Name auf der Karte, CVC) | Am TelefonGleiches Siegel wie Passwörter; der CVC ist optional und wird nur gespeichert, wenn Sie ihn eingeben. | SchlüsselGleicher Datenschlüssel |
| Metadaten (Dienstnamen, Benutzernamen, Symbole, Sortierreihenfolge) | Am TelefonDie Datenbank der App (SwiftData / Room) | SchlüsselDurch die Dateiverschlüsselung des Betriebssystems geschützt; als nicht geheim behandelt |
| Sicherungsdatei (.authbackup) | Am TelefonWo auch immer Sie es ablegen: Dateien, iCloud Drive, Google Drive-App-Datenordner, Freigabeblatt | SchlüsselEin Schlüssel, der aus Ihrer Passphrase abgeleitet wird (§3). Apple und Google erhalten die versiegelte Datei und sonst nichts. |
| Begleit-App für Watch / Wear | Am TelefonDer eigene Schlüsselbund der Uhr / Verschlüsselte SharedPreferences | SchlüsselDie Schlüssel der Uhrenplattform; übertragen über den gekoppelten Gerätekanal der Plattform. |
| Desktop-Erweiterungsdatenverkehr (einmalige Codes auf Anfrage) | Am TelefonNicht gespeichert; weitergeleitet als Ende-zu-Ende-verschlüsselte Umschläge | SchlüsselEin X25519-Schlüsselpaar pro Paarung, privater Schlüssel im Keychain/Keystore; das Relay sieht nur den Chiffretext. |
Die Diagnosefunktion bietet keine Methode, die ein Geheimnis akzeptiert. Kein Analyseereignis enthält ein Vault-Feld. In keinem Build wird jemals ein Wert aus dem Vault in ein Protokoll geschrieben.
2. Wo sich die Schlüssel befinden, auf jeder Plattform
iOS. Der Datenschlüssel ist durch einen in der Secure Enclave (kSecAttrTokenIDSecureEnclave) generierten Schlüssel geschützt. Dieser Schlüssel ist mit der Zugriffskontrolle .privateKeyUsage + .userPresence und der Barrierefreiheitseinstellung …ThisDeviceOnly in der gemeinsamen Keychain-Zugriffsgruppe der App verknüpft, sodass die AutoFill-Erweiterung denselben Schlüssel verwenden kann. Der private Schlüssel kann weder von der App noch von einem Backup oder einem Debugger aus der Enclave ausgelesen werden. Die Enclave stimmt seiner Verwendung erst zu, nachdem der Benutzer anwesend ist (Face ID, Touch ID oder Gerätepasswort). „ThisDeviceOnly“ bedeutet, dass ein iCloud- oder iTunes-Backup des Telefons den Schlüssel nicht enthält. Ein wiederhergestelltes Telefon startet mit einem leeren Tresor und fragt nach der Backup-Datei und der Passphrase. Ein Telefon ohne Passcode kann keinen .userPresence-Schlüssel absichern (die Enclave weigert sich, einen solchen zu erstellen), und der Simulator geht absichtlich den gleichen Weg (seine Anwesenheitsabfrage ist eine Warnung, die kein Test beantworten kann): Dort ist der Datenschlüssel ein einfaches, nur auf dem Gerät vorhandenes Keychain-Element – immer noch nicht in jedem Backup enthalten, immer noch unlesbar, solange das Telefon gesperrt ist, aber ohne zweite Abfrage – und der Sicherheitsbildschirm sagt genau das und schlägt vor, einen Passcode festzulegen.
Android. Der Datenschlüssel ist in einen AndroidKeyStore-AES-256-Schlüssel eingebettet, der in StrongBox generiert wird, sofern das Gerät über einen solchen Schlüssel verfügt (ansonsten in der TEE). Dabei sind `setUserAuthenticationRequired(true)` und eine Gültigkeitsdauer der Authentifizierung von 30 Sekunden nach biometrischer oder Geräteauthentifizierung aktiviert. Die Optionen `setUnlockedDeviceRequired(true)` und `setInvalidatedByBiometricEnrollment(true)` sind ebenfalls aktiviert. Letztere Option dient lediglich der Sicherheit und hat keine Systemlast: Android wendet sie nur auf Schlüssel an, die bei jeder Nutzung eine biometrische Authentifizierung erfordern. Bei diesem 30-Sekunden-Schlüssel mit aktivierter Geräteauthentifizierung ändert sie daher nichts. Der Schutz vor unbefugtem Zugriff besteht darin, dass für die Registrierung eine PIN benötigt wird und das Entfernen der Bildschirmsperre den Schlüssel dauerhaft ungültig macht. Keystore-Schlüssel sind nicht exportierbar und werden nicht in die Android-Cloud-Sicherung aufgenommen. Eine Domain, die eine App in ihren eigenen Ansichten (WebDomain) angibt, wird nur von einem bekannten Browser als gültig angesehen. Von jedem anderen Paket muss sie außerdem eine vom System für dieses Paket verifizierte Domain sein (Digital Asset Links), da jede App jede beliebige Domain beanspruchen kann.
Was dies für eine gestohlene Datenbankdatei bedeutet. Die SQLite-Datei und die darin enthaltenen verschlüsselten Zeilen sind verschlüsselter Text. Der Schlüssel zum Entschlüsseln befindet sich in der Sicherheitshardware des Telefons, von dem die Datei stammt, und kann nicht mit der Datei kopiert werden. Offline gibt es nichts zu erraten: Der Datenschlüssel ist zufällig und basiert nicht auf einer vom Benutzer gewählten Information.
3. Die Sicherungsdatei
Backups sind das Einzige, was das Telefon verlässt, daher sind sie prinzipiell die einzige Stelle, an der ein Offline-Angriff möglich ist. Das Design macht diesen Angriff teuer und bietet ihm so wenige Angriffsmöglichkeiten wie möglich:
- Die Passphrase hat mindestens 12 Zeichen (weniger nimmt das Formular nicht an, und es zeigt einen Stärkebalken).
- Es wird nirgendwo ein Hinweis auf die Passphrase gespeichert, weder in der Datei noch in der App.
- Für jede geschriebene Datei werden ein neuer, zufällig generierter 16-Byte-Salt und eine 12-Byte-Nonce verwendet.
- Der gesamte Datenkörper ist mit AES-256-GCM verschlüsselt, sodass eine falsche Passphrase oder eine beschädigte Datei abgelehnt und niemals zu Datenmüll entschlüsselt wird.
- Der Header (Format, Version, KDF-Parameter, Salt) wird als zusätzliche authentifizierte Daten in das GCM-Tag eingebunden, sodass eine Datei, deren Arbeitsfaktor reduziert wurde, nicht geöffnet werden kann.
Die Datei ist im JSON-Format und mit jedem Texteditor lesbar; nur der verschlüsselte Text ist undurchsichtig. Jemand, der die Datei in fünf Jahren findet, wenn die App nicht mehr existiert, kann genau sehen, wie sie verschlüsselt wurde, und sie mit OpenSSL oder einer beliebigen Argon2-Bibliothek öffnen.
Format v1 (in Version 1.0 enthalten, bleibt lesbar)
{
"format": "authbackup",
"version": 1,
"kdf": "PBKDF2-HMAC-SHA256",
"rounds": 600000,
"salt": "<base64, 16 bytes>",
"cipher": "AES-256-GCM",
"nonce": "<base64, 12 bytes>",
"ciphertext": "<base64>",
"tag": "<base64, 16 bytes>"
}| Schritt | Bytes |
|---|---|
key | PBKDF2-HMAC-SHA256(passphrase as UTF-8, salt, 600000 rounds, 32 bytes) |
aad | UTF-8("authbackup:1:600000:") ‖ salt (rohe Salt-Bytes, nicht Base64) |
ciphertext, tag | AES-256-GCM(key, nonce, plaintext, aad); Tag 16 Bytes, separat gespeichert |
plaintext | UTF-8 JSON, Schlüssel sortiert: {"accounts":[…],"exportedAt":"…Z","passwords":[…],"version":1} |
Hinweis zur Kompatibilität: Android 1.0 erzeugte eine Variante von v1 – KDF in Kleinbuchstaben, ohne Tag-Schlüssel (das 16-Byte-Tag, das an den Chiffretext angehängt wird) und ohne zusätzliche Daten. Beide Plattformen lesen diese Dateien weiterhin (wenn das Tag fehlt: die letzten 16 Bytes aufteilen, mit leerem AAD öffnen; KDF ohne Berücksichtigung der Groß-/Kleinschreibung vergleichen) und schreiben nun beide nur noch das oben beschriebene Layout.
Format v2 (aktuell; Standardeinstellung für neue Backups)
{
"format": "authbackup",
"version": 2,
"kdf": "Argon2id",
"memoryKiB": 65536,
"passes": 3,
"lanes": 1,
"salt": "<base64, 16 bytes>",
"cipher": "AES-256-GCM",
"nonce": "<base64, 12 bytes>",
"ciphertext": "<base64>",
"tag": "<base64, 16 bytes>"
}| Schritt | Bytes |
|---|---|
key | Argon2id(version 0x13, passphrase as UTF-8, salt, m = 65536 KiB, t = 3, p = 1, tagLength 32, no secret, no associated data) |
aad | UTF-8("authbackup:2:argon2id:65536:3:1:") ‖ salt |
ciphertext, tag | AES-256-GCM(key, nonce, plaintext, aad); Tag 16 Bytes, separat gespeichert |
plaintext | UTF-8 JSON, Schlüssel sortiert: {"accounts":[…],"cards":[…],"exportedAt":"…Z","passwords":[…],"version":2} |
Argon2id ist die Referenz-C-Implementierung (phc-winner-argon2, CC0), die auf beiden Plattformen verfügbar ist. 64 MiB und 3 Durchläufe benötigen auf einem aktuellen Smartphone etwa eine Sekunde, wodurch jeder Lesevorgang auf jeder Hardware diese Speicher- und Zeitkosten verursacht – eine Eigenschaft, die PBKDF2 gegenüber GPU-Systemen fehlt und der Grund für die Existenz von Version 2 ist. Ein Lesegerät ignoriert unbekannte Schlüssel, daher erkennt ein Version-1-Lesegerät mit einem Version-2-Gehäuse keine Karten.
Nachweis
Drei Testvektordateien (Backup v1, Backup v2 und Argon2id) werden von einer dritten, von beiden Anwendungen unabhängigen Implementierung generiert (Node.js OpenSSL für PBKDF2 und AES-GCM, ein WebAssembly-Argon2id, das bei der Generierung mit den veröffentlichten Antworten der Referenzimplementierung verglichen wird). Jede Datei enthält die Passphrase, das Salt, die Nonce, den Klartext, den abgeleiteten Schlüssel, den AAD, den erwarteten Chiffretext und das Tag sowie die vollständige Datei. Die Unit-Tests unter iOS und Android lesen dieselben Dateien und prüfen dieselben Bytes. Somit ist bewiesen, nicht nur angenommen, dass ein auf einer Plattform versiegeltes Backup auf der anderen Plattform geöffnet werden kann, und die Übereinstimmung aller drei Tests bedeutet nicht, dass es sich um zwei Kopien desselben Fehlers handelt. Ein Begleittool öffnet eine Datei, die ein Telefon tatsächlich mit derselben dritten Implementierung geschrieben hat, und überprüft den Header anhand der oben genannten Regeln (exakt die Schlüssel des Formats, sodass kein Hinweis oder Name vorhanden sein darf; 16-Byte-Salt, 12-Byte-Nonce, 16-Byte-Tag separat gespeichert; Version 2 bei genau 64 MiB / 3 / 1; falsche Passphrase abgelehnt); der automatisierte iOS-Lauf schreibt eine solche Datei auf den Simulator und öffnet sie auf diese Weise und durchsucht den App-Container, den App-Gruppen-Container und die Schlüsselbunddatenbank des Simulators nach jedem eingegebenen Passwort und jeder Kartennummer als UTF-8 und UTF-16 (0 Treffer).
4. Bedrohungsmodell
| Situation | Was sie haben | Was sie bekommen |
|---|---|---|
| Telefon verloren oder gestohlen, gesperrt | Was sie habenDas Gerät, die Datenbankdatei, die versiegelten Zeilen | Was sie bekommenDer verschlüsselte Text befindet sich in der sicheren Enklave/dem Tresor und wird erst nach Gerätesperre und Eingabe eines neuen biometrischen Datencodes oder Passworts freigegeben. Das Fernlöschen des Telefons (Mein Gerät suchen) vernichtet auch das Schlüsselmaterial. |
| Gestohlene Sicherungsdatei | Was sie habenDie .authbackup-Datei aus einem Cloud-Konto, einer E-Mail, einem Laptop | Was sie bekommenEin AES-256-GCM-Verschlüsselungskörper mit einem Schlüssel, der aus einer mindestens 12-stelligen Passphrase abgeleitet wird, mit einem dateispezifischen Salt und Argon2id mit 64 MiB × 3 Durchläufen (v2) oder PBKDF2 mit 600.000 Runden (v1). Keine Hinweise, kein Benutzername, keine unverschlüsselte Kontenliste. Jeder Versuch erfordert die vollständige Ableitung des Verschlüsselungsschlüssels; es gibt keine Abkürzung. Eine starke Passphrase ist hier die einzige Verteidigung, und die App weist ausdrücklich darauf hin. |
| Gestohlenes Gerät mit entsperrtem Bildschirm | Was sie habenEin Telefon in Ihrer Hand, entsperrt | Was sie bekommenDie Codeliste. Der Tresor (Passwörter, Karten) ist durch die App-Sperre geschützt und wird automatisch nach Ablauf der festgelegten Zeit (sofort / 1 Min. / 5 Min.) wieder gesperrt. Ein entschlüsselter Wert ist nur so lange im Speicher vorhanden, wie er angezeigt wird. Die automatische Ausfüllfunktion und der Klartextexport fordern auch bei geöffneter App eine erneute biometrische Authentifizierung an. Aktivieren Sie die App-Sperre mit der Einstellung „Sofort“, falls Sie diesbezüglich Bedenken haben. |
| Schad-App auf demselben Telefon | Was sie habenSandbox einer anderen App, Zwischenablage, Barrierefreiheits- oder Overlay-Tricks | Was sie bekommenEs kann weder unsere Dateien lesen (Plattform-Sandboxing) noch unseren Schlüssel verwenden (der Schlüssel ist an unsere Signaturidentität und die Benutzerpräsenz gebunden). Kopien werden nach 30 Sekunden aus der Zwischenablage gelöscht; unter Android wird die Kopie als vertraulich gekennzeichnet und vom Verlauf der Zwischenablage ausgeschlossen. Die Tresorbildschirme sind unter Android auf FLAG_SECURE gesetzt (keine Screenshots, keine Bildschirmaufzeichnung, leerer Bildschirmwechsler); unter iOS wird das Vorschaubild des Bildschirmwechslers ausgeblendet. Die automatische Ausfüllfunktion unter Android wird nur Apps zur Verfügung gestellt, die das System anhand der gespeicherten Domain (Digital Asset Links) verifiziert hat, sodass einer ähnlich aussehenden App Ihr Passwort nicht angeboten wird. |
| Phishing-Seite | Was sie habenEine Webseite, die der von Ihnen gespeicherten Webseite ähnelt. | Was sie bekommenEs werden keine Einträge ausgefüllt. Der Abgleich erfolgt anhand der registrierbaren Domain (öffentliche Suffixliste, die mit der App mitgeliefert und aktualisiert wird): login.example.com und example.com stimmen überein, example.com.evil.net und example1e.com hingegen nicht. Der In-App-Browser gleicht die Einträge auf dieselbe Weise ab und füllt sie nur in den angeforderten Frame aus. Dabei wird der Ursprung dieses Frames zum Zeitpunkt des Ausfüllens erneut überprüft. Ein Host ohne eigene registrierbare Domain – also eine IP-Adresse oder ein einfacher Name im lokalen Netzwerk – stimmt exakt überein. iOS AutoFill ergänzt Apples Prüfung auf zugehörige Domains. Ein Passwort, das manuell in ein ähnliches Feld eingefügt werden muss, birgt weiterhin ein Risiko; die App kann dieses Risiko nicht beseitigen, sondern lediglich verhindern, dass es auftritt. |
| Unsere eigenen Server | Was sie haben— | Was sie bekommenEs gibt keinen Tresorserver. AssuredAuth speichert weder Konten noch Anmeldungen oder eine Kopie Ihres Tresors. Daher befinden sich keine Ihrer Daten auf unserer Seite, die gestohlen oder geknackt werden könnten. Zwei serverseitige Prozesse laufen, die jedoch keinen Zugriff auf den Tresor haben: ein Relay-Postfach für die Desktop-Erweiterung, das Ende-zu-Ende-verschlüsselte Umschläge speichert (Einmalcodes, die nach dem Lesen gelöscht werden; das Relay besitzt niemals einen Schlüssel), und die Exit-Server der optionalen privaten Verbindung, die den Datenverkehr abwickeln und keine Zugriffsprotokolle führen. |
| Eine Vorladung oder eine Regierungsanfrage | Was sie habenAn uns gerichtete rechtliche Schritte | Was sie bekommenNichts, was wir aushändigen könnten: Wir besitzen weder einen Tresor, noch einen Schlüssel, noch eine Passphrase oder ein Backup. Wir können dazu gezwungen werden, das zu sagen; wir können aber nicht gezwungen werden, etwas vorzulegen, das nicht existiert. |
5. Zwischenablage, Screenshots und Speicher
- Beim Kopieren wird der Wert für 30 Sekunden in die Zwischenablage kopiert und anschließend gelöscht, falls er noch uns gehört. Unter Android ist der Eintrag mit „EXTRA_IS_SENSITIVE“ markiert, sodass er in der Zwischenablage-Vorschau und im Verlauf ausgeblendet wird; unter iOS ist der Eintrag nur lokal verfügbar (und wird nicht an andere Geräte weitergegeben).
- Die Tresorbildschirme (Passwörter, Passwort, Karten, Karte, Passphrasen-Tabellen, Klartext-Export) setzen unter Android das Flag FLAG_SECURE. iOS bietet kein entsprechendes Flag; die App blendet ihr Vorschaubild in der App-Übersicht aus, und die Werte werden standardmäßig hinter einem Augensymbol angezeigt.
- Entschlüsselte Werte bleiben nur so lange im Speicher, wie sie auf einem Bildschirm angezeigt werden, und gehen verloren, sobald der Bildschirm geschlossen oder die App gesperrt wird. Der Datenschlüssel wird für jede Anfrage entschlüsselt und nicht zwischengespeichert.
- Es gibt einen Klartext-Export (Sie können also jederzeit gehen), der durch ein Bestätigungsblatt und eine erneute biometrische Erfassung geschützt ist; auch der Bildschirm ist mit FLAG_SECURE gekennzeichnet.
6. Automatisches Ausfüllen: Was wird ausgefüllt und was nicht?
| Wo | Passwörter | Karten |
|---|---|---|
| iOS: Safari und Apps (AutoFill-Erweiterung) | PasswörterJa, nach einer erneuten Face ID-/Touch ID-/Passcode-Authentifizierung in der Erweiterung (LAContext) und nur für die registrierbare Domain, für die der Eintrag gespeichert wurde, mit Apples Überprüfung der zugehörigen Domains für Apps. | KartenNein. Die automatische Kartenausfüllfunktion in Safari ist eine Apple-eigene Funktion; auf dem Kartenbildschirm steht „Wird im AssuredAuth-Browser und mit Kopieren ausgefüllt“ und es wird nichts Weiteres versprochen. |
| Android: Apps und Chrome (AutofillService) | PasswörterJa, Authentifizierung pro Datensatz: Das System zeigt vor dem Ausfüllen eine biometrische Aufforderung an; das App-Paket wird nur dann zugeordnet, wenn Digital Asset Links es mit der gespeicherten Domäne verknüpft. | KartenJa, die Hinweise zu Kreditkartennummer, Kreditkartenablaufdatum* und Kreditkartensicherheitscode, gleiche biometrische Zugangskontrolle |
| Der AssuredAuth-Browser (beide Plattformen) | PasswörterJa, über eine registrierbare Domain – ein Host, der keine exakten Übereinstimmungen mit seinen eigenen Domains hat – in den Rahmen, der fragte, biometrisch vor dem Ausfüllen | KartenJa, durch Felderkennung, biometrische Daten vor dem Befüllen |
| Kopieren-Schaltflächen | PasswörterHinter der App-Sperre: 30-Sekunden-Zwischenablage | KartenNummer, Ablaufdatum, CVC (gleiche Regeln) |
Bei einem ähnlich aussehenden Host funktioniert nichts. Ohne biometrische Daten funktioniert nichts.
7. Was niemals passiert
Kein Tresorserver. Keine Analysen, die ein Tresorfeld verwenden. Kein Klartextexport ohne Bestätigungsformular und aktuelle biometrische Daten. Kein auf dem Tresorbildschirm geladenes Drittanbieter-SDK. Kein Screenshot des Tresorbildschirms. Kein Hinweis auf die Passphrase. Keine Protokollierung von Werten in irgendeiner Version.
8. Wovor wir uns nicht schützen können
Eine zu schwache Passphrase, um sie zu erraten. Ein Smartphone, dessen Betriebssystem von Grund auf kompromittiert ist (ein gerootetes oder gejailbreaktes Gerät kann der App falsche Angaben zu all den oben genannten Punkten machen). Eine Person, die beim Tippen überwacht wird. Schadsoftware auf dem Desktop, in den Sie Daten einfügen. Wir betonen dies, damit die obige Liste klar verstanden wird: Es geht um die Dinge, die ein Design verhindern kann.
9. Überprüfungsstatus
Dieses Design wurde auf beiden Plattformen anhand bekannter, veröffentlichter Lösungen und seiner eigenen plattformübergreifenden Vektoren getestet. Bevor der Tresor im Shop angeboten wird, steht eine externe Überprüfung auf dem Plan des Inhabers; bis dahin wird dies hier in diesem Dokument vermerkt.
10. Wo was läuft
Nichts aus dem Tresor verlässt das Telefon, aber einige zugehörige Prozesse laufen auf den Geräten anderer Nutzer. Die folgende Liste beschreibt die darin enthaltenen Daten; die Datenflüsse selbst sind in der Datenschutzerklärung unter https://assuredauth.com/privacy beschrieben.
- Google Cloud / Firebase – das Relay-Postfach für die Desktop-Erweiterung (Ende-zu-Ende-verschlüsselte Umschläge, die nach dem Lesen gelöscht werden), Push-Tokens, Kaufstatus und die über das Kontaktformular gesendeten Nachrichten.
- Vercel — securedauth.com, seine Seiten und die kleinen Funktionen dahinter.
- Vultr – die Exit-Server der privaten Verbindung. Der Datenverkehr wird über sie geleitet; es werden keine Daten gespeichert.
- Apple und Google Play – Käufe und Abonnements, in ihren jeweiligen Stores.
- PostHog – Produktanalyse: Zählt, was verwendet wird, ohne dabei auf eine bestimmte Person zurückzugreifen.
- RevenueCat – der Status eines Abonnements: aktiv oder abgelaufen, und auf welchem Tarif.
Jeder Eintrag enthält nur die Angaben seiner Zeile und keine Inhalte aus dem Archiv. Die Liste ändert sich mit dem Produkt, und dieser Abschnitt wird entsprechend angepasst.
Meldung einer Schwäche
Sollten Sie eine Schwachstelle in den hier beschriebenen Systemen entdeckt haben, schreiben Sie bitte an hello@assuredauth.com mit dem Betreff „Sicherheit“. Geben Sie dabei bitte die Plattform, die App-Version und die einzelnen Schritte an. Ein Nachweis mit Ihren eigenen Daten genügt. Bitte testen Sie nicht mit Daten anderer Personen. Wir stellen keinen PGP-Schlüssel zur Verfügung. Falls Ihr Bericht nicht unverschlüsselt per E-Mail übermittelt werden soll, teilen Sie uns dies bitte in Ihrer ersten Nachricht mit. Wir finden dann eine alternative Lösung.
Was wir Ihnen im Gegenzug versprechen: Wir bestätigen den Eingang Ihrer Anfrage innerhalb von drei Werktagen, halten Sie während der Bearbeitung auf dem Laufenden, korrigieren Fehler, bevor etwas veröffentlicht wird, und nennen Sie hier als Urheber, falls gewünscht. Wir werden keine rechtlichen Schritte gegen Recherchen einleiten, die in gutem Glauben und im unten beschriebenen Rahmen durchgeführt wurden.
Im Geltungsbereich: die iOS- und Android-Apps, die Smartwatch-Apps, die Desktop-Erweiterung, assuranceauth.com und dessen API. Nicht im Geltungsbereich: der App Store und Google Play selbst, die oben genannten Anbieter, Social Engineering jeglicher Art und Denial-of-Service-Angriffe.
Derzeit gibt es keine Belohnung. Auf eine Meldung wird mit einer Lösung und einem Dankeschön geantwortet, nicht mit Geld.