IT-Sicherheit ist heute in aller Munde. Jeder versteht etwas anderes darunter: Pen-Tests; Sicheres Coding oder Exploits; Antivirus, Antispam; Datenschutz; Immer noch Firewalls; Sicherheitsberatung; Identitymanagement; Authentifizierung. Das Thema „IT-Sicherheit“ ist  ein breites Spektrum. Und jeder beschäftigt sich deswegen auch mit „IT-Sicherheit“. Wir beschäftigen uns mit dem Spezialgebiet der sicheren oder starken Authentifizierung – der Mehr-Faktor-Authentifizierung.

Status Quo der proprietären Software und des Marktes

IT-Sicherheitsunternehmen sind eben oftmals sehr spezialisiert und daher eher kleine Unternehmen. Vor wenigen Jahren war dies noch ausgeprägter und viele wichtige Player am Markt hatten weniger als ein paar hundert Mitarbeiter weltweit.

Doch weil IT-Sicherheit in aller Munde kam, wurde das Thema und damit die Unternehmen auch im größeren Umfeld interessant und das Karussell der Merger and Akquisitions nahm Fahrt auf. Wer kennt noch Safeword Tokens? Secure Computing, Aladdin, SafeNet, Gemalto, Thales gaben und geben sich ein munteres Wechseln der Firmennamen und Produktlabels. Einstmals hatten Aladdin, SafeNet und Gemalto eigene Smartcard-Produkte und Portfolios. Diese sind nun endgültig in Gemalto aufgegangen. 

Bei einem Unternehmenszusammenschluss wächst das Unternehmen aber auch das Produktportfolio. Das ist wie nach Weihnachten – neues Spielzeug kommt, altes muss aus dem Kinderzimmer weichen! Und so wird auch das gewachsene Unternehmen sein Produktportfolio aufräumen und Produkte wie SafeWord 2008, SAM Express und dieses Jahr SafeNet Authentication Manager (der OTP-Teil) gehen End-of-Life.

Das Lebensende in einer proprietären Welt

Auch proprietäre Software-Produkte, die End-of-Life sind, müssen weggeschmissen werden.

Im Falle von proprietärer Software bedeutet End-of-Life oftmals auch das Aus für die Software. Hat der Hersteller die Software bspw. nach Benutzern lizensiert, ist es Ihnen als Kunde nach dem End-of-Life nicht möglich, auch nur eine weitere Benutzerlizenz für diese Software zu erwerben! Wenn Sie also nach dem End-of-Life zweite Faktoren für neue Benutzer im Unternehmen ausrollen wollen, dann ist auch das nicht mehr möglich. Sie haben nur 1000 Benutzer lizensiert? Der 1000-und-erste Benutzer kann in dem alten System keinen 2FA-Token mehr erhalten! Lizenz überschritten!

Nicht nur wegen des fehlenden Supports und der fehlenden Weiterentwicklung – Nein, sogar wegen der fehlenden Funktionalität sind Sie gezwungen von ihrem bestehenden System wegzumigrieren.

Zwar bieten Hersteller oftmals vermeintlich attraktive Migrationspfade zu dem anderen proprietären Produkt aus dem Portfolio an – doch Sie wissen selber, dass Migrationen mit hohem Kosten- und Zeitaufwand verbunden sind.

Painpoint: Mehr-Faktor-Authentifizierung

Die Migration eines Mehr-Faktor-System kann ungangenehme Schmerzfaktoren mit sich bringen. Zwei-Faktor-Authentifizierung bedeutet i.d.R. die Kombination aus Wissen und Besitz bei der Anmeldung. Der Besitzfaktor (Harward-Token oder eine registrierte Smartphone-App…) ist an das Backend gebunden und gleichzeitig an den Benutzer verteilt. Verteilt im Feld. Weltweit.

Im Extremfall kann die Migration eines Besitzfaktors also bedeuten, dass die da draußen verteilten Besitzfaktoren eingesammelt und neue Besitzfaktoren verteilt werden müssen.

Je nach Anzahl der Benutzer, Struktur Ihres Unternehmens, Workflows der Benutzer kann das ein langwieriger, teurer und schmerzhafter Prozess sein – selbst wenn das neue Produkt vom vermeindlich gleichen Hersteller kommt. (Dabei kommt es nicht vom gleichen Hersteller, sondern jetzt nach dem Merger nur aus dem gleichen Portfolio!)

