Sicherer "Passwort zurücksetzen"-Prozess


Inhaltsverzeichnis

Wie sollte der Prozess “Passwort Zurücksetzen” sicher gestaltet werden? Welche Vor- und Nachteile existieren bei der Implementierung einer Rücksetzfunktion?

Es gibt eine Menge verschiedener, völlig legitimer Blickwinkel und auch einen Haufen ziemlich schlechter Prozess-Definitionen. Möglicherweise haben die meisten Endbenutzer jede davon schon oft erlebt, also wird versucht, anhand einiger dieser Beispiele herauszufinden, wie der Prozess für das Zurücksetzen von Passwörtern funktionieren sollte und was bei der Implementierung beachtet werden muss. Dieser Artikel kann auch bei einem Penetrationstest als Testkatalog benutzt werden.

Passwortspeicherung: Hashing, Verschlüsselung und Klartext

Als Erstes muss geklärt werden wie Passwörter gespeichert werden. Es existieren drei Möglichkeiten, wie Passwörter normalerweise in einer Datenbank gespeichert werden:

  • Klartext - Die Passwortliste ist im Klartext.
  • Verschlüsselt - Gewöhnlich wird symmetrische Verschlüsselung verwendet und das verschlüsselte Passwort befindet sich ebenfalls in einer Spalte.
  • Hash-Wert - Ein Einwegverfahren, bei dem das Kennwort am besten von einer Salt-Funktion begleitet wird.



Passwörter sollten niemals im Klartext gespeichert werden! Eine Injection-Schwachstelle, eine schlampige Datensicherung oder einer von einem Dutzend anderer einfacher kleiner Ausrutscher und alle Passwörter sind öffentlich zugänglich.

Die Verschlüsselung ist besser, aber immer noch fehlerhaft. Das Problem bei der Verschlüsselung ist die Entschlüsselung, ist es möglich, die Chiffren in Klartext umzuwandeln, und sobald das passiert, sind die lesbaren Passwörtern zurück.

Die Idee des Hashings beschreibt eine Einwegfunktion. Die einzige Möglichkeit, ein Passwort von einem Benutzer mit seinem Hashing-Partner abzugleichen, besteht darin, die Eingabe zu hashen und zu vergleichen. Um Angriffe von Werkzeugen wie Rainbow Tables zu verhindern, wird dem Prozess eine Zufälligkeit hinzugefügt, indem eine Salt-Funktion eingerichtet wird. Somit müsste jedes Passwort einzeln mit einem Brute-Force-Angriff getestet werden.

Immer das Passwort zurücksetzen und nicht erinnern

Warum ist eine "Erinnerung" notwendig? Weil der Benutzer sein Passwort vergessen hat! Was wird versucht wirklich zu tun? Dem Benutzer helfen, sich wieder anzumelden. Eine Passwort-Erinnerungsfunktion ist aber der falsche Ansatz.

Das Wort "Erinnerung" wird umgangssprachlich verwendet, aber was wir hier wirklich tun wollen, ist, dem Benutzer sicher zu helfen, wieder online zu gehen. Da dieses sicher geschehen soll, gibt es zwei Gründe, warum eine Erinnerung (d.h. tatsächlich das aktuelle Passwort zu schicken) nicht funktionieren wird:

  • Die E-Mail ist ein unsicherer Kanal. Genauso wie keine sensiblen Daten über HTTP gesendet werden sollten, so ist die Transportschicht für E-Mail nicht sicher. Eigentlich ist es viel schlimmer als das bloße Versenden von Informationen über ein unsicheres Transportprotokoll, da Ihre E-Mail oft im Speicher verbleibt, von Systemadministratoren abgerufen werden kann.
  • Der Betreiber des Dienstes sollte sowieso keinen Zugriff auf das Passwort haben. In dem vorigen Abschnitt über die Speicherung, wurde erklärt, dass es sowieso keine Möglichkeit gibt, das Passwort zu lesen und es dann per E-Mail zu verschicken.

Aufzählung von Benutzernamen und die Auswirkungen auf die Anonymität

Die Nachricht, die besagt: "Es ist kein Benutzer mit dieser E-Mail-Adresse registriert" ist keine gute Wahl. Das Problem ist natürlich, wenn eine Website, dass ein Benutzer mit dieser E-Mail-Adresse registriert ist.

