HOSTBLOGGER.de

Wie wäre es, gleich dahinter die Zeichen im Buchastbieralphabet anzeigen zu lassen?

Support-Code: EDTZZ (Echo - Delta - Tango - Zulu - Zulu)

Das dürfte es am Telefon einfacher machen. Je nach Nerdigkeit auch mit einem anderen Buchastbieralphabet

Und zusätzlich könnte man es noch mit einem Ablaufdatum versehen. Sagen wir mal in dem Moment wo man es sich anzeigen lässt ist es noch 10 Minuten oder auch nur 1 Minute gültig.

An alle Vorpostenden und in allen Ehren... aber als dritter könnte man glatt meinen, dass hier eher Konkurrenzdenken der Grund für die Kommentare ist als etwas anderes.

Ich kenne den Hintergrund v.a. den technischen bei manitu nicht. Aber ich vermute mal, dass manitu hier auf eine 1-zu-1-Zuordnung von Session und Supportcode setzt (@Manuel: Wenn ich mich irre -> korrigiere mich bitte).

Bevor hier gleich gekräht wird, oder gar Schlimmeres: Ich habe studiert. Und ja: Informatik. Und ich arbeite im wissenschaftlichen Umfeld. Und ja, auch das in der Informatik. Und noch genauer: Ich forsche mehr oder weniger in dem Umfeld, und einige meiner Doktoranden tun das auch.

Ja, man kann durchaus diskutieren, wie sicher feste Telefon-Passworte sind, oder auch mehr oder minder feste Support-Codes.

Ich erspare euch jetzt theoretisch-mathematisch/informationstheoretische Ansätze, nicht zuletzt weil ich glaube, dass es nicht einmal alle Formelzeichen dafür hier im Blog gibt (@Manuel: utf8mb4 wäre mal toll!).

Man kann jetzt von 2 Seiten an Passwörter, Telefon-Passwörter, Supportcodes etc. herangehen:

a) man betrachtet sie grundsätzlich als sicher, bis man vom Gegenteil ausgeht
b) man betrachtet sie grundsätzlich als unsicher, bis man sicher ist, dass sie sicher sind

Starten wir mal bei b) - denn das ist der einfachste Fall. Wenn man grundsätzlich davon ausgeht, müsste man jedes Passwort, egal ob mit oder ohne 2FA, quasi bei jedem Login ändern, notfalls sogar proaktiv. Über diese unsinningen Empfehlungen sind wir zum Glück dank oder wegen des BSI endlich weg. Die Gründe sind nachlesbar.

Wer es denn gerne so "hart" mag und dennoch eine Gültigkeit fordert: Der müsste auch den session-Namen ("Session-ID") zwischen Browser und Server regelmäßig ändern. Und ja, das Thema haben wir hier erforscht - mit allen Pros und Cons. Die Cons überwiegen [Spoiler: maßlos].

Nun zu a). Betrachten wir also jedes Passwort, und das ist ja ein Supportcode ebenfalls, ersteinmal als sicher, bis es kompromittiert ist.

Kompromittiert könnte das Supportcode-Passwort u.a. durch

1. Mitlesen von einer Person, die dahinter steht oder es mithört
2. Zugriff auf den Rechner/Handy/Browser/... des Angegriffenen
3. (weitere interne Gründe bei manitu)

Wir sind uns einig: Alles unter 3. wäre durch egal welche Maßnahme in Form einer Gültigkeit nicht zu erschlagen.

Wer Zugriff auf die Systeme des Angegriffenen unter 2. hat, hat auch auf sich änderne Passwörter/Codes Zugriff, nicht zuletzt, weil er im Kunden-Panel eh vermutlich allles ändern kann.

Es geht bei einer Gültigkeit also nur noch um den Fall 1.

Soweit ich das sehe (ich habe keinen Zugriff auf ein Kunden-Panel bei manitu) ist der Supportcode verschleiert, bis der Kunde ihn aktiv kenntlich macht. Ein versehentliches Mitlesen ("Erspähen") ist damit ad acta.

Es besteht also nur noch der theoretische Fall, dass eine dritte Person dahinter steht, der Kunde den Supportcode "anzeigt", und die dritte Person während deselben Session (siehe oben) ebenfalls den Support von manitu telefonisch bemüht. Und dass all das nicht auffällt.

Ja, diese Gefahr ist real und ich weise sie nicht von der Hand. Ich sehe durchaus Grund für die Bedenken, und weise gleichzeitig darauf hin, dass im Umgang mit Passwörtern jeder Art eine Grundvorsicht Grundvoraussetzung für die Sicherheit ist. Bei "normalen" Passwörtern gibt es 2FA als Absicherung, denn auch ein normales Passwort kann durch einen Dritten, der hinter einem steht, "mitgelesen" werden.

Ich gebe an dieser Stelle bewusst zu bedenken, dass ein sich ständig ändernder Code auch Nachteile hat:

der Code wird - wie auch immer - ständig neu geladen oder auf Zuruf erzeugt. Der Anrufende muss diesen Code also sicher im Zeitfenster ermitteln und diesen dann mitteilen. Aus eigener familärer Erfahrung weiß ich: Viele Leute schauen sich das an, notieren sich etwas (oder merken es sich), rufen dann etwas später an und: Ihr ahnt es: Der Code ist ungültig. Ja, das kann der Service abfrühstücken und darum bitten, der neuen Code zu sagen (oder generieren - je nach Ansatz). Aber das führt zu ->

die Akzeptanz sinkt - manchmal gegen Null. Und ein solches Akzeptanzproblem ist der größte (Sicherheits-)Feind jeder Absicherung. Ein statischer Code, der für eine Session (die ist ja sicher auch nicht ewig gültig) gilt, ist besser als einer, den es nicht gibt.

Und wer zum Schluss noch daran denkt, dass der Code ja zumindest bei jeder Benutzung invalidiert werden kann: Ja, das ist ein Ansatz. Aber man bedenke, dass manitu vermutlich jede Aktion, die über den Code in Verbindung mit der Session erfolgt, genau über diesen Code mitloggt. Ja, das kann man alles sicher in vielen Datenbanken und Beziehungen etc. festhalten - und wer mal solch ein System auch nur in Ansätzen gecodet hat, weiß, wo das endet. Eine Logging-Tabelle in Form Mitarbeitender|Code|Kunde|Aktion ist meist die allererste Wahl.

Nochmal: Ich stelle die Bedenken nicht in Abrede. Gebe aber aus Forschungssicht zu bedenken, dass die Sicherheit eines Systems nicht nur von Informatikern und Mathematikern gemacht wird (wir haben ja oft heere Ziele), sondern auch von und mit den Kunden leben muss. Und welche Kunden manitu hat (Zielgruppe mitsamt Erfahrung und IT-Afinität) wissen wir hier ja alle nicht, oder?