Zum Inhalt springen
Gini Logo
  • Lösungen
    • Spacing column
    • Menu image 1
    • Banken
      • Bezahlen per Foto
      • Payment Initiierung
      • Mobile Wallet
    • Versicherungen
      • In-App Payment
      • Mobile Belegerfassung
      • Smarter Einreichungsordner
    • Spacing column
  • Produkte
    • Spacing column
    • Menu image 2
    • Extrahieren
      • Gini Smart
      • Gini Smart OCR+
      • Gini Smart Mobile Input
    • Bezahlen
      • Gini Pay Connect
      • Fotoüberweisung
      • Gini Request-to-pay
    • Spacing column
  • Über uns
    • Spacing column
    • Menu image 3
    • Spacing column
    • Über Gini
      • Jobs
      • Blog
      • Presse
    • Spacing column
  • Entwickler
  • Kontakt
  • DE
  • EN
  • Lösungen
    • Banken
      • Bezahlen per Foto
      • Payment Initiierung
      • Mobile Wallet
    • Versicherungen
      • Mobile Belegerfassung
      • In-App Payment
      • Smarter Einreichungsordner
  • Produkte
    • Extrahieren
      • Gini Smart
      • Gini Smart OCR+
      • Gini Smart Mobile Input
    • Bezahlen
      • Gini Pay Connect
      • Fotoüberweisung
      • Gini Request-to-pay
  • Über uns
    • Über Gini
    • Jobs
    • Blog
    • Presse
  • Entwickler
  • Kontakt
  • DE
  • EN

Wie wir Geheimnisse teilen

How we share secrets

Gini

Mai 29, 2018 • 

6 min read

Sichere Übermittlung von Secrets intern und extern mit Partner-Start-ups und Unternehmen

Es gibt viele Möglichkeiten, private Nachrichten und Geheimnisse sicher auszutauschen: PGP/GnuPG, S/MIME und verschiedene hausgemachte oder kommerzielle Lösungen.

In einer perfekten Welt würden sich alle unsere Partner (andere würden sie Kunden nennen, aber wir sehen unsere Beziehung anders) auf einen Standard einigen, wenn es um den Austausch sensibler Informationen geht. Einige haben sich auf S/MIME geeinigt, andere auf PGP, viele betreiben ihre eigenen webbasierten Tools und einige wenige haben gar kein Verfahren im Einsatz. Das macht es uns schwer, effizient und schnell auf sichere Weise zu kommunizieren.

Eine große Herausforderung in Bezug auf die Kommunikation für unsere Fakultäten CSM (Customer Success Management) und TAM (Technical Account Management) ist die Verteilung eines ersten Satzes von Anmeldedaten für unsere Produkt-APIs (z.B. Gini Pay). Zu diesem Zeitpunkt haben wir oft noch keine etablierten Kommunikationswege und wir wollen, dass unsere Partner schnell loslegen können, ohne ihre Anmeldedaten zu gefährden.

.        .        .

 

Wie wir angefangen haben (und ja, das mag Dich etwas schockieren)

Zu Beginn einer neuen Partnerschaft interagieren wir meist mit den Produktspezialisten unseres zukünftigen Partners, und Verschlüsselung ist in dieser Phase ein schwieriges Thema. Um diese Sackgasse zu überwinden, wählten wir ein Muster, das zumindest einige Vorteile im Vergleich zu Klartext-E-Mails bot: Die Aufteilung der Geheimnisse und die Verwendung von zwei Kommunikationskanälen.

Je nach Partner konnte dies eine beliebige Kombination aus E-Mail, SMS, Telefonat oder Fax bedeuten. Du hast richtig gelesen – Fax.

Wir waren dringend auf der Suche nach einer sicheren Lösung, die für alle Partnerstufen und Szenarien funktionieren würde.

Version 1 – burn after reading

Es begann als Nebenprojekt und wurde schnell zum Tool der Wahl für den geheimen Nachrichtenaustausch hier bei Gini: “burn after reading” oder zu deutsch, “nach dem Lesen verbrennen”.

Die Idee ist alt (sie wurde kürzlich in Gmails „Nachricht mit Ablaufdatum“-Funktion wiederverwendet) und funktioniert wie folgt:
Du generierst eine eindeutige URL, die Du Deinem Partner im Klartext (z. B. per E-Mail) schicken kannst.
Dein Partner kann die URL im eigenen Browser öffnen, aber nur einmal.
Nachdem der Link besucht wurde, ist die Nachricht „verbrannt“ und kann nicht mehr aufgerufen werden.

Foto von Antony Xia auf Unsplash