privacyIDEA

Unsere Mitarbeiter sind seit 2004 im Bereich der Zwei- oder Mehr-Faktor-Authentifizierung tätig und können daher die Schmerzen der Kunden nachvollziehen. Diese Erfahrungen haben wir in privacyIDEA integriert.

Mit privacyIDEA ermöglichen wir Ihnen bereits seit einer Weile eine sanfte Migration. Ohne jeglichen Zeitdruck betreiben Sie privacyIDEA und Ihre alte Software parallel, ohne dass der Benutzer etwas davon merken muss. Peu à peu teilen Sie neue Token innerhalb von privacyIDEA aus.

Mit der kommenden Version 3.1 wird es außerdem möglich sein, die Seeds alter Token in privacyIDEA zu importieren und die Token den Benutzern automatisch zuzuordnen und die alte Token-PIN automatisch zu setzen. Kein Aufwand für die Benutzer, minimaler Aufwand für die IT.

Viele Kunden,  wie das Klinikum Hanau, vertrauen bereits auf privacyIDEA und haben erfolgreich migriert.

 

Und was bringt die Zukunft?

Und wenn Sie mal von privacyIDEA wegmigireren wollen? Warum?

privacyIDEA ist Open Source. Mit privacyIDEA ereilt Sie nie das Schicksal, dass Sie den 1000-und-ersten Benutzer nicht ausrollen können. privacyIDEA läuft und läuft und läuft.

Investieren Sie in Ihre Zukunft! Investieren Sie in Open Source! Investieren Sie in privacyIDEA!

Unternehmen nutzen immer mehr Cloud-Dienste. Damit wächst die Menge an Accounts sowie auch die Menge an Logindaten. Wenn die Zahl an Benutzernamen und Passwörtern aber stetig zunimmt, erhöhen sich die Schnittstellen und damit die Sicherheitsrisiken. Single Sign-on mit privacyIDEA bietet deshalb die Möglichkeit, eine Identität zentral zu verwalten, um für mehr Sicherheit und Flexibilität zu sorgen.

Single Sign-on (kurz SSO) wird gerne missverstanden: Die Zuschreibung „Single” bedeutet nicht zwangsläufig, dass man sich als Nutzer nur noch ein einziges Passwort zu merken hätte – das gilt nur bedingt. Vielmehr meint SSO, dass sich ein User nur einmal anmelden muss, dann aber am selben Arbeitsplatz trotzdem Zugriff hat auf mehrere (Cloud-) Anwendungen – ohne weitere „Logins”.

Nicht zuletzt deshalb nutzen Unternehmen SSO gerne für die eigenen Webdienste. Ausschlaggebend ist aber eben nicht die Reduktion auf ein Passwort – dafür würde ein zentraler LDAP-Server ausreichen –, sondern der Umstand, dass sich Nutzer nur einmal anmelden. Mit SSO bieten Unternehmen ihren Angestellten so eine zentrale Anlaufstelle, wobei sie mit einem einzigen „Login” auf alle ERP-, Web- oder Cloud-Anwendungen zugreifen können, die sie für ihre (alltägliche) Arbeit benötigen.

Da laut Bitkom mittlerweile 44% aller Anwendungen und Arbeitsprozesse cloudbasiert ablaufen (bei Großunternehmen sogar 83 Prozent) und immer mehr Cloud-Services genutzt werden, wird der Bedarf an Single-Sign-on-Lösungen zunehmend wichtiger. Deshalb an dieser Stelle: ein Überblick, nicht über den Nutzen von SSO, sondern auch darüber, worauf Unternehmen achten müssen, wenn sie SSO sicher und effizient für ihre Organisation nutzen möchten.

Was ist Single Sign-on (SSO)?

Insbesondere der wachsende Bedarf an Cloud-Anwendungen führt zu einem vermehrten Einsatz von SSO. Der Grund dafür ist offensichtlich: Mehr Anwendungen (in der Cloud) bedeuten auch mehr Passwörter bzw. Logindaten für verschiedene Accounts. Single Sign-on bietet genau die Möglichkeit: sich nur einmal anmelden zu müssen, dann aber bei mehreren Anwendungen eingeloggt zu sein.

Welchen Nutzen kann ein Unternehmen aus SSO ziehen?

