Ein bestätigter Kontakt ist eine ganz bestimmte Aussage.
Wenn Sendity eine Kennung bestätigt, heißt das: Ein akzeptierter Kanal hat während dieser Verifizierung einen Nachweis der Kontrolle geliefert. Es heißt nicht, dass Sendity einen Ausweis geprüft, das Alter der Person festgestellt oder ihre Wohnanschrift bestätigt hat.
| Bestätigter Nachweis | Was er stützt | Was er nicht belegt |
|---|---|---|
| Ausgerichtete, per DKIM authentifizierte E-Mail | Kontrolle über die akzeptierte Absenderadresse während des Ablaufs. | Rechtliche Identität, alleinigen Zugriff auf das Postfach oder dauerhaftes Eigentum. |
| Vom Anbieter beobachtete WhatsApp-Nummer | Kontrolle über das WhatsApp-Konto, das zu dieser Nummer gehört, während des Ablaufs. | Aktuellen Besitz der SIM-Karte, einen echten Namen oder spätere fortbestehende Kontrolle. |
| Vom Anbieter beobachteter SMS-Absender | Den Nachweis über den Telefonkanal, der nach der SMS-Richtlinie Ihrer Kampagne akzeptiert wird. | Widerstandsfähigkeit gegen jeden Angriff über Mobilfunkanbieter, Weiterleitung oder Kontowiederherstellung. |
Namen aus dem Profil einer Person sind reine Anzeigedaten. Für eine freundliche Begrüßung können Sie den Namen verwenden, für eine Identitätsentscheidung nicht.
Absenderfelder brauchen einen unabhängigen Nachweis.
Echtheit von E-Mails
Eine E-Mail kann eine Absenderadresse angeben, ohne sie zu belegen. Der E-Mail-Weg von Sendity verlangt, dass DKIM erfolgreich geprüft wird und zur Absenderdomain passt. Ein passender Code ohne akzeptierten Echtheitsnachweis der E-Mail schließt die Verifizierung nicht ab. Mehr zur Echtheitsprüfung von E-Mails.
Offizielle Ereignisse von Telefonanbietern
WhatsApp läuft direkt über die Meta Cloud API. Sendity prüft die HMAC-Signatur über den unveränderten Request-Body, das konfigurierte Konto und die Business-Telefonnummer, den Zeitstempel der Nachricht und die Nachrichten-ID des Anbieters. Erforderlich ist eine vom Anbieter beobachtete Telefonnummer; ein Benutzername, ein Anzeigename oder eine unternehmensbezogene Nutzer-ID allein reichen nicht aus.
SMS läuft über den authentifizierten Webhook des unterstützten Anbieters und die Kanalrichtlinie der Anwendung. Inoffizielle Messenger-Clients, abgegriffene Sitzungen und beliebige Kontaktkarten werden nicht als Telefonnachweis akzeptiert.
Die Nachricht muss zu genau dieser Anfrage gehören.
Der kurze Code verknüpft eine eingehende Nachricht mit einer aktiven Challenge. Er läuft ab, und der akzeptierte Absendernachweis muss die Kanalregeln der Anfrage erfüllen. Nachrichten-IDs des Anbieters werden dedupliziert, sodass erneute Zustellversuche nicht als neue Verifizierungsereignisse gelten können.
Legen Sie die erlaubten Website-Origins fest und halten Sie Zugangsdaten der Anwendung und Geheimnisse der Anbieter auf dem Server. Ein öffentlicher Client-Schlüssel identifiziert Ihre Anwendung; er ersetzt keine Autorisierung im Backend.
Auch der Produktivbetrieb zählt. Gemeinsamer Cache und Locks koordinieren Challenges und Deduplizierung über mehrere Instanzen hinweg. Überwachen Sie fehlgeschlagene Zustellungen der Anbieter und Signaturfehler, und halten Sie Laufzeitumgebung und Abhängigkeiten aktuell. Open-Source-Code macht diese Abläufe überprüfbar; er betreibt oder sichert aber kein Deployment von selbst.
Der Browser ist die Oberfläche, nicht die Instanz, die entscheidet.
Ein abgeschlossenes Widget oder ein JavaScript-Ereignis kann Ihrer Seite helfen, zum nächsten Schritt zu gehen. Für die Freigabe eines Zugangs darf es nicht ausreichen. Ihr Backend muss die signierte Autorisierung, ihr Ablaufdatum und die vorgesehene Anwendung prüfen, bevor es der bestätigten Kennung vertraut.
Nutzen Sie die unterstützte Backend-Integration, um ein Konto anzulegen oder zu finden, eine eigene Sitzung Ihrer Anwendung auszustellen oder den ausstehenden Vorgang freizugeben. Halten Sie Kontoverknüpfung, Rollen, Einwilligungen und geschäftliche Berechtigungen explizit. Eine bestätigte Nummer ist keine Erlaubnis, zwei Konten zusammenzuführen oder eine sachfremde Zahlung zu autorisieren.
Planen Sie die Risiken ein, die kein Kanal beseitigen kann.
Ein kompromittiertes E-Mail- oder WhatsApp-Konto kann echte Nachrichten erzeugen. Durch Social Engineering kann jemand dazu gebracht werden, die Challenge eines Angreifers zu senden. Telefonnummern können den Besitzer wechseln, und gemeinsam genutzte Geräte können Konten für mehr als eine Person zugänglich machen. Eine codebasierte Kanalverifizierung ist nicht automatisch phishing-resistent.
Sorgen Sie für einen klaren Kontext der Aktion, angemessene Sitzungsdauern, Schutz vor Missbrauch und eine durchdachte Wiederherstellungsrichtlinie. Prüfen Sie bei Abläufen mit höherem Risiko, ob Passkeys oder ein anderer stärkerer Faktor angemessen sind. Stellen Sie die Verifizierung eines Kontakts nie als Garantie für die Identität oder für die Verhinderung von Betrug dar.
Wählen Sie gehostetes oder selbst gehostetes Sendity danach, wie Sie den Dienst betreiben möchten, und lesen Sie die Datenschutzhinweise für den gehosteten Dienst.