Ein Risiko, das entsteht, ist ein Risiko des Social Engineering. Sobald ein Angreifer eine Person einem Dienst zuordnen kann, hat er eine Information, die er nutzen kann. Beispielsweise kann er die Person kontaktieren, während er sich als Vertreter der Website ausgibt, und in einem Spearphishing-Angriff nach zusätzlichen Informationen fragen.

Diese Praxis birgt auch die Gefahr einer "Benutzernamen-Aufzählung", bei der eine ganze Sammlung von Benutzernamen oder E-Mail-Adressen auf ihre Existenz auf der Website überprüft werden kann, indem man einfach Anfragen stapelt und sich die Antworten ansieht.

Senden eines zurückgesetzten Passworts vs URL für gleiche Zwecke

Das nächste Konzept, welches evaluiert werden muss, betrifft die Art und Weise, wie das Passwort zurückgesetzt wird, und es gibt zwei gängige Ansätze:

  • Erzeugen Sie ein neues Passwort auf dem Server und senden Sie es per E-Mail
  • Senden Sie eine eindeutige URL per E-Mail, die ein Zurücksetzen erleichtert


Dennoch gibt es noch ein weiteres großes Problem mit dem ersten Ansatz, denn er macht die böswillige Sperrung eines Kontos denkbar einfach. Wenn die E-Mail-Adresse von jemandem bekannt ist, der ein Konto auf einer Website besitzt, dann kann dieser jederzeit gesperrt werden, indem das Passwort zurückgesetzt wird. Das ist ein Denial-of-Service-Angriff! Aus diesem Grund ist ein Zurücksetzen etwas, das nur nach erfolgreicher Überprüfung des Rechts des Benutzers geschehen sollte.

Wenn über eine Reset-URL gesprochen wird, ist eine Website-Adresse gemeint, die für diesen speziellen Fall des Reset-Prozesses einzigartig ist. Natürlich muss diese zufällig sein und darf weder etwas Rätselhaftes sein, noch externe Verweise auf das Konto enthalten, für das sie das Zurücksetzen ermöglicht. Zum Beispiel sollte eine zurückgesetzte URL nicht einfach ein Pfad wie "/reset/?user=Jan" sein.

Es muss ein eindeutiges Token erstellt werden, das in einer E-Mail als Teil der Reset-URL verschickt werden kann und dann mit einem Datensatz auf dem Server neben dem Konto des Benutzers abgeglichen wird, um zu bestätigen, dass der Inhaber des E-Mail-Kontos tatsächlich derjenige ist, der versucht, das Passwort zurückzusetzen. Da der obige Prozess dem Benutzer die Möglichkeit gibt, ein neues Passwort zu erstellen, müssen wir nun natürlich sicherstellen, dass die URL über HTTPS geladen wird.

Das andere, was wir mit einer Reset-URL erreichen wollen, ist die zeitliche Begrenzung des Token, so dass der Reset-Vorgang innerhalb einer bestimmten Zeitspanne, beispielsweise innerhalb einer Stunde, abgeschlossen sein muss. Auf diese Weise wird sichergestellt, dass das Fenster, in dem das Zurücksetzen erfolgen kann, auf ein Minimum beschränkt wird. Sollte also jemand die zurückgesetzte URL erhalten, kann er sie nur innerhalb eines sehr kleinen Fensters ausführen. Natürlich kann ein Angreifer jederzeit den Reset-Vorgang erneut beginnen, aber er muss dann eine weitere eindeutige Reset-URL erhalten.

Schließlich möchten wir sicherstellen, dass es sich um einen einmaligen Vorgang handelt. Sobald der Reset-Vorgang abgeschlossen ist, sollte das Token gelöscht werden, so dass die Reset-URL nicht mehr funktionsfähig ist. Wie im vorigen Punkt soll damit sichergestellt werden, dass ein Angreifer ein sehr begrenztes Fenster hat, in dem er die zurückgesetzte URL missbrauchen kann. Außerdem wird das Token natürlich nicht mehr benötigt, wenn der Rücksetzungsprozess erfolgreich abgeschlossen ist.

Einige dieser Schritte mögen etwas übertrieben erscheinen, aber sie verringern keineswegs die Nutzbarkeit der Funktion und erhöhen die IT-Sicherheit, wenn auch unter Umständen, von denen wir hoffen, dass diese ungewöhnlich sind. In 99% der Fälle wird der Benutzer das Zurücksetzen innerhalb einer sehr kurzen Zeitspanne durchführen, und das Passwort wird nicht in unmittelbarer Zukunft erneut zurückgesetzt.