Unternehmen umschiffen damit „mehrere Problemfelder” auf einmal: So steigert ein Single-Sign-on-System den Wildwuchs an verschiedenen Accounts und Passwörtern, sodass der Bedienkomfort für die Mitarbeiter deutlich steigt. Diese merken sich bestimmt lieber einen „Master-Zugang” als viele, viele einzelne Zugänge.

Außerdem verschlechtern zu viele Account nachweislich die Passwort-Hygiene, das heißt: zu viele Nutzer verwenden dann oft dieselben Passwörter für unterschiedliche Portale, was der IT-Sicherheit nicht zugutekommen kann.

Verstreute „Account-Silos” über mehrere Lösungen hinweg – das möchten Unternehmen vermeiden, nicht nur weil es einfach unpraktisch, sondern auch unsicher ist. Mit SSO kann die IT-Abteilung neue User-Accounts einfach zentral erstellen und sogar einzelne Berechtigungen verwalten. Und wenn ein Mitarbeiter das Unternehmen verlässt, sind auch „Offboarding-Prozesse” zentral administrierbar.

Genau eben diese Reduzierung auf ein „Credential” – z.B. Passwort und Benutzername – minimiert das Risiko, dass Zugangsdaten verloren gehen oder aus leicht zu erratenden Passwörtern bestehen. Im Gegenteil: Richtig eingesetzt erhöht SSO die Produktivität, erleichtert ein effektives IT-Monitoring und sorgt unterm Strich für mehr Kontrolle und Sicherheit – während den Mitarbeitern mit einer Anmeldung Zugriff auf mehrere Systeme, Plattformen und andere unternehmensrelevante Ressourcen gewährt oder entzogen wird.

Wie kann man SSO im Unternehmen einsetzen?

Um aber reibungslos zu funktionieren, müssen Single-Sign-on-Dienste auf bestimmte Protokolle zugreifen. Davon gibt es nicht wenige – zum Beispiel SAML2, das intensiv bspw. von Salesforce eingesetzt wird, oder OpenID Connect (OIDC), das bspw. auch bei Google Anwendung findet.

SAML-Protokoll

Bei einem SAML-Protokoll erhält der User einen verschlüsselten Session-Cookie, mit dem sich der Nutzer über einen festgelegten Zeitraum bei bestimmten (Cloud-) Diensten authentifizieren kann. Der große Vorteil dabei ist, dass der externe Dienst keine Verbindung zum internen Authentifizierungsdienst (Identity Provider – IdP) aufbauen muss – es genügt die Verbindung zum Browser des Users.

OAuth2 mit OpenID Connect

Das OAuth2-Protokoll wird u.a. bei Google-Diensten wie Gmail oder Google Drive zur Autorisierung verwendet. Bei OpenID Connect handelt es sich um eine Weiterentwicklung gängiger Protokolle wie OpenID oder SAML. Da es allgemein als einfach und sicher gilt, entwickelt sich OAuth2 mit OpenID Connect immer mehr zum Standard für die Autorisierung von API-Zugriffen im Web (und auch bei Apps).

Dabei erhalten Nutzer einen singulären Zugangsschlüssel der in Verbindung mit dem OAuth2-Protokoll den Login ermöglicht. So werden Informationen über die Identität des Users sowie die erbrachte Authentifizierung über einen OpenID-spezifischen Token, auch ID Token genannt, an einen Client zurückgegeben. Das Login gilt dann nur für diesen einen Client.

Individuelle Autorisierungsprozesse – mit Keycloak

Da Unternehmen aber oft unterschiedliche IT-Security- und Compliance-Vorgaben zu erfüllen haben, nutzen sie sog. Identitäts- oder Zugriffsmanagement-Systeme – wie z.B. die  Open-Source-Lösung Keycloak, die übrigens die beiden oben genannten Protokolle nutzt und von JBoss unter der Leitung von RedHat entwickelt wird. Wenn die rollenbasierte Autorisierung also nicht den betriebsinternen Bedürfnissen entspricht, so bietet Keycloak justierbare Autorisierungsdienste an.

Auf diese Weise können Unternehmen die Berechtigungen für alle Ihre Dienste über die Keycloak-Verwaltungskonsole verwalten und haben die Möglichkeit, genau die Richtlinien zu definieren, die sie gerade benötigen.

