Dockersafe für vertrauliche Software

Published in

C³AI

13 min readFeb 10, 2022

Container-Technologien wie Docker erfreuen sich immer größerer Beliebtheit, besonders da die klassische Installation und Konfiguration von Anwendungen in den letzten Jahren an Aktualität verloren hat.

Die Plattformunabhängigkeit spielt dabei eine große Rolle, da die dadurch resultierende Einfachheit ein enormes Zeitersparnis für Entwickler, Nutzer und Betreiber der gedockerten Anwendung ermöglicht. Aufgrund des generischen Ansatzes ist die Erzeugung von einer einfachen bis zu einer komplexen Anwendung innerhalb weniger Schritte erreicht. Dies bietet Einsteigern bis hin zu professionellen Anwendern die Möglichkeit, in kürzester Zeit Anwendungen bereitzustellen, weshalb sich die Anwendung somit an jede Zielgruppe richtet.

Die Bereitstellung kann über mehrere Wege erfolgen. Eine der Möglichkeiten ist die lokale Erzeugung des Dockerimages auf dem Hostsystem, das eine unmittelbare Verwendung gewährt. Eine weitere Möglichkeit ist die Bereitstellung über eine Registry, die der zentrale Speicherort der fertigen Anwendung ist. Von dort aus kann jeder Nutzer, der über den Zugriff auf die Registry verfügt, die Anwendung verwenden. Abhängig von den Unternehmensrichtlinien ist die Registry entweder öffentlich zugänglich oder steht nur für die interne Verwendung bereit. Docker Hub ist eine der größten und bekanntesten öffentlichen Registries auf der ca. 8.7 Mio. Dockerimages bereitgestellt werden.

Der Vorteil der leichten Verwendung von Dockerimages stellt jedoch zugleich einen Risikofaktor dar. Die durch die Einfachheit der Anwendung suggerierte Sicherheit ist ein Trugschluss, der oftmals dazu führt, dass Nutzer sich den Risiken nicht bewusst sind beziehungsweise diese unterschätzen und dadurch nachlässig in der Verwendung von Images agieren.

Ähnlich wie klassische Software, unterliegen auch Images der Notwendigkeit regelmäßiger Wartung und Aktualisierung. Angesichts der Größe und des Aufbaus der Images stellt die Wartung jedoch einen hohen Aufwand dar, infolgedessen die Aktualität einer Vielzahl an Images nicht gewährleistet ist. Diese Obsoleszenz hat zur Folge, dass Images Sicherheitslücken und Verwundbarkeiten aufweisen.

Die Auffindung sowie die Behebung von Sicherheitslücken und Verwundbarkeiten bei Dockerimages stellt Anwender vor eine Herausforderung. Mit Hilfe von DockerSafe werden Dockerimages auf Sicherheitslücken und Verwundbarkeiten überprüft und potenzielle Systemrisiken somit restringiert.

Produkt

Idee

Die Idee von DockerSafe ist die Offenlegung von sicherheitskritischen Bestandteilen einer Anwendung. Im Hinblick auf diesen starken Gesichtspunkt wird das Ziel der Verfügbarkeit und der Verbreitung von sicherer Software angestrebt sowie eine Transparenz der erstellten beziehungsweise genutzten Anwendung von DockerSafe Nutzern sichergestellt.

Die Implementierung der Sicherheitsaspekte in die Entwicklung von Dockerimages geht mit einer hohen Komplexität einher, weshalb die intuitive Gestaltung des User Interfaces von DockerSafe von hoher Relevanz ist, sodass eine möglichst einfache Bedienung sowie Interaktion für die Nutzer erzielt wird.

DockerSafe schafft einen Mehrwert für den Nutzer, indem es durch die intuitiven Bedienungseigenschaften eine mühelose Integration in den Verwendungsprozess von Dockerimages ermöglicht sowie ein qualitativ höherwertigeres Ergebnis, ohne dabei zusätzlichen Aufwand in Anspruch zu nehmen, liefert.

Oberfläche

Die über mehrere Iterationen hinweg entwickelte Oberfläche besteht aus zwei Ansichten, der Übersichts- und der Reportansicht. Das Eingabefeld sowie eine Auflistung der gescannten Dockerimages bilden die Elemente der Übersichtsseite.

Über die Eingabe des Referenznamens des zu scannenden Dockerimages in das Eingabefeld und des folgenden Absendebefehls, erfolgt die Aufnahme in die Liste und ein einmaliger Scan wird durch einen im Hintergrund laufenden Cronjob ausgeführt.