Der Prototyp war eine kleine TLS-geschützte Web-Applikation, die in Go gebaut wurde und von einem netten In-Memory-Schlüsselwertspeicher namens go-cache angetrieben wurde, der von Patrick Mylund Nielsen geschrieben wurde. Der k/v-Speicher bot einen automatischen Verfall von Elementen nach einer bestimmten Zeit und wir entfernten das Element aus dem Speicher, wenn der Partner es ansah. Wenn jemand die E-Mail abfing und die Anmeldedaten ansah, wussten wir das (das Geheimnis wäre weg) und konnten entsprechend handeln.

Das Nutzungserlebnis war schon sehr gut und eine große Verbesserung zu unserem bisherigen Verfahren, aber es hatte auch einige Nachteile:

  • Geheimnisse werden im Speicher gehalten und ein erneutes Deployment oder ein Neustart des Servers löschte die Daten
  • Die Daten wurden unverschlüsselt im Speicher abgelegt

Es war Zeit für eine Neuimplementierung mit einem größeren Fokus auf Sicherheit – und hier betritt Vault die Bühne.

Version 2 – powered by Vault

Zu dieser Zeit haben wir viel mit Vault von HashiCorp experimentiert, und wenn Du es noch nicht ausprobiert hast, solltest Du heute damit anfangen. Die Verwendung von Vault für unsere Neuimplementierung brachte uns auf Anhieb eine Reihe von Vorteilen:

  • Die Daten sind nicht mehr an eine einzige Serverinstanz gebunden
  • Sichere Persistenz für Nachrichten im k/v-Speicher
  • Verhinderung des einfachen Ausprobierens von Geheimnissen mit HMAC
  • Automatischer Ablauf der Token (und zugehörigen Nachrichten)
  • Einrichtung von Hochverfügbarkeit und verbesserte Skalierbarkeit

Achtung! Wir werden jetzt einige Details der Vault-Integration behandeln. Wenn Du nicht mehr weiter weißt, besuch die hervorragende Vault-Dokumentation und -Anleitungen und vergiss nicht, wiederzukommen!

Wie Geheimnisse geboren werden und wie sie verschwinden:

Die Geburt eines Geheimnisses

  • Wenn ein neues Geheimnis in der Weboberfläche hinzugefügt wird, erstellt der Server ein neues Vault-Token. Dieses Token hat eine Time To Live (TTL), die dafür sorgt, dass eine ungelesene Nachricht nach einer bestimmten Anzahl von Nutzungen automatisch gelöscht wird. Die TTL kann nach Bedarf eingestellt werden.
  • Die Anzahl der Verwendungen ist immer 2 (1, um etwas in den Speicher zu schreiben + 1, um es später wieder abzurufen).
  • Der eigentliche Satz von Anmeldeinformationen wird in das Cubbyhole Vault Backend geschrieben. Jeder Token hat sein eigenes Cubbyhole, und das macht es zum perfekten Backend für unsere Geheimnisse. Dies erzwingt eine klare Trennung der gespeicherten Geheimnisse – der Zugriff auf ein Token gefährdet nicht die anderen Geheimnisse.
  • Zusätzliche Metadaten-Parameter werden in einem speziellen Bereich in einem gemeinsamen k/v-Backend gespeichert. Der Grund dafür ist, dass diese Parameter gelesen werden müssen, bevor das Geheimnis aus Cubbyhole geholt wird (z.B. ob eine akzeptierte GDPR-Erklärung erforderlich ist, bevor das Geheimnis offengelegt wird).
  • Ein eindeutiger Link wird aus dem Token, gefolgt vom HMAC des Tokens, generiert und an den Partner verteilt.

Töte es mit Feuer

  • Der Partner klickt auf den TLS-geschützten Link und der Server rendert eine HTML-Seite mit einer Enthüllungsschaltfläche.
  • Wenn die Schaltfläche angeklickt wird, extrahiert der Server das Token und den HMAC aus der URL und verifiziert den HMAC. Er verwendet das Vault Transit-Backend, um den HMAC-Schlüssel zu speichern und die Verifizierung durchzuführen. Dies fügt dem Geheimnis eine zusätzliche Schutzebene hinzu.
  • Sobald das Token validiert ist, wird es verwendet, um das Geheimnis aus Cubbyhole zu lesen. Der Token wird automatisch ungültig gemacht, da die Anzahl der Verwendungen nun erschöpft ist.
  • Eine HTML-Seite wird gerendert und das Geheimnis wird dem Partner angezeigt.

Zeit für einige Screenshots

Dies ist der Eingabebildschirm in unserem internen Self-Service-Portal. Wir verwenden die Slack-Webhook-Integration, um benachrichtigt zu werden, wenn ein Geheimnis gelüftet wird.