Das Thema Sicherheit – Chance und Hürde zugleich

Dass Single-Sign-on-Systeme die Sicherheit grundsätzlich erhöhen ist unbestritten: sie reduzieren den Passwort-Dschungel, verhindern die Entstehung von (Account-) Silos, erhöhen die Produktivität und erleichtern Offboarding-Prozesse. Doch ein großes Restrisiko bleibt: Ein erfolgreicher Angriff würde immer dazu führen, dass mit einem Schlag mehrere Anwendungen betroffen sind.

Diese Hürde lässt sich aber überwinden, indem man zusätzlich eine 2-Faktor-Authentifizierungslösung für SSO integriert. Mit privacyIDEA als authproc-Filter (in simpleSAMLphp) können Anwender beispielsweise den Authentifizierungsprozess auf vielfältige Weise erweitern und individualisieren. Der erste Faktor wird dabei gegen die Authentifizierungsquelle (z.B. LDAP) und der zweite gegen privacyIDEA authentifiziert.

Funktionen, die Keycloak und privacyIDEA bieten

Seit kurzem kann man sich auch bei Keycloak mit einem zweiten Faktor von privacyIDEA anmelden. Dabei ermöglichen folgende Funktionen ein sicheres und benutzerfreundliches Einloggen:

  • Sicheres Anmelden mit SSO
  • Ausschluss bestimmter Gruppen
  • Automatisches Token Enrollment (falls ein Nutzer noch keinen Token hat)
  • Seit privacyIDEA 3.0: Unterstützung von Pushtoken
  • Keine Eingabe notwendig: Benutzerbestätigung via Smartphone

Fazit

Das Konzept Single Sign-on war in vielen Organisationen immer schon ein großes Thema. Wenn Unternehmen heute gängige Software- und Cloud-Lösungen wie Office 365, Box oder Slack nutzen, bedeutet das nicht, dass sie für diese Services auch unterschiedliche Passwörter und Login-Daten benötigen bzw. haben möchten.

Insbesondere mit Blick auf kulturelle Themen wie Bring your own device (BYOD) oder die Zunahme dezentraler Arbeitsplätze, die von der internen IT nicht mehr kontrolliert werden können, wird der Einsatz von SSO immer mehr zu einer Grundvoraussetzung, um nachvollziehbare Authentifizierungsprozesse sicher und flexibel zu gestalten.

Wir sind stolz, dass wir heute privacyIDEA 3.0 veröffentlichen können. Denn mit privacyIDEA 3.0 stellen wir die Weichen für eine stabile Zukunft.

Während viele sich schnell in verlockenden MFA SaaS-Angeboten verlieren, wollen wir unseren Kunden weiter die Möglichkeit geben, ihre sichere Mehr-Faktor-Authentifizierung mit einem vertrauenswürdigen System unter der eigenen Kontrolle, on Premise, durchzuführen. Damit das auch in Zukunft so bleibt, haben wir an mehreren Punkten in den vergangenen Monaten gearbeitet. Vordergründig scheinen die erstmal keinen Wow-Effekt zu bringen, aber Ihnen als Unternehmenskunde geben sie das, was für Sie zählt: Langfristige Stabilität!

Python 3

privacyIDEA ist in Python geschrieben. Die Python Version 2.7 wird ab 2020 nicht mehr weiterentwickelt. Wir haben den Code von privacyIDEA 3.0 so geschrieben, dass er sowohl unter Python 2.7 als auch unter Python 3.x läuft. Das gibt Ihnen die Sicherheit, dass Sie ohne Migrationsprojekte von Python 2.7 auf Python 3 wechseln können und auch nach 2020 privacyIDEA entspannt einsetzen können.

Eine PIP-Installation von privacyIDEA 3.0 können Sie wahlweise schon auf Python 3 betreiben. Die Enterprise-Pakete werden wir derzeit noch mit Python 2.7 ausliefern und sie dann im Laufe der kommenden Monate auf Python 3 ändern. Für Sie ist dann außer einem normalen Update nichts weiter zu tun.

Cryptofunktionen