Beispiele für Referenznamen können alpine:lastet oder privateregistry.company.local/myapp:3.4.1 sein. Wird die Eingabe des Versions-Tags weggelassen, greift DockerSafe automatisch auf das Versions-Tag latest zu.

Die Listendarstellung der Scanresultate (Abbildung 1) gewährleisten eine Übersicht der wichtigsten Merkmale und Erkenntnisse des Scans.

Dazu zählen der Imagename, die Anzahl der Verwundbarkeiten und der Scan Status. Des Weiteren lassen sich pro Listenelement zwei Aktionsbuttons auslösen, die den Scan erneut durchführen oder den Scaneintrag löschen. Die Reportansicht lässt sich über den Imagenamenlink erreichen. Ein Intervall in der Übersichtsseite aktualisiert alle 5 Sekunden die Darstellung, damit dem Nutzer eine aktuelle Ansicht geboten wird. Es öffnet dem Nutzer die Transparenz in welchem Status sich seine Scans befinden.

Abbildung 1: Übersicht der Scanresultate

Auf der Reportansicht (Abbildung 2) werden in dem oberen Bereich der Dockerimagename sowie die Anzahl der Verwundbarkeiten angezeigt.

Direkt darunter folgt eine tabellarische Darstellung aller Pakete mit den ermittelten Verwundbarkeiten. Zu jedem Paket ist der Name, die installierte Version, die Verwundbarkeiten-ID und der Schweregrad ersichtlich. Des Weiteren kann die Anzahl der auszugebenden Einträge pro Seite sowie eine Sortierung der oben genannten Felder, als auch eine Filterung durch ein Suchfeld vorgenommen werden. Zusätzlich dazu kann über einen Link der jeweiligen ID eine externe Referenz zur Detailansicht der Verwundbarkeiten abgerufen werden. Diese Eigenschaften ermöglichen eine individuelle Ausgabe und Informationsauswahl für den Nutzer.

Abbildung 2: Reportansicht der Verwundbarkeiten eines Dockerimages

Aufgrund der Vererbungsstruktur von Dockerimages besteht die Möglichkeit, dass Verwundbarkeiten mehrfach durch den Scan gefunden und mehrmals in der Reportansicht angezeigt werden.

Tech Stack

Das Produkt ist in Form einer Webanwendung umgesetzt und wird zentral über einen Webserver bereitgestellt. Die wesentlichen Gesichtspunkte bei der Wahl des Tech Stacks innerhalb von Dockersafe bestanden darin, leichte Komponenten zu integrieren, die durch die Größe der Community und der kurzen Updatezyklen einen hohen Sicherheitsstandard haben sowie schnell und einfach erlernbar sind.

Das Deployment erfolgt über den Einsatz der Docker-Technologie in Verbindung mit Docker-Compose, das für die komfortable Nutzung von Docker steht. Die Verwendung von Docker-Compose erfolgt durch eine YAML-Datei, in der einzelne Services (Container) definiert werden und infolgedessen eine Dokumentation der gesamten Installation zur Verfügung gestellt wird. Die umfassende Komposition der Anwendung (Abbildung 3) erfolgt mittels vier Komponenten sowie einem externen Dienst. Im weiteren Verlauf werden die einzelnen Komponenten sowie ihre Funktionalitäten näher spezifiziert.

Frontend Layer

Der Einstieg des Nutzers erfolgt über das Frontend und geht nicht über das User-Interface hinaus. Die Gestaltung dessen wurde mittels Vue.js (gesprochen vju engl. view) umgesetzt. Vue.js ist eines der drei verbreitetsten progressiven Frameworks der Welt für die Erzeugung von Single-Page-Applications (SPA). Aufgrund der Popularität ist davon auszugehen, dass eine stetige Weiterentwicklung besteht und in regelmäßigen Zyklen Updates bereitgestellt werden. Aktuell wird Vue.js in Version 3.x über die offizielle Community-Seite angeboten und in DockerSafe integriert. Das SPA-Framework ist dafür bekannt, dem Entwickler einen leichten Einstieg ohne große Vorkenntnisse mit schnellen Ergebnissen zu ermöglichen.

