,

privacyIDEA mit Open Source Business Award ausgezeichnet

Im Mai diesen Jahres haben wir privacyIDEA als Projekt bei dem Open Source Business Award eingereicht.

Am Mittwoch Abend wurden im Rahmen der Open!2016 Konferenz die Gewinner gekührt.

privacyIDEA belegt den ersten Platz beim Open Source Business Award

Die Spannung steigt! Schließlich wurde privacyIDEA auf die Bühne gerufen. Die hochkarätig besetzte Jury verleiht dem Open Source Projekt privacyIDEA den ersten Platz (in Gold 😉 beim OSBAR. 

Ich war in Stuttgart am Mittwoch Abend zugegen und konnte freudig den Preis entgegennehmen. Die Sponsoren Kopano, Nextcloud und Spreed unterstützen die Auszeichnung außerdem noch jeweils mit einem Sachwert. Das erstplatzierte Projekt darf sich über eine Spreedbox freuen, mit der sichere Webkonferenzen durchgeführt werden können.

Ausgezeichnete Sicherheit

Nicht nur wurden Projekte nach dem Innovations- und Reifegrad bewertet sondern vor allem auch nach dem Nutzen für Business-Anwender. Lange schien in der Öffentlichkeit die Bereitschaft, etwas für Sicherheit zu tun, ein Lippenbekenntnis zu sein.

Meine persönliche Interpretation der Auszeichnung ist, dass die Jury erkannt hat, dass durch die Verwendung einer Sicherheitslösung wie privacyIDEA eben durchaus ein Mehrwert für Unternehmen geschaffen wird – indem geheime Daten geschützt und Complience-Regeln eingehalten werden. Als Open Source Produkt, das unter der Kontrolle des Anwenders on Premise läuft, behält ein Unternehmen vollständig seine Identitätssouveränität.

Ihre Sicherheit

privacyIDEA ist ein System zur zentralen Verwaltung von Authentifizierungsobjekten zur Zwei- oder Mehr-Faktor-Authentifizierung. Das Open Source Produkt ist produktiv zuverlässig einsetzbar, für den Unternehmenseinsatz ist eine Enterprise Edition mit entsprechenden Subskriptionen/SLAs verfügbar.

,

Zukunftssichere Zwei-Faktor-Authentifizierung mit privacyIDEA

Seit einiger Zeit macht das NIST von sich Reden. Es aktualisiert seinen Digital Authentication Guideline.

Das NIST

Das NIST ist das National Institute of Standards and Technologies. Es gehört zum Handelsministerium der Vereinigten Staaten und legt Standards fest, an denen sich andere Behörden und Unternehmen orientieren oder nach denen sogar richten. Als ebenfalls physikalisches Labor geht es hier auch um Themen wie Erdbeben und Feuerschutzrichtlinien aber eben auch um Standards in der IT. So gehen die Verschlüsselungsprotokolle DES und AES auch aus die Mitarbeit des NIST hervor.

Digital Authentication Guideline

Die Verwendung von SMS für Authentifizierung wird von NIST als veraltet eingestuft.

Die Verwendung von SMS für Authentifizierung wird von NIST als überholt eingestuft.

Nun hat das NIST eine neue Vorabversion seiner Digital Authentication Guideline herausgebracht. Eine Richtlinie, die zum einen beschreibt, wie die Kritikalität verschiedener Anmeldesituationen in der IT zu bewerten sind aber dann auch konkrete Empfehlungen ausspricht, wie hier in den verschiedenen Sicherheitsstufen zu handeln ist. Das Thema Zwei-Faktor-Authentifizierung wird ins Feld geführt.

Interessant ist nun, dass im Draft SP800-63B explizit auf die Risiken von Out-Of-Band Authentifizierung mit SMS hingewiesen wird und in Abschnitt 5.1.3.2 sogar die Verwendung von SMS als überholt eingestuft wird.

OOB using SMS is deprecated, and may no longer be allowed in future releases of this guidance.

Authentifizierungsverfahren nicht für die Ewigkeit

Nun müssen wir nicht über SMS herziehen. Es sollte uns aber bewusst machen, dass auch kein Authentifizierungsverfahren für die Ewigkeit gemacht ist. Das Verfahren, mit dem wir heute noch sehr glücklich sind, kann morgen für Hacker schon ein leichtes Spiel sein.

Hier müssen wir also einen viel allgemeineren Schluss ziehen: Die eingesetzten Authentifizierungsverfahren sollten austauschbar sein. Wir sollten nicht auf ein Produkt setzen, das ausschließlich auf ein Authentifizierungsverfahren – in diesem Fall  auf SMS – baut. Denn der Aufwand, nun wieder zu einem zeitgemäßen Authentifizierungsverfahren zu wechseln, bedeutet den kompletten Austausch eines solchen Produkts, des Backends nach einer langen Evaluierung eines geeigneten Herstellers und einer entsprechenden neuen Lösung.

Zukunftssicherheit mit privacyIDEA

Deswegen setzt die NetKnights GmbH auf privacyIDEA. privacyIDEA ist ein Authentifizierungssystem, das eine breite Anzahl an Token, Authentifizierungsgeräten und eben auch Authentifizierungsarten oder -protokollen unterstützt. Natürlich unterstützt privacyIDEA OTP per SMS oder Email. Aber eben auch Einmalpasswörter mittels Smartphone Apps, per Challenge Response, verschiedete OTP-Hardware-Token, Yubikeys und aber auch x.509-Zertifikate und SSH-Keys.

In diesem Fall kann ein Unternehmen, das privacyIDEA einsetzt, bei einer Veröffentlichung wie der des NISTs, entspannt neue Authentifizierungsgeräte an die Benutzer ausrollen, ohne die Software, den Hersteller und die Prozesse ändern zu müssen.

Auf diese Art und Weise spart privacyIDEA auch in Zukunft Verwaltungskosten und reduziert den TCO. Die NetKnights GmbH bietet verschiedene Support-Stufen für privacyIDEA, berät Sie bei der Integration in Ihr Netzwerk und liefert entsprechende Token-Hardware.

Sprechen Sie uns an.

 

,

privacyIDEA bewirbt sich für den Open Source Business Award

OSBAR

Der Open Source Business Award (auch OSBAR) wird von der Open Source Business Alliance durchgeführt. Dabei werden Open Source Projekt und auch Ideen prämiert, die innovativ sind und einen entscheidenden Mehrwert für Unternehmen und Institutionen der öffentlichen Hand bieten.

privacyIDEA

Wir glauben, dass das Open Source Projekt privacyIDEA dies voll erfüllt. Gegenüber herkömmlichen OTP-Systemen setzt es viele, neue Ideen um und ermöglich den Anwendern so, individuelle und elegante Lösungen in ihrer Infrastruktur zu bauen.

Daher hat die NetKnights GmbH das Projekt privacyIDEA beim Open Source Business Award eingereicht. Hier können Sie die Einreichung lesen: privacyIDEA_OSBAR_2016.

,

Zwei-Faktor-Authentifizierung mit Event Handler Framework

privacyIDEA wird in der kommenden Version um ein Event Handler Framework erweitert.

Richtlinien für Zwei-Faktor-Authentifizierung

Das Zwei-Faktor-Authentifizierungssystem privacyIDEA lässt sich bereits über Richtlinien (Policies) detailliert konfigurieren und das Verhalten abhängig von vielen Rahmenbedingungen beeinflussen. So lassen sich mit Hilfe der Richtlinien unterschiedliche Szenarien abbilden und zu nahezu allen Herausforderungen eine Lösungen finden. Richtlinien verändern das Authentifizierungs- und Autorisierungsverhalten. Der Administrator kann beispielsweise verschiedene Sicherheitsstufen abbilden oder einfache Migrationen durchführen.

Event-Handler

Mit Hilfe der neuen Event-Handler eröffnen sich noch mehr Möglichkeiten. Die Richtlinien beeinflussen und verändern das Verhalten von privacyIDEA an sich. Der Event-Handler hingegen ändert nichts an dem Verhalten, sondern startet, abhängig von eintretenden Ereignissen, zusätzliche Aktionen, ohne das eigentliche Ereignis zu verändern.

event-handler-privacyidea

So wird in dem obigen Beispiel an das Ereignis „token_init“ (Ein Token wird für einen Benutzer ausgerollt) die Aktion „sendmail“ gehängt.

Um die Logik kümmert sich das Event-Handler-Modul „UserNotification“. Das Interessante ist nun, dass der Administrator ganz flexibel die entsprechende Aktion an jedes beliebige Ereignis hängen kann.

Weitere Event-Handler-Module

Als erstes Event-Handler-Modul wird „UserNotification“ ausgeliefert. Weitere Module sind denkbar und können schnell folgen. So könnte ein Modul „Enrollment“ für einen Benutzer einen speziellen Token-Typen ausstellen — als Reaktion auf ein beliebiges Ereignis.

Somit eröffnen sich ungeahnte Möglichkeiten, neue, kreative Konfigurationen und Workflows abzubilden. Einmal mehr beweist privacyIDEA, dass es ein modernes, innovatives und richtungsweisendes Authentifizierungssystem ist.

Abonnieren Sie unseren Newsletter, um immer auf dem Laufenden zu sein.

, ,

Migration einer proprietären OTP / Zwei-Faktor-Lösung

Leichte Migration eines bestehenden OTP-Systems zu privacyIDEA

Oftmals entscheiden sich Kunden, ihr bestehendes, proprietäre OTP-System zur Zwei-Faktor-Authentifizierung abzulösen. Dies hat verschiedene Gründe. Das bestehende System ist zu alt und es gibt keine Updates mehr. Gleichzeitig wird es zu unflexibel. Die für das System verfügbaren Token erfüllen nicht mehr die Anforderungen der heutigen Zeit. Unternehmen wachsen zusammen und jedes Unternehmen bringt seine eigene, proprietäre Lösung mit. Manchmal ist das bestehende System auch einfach zu teuer oder im Zuge der Vertrauens- und Überwachungsthematik möchte man lieber ein Open Source System einsetzen.

Dies sind Gründe, wieso sich Kunden für die Nutzung von privacyIDEA entscheiden.

privacyIDEA bietet schon heute verschiedene Möglichkeiten — bspw. mit den RADIUS Token, eine solche Migration sanft durchzuführen. Doch mit der Version 2.11 wird eine solche Migration nochmal leichter. privacyIDEA 2.11 wird am 18. März veröffentlicht. Wenn Sie auf dem Laufenden bleiben wollen, abonnieren Sie bitte hier unseren Newsletter.

Zentral definierte RADIUS-Server

In privacyIDEA 2.11 ist es möglich, an zentraler Stelle mehrere RADIUS-Sever zu konfigurieren. Dies ist vergleichbar mit der letztens eingeführten Möglichkeit, zentral SMTP-Server zu konfigurieren.

Zentral definierte RADIUS-Server

Zentral definierte RADIUS-Server „RSA SecurID“.

Diese RADIUS-Server können für den RADIUS-Token oder auch in den Richtlinien verwendet werden.

Bisher (bis einschließlich privacyIDEA 2.10) muss für jeden Benutzer in privacyIDEA ein RADIUS-Token ausgestellt werden. Dieser RADIUS-Token verweist auf den alten RADIUS-Server des abzulösenden OTP-Systems. Solange der Benutzer also noch keinen OTP-Token innerhalb von privacyIDEA hat, kann er sich noch immer mit dem alten Token authentisieren.

Eine Richtlinie für alle Benutzer

Ab Version 2.11 können die zentral definierten RADIUS-Server in den privacyIDEA-Richtlinien verwendet werden.

policy-radius-passthru

Der zentral definierte RADIUS-Server „RSA SecurID“ wird in der passthru-Policy verwendet.

Hierzu wurde die bereits existierende passthru-Richtlinie erweitert. Die passthru-Richtlinie greift, wenn ein Benutzer innerhalb von privacyIDEA noch keinen Token zugewiesen bekommt. Die Authentifizierungsanfrage wird dann an das LDAP oder AD weitergereicht oder – nun neu in 2.11 – an einen konfigurierten RADIUS-Server.

Das bedeutet, dass in einem sanften Migrationsszenario von Ihrem alten OTP-System hin zu privacyIDEA nur noch eine einzige Richtlinie zu definieren ist, und Sie nach und nach allen Benutzern einen neuen Token innerhalb von privacyIDEA ausstellen können!

Migrieren!

Das hier beschriebene Szenario funktioniert problemlos für alle Systeme, die einen RADIUS-Server bereitstellen. Darunter Systeme wie Kobil, RSA SecurID, SafeNet, Vasco (in alphabetischer Reihenfolge).

Sprechen Sie uns an!

,

Benutzerregistrierung mit privacyIDEA – Der Blick hinter die Kulissen

Die Entwicklungen für privacyIDEA 2.10 rund um das Thema Benutzerregistrierung laufen auf Hochtouren.

Benutzerregistrierung in privacyIDEA.

In der Version 2.10 von privacyIDEA wird es die Möglichkeit geben, dass sich neue Benutzer registrieren. Im Blog von privacyIDEA.org finden sich weitere technische Details.

Neue Szenarien mit Benutzerregistrierung

Mit der Möglichkeit, dass sich Benutzer am privacyIDEA-System selber registrieren können, ergeben sich neue Benutzungsszenarien für Zwei-Faktor Authentisierung.

Zwei-Faktor-Provider

Zwei-Faktor Authentifizierung kann nun also Benutzer angeboten werden, die vorher nicht bekannt sind. So kann bspw. ein Provider mit Hilfe einer privacyIDEA-Installation einen öffentlichen Zwei-Faktor-Dienst anbieten. Benutzer können sich somit frei an privacyIDEA registrieren, der Provider kann mit einem entsprechenden Abrechnungsmodell für den Benutzer eine monatliche Gebühr erheben. Der Benutzer kann ein Authentisierungs-Gerät aus der vom Provider vorgegebenen Liste wählen. Dies können klassische HOTP oder TOTP Token sein, Google Authenticator oder andere Apps oder U2F-Geräte wie der Yubikey oder NitroKey.

Die Authentifizierung kann der Provider über unterschiedliche Protokolle wie bspw. SAML, RADIUS oder die WebAPI anbieten.

Gast-Accounts

In Unternehmen oder Hotels können sich Gäste an einem privacyIDEA System registrieren, um einen zweiten Faktor auszurollen. Damit können sie bspw. für einen bestimmten Zeitraum Zugriff auf sensible Resourcen erhalten. Wenn sich ein externer Mitarbeiter registriert und einen zweiten Authentisierungs-Faktor im privacyIDEA erstellt hat, könnte das Unternehmen ihm mit diesem zweiten Faktor Zugriff auf schützenswerte Projektinformationen gewähren.

Neue Workflows

Auch innerhalb eines Unternehmens, einer Organisation oder einer Universität ermöglicht die Benutzerregistrierung neue Abläufe. Anstatt während des Rollout-Prozesses aktiv den Benutzern den Token zuzuweisen oder den Rolloutprozess lediglich an das Wissen des Domänenpasswortes zu binden, kann ein Mitarbeiter sich selber registrieren müssen. Durch den Registrierungsprozess wird er identifiziert und erhält seinen zweiten Faktor, den er dann bpsw. für den Remote-Zugriff mittels VPN nutzen kann.

Die Registrierung kann auf einen bestimmten Mitarbeiterkreis bspw. anhand der Email-Adresse beschränkt werden.

privacyIDEA Workshop

Über die Registrierung hinaus bietet privacyIDEA bereits eine Vielzahl an flexiblen Einsatzmöglichkeiten. Lernen Sie privacyIDEA besser kennen und sehen Sie, wie es in Ihrem Unternehmen die Anmeldeverfahren sicherer machen kann und wie Sie auf einfache Art und Weise Ihren Mitarbeitern einen zweiten Faktor ausstellen. Besuchen Sie hierzu im Januar das kostenlosen privacyIDEA-Webinar.

 

,

Video: privacyIDEA Talk auf der T-Dose

Das Video zum privacyIDEA Talk auf der T-Dose ist nun verfügbar (Englisch).

Cornelius Kölbel hielt am 28.11.2015 auf der T-Dose in Einhoven (Niederlande) einen Vortrag mit dem Titel

No Need For Gemalto – Do it yourself! Two Factor Authentication with privacyIDEA.

Hierbei wird dargelegt, wie man sich von kommerziellen, proprietären Herstellern in Bezug auf starke Authentifizierung unabhängig machen kann.

Das besondere Augenmerk ist zu richten auf:

  • Kontrolle über das Schlüsselmaterial
  • Kontrolle über den Code (Open Source)
  • Kontrolle über den Computer, auf dem die Software läuft.

Die Open Source Software privacyIDEA bietet hierfür die entsprechenden Voraussetzungen.

U2F im Unternehmenseinsatz

Universal 2nd Factor ist ein von der FIDO Alliance spezifiziertes Protokoll, bei dem die Anmeldung an einer Webseite um einen zweiten Faktor — konkret einen Hardware-Besitz — ergänzt wird.

Die FIDO Alliance

In der FIDO Alliance engagieren sich große Player mit einer großen Benutzeranzahl wie Google und Paypal und klassische Hardwarehersteller wir RSA, Gemalto, Feitian und Yubico. Die Masse der Benutzer bei Google und Paypal sind überwiegend denzentrale, nicht organisierte Endanwender.

Das U2F Protokoll

Security-Key-by-Yubico-in-USB-Port-on-Keychain

Yubico U2F Yubiky

Die Idee bei U2F ist, dass ein Benutzer lediglich ein Hardware-Gerät hat, mit dem er sich ausweisen kann. Dazu registriert er dieses Gerät an den Webdiensten und Portalen, die das U2F Protokoll unterstützen. Das besondere hierbei ist, dass die einzelnen Webdienste nichts voneinander wissen. D.h. der Webdienst B weiß nicht, dass das gleiche Gerät bei Webdienst A registriert wurde. Dies soll die Anonymität des Endanwenders sicherstellen und die komplette Unabhängigkeit zwichen den einzelnen Webdiensten gewährleisten.

U2F ist also ein Protokoll für eine denzentrale Authentifizierung von Endanwendern.

Die Registrierung und Authentifizierung

Um dies zu ermöglichen, muss der Benutzer an jedem Webdienst, das Gerät registrieren. Dabei wird ein asymmetrisches  Schlüsselpaar erzeugt. Der öffentliche Schlüssel wird mit weiteren Meta-Informationen bei dem Webdienst gespeichert.

Wenn nun der Benutzer sich später an dem Webdienst authentisieren möchte, kann der Webdienst eine Challenge zusammen mit den Metainformationen an das U2F-Device senden. Die Authentifizierung erfolgt als Challenge-Response-Verfahren mit dem asymmetrischen Schlüsselmaterial.

Wieviele Schlüsselpaare passen auf den Yubikey?

Unendlich viele. Wenn der Yubikey bei der Registrierung das Schlüsselpaar erzeugt, speichert er den privaten Schlüssel nicht ab. Sondern er generiert das Schlüsselpaar aus einem Masterkey, der fest auf dem Yubikey gespeichert ist.

In die Generierung fließen außerdem die Metainformationen mit ein. Allem voran die sogenannte AppId, die im wesentlichen der URL des Webdienstes entspricht. Hierzu später mehr.

D.h. wenn der Webdienst die Challenge und die Metainformationen an das U2F-Device sendet, kann der Yubikey daraus mit dem fest gespeicherten Masterkey wiederum den speziellen, privaten Schlüssel für diesen Webdienst berechnen und die Challenge korrekt beantworten.

U2F im Unterschied zu klassischen 2FA

OTP Authentifizierung

Die Authentifizierung mit Einmalpasswörtern setzt auf symmetrische Kryptographie. Außerdem wird für die Authentifizierung mit Einmalpasswörtern ein Backend benötigt, das den gemeinsamen, symmetrischen Schlüssel kennt. Will man sich mit Einmalpasswörtern an mehreren Webdiensten anmelden, so benötigt man entweder eine zentrale Authentifizierungsinstanz, die die symmtrischen Schlüssel kennt, oder man benötigt für jeden Webdienst ein eigenen OTP-Token.

Eine Weile sind verschiedene Anbieter den zweiten Ansatz gefahren. Bei allen möglichen Webdiensten konnte man sich einen Google Authenticator — speziell bei diesem Webdienst — ausrollen. Die Google Authenticator App quillt über mit Profilen unterschiedlicher Webdienste. Der Benutzer muss in der langen Liste der Profile, jeweils im richtigen Moment das richtige finden.

Mit einem U2F-Token ist das nicht nötig. Der Benutzer hat nur ein Gerät und wo er sich mit diesem Gerät überall registriert hat, ist im Endeffekt egal. Die Anzahl der registrierten Webdienste beeinträchtigt die Usability nicht.

Authentifizierung mit Smartcard

Eine Authentifizierung mit einer Smartcard arbeitet genau wie U2F mit einem asymmetrischen Schlüsselpaar. Der große Nachteil der Smartcard ist aber die Notwendigkeit eines Treibers. Nicht zuletzt ist das ein entscheidender Grund, weshalb in den vergangenen Jahren OTP ein solches Revival erlebt hat. Gerade im B2C bzw. Endanwender-Bereich ist es undenkbar, von Benutzern die Installation eines Treibers zu fordern.

Das U2F Protokoll wird mittels einer Javascript Bibliothek, die der jeweilige Webdienst einbinden muss, bereitgestellt.

Die Nutzung des USB-basierten U2F-Tokens funktioniert zur Zeit allerdings lediglich im Chrome Browser. Andere Browser sollen folgen.

U2F im Unternehmenseinsatz

U2F ist ein Protokoll, das deutlich für den Endanwender-Bereich gedacht ist. Es ist dezentral. Es schottet die einzelnen Webdienste gegeneinander ab. Der Benutzer kann bzw. muss den U2F-Token selber registrieren.

Wenn man sich die Player vom Anfang anschaut, dann macht auch dies Sinn. Die FIDO Alliance Mitglieder kommen zum größten Teil aus dem Endanwender-Markt. Ob Google, Mastercard, American Express. D.h. per se ist U2F nicht für den Unternehmenseinsatz entworfen.

Die charmante Handhabung bei der Anmeldung und der vergleichsweise niedrige Preis der Hardwaregeräte lassen uns aber trotzdem ein zweites mal über den Unternehmenseinsatz nachdenken.

Die AppId und Trusted Facets

Die oben erwähnte AppId ist im wesentlichen die URL. Anhand derer wird das für diesen Webdienst gültige Schlüsselpaar erzeugt bzw. später identifiziert. D.h. andere Webdienste mit anderen URLs müssten selber ein Schlüsselpaar registrieren. Da aber manche Anbieter wie https://google.com, https://maps.google.com, https://docs.google.com unter unterschiedlichen URLs mehrere Webdienste bereitstellen, für die der Anwender nicht jeweils wieder seinen U2F-Token registrieren soll, gibt es das Konzept der „Trusted Facets“. Hier kann definiert werden, dass ein einmal registrierter U2F-Token für spezielle Subdomains bzw. Hosts innerhalb der gleichen Domain verwendet werden darf.

D.h. der U2F-Token, der einmal für https://google.com registriert wurde kann außerdem auf https://maps.google.com und https://docs.google.com ohne erneute Registrierung verwendet werden.

Im Unternehmenseinsatz kommt man um die Nutzung der „Trusted Facets“ nicht umhin. Denn kein Unternehmen erwartet von seinen Benutzern, dass er sein Authentifizierungs-Device an https://crm.example.com, https://portal.example.com und https://vpn.example.com registrieren soll. Mit den „Trusted Factes“ lässt sich eine einmalige Registrierung realisieren.

Grenzen der Trusted Facets

Das Leben im Unternehmen gestaltet sich aber oft nicht so geradlinig. Innerhalb des Unternehmensnetzwerks sind manche Resourcen evtl. über andere Domainnamen als extern erreichbar. Manche Unternehmen verwenden intern bspw. eine Domain wie example.intranet oder example-intern.com, währen sie extern example.com verwenden.

Das CRM, das innerhalb des Unternehemsnetzwerk steht, ist also über https://crm.example-intern.com erreichbar, während der VPN-Zugang über https://vpn.example.com läuft. Die Trusted Facets erlauben aber nicht, eine andere Domain als vertrauenswürdig anzugeben. D.h. mit einem U2F-Token, der an https://example.com registriert wurde, kann man sich nicht an https://…example-intern.com anmelden. In dieser Domäne wäre eine erneute Registrierung nötig.

Zentrales Rollout

privacyIDEA-200pxWeiterhin will man im Unternehmensumfeld die Verteilung von Authentifizierungsgeräten zentral kontrollieren und nicht unbegrenzt und unkontrolliert dem Benutzer überlassen. Hierzu unterstützt ein Management-System wie privacyIDEA die Registrierung von U2F-Token nicht nur durch den Anwender, sondern auch durch den Administrator bzw. den Helpdesk. So können U2F-Geräte zentral und kontrolliert für die Mitarbeiter im Unternehmen ausgerollt bzw. registriert werden.

Der Masterkey

Schließlich gibt es bei den U2F-Geräten weiterhin einen Punkt, über den man sich im Klaren sein muss. Das Schlüsselmaterial. Zwar wird bei der Registrierung das asymmetrische Schlüsselpaar für den jeweiligen Webdienst erzeugt. Allerdings passiert dies auf Basis des Masterkeys. Dieser wurde vom Hersteller in einer konktrollierten Umgebung auf dem U2F-Token erzeugt. Es ist nicht vorgesehen, den Masterkey selber zu erzeugen. An anderer Stellen hatten wir bereits über die Risiken, das eigene Schlüsselmaterial nicht selber zu erzeugen, berichtet.

Die Argumentationslinie bei U2F ist hierbei folgende. Das Gerät schickt bei der Registrierung ein sogenanntes „Attestation Certificate“ — ein Beglaubigungszertifikat. Dieses Zertifikat soll gegenüber dem Registrar nachweisen, dass es sich um ein bestimmtes Gerät einer gewissen Klasse handelt. Somit könnte der Registrar sicherstellen, dass bspw. nur Geräte des Herstellers A registriert werden dürfen, weil diese vermeindlich einen höheren Sicherheitsstandard haben. D.h. durch das Beglaubigungszertifikat ist somit auch nachgewiesen, dass dies ein Gerät des Herstellers A ist und dieses Gerät nach gewissen Sicherheitsstandards erzeugt und initialisiert worden war. Könnte nun ein Anwender oder Unternehmen ein U2F-Token selber initialisieren, so wäre das Beglaubigungzertifikat nutzlos, da für den Registrar nicht mehr ersichtlich wäre, mit welchen Sicherheitsstandards der Token initialisiert wurde.

Hier muss jeder für sich abwägen, ob der Einsatz von vorinitialisierten U2F-Token im Unternehemsumfeld eine Option ist. Yubikeys im OTP- oder Challenge-Response-Modus lassen sich mit privacyIDEA initialieren, so dass Sie die Wahl zwischen U2F, OTP und Challenge Response haben.

 

 

,

OPOSSO – Subskriptionen verwalten

Die Open Source Busines Alliance vergibt dieses Jahr wieder den Open Source Busines Award – OSBAR. Diesmal sitze ich in der Jury und darf die verschiedenen eingesandten Projekte bewerten.

In den letzten Tagen gab es für mich eine interessante Projekteinreichung, die ich hier kurz vorstellen möchte.

Mein Hintergrund

Seit vielen Jahren erbringe ich IT-Dienstleistungen. Hierzu wurden viele Fremdprodukte und in letzter Zeit vermehrt Eigenprodukte beim Kunden genutzt, um die passende Lösung für den Kunden zusammenzustellen.

Auch als Reseller und IT-Dienstleister stellte ich bald fest, dass es wichtig ist, den Überblick über die Software beim Kunden zu behalten. Dabei war es eben nicht nur wichtig, zu wissen, welche Software beim Kunden im Einsatz ist. Sondern ebenso, wieviele Lizenzen oder Subskriptionen einer Software der Kunde hat. Wann laufen diese Subskriptionen aus? Als Reseller ist dies wichtig, um dem Kunden zeitnah entsprechende Verlängerungen anbieten zu können. Der Endkunde profitiert ebenfalls davon, einen Überblick über die Anzahl und Laufzeiten seiner Subskriptionen und Lizenzen zu haben. So kann er zu jeder Zeit optimal den Support des Herstellers in Anspruch nehmen oder sich von überflüssigen Lizenzen und Subskriptionen trennen.

Doch in all den Jahren begegnete mir nur ein proprietärer Hersteller, der für Reseller und Endkunden ein entsprechendes Portal bereitstellte, das mehr oder weniger gut dem Reseller und Kunde ermöglichte, Subskriptionen einzusehen und zu verwalten.

Für mich war das jeher unverständlich, denn der Hersteller muss diese Subskriptionen intern doch auch verwalten! Oder betreibt er hierzu eine Excel-Tabelle oder gar Google Docs?

In meiner Zeit als Produktmanager entwickelte ich ein entsprechendes Portal, mit dem wir firmenintern die Subskriptionen verwalteten. Es unterstütze auch die Sicht der Kunden, des Resellers und des Distributors. Doch leider wurde diese Software nie veröffentlicht.

Umso mehr freue ich mich, dass die SerNet GmbH dieses Thema aufgegriffen hat.

OPOSSO

Die SerNet GmbH entwickelt nun ein solches „Subscription Management System“ mit dem Namen „OPOSSO“ und dem Ziel, dieses als Open Source öffentlich verfügbar zu machen. OPOSSO wurde beim Open Source Business Award eingereicht. Derzeit ist das System noch nicht als Download verfügbar, da es sich bei der SerNet noch in Entwicklung befindet und sich die Entwickler noch nicht entschieden haben, es zu veröffentlichen. Allerdings kann man sich unter oposso.samba.plus ein erstes Bild davon machen, was uns erwartet.

Die SerNet GmbH ist bzw. Mitarbeiter der SerNet sind federführend in der Samba-Entwicklung. Außerdem hat die SerNet mit Verinice ein Information-Secucity-Management-System als Open Source am Start.

Wir dürfen also gespannt sein, was uns erwartet!

Open Source Business Award

Open_2015_Logo_Farbe_RGB

Administrative Aufgaben stellen vor allem auch für kleine Unternehmen, oft schwere Herausforderungen dar. Man konzentriert sich gerne auf das Kerngeschäft: Die Entwicklung der eigenen Produkte. Da stellt die Verwaltung der Subskriptionen eine selten geliebte Herausforderung dar. Größere Unternehmen haben aufgrund der Menge der Kunden und Subskriptionen vielmehr das Problem, in diesem Verwaltungsakt nicht die Übersicht zu verlieren.

Kunden können sich freuen, zentral eine klare Aussage über den Zustand ihrer Subskriptionen zu erhalten.

Somit kann ein entsprechende Open Source Software zur Verwaltung diese Subskriptionen für Hersteller und Kunden gleichermaßen sehr hilfreich sein.

Am 2.12.2015 wird auf der Open!2015 der Open Source Business Award verliehen. Ob OPOSSO einen Platz belegt haben wird, wird sich dort erweisen.

Zwei-Faktor-Authenti(fi)sierung

Ja was nun – Zwei-Faktor-Authentisierung oder Zwei-Faktor-Authentifizierung?

Im Deutschen gibt es zwei Begriffe. Die Authentisierung und die Authentifizierung. Im normalen Umfeld mag das noch klar sein. Die Authentisierung ist die Sichtweise des Benutzers. Der Benutzer authentisiert sich an einem System. Die Authentifizierung ist die Sichtweise des Systems selber. Das System authentifiziert den Benutzer.

Wenn sich ein Benutzer anmeldet, muss der Server definitiv viel mehr tun als der Benutzer. Seine Aufgabe ist viel komplexer. Es muss erst einmal nachschauen, ob der Benutzer existiert und dann auch noch, ob die Credentials, die der Benutzer gesendet hat, valide sind. Hieraus ergibt sich eine kleine Eselsbrücke. Der Server macht die Authentifizierung. Denn das Wort Authentifizierung ist auch viel komplexer als Authentisierung. Schließlich hat der Server mehr zu tun und deswegen das Wort auch zwei Buchstaben (fi) mehr.

Doch wie ist das, wenn man zwei Faktoren hat?

Die „Two-Factor-Authentication“im Computerbereich mit einem Hardware-Faktor hat RSA im Jahr 1986 ins Leben gerufen. Dumme Sache nur, dass die englische Sprache nicht zwischen Authentisieren und Authentifizieren unterscheidet. Dort heißt es eben nur to authenticate und authentication.

Bundesamt für Sicherheit in der Informationstechnik

Das BSI selber spricht im Grundschutzkatalog von von Zwei-Faktor-Authentisierung bei Maßnahme 4.392 und Maßnahme 4.133. Allerdings scheint im ganzen Maßnahmenkatalog auch nicht das Wort Authentifizierung zu fallen.

Wikipedia

Die Einträge bei Wikipedia laufen unter Zwei-Faktor-Authentifizieung.

Heise

Ebenso wird das Schlagwort Zweifaktor-Authentifizierung als Thema bei Heise geführt.

Der Duden

Der Duden (20. Auflage, 1991) kennt die Worte authentifizieren und authentisieren.

authentifizieren: Die Echtheit bezeugen, beglaubigen.

authentisieren: Gehoben für glaubwürdig/rechtsgültig machen

Keep it simple and the customer happy

Unabhängig davon, dass es scheinbar offiziell Zwei-Faktor-Authentifizierung heißt, wähle ich persönlich oft die einfachere Bezeichnung Zwei-Faktor-Authentisierung. Damit stelle ich die Person als den Handelnden und nicht das authentifizierende Geräte in den Mittelpunkt. Außerdem erscheint mir das Wort leichter zu merken und auszusprechen zu sein.

Neulich wies mich ein Bekannter darauf hin, dass es doch zwei Faktoren sein. Grammitikalisch korrekt müsste es also Zwei-Faktoren-Authentifizierung heißen. Oder aber Zweit-Faktor-Authentifizierung.

Doch das nehme ich gar nicht in den Mund. Denn hätte ich meine Kunden mit komplizierten Worten verwirren wollen, wäre ich Arzt geworden.