Die Rolle von CAPTCHA

Tatsächlich ist das CAPTCHA nicht so sehr eine Sicherheitsmaßnahme als vielmehr eine Identifizierungsmaßnahme. Die Absicht ist es, die automatisierte Einreichung von Formularen zu vermeiden, die natürlich als Versuch, die IT-Sicherheit zu verletzen, benutzt werden könnten. In einem Kontext der Passwort-Rücksetzung bedeutet ein CAPTCHA, dass die Rücksetzfunktion nicht erzwungen werden kann, weder um eine Person zu spammen noch um zu versuchen, die Existenz von Konten zu identifizieren, was natürlich nicht möglich ist, wenn die Hinweise im Abschnitt zur Identitätsprüfung weiter oben befolgt wurden.

Geheime Fragen und Antworten

Das Problem bei Passwort-Rücksetzungen, die zu 100% von E-Mail abhängig sind, besteht darin, dass die Konto-Integrität der Website, auf der versucht wird, das Passwort zurückzusetzen, dann zu 100% von der Integrität des E-Mail-Kontos abhängt. Wer Zugriff auf die E-Mail hat, hat nun Zugriff auf jedes Konto, das allein durch den Erhalt einer E-Mail zurückgesetzt werden kann. Für diese Konten ist Ihre E-Mail wirklich der Hauptschlüssel zu dem Online-Leben.Ein Thema, das diesen Posten durchdrungen hat, ist die Kommunikation: Dem Kontoinhaber muss so viel wie möglich darüber gezeigt werden, was in den einzelnen Prozessschritten vor sich geht, ohne etwas preiszugeben, das für bösartige Zwecke verwendet werden könnte.

Eine Änderung des Passwortes kann aus einer von zwei verschiedenen Quellen stammen:

Änderung des Passwortes, während man bereits angemeldet ist, weil der Besitzer etwas anderes will. Zurücksetzen des Passworts beim Abmelden, weil der Besitzer es vergessen hat. Während es in diesem Post in erster Linie um Resets geht, mindert eine Benachrichtigung im ersten Beispiel oben das Risiko, dass jemand anderes das Passwort ohne Wissen des rechtmäßigen Eigentümers ändert. Wie könnte dies geschehen? Ein sehr häufiges Szenario ist, dass sich jemand anderes das Passwort des rechtmäßigen Eigentümers beschafft hat (wiederverwendetes Passwort, das von einem anderen Ort aus geknackt wurde, Schlüssel angemeldet, leicht zu erraten usw.) und beschlossen hat, es zu ändern und ihn auszusperren. Ohne eine E-Mail-Benachrichtigung hat der wirkliche Besitzer keine Ahnung von der Änderung.

Nun muss der Eigentümer beim Zurücksetzen natürlich bereits den Prozess eingeleitet haben (oder die verschiedenen oben beschriebenen Maßnahmen zur Identitätsüberprüfung überwunden haben), so dass die Änderung für ihn keine Überraschung darstellen sollte, aber die E-Mail-Benachrichtigung ist ein positives Feedback und eine zusätzliche Überprüfung. Außerdem sorgt sie für eine konsistente Erfahrung in beiden oben genannten Szenarien.

Eine Möglichkeit, dieses Risiko zu mindern, ist die Implementierung eines geheimen Frage- und Antwort-Musters. Wählen Sie eine Frage, deren Antwort nur der Nutzer kennen sollte, dann werden dieser möglicherweise dazu aufgefordert, bevor eine Passwortzurücksetzung durchführt wird. Das gibt die zusätzliche Gewissheit, dass die Person, die versucht, das Zurücksetzen durchzuführen, tatsächlich der Inhaber des Kontos ist.

Wenn es um geheime Fragen geht, müssen die Menschen vor sich selbst geschützt werden! Mit anderen Worten, die Webanwendung selbst sollte die geheime Frage definieren, oder besser gesagt, eine Reihe von geheimen Fragen festlegen, aus denen der Benutzer wählen kann. Im Idealfall sollte der Benutzer bei der Registrierung seines Kontos zwei oder mehr geheime Fragen definieren, die dann als zweiter Kanal zur Identitätsprüfung verwendet werden können. Mehrfache Fragen erhöhen das Vertrauen in den Verifizierungsprozess und geben die Möglichkeit, Zufälligkeiten hinzuzufügen, die Redundanz bieten, falls jemand legitimerweise eine Antwort vergessen haben sollte.