Unter der Haube haben wir auch Crypto-Bibliotheken ausgetauscht. Die alte Bibliothek pycrypto musste dem de-Facto-Standard cryptography weichen. Signaturen und verschlüsselte Daten haben nun zusätzlich eine eigene Versionierung, so dass wir hier zukunftssicher sind, wenn wir die Art und Weise, wie wir signieren oder verschlüsseln, austauschen wollen. Dank der Versionierung können wir hier einfach die Abwärtskompatibilität sicherstellen.

Datenbank-Schema

Wir haben mit einer Design-Altlast gebrochen, die auf die ersten Versionen im Jahr 2009 zurückgeht. Bisher wurde die Zuordnung eines Tokens zum Benutzer in der Datenbank in der Tokentabelle selber gespeichert. Das war zwar einfach, aber nicht flexibel. Die Zuordnung erfolgt nun in einer eigenen Tabelle, so dass wir datenbankseitig schon vorbereitet haben, dass mehrere Benutzer den gleichen Token besitzen können. Dies wird es uns in der Zukunft erleichtern, ganz neue Tokentypen zu entwickeln.

Installationsvarianten

Wir haben uns entschieden, alle Installationsvarianten als sogenannte Python virtualenv auszuliefern. In einem dedizierten Verzeichnis bringt privacyIDEA alle Abhängigkeiten mit, die es benötigt. Dadurch stellen wir sicher, dass unabhängig davon, ob privacyIDEA auf einem Debian, Ubuntu, RHEL oder SLES läuft und per pip, apt oder yum installiert wurde, in einer gegebenen Version der komplett gleiche Code läuft. Das hilft, Seiteneffekte von unterliegenden Abhängigkeiten auszuschließen. Die Installationen werden homogener und stabiler.

Dennoch ist weiterhin wie gehabt eine einfache Installation und Update mittels apt/aptitude oder yum möglich.

Ab privacyIDEA 3.0 werden wir keine Pakete mehr für Ubuntu 14.04LTS bauen. Dafür bieten wir ab 3.0 Pakete für Ubuntu 18.04LTS und 16.04LTS an. Die Pakete für Ubuntu können wir aber nicht mehr in den PPA Launchpad Repositories veröffentlichen. Vielmehr veröffentlichen wir diese nun in einem eigenen Repository.

Installation der neuen Version privacyIDEA 3.0

privacyIDEA 3.0 ist die Community Edition, die auf dem Python Package Index und in Repositories für Ubuntu 16.04LTS und 18.04LTS verfügbar ist. Wegen der Änderungen bitten wir Sie, die Installations- und Update-Anleitungen genau zu lesen.

Die Enterprise Edition für Unternehmenskunden wird in einigen Wochen als Version 3.0.1 folgen.

Lesen Sie außerdem unsere Pressemitteilung zum Release von privacyIDEA 3.0.

Am Wochenende 16. und 17.03.2019 waren wir mit unserem privacyIDEA-Stand auf den Chemnitzer Linuxtagen. Auf den Chemnitzer Linuxtagen präsentieren sich Projekte und Unternehmen aus dem Open Source-Umfeld, Referenzen halten Vorträge zu aktuellen Themen, Workshops gibt es für die erwachsenen Besucher aber auch für Kinder. Die Veranstaltung fand dieses Jahr zum 21sten mal statt. Die Professionalität der Organisation ist fast nicht mehr zu toppen.

Gourmets und Jobsuche

Vom Programmheft, über Besucherführung, Merchandising, Außenwerbung bis hin zur Verpflegung. Ist es Eigenironie, wenn sich das Team, das sich um die Verpflegung der Aussteller kümmert „Chemnitzer Catering-Tage“ nennt?

Neben den Vorträgen gibt es im großen Hörsaalgebäude Ausstellungsstände von freien Projekten und Unternehmen, die die Chemnitzer Linux-Tage mit Sponsorbeiträgen unterstützen und in dieser Form ermöglichen.

Wir haben privacyIDEA als Projekt angemeldet und mussten wahrheitsgemäß bei der Anmeldung bestätigen, dass wir mit dem Projekt Geld verdienen und schwupp – schon waren wir eine „Firma privacyIDEA“ und somit mit unserem im Innenbereich des Hörsaalgebäudes platziert.

Die Firmenrepräsentanz war eine illustere Mischung und man fragte sich, was haben die Firmen den Besuchern zu vermitteln – außer der Information, dass sie Mitarbeiter suchen. So wirkte die Ausstellung an einigen Stellen leider wie eine Jobmesse als ein informatives Linux-Event.