SPAs sind Anwendungen, die nicht bei jeder Aktion des Nutzers den gesamten Content der Seite aktualisieren, sondern nur Änderungen an verwendeten Komponenten durchführen. Bei dem initialen Aufruf der Anwendung werden einmalig alle Komponenten der Seite erzeugt und jede weitere Aktion des Nutzers lädt nur die angesprochenen Komponenten neu. Daraus resultierend werden Ladezeiten gering gehalten, die zu einer smootheren User-Experience führen.

Der Datenaustausch zwischen dem Frontend und Backend Layer wurde mittels einer unidirektionalen HTTP-Schnittstelle gelöst, die im Backend Layer Abschnitt weiter beschrieben wird.

Backend Layer

Dockersafe ist serverseitig in der Interpretersprache PHP entwickelt worden. PHP gilt als eine, für die serverseitige Webprogrammierung, leichte Sprache und ermöglicht sowohl Einsteigern als auch professionellen Entwicklern, die Umsetzung von komplexen Anwendungen. Die aktuelle Version 8.x von PHP wird in Dockersafe verwendet.

Slim, ein kleines aber dennoch mächtiges PHP-Framework, bietet eine simpel und schnelle Gestaltung der Serverseitigen RESTful Anwendung und wird in der aktuellen Version 4.x genutzt. Sowohl PHP als auch Slim gelten als Systeme, die eine große Community vorweisen. Sie stehen in stetiger Weiterentwicklung und bringen neue Features sowie Fixes mit sich.

Backendseitig sind zwei Komponenten integriert, welche zum einen aus einer RESTful-API und zum anderen aus dem Dockerimage-Scan bestehen und auf die gemeinsame Geschäftslogik als auch auf die Daten im Persistence Layer zugreifen.

Die Restful-API Komponente wurde vorgesehen, um die Kommunikation zwischen dem Frontend und Backend Layer zu gestalten. Die unidirektionale Schnittstelle bietet dem Frontend die Möglichkeit, über die im Backend integrierten REST-Controller und die damit verbundenen HTTP-Methoden Scans zu erzeugen, abzuholen, erneut durchzuführen und zu löschen. Die Responses werden dem Frontend als JSON Datenstruktur zurückgegeben.

Die zweite Komponente in dem Backend Layer umfasst den Dockerimage-Scan. Diese wird sowohl asynchron als auch synchron verwendet. Die asynchrone Verwendung wird mittels eines Schedulers, welcher im Rahmens eines Cronjobs eingesetzt wird und die synchrone Variante durch die Ansprache eines Rest-Controllers genutzt. Die Implementation der Businesslogik des Dockerimage-Scans prüft diese auf die installierten Pakete innerhalb der Dockerimages. In diesem Zuge führt führt die externe Komponente, die sich über REST ansprechen lässt, die Klassifizierung der Pakete durch. Dabei handelt es sich um Verwundbarkeitsdatenbanken wie CVE oder GHSA, in denen bekannte Sicherheitslücken katalogisiert werden.

Der Response des Requests erfolgt als JSON und wird im nächsten Schritt aufbereitet, sodass eine Auswahl an Parametern zu dem Dockerimage in die Datenbank abgelegt wird.

Persistence Layer

Die Persistenz der Daten wird durch eine SQLite Datenbank abgebildet. Es ist das am meisten verwendete Datenbanksystem der Welt und unterstützt einen Großteil der im SQL-92-Standard festgelegten SQL-Sprachbefehle. SQLite enthält ein relationales Datenbanksystem, welches keine weitere Server-Software auf dem Hostsystem benötigt. Es muss lediglich eine SQLite-Bibliothek im Backend integriert werden, damit die Anwendung um Datenbankfunktionen erweitert wird, was folglich den großen Vorteil mit sich bringt, nicht auf externe Softwarepakete angewiesen zu sein. SQLite wurde als default Datenbank gewählt, um eine möglichst schnelle und einfache Installation der Anwendung zu ermöglichen. Abhängig von den Unternehmensrichtlinien oder der eigenen Präferenzen ist es dennoch möglich, weitere Datenbank-Management-Systeme anzubinden, die sowohl relational als auch nicht relational sein können.

Webserver

Der Webserver, der die Komposition zwischen dem Nutzer und der Anwendung abschließt, ist der am stärksten verbreitete Dienst Apache. Der Apache-Dienst wird in der aktuellen Version 2.x verwendet und erweckt durch das PHP-Erweiterungsmodul die Anwendung zum Leben. Um ein sicheres Erlebnis für den Anwender im Rahmen des Webservers zu realisieren, ist die Absicherung durch HTTPS unerlässlich. HTTPS ermöglicht die Verschlüsselung der Requests, die der Nutzer an die Webanwendung richtet, was dazu führt, dass ein Mitlesen des Verkehrs als sehr schwierig eingestuft wird.

