Fallstudien
Zoho erzielt mit der Integration von Passkeys und dem Anmeldedaten-Manager 6‑mal schnellere Anmeldungen
Lesezeit: 10 Minuten
Als Android-Entwickler sind Sie ständig auf der Suche nach Möglichkeiten, die Sicherheit zu erhöhen, die Nutzerfreundlichkeit zu verbessern und die Entwicklung zu optimieren. Zoho, eine umfassende cloudbasierte Software-Suite mit Schwerpunkt auf Sicherheit und nahtlosen Abläufen, hat durch die Einführung von Passkeys in der OneAuth Android-App erhebliche Verbesserungen erzielt.
Seit der Integration von Passkeys im Jahr 2024 hat Zoho Anmeldegeschwindigkeiten erreicht, die bis zu 6‑mal schneller sind als bei früheren Methoden. Außerdem wurde ein monatliches Wachstum von 31% bei der Einführung von Passkeys verzeichnet.
In dieser Fallstudie wird die Einführung von Passkeys und der Credential Manager API von Android bei Zoho untersucht, um Authentifizierungsprobleme zu beheben. Dabei wird der technische Implementierungsprozess detailliert beschrieben und die wirkungsvollen Ergebnisse hervorgehoben.
Authentifizierungsprobleme beheben
Zoho verwendet eine Kombination aus Authentifizierungsmethoden, um Nutzerkonten zu schützen. Dazu gehörte Zoho OneAuth, die eigene Multi-Faktor-Authentifizierungslösung (MFA), die sowohl die passwortbasierte als auch die passwortlose Authentifizierung mit Push-Benachrichtigungen, QR-Codes und zeitbasierten Einmalpasswörtern (TOTP) unterstützte. Zoho unterstützte auch Verbundanmeldungen, die die Authentifizierung über Security Assertion Markup Language (SAML) und andere Identitätsanbieter von Drittanbietern ermöglichten.
Herausforderungen
Wie viele andere Unternehmen wollte auch Zoho die Sicherheit und Nutzerfreundlichkeit bei der Authentifizierung verbessern und gleichzeitig den Betriebsaufwand reduzieren. Zu den wichtigsten Herausforderungen, die zur Einführung von Passkeys führten, gehörten:
- Sicherheitslücken: Bei herkömmlichen passwortbasierten Methoden waren Nutzer anfällig für Phishing-Angriffe und Passwortlecks.
- Nutzerprobleme: Passwortmüdigkeit führte zu vergessenen Passwörtern, Frustration und einer verstärkten Nutzung umständlicher Wiederherstellungsprozesse.
- Betriebliche Ineffizienzen: Die Bearbeitung von Passwortzurücksetzungen und MFA-Problemen verursachte erhebliche Supportkosten.
- Skalierbarkeitsprobleme: Eine wachsende Nutzerbasis erforderte eine sicherere und effizientere Authentifizierungslösung.
Warum der Wechsel zu Passkeys?
Passkeys wurden in den Apps von Zoho implementiert, um Authentifizierungsprobleme zu beheben. Sie bieten einen passwortlosen Ansatz, der die Sicherheit und Nutzerfreundlichkeit erheblich verbessert. Diese Lösung nutzt eine phishingresistente Authentifizierung, cloudsynchronisierte Anmeldedaten für den mühelosen Zugriff über verschiedene Geräte hinweg sowie biometrische Daten (z. B. Fingerabdruck oder Gesichtserkennung), eine PIN oder ein Muster für sichere Anmeldungen. Dadurch werden die Schwachstellen und Unannehmlichkeiten, die mit herkömmlichen Passwörtern verbunden sind, reduziert.
Durch die Einführung von Passkeys mit dem Anmeldedaten-Manager konnte Zoho die Anmeldezeiten um das bis zu 6‑Fache verkürzen, die supportbezogenen Kosten für Passwörter senken und eine starke Nutzerakzeptanz erzielen. Die Anzahl der Passkey-Anmeldungen hat sich in 4 Monaten verdoppelt und es wurde ein monatliches Wachstum von 31% verzeichnet. Zoho-Nutzer profitieren jetzt von schnelleren, einfacheren Anmeldungen und phishingresistenter Sicherheit.
Implementierung mit dem Anmeldedaten-Manager unter Android
Wie hat Zoho diese Ergebnisse erzielt? Das Unternehmen hat die Credential Manager API von Android verwendet, die empfohlene Jetpack-Bibliothek für die Implementierung der Authentifizierung unter Android.
Der Anmeldedaten-Manager bietet eine einheitliche API, die die Handhabung der verschiedenen Authentifizierungsmethoden vereinfacht. Statt verschiedene APIs für Passwörter, Passkeys und Verbundanmeldungen (z. B. „Über Google anmelden“) zu verwenden, nutzen Sie eine einzige Schnittstelle.
Die Implementierung von Passkeys bei Zoho erforderte sowohl client- als auch serverseitige Anpassungen. Hier finden Sie eine detaillierte Aufschlüsselung des Prozesses zur Erstellung von Passkeys, zur Anmeldung und zur serverseitigen Implementierung.
Passkey erstellen
Um einen Passkey zu erstellen, ruft die App zuerst Konfigurationsdetails vom Server von Zoho ab. Dieser Prozess umfasst eine eindeutige Bestätigung, z. B. per Fingerabdruck oder Gesichtserkennung. Diese Bestätigungsdaten, formatiert als requestJson-String, werden von der App verwendet, um eine CreatePublicKeyCredentialRequest zu erstellen. Die App ruft dann die Methode credentialManager.createCredential auf, die den Nutzer auffordert, sich mit der Displaysperre des Geräts zu authentifizieren (biometrische Daten, Fingerabdruck, PIN usw.).
Nach der erfolgreichen Bestätigung durch den Nutzer erhält die App die neuen Passkey-Anmeldedaten, sendet sie zur Bestätigung an den Server von Zoho und der Server speichert die Passkey-Informationen, die mit dem Konto des Nutzers verknüpft sind. Fehler oder Nutzerabbrüche während des Prozesses werden von der App erfasst und verarbeitet.
Anmeldung
Die Android-App von Zoho initiiert den Passkey-Anmelde-Prozess, indem sie Anmeldeoptionen, einschließlich einer eindeutigen challenge, vom Backend-Server von Zoho anfordert. Die App verwendet diese Daten dann, um eine GetCredentialRequest zu erstellen, die angibt, dass die Authentifizierung mit einem Passkey erfolgt. Anschließend ruft sie die Android-API CredentialManager.getCredential() mit dieser Anfrage auf. Diese Aktion löst eine standardisierte Android-Systemschnittstelle aus, die den Nutzer auffordert, sein Zoho-Konto auszuwählen (wenn mehrere Passkeys vorhanden sind) und sich mit der konfigurierten Displaysperre des Geräts zu authentifizieren (Fingerabdruck, Gesichtsscan oder PIN). Nach erfolgreicher Authentifizierung gibt der Anmeldedaten-Manager eine signierte Assertion (Anmeldebestätigung) an die Zoho-App zurück. Die App leitet diese Assertion an den Server von Zoho weiter, der die Signatur mit dem gespeicherten öffentlichen Schlüssel des Nutzers vergleicht und die Challenge bestätigt. Damit ist der sichere Anmeldeprozess abgeschlossen.
Serverseitige Implementierung
Der Übergang von Zoho zur Unterstützung von Passkeys wurde dadurch erleichtert, dass die Backend-Systeme bereits FIDO WebAuthn-konform waren. Das optimierte den serverseitigen Implementierungsprozess. Dennoch waren bestimmte Änderungen erforderlich, um die Passkey-Funktionalität vollständig zu integrieren.
Die größte Herausforderung bestand darin, das System zur Speicherung von Anmeldedaten anzupassen. Die vorhandenen Authentifizierungsmethoden von Zoho, bei denen hauptsächlich Passwörter und FIDO-Sicherheitsschlüssel für die Multi-Faktor-Authentifizierung verwendet wurden, erforderten andere Speicheransätze als Passkeys, die auf kryptografischen öffentlichen Schlüsseln basieren. Um dieses Problem zu beheben, hat Zoho ein neues Datenbankschema implementiert, das speziell für die sichere Speicherung von öffentlichen Passkey-Schlüsseln und zugehörigen Daten gemäß den WebAuthn-Protokollen entwickelt wurde. Dieses neue System wurde zusammen mit einem Suchmechanismus entwickelt, um Anmeldedaten basierend auf Nutzer- und Geräteinformationen zu bestätigen und abzurufen. So wird die Abwärtskompatibilität mit älteren Authentifizierungsmethoden gewährleistet.
Eine weitere serverseitige Anpassung war die Implementierung der Möglichkeit, Anfragen von Android-Geräten zu verarbeiten. Passkey-Anfragen, die von Android-Apps stammen, verwenden ein eindeutiges Ursprungsformat (android:apk-key-hash:example), das sich von Standard-Webursprüngen unterscheidet, die ein URI-basiertes Format verwenden (https://example.com/app). Die Serverlogik musste aktualisiert werden, um dieses Format korrekt zu parsen, den SHA-256-Fingerabdruck-Hash des Signaturzertifikats der App zu extrahieren und ihn mit einer vorregistrierten Liste zu vergleichen. Dieser Bestätigungsschritt stellt sicher, dass Authentifizierungsanfragen tatsächlich von der Android-App von Zoho stammen, und schützt vor Phishing-Angriffen.
Dieser Code-Snippet zeigt, wie der Server nach dem Android-spezifischen Ursprungsformat sucht und den Zertifikats-Hash bestätigt:
val origin: String = clientData.getString("origin")
if (origin.startsWith("android:apk-key-hash:")) {
val originSplit: List<String> = origin.split(":")
if (originSplit.size > 3) {
val androidOriginHashDecoded: ByteArray = Base64.getDecoder().decode(originSplit[3])
if (!androidOriginHashDecoded.contentEquals(oneAuthSha256FingerPrint)) {
throw IAMException(IAMErrorCode.WEBAUTH003)
}
} else {
// Optional: Handle the case where the origin string is malformed }
}
Fehlerbehandlung
Zoho hat robuste Fehlerbehandlungsmechanismen implementiert, um sowohl nutzer- als auch entwicklerseitige Fehler zu verwalten. Ein häufiger Fehler, CreateCredentialCancellationException, trat auf, wenn Nutzer die Passkey-Einrichtung manuell abgebrochen haben. Zoho hat die Häufigkeit dieses Fehlers erfasst, um potenzielle Verbesserungen der Nutzerfreundlichkeit zu bewerten. Basierend auf den UX-Empfehlungen von Android hat Zoho Maßnahmen ergriffen, um Nutzer besser über Passkeys zu informieren, sie auf die Verfügbarkeit von Passkeys aufmerksam zu machen und die Einführung von Passkeys bei nachfolgenden Anmeldeversuchen zu fördern.
Dieses Codebeispiel zeigt, wie Zoho die häufigsten Fehler bei der Erstellung von Passkeys behandelt hat:
private fun handleFailure(e: CreateCredentialException) {
val msg = when (e) {
is CreateCredentialCancellationException -> {
Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_SETUP_CANCELLED", GROUP_NAME)
Analytics.addNonFatalException(e)
"The operation was canceled by the user."
}
is CreateCredentialInterruptedException -> {
Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_SETUP_INTERRUPTED", GROUP_NAME)
Analytics.addNonFatalException(e)
"Passkey setup was interrupted. Please try again."
}
is CreateCredentialProviderConfigurationException -> {
Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_PROVIDER_MISCONFIGURED", GROUP_NAME)
Analytics.addNonFatalException(e)
"Credential provider misconfigured. Contact support."
}
is CreateCredentialUnknownException -> {
Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_SETUP_UNKNOWN_ERROR", GROUP_NAME)
Analytics.addNonFatalException(e)
"An unknown error occurred during Passkey setup."
}
is CreatePublicKeyCredentialDomException -> {
Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_WEB_AUTHN_ERROR", GROUP_NAME)
Analytics.addNonFatalException(e)
"Passkey creation failed: ${e.domError}"
}
else -> {
Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_SETUP_FAILED", GROUP_NAME)
Analytics.addNonFatalException(e)
"An unexpected error occurred. Please try again."
}
}
}
Passkeys in Intranet-Umgebungen testen
Zoho stand vor einer ersten Herausforderung beim Testen von Passkeys in einer geschlossenen Intranet-Umgebung. Für den Bestätigungsprozess von Passkeys im Google Passwortmanager ist ein öffentlicher Domainzugriff erforderlich, um die Domain der vertrauenden Partei (Relying Party, RP) zu bestätigen. In der internen Testumgebung von Zoho fehlte jedoch dieser öffentliche Internetzugriff, was dazu führte, dass der Bestätigungsprozess fehlschlug und erfolgreiche Tests der Passkey-Authentifizierung verhindert wurden. Um dieses Problem zu beheben, hat Zoho eine öffentlich zugängliche Testumgebung erstellt, in der ein temporärer Server mit einer Asset-Link-Datei und Domainbestätigung gehostet wurde.
Dieses Beispiel aus der Datei assetlinks.json, die in der öffentlichen Testumgebung von Zoho verwendet wird, zeigt, wie die Domain der vertrauenden Partei mit der angegebenen Android-App für die Passkey-Bestätigung verknüpft wird.
[
{
"relation": [
"delegate_permission/common.handle_all_urls",
"delegate_permission/common.get_login_creds"
],
"target": {
"namespace": "android_app",
"package_name": "com.zoho.accounts.oneauth",
"sha256_cert_fingerprints": [
"SHA_HEX_VALUE"
]
}
}
]
In einen vorhandenen FIDO-Server einbinden
Das Passkey-System von Android verwendet den modernen FIDO2 WebAuthn-Standard. Dieser Standard erfordert Anfragen in einem bestimmten JSON-Format, was dazu beiträgt, die Konsistenz zwischen nativen Anwendungen und Webplattformen aufrechtzuerhalten. Um die Unterstützung von Android-Passkeys zu ermöglichen, hat Zoho geringfügige Kompatibilitäts- und Strukturänderungen vorgenommen, um Anfragen korrekt zu generieren und zu verarbeiten, die der erforderlichen FIDO2-JSON-Struktur entsprechen.
Dieses Serverupdate umfasste mehrere spezifische technische Anpassungen:
1. Codierungskonvertierung:Der Server konvertiert die Base64-URL-Codierung (die häufig in WebAuthn für Felder wie Anmeldedaten-IDs verwendet wird) in die Standard-Base64-Codierung, bevor er die relevanten Daten speichert. Der folgende Snippet zeigt, wie eine rawId in Standard-Base64 codiert werden kann:
// Convert rawId bytes to a standard Base64 encoded string for storage val base64RawId: String = Base64.getEncoder().encodeToString(rawId.toByteArray())
2. Transportlistenformat:Um eine konsistente Datenverarbeitung zu gewährleisten, verarbeitet die Serverlogik Listen von Transportmechanismen (z. B. USB, NFC und Bluetooth, die angeben, wie der Authentifikator kommuniziert) als JSON-Arrays.
3. Abstimmung der Clientdaten:Das Zoho-Team hat angepasst, wie der Server das Feld „clientDataJson“ codiert und decodiert. So wird sichergestellt, dass die Datenstruktur genau den Erwartungen der vorhandenen internen APIs von Zoho entspricht. Das folgende Beispiel veranschaulicht einen Teil der Konvertierungslogik, die auf Clientdaten angewendet wird, bevor der Server sie verarbeitet:
private fun convertForServer(type: String): String {
val clientDataBytes = BaseEncoding.base64().decode(type)
val clientDataJson = JSONObject(String(clientDataBytes, StandardCharsets.UTF_8))
val clientJson = JSONObject()
val challengeFromJson = clientDataJson.getString("challenge")
// 'challenge' is a technical identifier/token, not localizable text.
clientJson.put("challenge", BaseEncoding.base64Url()
.encode(challengeFromJson.toByteArray(StandardCharsets.UTF_8)))
clientJson.put("origin", clientDataJson.getString("origin"))
clientJson.put("type", clientDataJson.getString("type"))
clientJson.put("androidPackageName", clientDataJson.getString("androidPackageName"))
return BaseEncoding.base64().encode(clientJson.toString().toByteArray())
}
Nutzeranleitung und Authentifizierungseinstellungen
Ein zentraler Bestandteil der Passkey-Strategie von Zoho war es, die Einführung durch Nutzer zu fördern und gleichzeitig Flexibilität zu bieten, um unterschiedlichen Unternehmensanforderungen gerecht zu werden. Dies wurde durch ein sorgfältiges UI-Design und Richtlinienkontrollen erreicht.
Zoho war sich bewusst, dass Unternehmen unterschiedliche Sicherheitsanforderungen haben. Um dem gerecht zu werden, hat Zoho Folgendes implementiert:
- Administratorerzwingung: Über das Admin-Panel von Zoho Directory können Administratoren Passkeys als obligatorische Standardauthentifizierungsmethode für das gesamte Unternehmen festlegen. Wenn diese Richtlinie aktiviert ist, müssen Mitarbeiter bei der nächsten Anmeldung einen Passkey einrichten und ihn künftig verwenden.
- Nutzerwahl:Wenn ein Unternehmen keine bestimmte Richtlinie erzwingt, behalten einzelne Nutzer die Kontrolle. Sie können bei der Anmeldung ihre bevorzugte Authentifizierungsmethode auswählen und in den Authentifizierungseinstellungen zwischen Passkeys und anderen konfigurierten Optionen wählen.
Um die Einführung von Passkeys für Endnutzer attraktiv und einfach zu gestalten, hat Zoho Folgendes implementiert:
- Einfache Einrichtung: Zoho hat die Passkey-Einrichtung direkt in die mobile App Zoho OneAuth eingebunden (verfügbar für Android und iOS). Nutzer können ihre Passkeys jederzeit bequem in der App konfigurieren, was den Übergang erleichtert.
- Konsistenter Zugriff:Die Passkey-Unterstützung wurde an wichtigen Nutzer-Touchpoints implementiert. So können sich Nutzer über Passkeys registrieren und authentifizieren:
- Mobile App Zoho OneAuth (Android und iOS)
- Seite „Zoho-Webkonten“
So wurde sichergestellt, dass der Prozess zum Einrichten und Verwenden von Passkeys zugänglich ist und in die bereits verwendeten Plattformen eingebunden wurde, unabhängig davon, ob er von einem Administrator vorgeschrieben oder vom Nutzer ausgewählt wurde. Weitere Informationen zum Erstellen reibungsloser Nutzerabläufe für die Passkey-Authentifizierung finden Sie in unserem umfassenden Leitfaden zur Nutzererfahrung mit Passkeys.
Auswirkungen auf die Entwicklergeschwindigkeit und die Effizienz der Integration
Der Anmeldedaten-Manager als einheitliche API hat auch die Produktivität von Entwicklern im Vergleich zu älteren Anmeldeabläufen verbessert. Er hat die Komplexität der separaten Handhabung mehrerer Authentifizierungsmethoden und APIs reduziert, was zu einer schnelleren Integration (von Monaten auf Wochen) und weniger Implementierungsfehlern geführt hat. Insgesamt wurde so der Anmeldeprozess optimiert und die Zuverlässigkeit verbessert.
Durch die Implementierung von Passkeys mit dem Credential Manager hat Zoho in allen Bereichen erhebliche, messbare Verbesserungen erzielt:
- Erhebliche Geschwindigkeitsverbesserungen
- 2‑mal schnellere Anmeldung im Vergleich zur herkömmlichen Passwortauthentifizierung
- 4‑mal schnellere Anmeldung im Vergleich zu Nutzername oder Mobiltelefonnummer mit E‑Mail- oder SMS-OTP-Authentifizierung
- 6‑mal schnellere Anmeldung im Vergleich zu Nutzername, Passwort und SMS- oder Authenticator-OTP-Authentifizierung
- Geringere Supportkosten
- Weniger supportbezogene Anfragen zu Passwörtern, insbesondere zu vergessenen Passwörtern.
- Geringere Kosten im Zusammenhang mit der SMS-basierten 2‑Faktor-Authentifizierung, da bestehende Nutzer direkt mit Passkeys einsteigen können
- Starke Nutzerakzeptanz und erhöhte Sicherheit
- Die Anzahl der Passkey-Anmeldungen hat sich in nur 4 Monaten verdoppelt, was eine hohe Nutzerakzeptanz zeigt.
- Nutzer, die zu Passkeys wechseln, sind vollständig vor häufigen Phishing- und Passwortlecks geschützt.
- Mit einem monatlichen Wachstum von 31% bei der Einführung profitieren täglich mehr Nutzer von erhöhter Sicherheit vor Schwachstellen wie Phishing und SIM-Swaps.
Empfehlungen und Best Practices
Für die erfolgreiche Implementierung von Passkeys unter Android sollten Entwickler die folgenden Best Practices berücksichtigen:
- Credential Manager API von Android nutzen:
- Der Anmeldedaten-Manager vereinfacht das Abrufen von Anmeldedaten, reduziert den Aufwand für Entwickler und sorgt für eine einheitliche Authentifizierung.
- Verarbeitet Passwörter, Passkeys und Verbundanmeldeabläufe über eine einzige Schnittstelle.
- Bei der Migration von anderen FIDO-Authentifizierungslösungen für eine konsistente Datencodierung sorgen
- Achten Sie darauf, dass bei der Migration von anderen FIDO-Authentifizierungslösungen wie FIDO-Sicherheitsschlüsseln ein einheitliches Format für alle Ein- und Ausgaben verwendet wird.
- Fehlerbehandlung und Logging optimieren:
- Implementieren Sie eine robuste Fehlerbehandlung für eine nahtlose Nutzererfahrung.
- Stellen Sie lokalisierte Fehlermeldungen bereit und verwenden Sie detaillierte Logs, um unerwartete Fehler zu beheben.
- Nutzer über Optionen zur Passkey-Wiederherstellung informieren:
- Verhindern Sie Sperrszenarien, indem Sie Nutzer proaktiv über Wiederherstellungsoptionen informieren.
- Einführungsstatistiken und Nutzerfeedback im Blick behalten:
- Erfassen Sie Nutzerinteraktionen, Einführungsraten für Passkeys und Anmeldeerfolgsraten, um die Nutzerfreundlichkeit weiter zu optimieren.
- Führen Sie A/B-Tests für verschiedene Authentifizierungsabläufe durch, um Conversion und Kundenbindung zu verbessern.
Passkeys in Kombination mit der Credential Manager API von Android bieten eine leistungsstarke, einheitliche Authentifizierungslösung, die die Sicherheit erhöht und gleichzeitig die Nutzerfreundlichkeit verbessert. Passkeys reduzieren das Risiko von Phishing, Anmeldedatendiebstahl und unbefugtem Zugriff erheblich. Wir empfehlen Entwicklern, die Lösung in ihrer App zu testen und ihren Nutzern die sicherste Authentifizierung zu bieten.
Erste Schritte mit Passkeys und dem Anmeldedaten-Manager
Mit unserem öffentlichen Beispielcode können Sie Passkeys und den Anmeldedaten-Manager unter Android testen.
Bei Fragen oder Problemen können Sie uns über den Issue Tracker für Android-Anmeldedaten informieren.
Weiterlesen
-
Fallstudien
Uber hat die Android Restore Credentials API genutzt, um die Anmeldung auf neuen Geräten zu optimieren. Dadurch werden voraussichtlich 4 Millionen manuelle Anmeldungen pro Jahr reduziert und die Kundenbindung erhöht.
Niharika Arora, Tracy Agyemang • Lesezeit: 5 Minuten
-
Fallstudien
X ist eine Social-Media-App, die fast 500 Millionen Nutzern weltweit aktuelle Nachrichten, Unterhaltung, Sport und Politik mit Live-Kommentaren bietet.
Niharika Arora, Tracy Agyemang • Lesezeit: 3 Minuten
-
Fallstudien
Wie FotMob die geräteübergreifende Suche genutzt hat, um die Einführung von Wear OS zu beschleunigen
FotMob hat vor Kurzem den größten Anstieg der Installationen auf Wear OS innerhalb eines Tages seit 5 Jahren verzeichnet. Die Anzahl der Installationen war 2‑ bis 3‑mal so hoch wie der Tagesdurchschnitt. Das Geheimnis? Ein einfacher geräteübergreifender Installationsablauf, mit dem Nutzer die Wear OS App direkt über ihr Smartphone finden können.
Garan Jenkin • Lesezeit: 3 Minuten
Auf dem Laufenden bleiben
Lassen Sie sich Woche für Woche die neuesten Informationen zur Android-Entwicklung zusenden.