Unser Stand und unseren Kontakte

Wir entschieden uns, an unserem Stand niemanden mit Stellenangeboten zu belästigen – wie soll eine „Firma privacyIDEA“ auch Arbeitsverträge unterschreiben?

So zogen wie immer die Hardwaremischung aus Token, Yubikeys, OTP-Karten, Thomas-Krenn-Server und Raspberry PI die Leute in Ihren Bann.

Viele sind daran interessiert ihre persönlichen Rechner abzusichern.

Doch auch Entwicklern und Unternehmensadministratoren konnten wir die flexible Mehr-Faktor-Lösung privacyIDEA näher bringen.

Besonders nutzten wir aber auch die Gelegenheit, um die Kontakte zwischen den Unternehmen und Projekten weiter zu intensivieren. privacyIDEA ist als Authentifizierungssystem eine Brückentechnologie, die mit anderen Produkten und Projekten interagieren muss. Und so freuen wir uns, dass wir solche Veranstaltungen nutzen können, um die Kommunikation unkompliziert aufrecht zu erhalten.

Vollbepackt nach Chemnitz

Auch dieses Jahr hat die NetKnights GmbH die Chemnitzer Linuxtage als Sponsor unterstützt und wir haben den Community-Stand von privacyIDEA gestellt. Also sind drei Mitarbeiter der NetKnights am Freitag Nachmittag mit dem vollgepackten Auto in Kassel aufgebrochen.

Weiterlesen

Am 27. Februar 2018 fand in den Räumlichkeiten der NetKnights GmbH ein Workshop zur 2-Faktor-Authentifizierung statt. IT-Verantwortliche aus verschiedensten Branchen hatten den ganzen Tag Gelegenheit, ihre Fragen zu stellen, Anwendungsszenarien zu klären und privacyIDEA im Detail kennenzulernen.

(mehr …)

Thales kauft Gemalto. Die Konsolidierung in der Welt der IT-Sicherheit schreitet weiter voran. Das muss nicht unbedingt gut sein. Denn Varianz und Pluralität stärkt die Wiederstandskraft und lässt dem Kunden die Wahl. Ich finde es spannend, wie sich das entwickeln wird. In der Vergangenheit nutzen wir SafeNet (Gemalto) HSMs und Thales HSMs. Während SafeNet vehement den Ansatz Key in Hardware vertrat öffnete sich Thales mit der Flexibilität des Security World-Konzepts. In unseren Augen hatte beides seine Daseinsberechtigung. Es werden sich nun wohl auch die Aussagen in Bezug auf die ehemaligen Konkurrenz relativieren.

In diesem Artikel zeigen wir, wie Sie den Zugang zu Ihrem Benno-Mailarchiv mit Hilfe von privacyIDEA mit Mehr-Faktor-Authentifzierung absichern können und erklären, wieso Sie ihr Mailarchiv so schützen sollten.

Weiterlesen

Die Absicherung von Bank-Transaktionen ist eine große Herausforderung. Wir alle sind dankbar, dass wir uns oft den Weg zum Geldinstitut mit den wohl merkwürdigsten Öffnungszeiten sparen können. Ebenso sind wir froh, dass die Zeiten der TAN-Listen, auf denen wir mit dem Stift nach und nach Zahlenkolonnen ausgestrichen haben, vorbei sind.

Aber was ist heute noch die Herausforderung bei Bank-Transaktionen?

Die Unveränderbarkeit der Transaktionsdaten

Der Bankkunde teilt der Bank über ein Webinterface mit, wieviel Geld an welches Konto geschickt werden soll. Ein Trojaner, den sich der Benutzer im Browser eingefangen hat, kann diese Daten verändern. Kurz gesagt, würde der Bankkunde 100 Euro für Konto 1234567890 eingeben und überweisen wollen und der Trojaner im Browser würde nach dem Klick auf den Button „Überweisung senden“ ungesehen daraus 10.000 Euro für Konto 666.666.XX machen. Die Bank bekommt von dem Vorfall im Browser des Benutzers nichts mit. Sie erhält die Daten 10.000 Euro für 666.666.XX und muss annehmen, dass dies das ist, was ihr Kunde will.

Geld weg.

TAN-Listen und OTP-Token

Die Transaktionsdaten können, bevor sie die Bank erreichen, verändert worden sein!