Security Features

Eine wesentliche Zielgruppe von DockerSafe bilden Unternehmen, die mittels der Anwendung die interne Sicherheit sicherstellen möchten. Insbesondere für Geschäftskunden ist die IT-Sicherheit eine unabdingbare Voraussetzung, um das Unternehmen vor möglichen Cyberangriffen zu schützen und somit den Unternehmenserfolg zu wahren. Dementsprechend sind umfassende Sicherheitsstandards erforderlich.

In Unternehmen werden Images hauptsächlich für die interne Verwendung konstruiert, um in diesen Containern entweder Produktivsysteme oder Anwendungen für die betrieblichen Prozesse zu implementieren. Dabei handelt es sich um vertrauliche Informationen beziehungsweise sensible Daten, die nicht dafür bestimmt sind, über die Unternehmensgrenzen hinweg veröffentlicht zu werden. Demzufolge sind die Evaluierungsergebnisse über die Verwundbarkeiten, die gegebenenfalls in diesen Dockerimages gefunden werden, ebenso als vertraulich zu betrachten.

Eine Preisgebung der Sicherheitslücken oder der Verwundbarkeiten könnte mitunter verhängnisvolle Konsequenzen haben. Gelangen die potenziellen Schwachpunkte des Unternehmens in die Hände eines Angreifers, indem dieser sich Zugang zu dem DockerSafe-Account des Unternehmens verschaffen hat, kann nicht nur durch die Veröffentlichung der vertraulichen Informationen der Ruf des Unternehmens, sondern gleichermaßen der wirtschaftliche Erfolg gefährdet werden.

Anforderungen

Die Überprüfung von vertraulicher Software erfordert einen höheren Sicherheitsstandard, der am derzeitigen Stand mittels zusätzlicher Features implementiert werden soll. Die Anpassungen sollten darauf ausgelegt sein, das Sicherheitspotential von DockerSafe zu optimieren und den Zugriff auf die Scanergebnisse durch Unbefugte zu verhindern.

OWASP, eine Organisation für mehr Sicherheit im Web, hat bereits Sicherheitslücken dieser Art in dessen Top 10 aufgenommen. Unter der Bezeichnung “Insecure Design” ist diese Lücke auf Platz 4. Unter einem Insecure Design werden primär nicht ausreichende Sicherheitsfeatures einer Software verstanden. Dabei unterscheidet sich diese Verwundbarkeit insofern von anderen, dass nicht die Umsetzung das Problem ist, sondern die Planung. Wären alle Sicherheitsmaßnahmen in einer Anwendung korrekt und vollständig implementiert, könnte dennoch ein unsicheres Design vorliegen. Anders ausgedrückt, besteht ein unsicheres Design immer dann, wenn bei der Planung der Sicherheitsfeatures einer Anwendung nicht alle Aspekte bedacht wurden und bestimmte Features gänzlich fehlen. Auch im Fall von DockerSafe liegt das Problem nicht darin, dass vorhandene Features nicht vollständig umgesetzt sind. Vielmehr besteht die Herausforderung, dass eine Absicherung im Unternehmensbereich nicht eingeplant war und aufgrund dessen eine Sicherheitslücke eines unsicheren Designs vorliegt.

Ein höherer Sicherheitsstandard für vertrauliche Software sowie die Vermeidung von Schäden können mittels einer Implementierung erforderlicher Sicherheitsfeatures geboten werden.

Gegenspieler

Für eine vollständige Beleuchtung der Risiken durch diese Unsicherheit, ist eine Betrachtung von Beispielen für solche Angriffe erforderlich.

Ein Szenario für das Mitlesen von Informationen über die Verwundbarkeiten unternehmensinterner Dockerimages wäre beispielsweise der Aufruf durch andere Mitarbeiter. Je nach Unternehmen und deren Richtlinien bezüglich interner Informationsweitergabe kann es vorkommen, dass nur bestimmte Unternehmensangehörige Informationen über sicherheitsrelevante Details, wie die Verwundbarkeiten in Dockerimages, verfügen. Dies kann verschiedene Gründe haben, vorrangig steht für Unternehmen allerdings die Risikominimierung. Durch die Geheimhaltung von solchen Informationen soll verhindert werden, dass die Öffentlichkeit Wissen davon erhält und schlimmstenfalls Angriffe auf vorhandene Sicherheitslücken ausgeführt werden. Die Vergangenheit in der IT-Sicherheit zeigt, dass Angreifer versuchen bekannte Sicherheitslücken in einem System auszunutzen.