Was macht also eine gute Geheimfrage aus? Es gibt ein paar Faktoren:

  • Sie sollte prägnant sein - Die Frage ist auf den Punkt gebracht und unmissverständlich.
  • Die Antwort ist spezifisch - Keine Fragen, die von ein und derselben Person auf unterschiedliche Weise beantwortet werden könnte.
  • Die möglichen Antworten müssen vielfältig sein - Eine Frage nach der Lieblingsfarbe einer Person würde zu einer kleinen Teilmenge möglicher Antworten führen.
  • Es sollte schwer sein, die Antwort zu finden - Wenn die Antwort für jeden leicht zu finden ist, ist diese unsicher.
  • Die Antwort muss im Laufe der Zeit konstant sein - Die Frage nach dem Lieblingsfilm einer Person kann in einem Jahr zu einer anderen Antwort führen.


Die andere Sache, die bei der Antwortkomponente der Geheimfrage zu berücksichtigen ist, ist die Speicherung. Es in der Datenbank im Klartext zu speichern, birgt ähnliche Risiken wie das gleiche mit dem Passwort, nämlich dass eine Offenlegung der Datenbank sofort den Wert offenbart und nicht nur die Anwendung gefährdet, sondern möglicherweise auch andere, völlig unabhängige Anwendungen, die von den gleichen geheimen Fragen abhängen.

Durch geheimen Fragen und Antworten sind User anfälliger für Social Engineering. Der Versuch, jemandem direkt das Passwort eines Kontos zu entlocken ist fast unmöglich. Tatsächlich kann man mit jemandem ganz legitim ein Gespräch über viele Aspekte seines Lebens führen, die die Geheimfrage ausmachen und keinen Verdacht erregen könnten. Natürlich besteht die eigentliche Absicht einer Geheimfrage darin, dass sie sich auf die Lebenserfahrungen von jemandem bezieht, so dass sie einprägsam ist, und genau darin liegt das Problem - die Leute sprechen gerne über ihre Lebenserfahrungen! Dagegen kann man nicht viel tun, außer dafür zu sorgen, dass die verfügbaren geheimen Fragen weniger wahrscheinlich von der Art sind, die aus jemandem durch Social Engineering entwendet werden kann.

Zwei-Faktor-Authentifizierung

Bisher ging es darum, eine Identität auf der Grundlage von Kenntnissen des Antragstellers zu überprüfen. Ein zusätzliche geheime Konstante wird als ein Faktor der Authentifizierung betrachtet. In den meisten Szenarien ist es fast undurchführbar, eine biologische Validierung durchzuführen, insbesondere wenn es um die IT-Sicherheit von Webanwendungen geht. Daher ist es normalerweise das zweite Attribut, das bei der Zwei-Faktor-Authentifizierung (2FA) verwendet wird. Ein üblicher Ansatz für diesen zweiten Faktor ist die Verwendung eines physischen Tokens wie einer RSA SecurID oder Google Authenticator. Hier wird ein kryptischer PIN generiert, der von kurzer Dauer gültig ist und nicht durch statische Analysen abgeleitet werden kann.

Zurücksetzen über den Benutzernamen versus die E-Mail-Adresse

Sollte das Zurücksetzen nur über die E-Mail-Adresse möglich sein? Oder sollte das Zurücksetzen auch über den Benutzernamen erlaubt werden? Das Problem mit dem Zurücksetzen über den Benutzernamen ist, dass es keine Möglichkeit gibt, den Benutzer zu benachrichtigen, wenn der Benutzername ungültig war, was nicht die Tatsache offenbart, dass jemand anderes ein Konto mit diesem Namen haben könnte. Im vorigen Abschnitt wurde durch das Zurücksetzen per E-Mail sichergestellt, dass der rechtmäßige Eigentümer dieser E-Mail immer eine Rückmeldung erhalten konnte, ohne ihre Existenz im System öffentlich bekannt zu geben. Das kann man nicht mit nur einem Benutzernamen tun.