In früheren Zeiten wurden TAN-Listen verwendet. Manche Bank (die sich eher im nicht-deutschsprachigen Raum befindet), setzt auf OTP-Token. Doch TAN-Listen (obwohl bisweilen auch anderes behauptet wird) und OTP-Token können die Unveränderbarkeit der Transaktionsdaten nicht sicherstellen. Der OTP-Token kann dazu dienen, dass die Bank weiß, dass diese Transaktion von genau dem Bankkunden, der im Besitz dieses Gerätes ist, diese Transaktion angestoßen wurde, jedoch kann die Bank nicht sicher wissen, dass die Transaktionsdaten von einem Trojaner im Browser oder anderen Angriffen verändert wurden, ohne dass der Bankkunde und ohne dass die Bank dies weiß.

Es besteht keine kryptographische Verbindung zwischen den Transaktionsdaten und dem Einmal-Passwort.

OCRA: Die Verbindung zwischen Transaktion und TAN

Hier setzt z.B. der OATH Challenge Response Algorithm (kurz OCRA) an, der in RFC 6287 definiert ist. OCRA wurde genau wie HOTP und TOTP von der Initiative for Open Authentication definiert. Grob gesagt ist OCRA ein etwas erweiterter HOTP-Altgorithmus.

Beim HOTP-Algorithmus ist das einzige Eingangsdatum ein Zähler, der kontinuierlich hochgezählt wird. Zusammen mit einem geheimen Schlüssel (der in diesem Fall den Besitz repräsentiert) wird nun ein 6 oder 8-stelliges Einmalpasswort berechnet. D.h. das Einmalpasswort hängt ab vom geheimen Schlüssel und von dem Eingangsdatum „Zähler“. (Für die, die lieber Dinge wie HMAC und mod lesen, sei hier auf das RFC4226 verwiesen).

Grob gesprochen können im Falle von OCRA noch mehr Daten außer dem „Zähler“ in den Algorithmus hineingepackt werden. So zum Beispiel die Kontonummer des Empfängers und der zu überweisende Betrag. Das aus dem OCRA-Algorithmus resultierende Einmalpasswort ist nun also abhängig vom geheimen Schlüssel und den Transaktionsdaten. Andere Transaktionsdaten generieren ein anderes Einmalpasswort.

Wie kann man sich dies nun bei der Überweisung zu Nutze machen?

Die Bank händigt dem Kunden einmalig einen geheimen Schlüssel aus. Entweder in Form eines Hardware-Gerätes oder einer Smartphone-App. Die Bank kennt den geheimen Schlüssel des Kunden.

Der Kunde gibt nun auf der Banking-Website die Transaktionsdaten ein. Gleichzeitig überträgt er die Transaktionsdaten an sein Gerät (mit dem geheimen Schlüssel). Diese Übertragung könnte auch manuell erfolgen, es sind aber viele unterschiedliche Methoden mit QR-Code, Netzwerk oder Bluetooth denkbar, die die Bedienfreundlichkeit erhöhen.

Auf dem Gerät kann der Kunde nochmal überprüfen, ob dies die richtigen Transaktionsdaten sind, falls sich ein Angreifer auch in diesen Übertragungsweg eingeklinkt hätte. Nur wenn es die richtigen Daten sind, lässt er das Gerät die TAN berechnen und er fährt mit der Überweisung fort. Nun gibt er die TAN in die Banking Webseite ein und die Daten werden zur Bank geschickt.

Die Bank erhält die Transaktionsdaten und die TAN. Die TAN hängt aber genau von den Transaktionsdaten ab, die der Kunden nochmal auf dem Gerät verifiziert hat. Die Bank errechnet mit dem geheimen Schlüssel des Kunden und den erhaltenen Transaktionsdaten ebenfalls die TAN. Sollte sich ein Angreifer eingeklinkt und die Transaktionsdaten auf dem Weg zur Bank verändert haben, so erhält die Bank eine andere TAN als der Kunde geschickt hat und wird die Transaktion nicht durchführen.

In diesem Szenario ist jede einzelne Transaktion kryptographisch gesichert. Etwas provokativ gesprochen kommt es gar nicht so sehr darauf an, die Online-Zugangsdaten zu schützen, weil ohne das Gerät mit dem geheimen Schlüssel sowieso keine kryptographisch gesicherte Transaktion durchgeführt werden kann.