Sind die Details eines Dockerimages innerhalb von DockerSafe offen einsehbar, besteht das Risiko, dass unbefugte Mitarbeiter oder Externe die Informationen einsehen.

Ein anderes Szenario zum Einsehen dieser Details könnte eine Kompromittierung des Clients durch Angreifer sein. Hat dieser sich beispielsweise Zugriff auf die Anmeldedaten zu DockerSafe verschafft, könnten so sämtliche Informationen ausgelesen werden. Denkbar wäre ein Brute-Force Angriff auf das jeweilige Passwort, was je nach Passwortlänge und Zeichenkombination schnell Erfolg zeigen kann. Die Kommunikation vom Client zum DockerSafe-Server kann jedoch als relativ sicher vor Angriffen betrachtet werden, da diese über HTTPS erfolgen soll.

Je nach Unternehmen kann es entscheidend sein, Informationen über Unsicherheiten in Dockerimages geheim zu halten. Sind diese erst verbreitet, können Verwundbarkeiten ausgenutzt und das System angegriffen werden, bevor die Entwickler die Chance haben, diese zu schließen.

Lösungsvorschläge

Das Mitlesen von sensiblen Daten durch unbefugte Dritte kann mit Hilfe verschiedener Optionen, die jeweils unterschiedliche Vor- und Nachteile aufweisen, verhindert werden. Dabei muss vor allem in Bezug auf die Nutzung durch Unternehmen darauf geachtet werden, wie nahtlos sich die jeweilige Lösung in das Gesamtsystem integrieren lässt.

Ein Ansatz, Informationen über die Scans privater Images vor Spionage zu schützen, wäre die persistente Speicherung zu umgehen. Anhand einer temporären Speicherung würden die Ergebnisse nach Abschluss des Scans, sobald die Ergebnisse vorliegen, direkt ausgegeben werden. Dies könnte beispielsweise in Form einer CSV-Datei oder einer PDF erfolgen, die unmittelbar heruntergeladen und vom Benutzer an einem beliebigen Speicherort abgelegt werden kann. So wird vermieden, dass ein Unbefugter sich in DockerSafe einloggt und die Ergebnisse einsieht, irrelevant ob es ein externer Angreifer oder ein interner Mitarbeiter ist.

Ein gänzlich anderer Ansatz könnte mit einer besseren Autorisierung realisiert werden. Immer dann, wenn es essentiell ist, dass Informationen nur für autorisierte Personen zugänglich sind, erweist es sich als nützlich deren Identität auf mehrere Arten zu prüfen. Dies beschreibt den Vorgang der Multi-Faktor-Authentifizierung.

Dabei wird nach dem klassischen Login durch Nutzername und Passwort noch ein weiteres Merkmal des Benutzers angefordert. Klassische Beispiele davon sind der Versand eines Codes an die hinterlegte Email-Adresse oder an die Mobilnummer. Des Weiteren sind Sicherheitsfragen zu privaten Themen, die ausschließlich diese Person beantworten kann, verbreitet. Damit kann verlässlich festgestellt werden, ob der Benutzer tatsächlich der ist, der er vorgibt zu sein.

Auswahl

Um die richtige Lösung für das Problem des unbefugten Zugriffes wählen zu können, ist es sinnvoll deren mögliche Auswirkungen zu betrachten. Dabei sind nicht nur die Aspekte der Sicherheit wichtig, sondern auch die der Usability.

Die Implementierung einer Lösung ohne eine persistente Speicherung der Scanergebnisse hat einerseits den Vorteil, dass diese in dem Tool nicht ausgelesen werden können, andererseits entstehen dadurch zugleich neue Hindernisse. Eines davon ist die manuelle Ausführung der Speicherung sowie der sicheren und übersichtlichen Ablage der Ergebnisse. Dies ist nicht nur mühsam und widerspricht dem Sinn von DockerSafe, die Daten einfach zu präsentieren, sondern bringt außerdem neue Sicherheitsrisiken mit sich. Ein Beispiel für ein solches Risiko ist ein mögliches Auslesen, der auf dem System abgelegten und gar nicht verschlüsselten, Daten. Damit wäre das Problem lediglich an einen anderen Ort verschoben.