Erstellen eines Geheimnisses

 

Dies ist der Begrüßungsbildschirm, den der Partner sieht, wenn der Link geöffnet wird.

Der Willkommensbildschirm für unsere Partner

Zeit, das Geheimnis zu lüften.

Das Geheimnis ist gelüftet.

Fazit

Es ist nur ein kleines Tool, das wir gebaut haben, um eine Herausforderung im B2B2C-Markt zu bewältigen, aber es hat sich für uns als sehr wertvoll erwiesen.

Wir haben Vault und „Burn after reading“ in unser internes Self-Service-Portal integriert und beide passen perfekt zueinander. Das Feedback von internen Nutzern und Partnern war bisher großartig und wir haben noch keinen Partner gefunden, der es nicht benutzen kann.

Vault erwies sich als sehr flexibel und machte es einfach, gute Sicherheitsprinzipien auf unsere Implementierung anzuwenden. Es ist beruhigend, Krypto-Operationen an ein Tool delegieren zu können, das speziell für diesen Zweck entwickelt wurde.

Schreib uns, wenn Du mehr über die technischen Details der Implementierung wissen möchtest oder wenn Du andere Fragen hast. Wir freuen uns, sie alle zu beantworten!

 

.        .        .

 

Wenn Du bis hierher gelesen hast, schau Dir unsere offenen Stellen an. Wir sind immer auf der Suche nach exzellenten Technikern, die sich uns anschließen möchten!

Gini

The Gini Way is our place where you can learn how we do things around here. We are driven by culture, values, and creating happy people.

Wir bei Gini möchten mit unseren Beiträgen, Artikeln, Leitfäden, Whitepaper und Pressemitteilungen alle Menschen erreichen. Deshalb betonen wir, dass sowohl weibliche, männliche als auch anderweitige Geschlechteridentitäten dabei ausdrücklich angesprochen werden. Sämtliche Personenbezeichnungen beziehen sich auf alle Geschlechter, auch dann, wenn in Inhalten das generische Maskulinum genutzt wird.

Weitere Posts

Wie wir bei Gini Binärbilder erzeugen

Wie wir bei Gini Binärbilder erzeugen

Sep, 26 2022
Wie wir OCR mit Deep Learning betreiben

Wie wir OCR mit Deep Learning betreiben

Jun, 22 2022
Wie wir das Vertrauen in unsere Datenextraktionen vorhersagen

Wie wir das Vertrauen in unsere Datenextraktionen vorhersagen

Mai, 29 2020
Certificates

Footer list slide 1

Über 10 Jahre am Markt

Rechenzentrum in Deutschland

Footer list slide 2

Einbindung per SDK

ISO 27001 zertifiziert

Footer list slide 3

Datenextraktion in Echtzeit

Verschlüsselter Datentransport

Footer list mobile slide 1

Über 10 Jahre am Markt

Rechenzentrum in Deutschland

Einbindung per SDK

Footer list mobile slide 2

ISO 27001 zertifiziert

Datenextraktion in Echtzeit

Verschlüsselter Datentransport

Lösungen

  • Banken
  • Versicherungen

Ressourcen

  • Input Channel
  • Entwicklerressourcen
  • Status

Unternehmen

  • Übersicht
  • Jobs
  • Blog
  • Presse
  • Gini Handbook

Rechtliches

  • Impressum
  • Datenschutz
  • LinkedIn
  • Instagram
  • Kununu
  • Blog
  • Twitter
  • YouTube
  • Github

Kontakt

Vielen Dank!

Wie dürfen wir Dich ansprechen?

Damit wir uns auf unser erstes Gespräch mit Dir am besten vorbereiten können, verrate uns doch noch ein paar Details über dein Projekt:

Danke für deine Nachricht. Es wurde gesendet.
Beim Senden Ihrer Nachricht ist ein Fehler aufgetreten. Bitte versuchen Sie es später noch einmal.

Kontakt

Hi – wie können wir helfen?

Wie dürfen wir Dich ansprechen?

Damit wir uns auf unser erstes Gespräch mit Dir am besten vorbereiten können, verrate uns doch noch ein paar Details über dein Unternehmen:

Vielen Dank – deine Nachricht wurde gesendet.
Beim Senden der Nachricht ist ein Fehler aufgetreten – bitte versuche es später noch einmal.

Supportanfrage

Support ticket

Wie dürfen wir Dich ansprechen?

Bitte beschreibe uns dein Problem inklusive deiner Umgebung und der verwendeten Versionen.

Vielen Dank – deine Nachricht wurde gesendet.
Beim Senden der Nachricht ist ein Fehler aufgetreten – bitte versuche es später noch einmal.
Page load link
Nach oben