privacyIDEA, OCRA und DisplayTAN

privacyIDEA unterstützt schon lange den OCRA Algorithmus in Form des TiQR tokens. In Version 2.20 wurde die Anwendung des OCRA-Algorithmus derart erweitert, dass bspw. die DisplayTAN-Karte problemlos genutzt werden kann.

Banken brauchen also nicht das komplette Schlüsselmanagement in ihre Web-Applikation zu integrieren sondern können die OCRA-gesicherte TAN erzeugen über eine einzige einfache REST API an privacyIDEA auslagern.

Die DisplayTAN-Karten sind für den Bankkunden sehr attraktiv, da sie die eigentliche Bank-Karte komplett ersetzen können aber zusätzlich die Nutzung des sicheren TAN-Verfahren ermöglichen.

Sprechen Sie uns an!

Am Wochenende waren wir in Sankt Augustin an der Hochschule Bonn-Rhein-Sieg. Dort fand zum zwölften mal die „Free and Open Source Software Conference“ kurz FrOSCon statt. Die NetKnights GmbH ist dort als Sponsor aufgetreten, hatte einen Ausstellungsstand und wir haben in einem Vortrag über den privacyIDEA LDAP Proxy berichtet.

Aufbau

Am Vorabend wurde der kleine Messestand aufgebaut. Ganz in der Nähe vom heißbegehrten T-Shirt-Stand und der Treppe zum Obergeschoss kam vor allem am Samstag viel Laufkundschaft vorbei.privacyIDEA ist Mehr-Faktor-Authentifizierung, die befreit.

Die privacyIDEA Enterprise Edition ist Open Source. D.h. mit dem Einsatz von privacyIDEA können Unternehmen vermeiden, dass die Software irgendwann End-Of-Sale oder End-Of-Life geht. Gegenüber Online-2FA-Lösungen wie Duo, ist sogar klar, dass die eigenen privacyIDEA-Instanz im eigenen Unternehmen niemals eingestellt werden wird, Leistungen verändert werden, man machtlos gegen Preisanhebungen ist oder Daten nicht wegmigrieren kann.

Die unglaubliche Schnittstellenvielfalt, die Offenheit und das neue Event-Handler-Framework ermöglichen dem Administrator außerdem, viele Aufgaben zu automatisieren. Der Rollout an große Benutzerzahlen wird einfacher, Helpdesk-Funktionen erfordern weniger manuelle Schritte. Die IT-Abteilung spart wertvolle Zeit bei alltäglichen Aufgaben und gewinnt somit die Freiheit, sich mit neuen Projekten zu befassen.

Diese Flexibilität und die damit gewonnene Freiheit gefällt vielen.

Wenn Sie die FrOSCon verpasst haben, schauen Sie doch einfach dieses Jahr bei unserem Auftritt auf der Business-Messe it-sa in Nürnberg vorbei!

Freunde

Am Vorabend des Aufbaus schlenderten wir über die Ausstellung und stellten fest, dass noch nicht alle Stände aufgebaut hatte. Der Stand unserer Freunde von ownCloud war noch nicht aufgebaut. Dem konnten wir abhelfen: Vom ownCloud X Launchevent hatten wir noch ein Rollup in petto, das wir gleich dem Stand spendeten.

Sieht doch gleich viel besser aus!

Das ist Enterprise-taugliche Mehr-Faktor-Authentifizierung mit ownCloud!

So integriert sich privacyIDEA mit vielen verschiedenen Applikationen von CRM-Systemen, CMS, Ticketsystemen, VPN, Firewall, SSH und Desktop und hilft dabei sicherer, entspannter und befreiter auf die eigenen Daten zuzugreifen.

Skalierung

privacyIDEA skaliert von kleinen bis hin zu großen Installationen. Es lässt sich auf kleinen virtuellen Maschinen und in großen Clustern betreiben.

privacyIDEA skaliert von M über XL bis XXXL.

Vortrag

Am Sonntag Nachmittag hielten Friedrich Weber und Cornelius Kölbel dann den Vortrag zum neuen privacyIDEA LDAP Proxy. Der Mitschnitt ist bei Youtube verfügbar.

Abonnieren Sie den privacyIDEA Youtube Kanal oder den Newsletter der NetKnights.