Der Einsatz einer Multi-Faktor-Authentifizierung hingegen, erhöht die Arbeit für den Nutzer kaum. Bei der ersten Anmeldung beziehungsweise Registrierung muss diese einmalig eingerichtet werden, je nachdem welcher “Faktor” genutzt wird. Bei dem Faktor “Wissen” handelt es sich größtenteils um eine Sicherheitsfrage, deren Antwort ausschließlich der Nutzer weiß. Ein anderer oft genutzter Faktor sind Email-Adressen oder Smartphones, an die Codes gesendet und in die Anwendung eingegeben werden.

Mit einer Multi-Faktor-Authentifizierung kann festgestellt werden, ob der Nutzer, der sich Zugang zu DockerSafe verschaffen will, tatsächlich die Person ist, für die er sich ausgibt oder ein unbefugter Dritter.

Implementierung

Die Implementierung einer Multi-Faktor-Authentifizierung kann entweder durch eigene Entwicklung geschehen, oder durch die Nutzung von fertigen Systemen und Abhängigkeiten. Darüber hinaus ist die Wahl des Faktors zu treffen, mit dem die Authentifizierung erfolgen soll. Da die Umsetzung mit einer Sicherheitsfrage aufgrund von möglichen Tippfehlern tendenziell fehleranfälliger ist, bietet sich diese Lösung weniger an. Unkomplizierter ist eine Realisierung über das Verschicken von Codes an Mobilgeräte.

Eine eigene Entwicklung kann zwar so erschaffen werden, dass sämtliche Anforderungen daran optimal erfüllt werden, bringt allerdings andere Nachteile mit sich. Zum einen ist eine derartige Entwicklung sehr zeitaufwändig. Insbesondere bei der Implementierung eines so umfangreichen Features, wie der Multi-Faktor-Authentifizierung, sind viele Aspekte zu beachten. Zum anderen muss das Feature selbst gepflegt werden, indem verwendete Pakete regelmäßig aktualisiert und etwaige Sicherheitslücken geschlossen werden. Dies ist sehr zeitintensiv und erfordert regelmäßige Aufmerksamkeit.

Deutlich leichter in der Implementierung und Wartung ist die Nutzung von fertigen Paketen und Abhängigkeiten. Für PHP gibt es dafür zahlreiche Angebote, die solche Lösungen enthalten und unentgeltlich verwendet werden können. Diese lassen sich einfach und unkompliziert in den bestehenden Quellcode integrieren und stellen alle nötigen Funktionen bereit. Je nachdem, welches Paket gewählt wird, sind unterschiedliche Services angebunden, die die Logik für die Erstellung des Faktors übernehmen. Der Google Authenticator ist nur eine von vielen Systemen, die eine Multi-Faktor-Authentifizierung anbieten.

Dabei wird ein QR-Code in der Anwendung eingebettet, der durch die entsprechende Google Authenticator App (Abbildung 4) gescannt und der anschließend generierte Code in die Anwendung eingegeben werden muss. Erst dann ist die Anmeldung vollständig abgeschlossen.

Abbildung 4: App Ansicht Google Authenticator

Dieser Vorgang obliegt bei jeder Anmeldung einer erneuten Ausführung. Zusätzlich ist es sinnvoll, eine automatische Logout-Funktion zu implementieren. Diese würde den Benutzer nach beispielsweise 10 Minuten abmelden und schützt vor einer Weiternutzung der aktiven Session durch Unbefugte.

Aufgrund dessen, dass ein potenzieller Angreifer bei einer Multi-Faktor-Authentifizierung nicht nur den Client beziehungsweise das Passwort kompromittieren, sondern zusätzlich Zugriff auf den sekundären Faktor, in diesem Fall auf das Mobilgerät, erlangen muss, ist ein erfolgreicher Angriff unwahrscheinlich.

Zusammenfassung

Im Fokus jeder Anwendung sollten Aspekte wie die Sicherheit des Anwenders und die Usability stehen. Da Unternehmen gegebenenfalls andere Anforderungen an Software haben, als private Nutzer, müssen nicht selten Anpassungen getätigt werden. Jedoch ist es unabdingbar, diese tatsächlich zu implementieren, damit die Anwendung weiterhin die Bedürfnisse der Benutzer erfüllt und wettbewerbsfähig ist. Insbesondere sind Sicherheitsfeatures eine lohnenswerte und zeitgemäße Erweiterung.