Die kurze Antwort lautet also: Nur E-Mail! Wenn versucht wird, es mit einem Benutzernamen zu ermöglichen, dann wird es Fälle geben, in denen der Benutzer sich fragt, was vor sich geht, oder in denen Sie die Existenz von Konten offenlegen. Ja, es ist nur ein Benutzername und keine E-Mail-Adresse, und ja, jeder kann jeden (verfügbaren) Benutzernamen wählen, den er möchte, aber es besteht immer noch eine gute Chance, dass Sie aufgrund der Neigung zur Wiederverwendung von Benutzernamen implizit Kontoinhaber preisgeben werden.

Was passiert also, wenn jemand seinen Benutzernamen vergisst? Angenommen, der Benutzername ist nicht bereits die E-Mail-Adresse (was oft der Fall ist), dann ist der Vorgang ähnlich wie bei einer Passwortzurücksetzung - man gibt die E-Mail-Adresse ein und schickt dann eine Nachricht an diese Adresse, ohne ihre Existenz preiszugeben. Der einzige Unterschied besteht darin, dass die Nachricht diesmal lediglich den Benutzernamen und nicht die URL zum Zurücksetzen des Passworts enthält. Entweder das oder die E-Mail erklärt, dass es für diese Adresse kein Konto gibt.


Identitätsprüfung und Genauigkeit von E-Mail-Adressen

Ein Schlüsselaspekt von Passwort-Rücksetzungen ist die Überprüfung der Identität der Person, die versucht, die Rücksetzung durchzuführen. Ist dies tatsächlich der rechtmäßige Eigentümer des Kontos? Oder jemand, der versucht, entweder das Konto zu infiltrieren oder den Besitzer zu belästigen?

E-Mail ist eindeutig der bequemste und allgegenwärtige Kanal zur Überprüfung der Identität. Es ist kein idiotensicherer Beweis, und es gibt viele Fälle, in denen es nicht ausreicht, einfach nur E-Mails unter der Adresse des Kontoinhabers zu empfangen, wenn ein hohes Maß an Identität-Vertrauen erforderlich ist, daher die Verwendung von 2FA, aber es ist fast immer der Ausgangspunkt eines Rücksetzungsprozesses.

Eine Sache, die entscheidend ist, wenn E-Mail eine Rolle spielen soll, ist das Vertrauen, dass die E-Mail-Adresse zunächst einmal korrekt ist. Wenn jemand ein falsches Zeichen hat, dann werden Resets eindeutig nicht durchkommen. Ein E-Mail-Verifizierungsprozess zum Zeitpunkt der Registrierung ist ein sicherer Weg, um sicherzustellen, dass die Adresse korrekt ist. Ein bekannter Ablauf aus der Praxis: Eine Registrierung, eine E-Mail wird mit einer eindeutigen URL zugeschickt, auf die durchgeklickt werden muss, um zu überprüfen, ob der Empfänger tatsächlich der Inhaber dieses E-Mail-Kontos sind. Wenn die Anmeldung nicht funktioniert, bevor dieser Vorgang abgeschlossen ist, besteht eine Motivation, die E-Mail-Adresse zu validieren.

Wie bei vielen Sicherheitsaspekten erlegt auch dieses Modell einen Aufwand für die Benutzerfreundlichkeit auf und bietet uns im Gegenzug ein höheres Maß an IT-Sicherheit in Bezug auf das Vertrauen in die Identität des Benutzers. Dies mag für eine Website in Ordnung sein, bei der der Benutzer großen Wert darauf legt, sich erfolgreich und sicher registrieren zu können, und gerne einen weiteren Schritt im Prozess in Kauf nimmt (bezahlte Dienstleistungen, Bankgeschäfte usw.), aber es ist die Art von Dingen, von denen er sich vielleicht einfach abwendet, wenn er das Konto als "Wegwerfkonto" wahrnimmt, wie z.B. einfach als ein Mittel, um einen Beitrag zu kommentieren ohne personenbezogene Daten zu hinterlassen.

Identifizieren, wer den Rücksetzvorgang initiiert hat

Offensichtlich gibt es Spielraum für den Missbrauch der Funktion zum Zurücksetzen des Passworts, und Übeltäter können dies auf verschiedene Weise tun. Ein sehr einfacher Trick, mit dem wir die Quelle der Anfrage verifizieren können besteht darin, die IP-Adresse des Anfragenden an die Rücksetz-E-Mail anzuhängen. Dadurch erhält der Empfänger einige Informationen zur Identifizierung der Quelle der Anfrage.

Benachrichtigung über eine Änderung per E-Mail

Ein Thema, das diesen Posten durchdrungen hat, ist die Kommunikation: Dem Kontoinhaber muss so viel wie möglich darüber gezeigt werden, was in den einzelnen Prozessschritten vor sich geht, ohne etwas preiszugeben, das für bösartige Zwecke verwendet werden könnte.

Eine Änderung des Passwortes kann aus einer von zwei verschiedenen Quellen stammen:

Änderung des Passwortes, während man bereits angemeldet ist, weil der Besitzer etwas anderes will. Zurücksetzen des Passworts beim Abmelden, weil der Besitzer es vergessen hat. Während es in diesem Post in erster Linie um Resets geht, mindert eine Benachrichtigung im ersten Beispiel oben das Risiko, dass jemand anderes das Passwort ohne Wissen des rechtmäßigen Eigentümers ändert. Wie könnte dies geschehen? Ein sehr häufiges Szenario ist, dass sich jemand anderes das Passwort des rechtmäßigen Eigentümers beschafft hat (wiederverwendetes Passwort, das von einem anderen Ort aus geknackt wurde, Schlüssel angemeldet, leicht zu erraten usw.) und beschlossen hat, es zu ändern und ihn auszusperren. Ohne eine E-Mail-Benachrichtigung hat der wirkliche Besitzer keine Ahnung von der Änderung.

Nun muss der Eigentümer beim Zurücksetzen natürlich bereits den Prozess eingeleitet haben (oder die verschiedenen oben beschriebenen Maßnahmen zur Identitätsüberprüfung überwunden haben), so dass die Änderung für ihn keine Überraschung darstellen sollte, aber die E-Mail-Benachrichtigung ist ein positives Feedback und eine zusätzliche Überprüfung. Außerdem sorgt sie für eine konsistente Erfahrung in beiden oben genannten Szenarien.

Verantwortung an andere Anbieter delegieren

Die Realität ist, dass der Aufbau einer sicheren Kontoverwaltung nicht einfach ist. Es ist nicht so, dass es technisch schwierig wäre, es ist nur so, dass eine Menge Einstellungsmöglichkeiten existieren. Es geht nicht nur um das Zurücksetzen, sondern um den gesamten Registrierungsprozess, die sichere Speicherung von Passwörtern, die Handhabung mehrerer ungültiger Anmeldeversuche und so weiter.

Heutzutage gibt es zahlreiche Drittanbieter, die gerne die Mühe auf sich nehmen, all dies selbst zu schreiben und alles in einen verwalteten Dienst zu abstrahieren. Zu den Optionen gehören unter anderem Keycloak, OpenID, OAuth, Google und Facebook.


Penetrationstest, um das schwächste Glied zu finden

All das, was oben steht, ist im Hinblick auf die Sicherung eines einzigen Kontos passend, aber eine Sache, die immer beachtet werden muss, ist das Ökosystem rund um das Konto. Diese Szenarien sind immer Teil eines Penetration Tests.

Fazit

Wenn dies wie ein umfassender Beitrag aussieht, gibt es dennoch reichlich zusätzliches Material. Die Rolle einer Rettungs-E-Mail-Adresse, was passiert, wenn Sie den Zugriff auf die E-Mail des Kontos verlieren. Wie bereits gesagt wurde, ist es nicht so, dass Resets schwierig sind, es ist nur so, dass es eine Menge Angriffsvektoren dazu gibt.

Oben stehen Beispiele, bei denen die Umsetzung zu Problemen führen konnte, und es gibt noch viele weitere Präzedenzfälle, in denen schiefgegangene Resets Probleme verursacht haben.

Es ist also vorsicht geboten bei der Erstellung des Resets. Ein Bedrohungsbaum für die verschiedenen Berührungspunkte ist hilfreich und beim Aufbau des Features zu denken, wie ein Black Hat, sonst besteht eine gute Chance, dass es jemand anderes als ein Pentester dieses tut!


Neugierig? Überzeugt? Interessiert?

Vereinbaren Sie ein unverbindliches Erstgespräch mit einem unserer Vertriebsmitarbeiter. Nutzen Sie den folgenden Link um einen Termin auszuwählen:

 Termin vereinbaren

Loading...