Von (Zwei-Faktor-)Authentisierung, (zu?) mächtigen Apps, Smartphones, TAN-Generatoren und Sicherheitsbedenken

[dev]

Ja, das ist ein Katz und Maus-Spiel, dennoch scheinst du auch deine Angriffsfläche nicht unbedingt vergrößern zu wollen.

 

Ich kenne halt schon Geschädigte, allerdings über App-In-Käufe und auf dem Großteil des Schadens ist er sitzen geblieben.

Es gibt keinen 100% Sicherheit, man kann es nur immer wieder schwerer machen, aber halt nicht unmöglich.

[MonacoFranzl]

Nach meinem Post von letzter Woche aufgrund eines Radiobeitrages, nun auch auf it-finanzmagazin.de ...

 

Zitat

 

17. Oktober 2023
„Erhöhtes Gefährdungs­potenzial“: Gericht hält App-TAN für unsicher – Banken müssen handeln

 

Eine Praxis zahlreicher Banken, die Banking-App und die Push-TAN-Lösung auf ein und demselben Smartphone oder anderem mobilen Endgerät zu erlauben, könnte gegen den Grundsatz der Zwei-Faktor-Authentifizierung verstoßen. Das zumindest stellt [...] das Landgericht Heilbronn fest. Für die Banken könnte das Handlungsbedarf mit sich bringen, denn sie müssten dies ggf. unterbinden.

 

Bei den meisten Online-Banking-Konten wird zur Sicherheit ein TAN-Verfahren per App verwendet, [...]. Problematisch ist es, das hat jetzt das LG Heilbronn entschieden, dass die Banken nicht Sorge dafür tragen, dass Kundinnen und Kunden die TAN-App, die ja funktional in einigen Fällen mit einer Photo-TAN-App kombiniert ist, nicht auf ein und demselben Gerät mit der jeweiligen Banking-App installiert ist. [...]

Spannender als die eigentliche Beurteilung des Sachverhalts, [...], ist ein Sachverhalt, den das Gericht in der Urteilsbegründung ausführt:

"Das sog. pushTAN-Verfahren, in dem die TAN auf dem Mobiltelefon in einem anderen Programm (App) angezeigt wird, als demjenigen, das den Bankzugang ebenfalls mittels auf demselben Smartphone installierter BankApp (SecureGo-App) vermittelt, weist ein erhöhtes Gefährdungspotenzial auf, da eine Verwendung nur noch zweier Apps auf einem Gerät statt Nutzung getrennter Kommunikationswege erfolgt; es liegt deshalb keine Authentifizierung aus wenigstens zwei voneinander unabhängigen Elementen i.S.v. § 1 Abs. 24 ZAG vor, weshalb die für die Annahme eines Anscheinsbeweises für die Autorisierung einer Zahlungsanweisung im Sinne von § 675w BGB erforderliche sehr hohe Sicherheit nicht bejaht werden kann."

Die regulatorischen technischen Standards (RTS) besagen bekanntermaßen, dass zwei unabhängige Elemente aus zwei Bereichen vorhanden sein müssen (Wissen, Besitz und Inhärenz) und dass erst hier die 2FA gewahrt wird. Sind beide Apps auf demselben Device installiert, wirft das folglich die Frage auf, ob diese Elemente tatsächlich unabhängig voneinander sind. Denn wird das Smartphone beispielsweise durch Malware oder einen Virus kompromittiert, würde das möglicherweise beide Apps betreffen und einen unerlaubten Zugriff auf das Konto erlauben.

Doch was bedeutet das jetzt für die Banken? Sie müssen sich fragen lassen, ob das bisherige Verhalten, das ja in der Vergangenheit mehrfach durch IT-Sicherheitsexperten in Zweifel gezogen wurde, in Ordnung und rechtssicher ist. Denn zumindest müssten sie vom Verbraucher verlangen, separate Geräte für Banking und TAN-Generierung zu nutzen. Das wiederum widerspricht der Convenience, ähnlich wie auf dem Gerät gespeicherte Passwörter.

Unklar ist allerdings noch, ob es damit getan ist, die Verbraucher zu einem solchen Verhalten aufzufordern oder ob es nicht vielmehr erforderlich ist, hier einen Riegel im Sinne des Verbraucherschutzes vorzuschieben. Banken sollten hier tätig werden, wollen sie in späteren Situationen nicht riskieren, für Betrugsdelikte zur Rechenschaft gezogen zu werden. Doch auch die Kunden müssen hier auf der Hut sein, auch wenn sich hieraus ein weniger bequemer Service erwächst. [...]

 

 

[MonacoFranzl]

Nun auch in anderen weniger "speziellen" Medien, z.B. chip.de ....

 

Zitat

 

Gerichtsentscheidung betrifft Millionen Bankkunden: TAN-Verfahren unsicher
24.10.2023

[...] Gleich in § 1 Absatz 24 des Zahlungsdiensteaufsichtsgesetzes (ZAG) wird geregelt, wie eine starke Kundenauthentifizierung beim Online-Banking auszusehen hat. Der Kernpunkt: Es müssen mindestens zwei Faktoren zum Einsatz kommen, so schreibt es auch die aktuell gültige Zahlungsdiensterichtlinie PSD2 vor. [...]
Das haben die meisten Banken als kostenlose TAN-Option im Angebot. Ein aktuelles Gerichtsurteil bescheinigt dem AppTAN-Verfahren jetzt aber ein "erhöhtes Gefährdungspotenzial" und spricht ihm die erforderliche Sicherheit ab. Das ist insofern ein Problem, weil viele Banken die AppTANs als sehr sicheren Weg für Mobile Banking verkaufen. [...]
[... Das]Gericht [hat] festgestellt, dass die Kombination aus Banking-App und TAN-App auf einem Gerät ein erhöhtes Gefährdungspotenzial besitzt.
Diese Diskussion ist nicht neu, denn man fasst die zwei Faktoren bei AppTAN auf einem Gerät zusammen. Schafft es ein Angreifer, ein Handy zum Beispiel durch eine Malware-Infektion zu kapern, ist nichts mehr sicher. Heute ist es durchaus gängige Praxis, dass Nutzer zwei Apps auf dem gleichen Handy nutzen, die Banking und TAN-Erzeugung erledigen.
Da aber die TAN-App isoliert von anderen Apps betrieben wird und sie wiederum durch ein Passwort oder biometrische Merkmale geschützt ist, hat man sie in der PSD2 als gesetzeskonform eingestuft, was Sicherheitsexperten schon damals kritisierten. Doch egal, wie man die Sache sieht, AppTANs werden millionenfach eingesetzt und bieten eben nicht den höchsten Sicherheitsstandard.
AppTAN ist unserer Einschätzung nach nicht unsicher, aber ein Kompromiss, weil man keine Gerätetrennung für die eingesetzten Faktoren hat. Auch das BSI rät deshalb dazu, die Sicherheit zu erhöhen, indem man zwei Geräte für Banking und TAN-Generierung einsetzt. Das ist ganz einfach möglich, indem man die Banking-Seite auf dem Computer öffnet und sich auf dem Handy dazu die TANs erzeugen lässt.
Außerdem gibt es Alternativen zu AppTAN, die man nutzen kann:
- chipTAN: Bei chipTAN kommt ein zusätzliches Gerät zum Einsatz, in das man die Girocard steckt und das dann passend zur Überweisung eine TAN erzeugt.
- PhotoTAN: Auch hier bieten Banken zusätzliche Geräte an, mit denen eine Grafik vom Bildschirm abgescannt wird und das daraufhin eine TAN generiert.
- Ohne TAN: Was nicht erzeugt wird, kann man nicht verlieren. Die Postbank zum Beispiel bietet mit BestSign ein Verfahren an, bei dem man gar nicht mehr mit einer TAN hantieren muss.
Leider bieten nicht alle Banken die genannten Alternativen an. Es bleibt abzuwarten, ob die Einschätzung aus dem Urteil höhere Wellen schlägt und die Anforderungen an TAN-Verfahren in der nächsten Zahlungsdiensterichtlinie möglicherweise verschärft werden.

 

 

[wpf-leser]

Eine durchaus mehrseitige Betrachtung des Themas gibt es nun bei der Finanz-Szene:

Nach dem Push-TAN-Urteil: Wie sicher ist Smartphone-Banking?

[Holgerli]

Ich fand das Interview interessant. Das Fazit war (zumindest habe ich es so verstanden): Auch wenn das aktuelle, bankenübergreifende Sicherheitskonzept nicht optimal ist und sogar ein Rückschritt zu den Hardwaregeräten ist, so gibt es keine breiten Angriffs-Vektoren.

[morini]

Am 21.9.2023 um 22:34 von alsuna:

Wie macht ihr das denn mit den Passwörtern? Passwortmanager in Android empfinde ich als stressig und absolut unschön in der Bedienung. Und es kennt ja hoffentlich kaum jemand hier sein Passwort für's Depot aus den Kopf. 

 

Bei den allermeisten Leuten dürften die Passwörter im Browser (Google Chrome, Firefox etc.) abgespeichert sein. Vielleicht ist das relativ unsicher, dafür aber sehr bequem zu handhaben, weil man sich das jeweilige Passwort nicht merken muss.

[morini]

Am 12.10.2023 um 18:03 von dev:

Durch Offline-TAN-Generatoren, hat man meiner Meinung nach, eine viel geringere Angriffsfläche.

 

Das sehe ich genauso.

 

Am 12.10.2023 um 18:03 von dev:

Vor ein paar Monaten hatte ich die Bank wegen der Einstellung von Offline-Verfahren gewechselt, das ist die, welche aktuell mit Softwareproblemen kämpft.

 

Ein Offline-Verfahren bietet beispielsweise die DAB (Smartbroker_alt) an, während die Baader Bank (Smartbroker+) damit leider nicht dienen klann, was natürlich sehr schade ist. Vielleicht meinst du ja diese Kombination.

[alsuna]

vor 3 Stunden von morini:

Bei den allermeisten Leuten dürften die Passwörter im Browser (Google Chrome, Firefox etc.) abgespeichert sein. Vielleicht ist das relativ unsicher, dafür aber sehr bequem zu handhaben, weil man sich das jeweilige Passwort nicht merken muss.

Und zur Synchronisierung über Geräte hinweg dann deren Server? Tut mir leid, es werden viel zu häufig Kundendaten irgendwo rausgetragen, als dass ich meine Passwörter auf irgendeinem Server lagern würde.

[morini]

vor 7 Stunden von alsuna:

Und zur Synchronisierung über Geräte hinweg dann deren Server? Tut mir leid, es werden viel zu häufig Kundendaten irgendwo rausgetragen, als dass ich meine Passwörter auf irgendeinem Server lagern würde.

 

Ich weiß nicht, ob es von Bankenseite aus zulässig ist, dass Kunden ihre Zugangsdaten (Zugangsnummern sowie Online-Banking/Brokerage-Passwörter) im Internetbrowser abspeichern. Auf jeden Fall dürften das sehr viele Kunden (vielleicht sogar die meisten) so machen.

 

Zum Glück haben mögliche Hacker damit zunächst "nur" einen Lesezugriff auf Werpapierdepots und Konten, was natürlich auch nicht passieren dürfte.

[alsuna]

@morini das meinte ich nicht, sondern die Frage, wie denn das Passwort von Gerät A auf Gerät B kommt.

 

Und ich würde immer noch gerne wissen, wie ihr euch in den Apps einloggt. Denn da hilft es nicht, dass der Browser das Passwort kennt.

 

vor 1 Stunde von morini:

Ich weiß nicht, ob es von Bankenseite aus zulässig ist, dass Kunden ihre Zugangsdaten (Zugangsnummern sowie Online-Banking/Brokerage-Passwörter) im Internetbrowser abspeichern.

Interessanter Gedanke. Ich habe mal auf die Schnelle bei DKB, Onvista-Bank und ING geschaut: In den Details sind sie erstaunlich unterschiedlich, aber im Grunde verbieten sie nur das ungesicherte elektronische Speichern. Damit sollte der Passwortmanager eines vernünftigen Browsers erlaubt sein.

 

Interessant wird es dann an diesem Punkt:

Zitat

Wissenselemente (siehe Ziff. 2 Absatz 3) sind geheim zu halten; sie dürfen insbesondere

[...]

nicht auf einem Gerät notiert oder als Abschrift zusammen mit einem
Gerät aufbewahrt werden, das als Besitzelement oder zur Prüfung des
Seinselements dient.

 

(DKB Bedingungen für das Online Banking, Absatz 8.1. Nr 2, quasi wortgleich bei der ING)

Das lese sich so, dass die Bank auch nicht will, dass der Passwortmanager auf dem Gerät genutzt wird, das als Besitzfaktor genutzt wird. In der Praxis heißt das, der Passwortmanager auf dem Mobiltelefon darf das Passwort nicht kennen. Interessant.

[magicw]

vor 25 Minuten von alsuna:

Das lese sich so, dass die Bank auch nicht will, dass der Passwortmanager auf dem Gerät genutzt wird,

Ist eine interessante Frage.  Ich denke eher, dass sich das nur auf Klartextkopien des Passworts auf dem Selben Gerät beschränkt. 

Ein Passwortmanager speichert a) Passwörter nicht in Klartext --> damit ist für mich nämlich "..nicht auf einem Gerät notiert oder als Abschrift.." schon mal nicht erfüllt.

Und b) benötigt man wiederum ein "Wissenselement", nämlich ein Passwort, um den Paswortmanager überhaupt nutzen zu können.

Vermutlich gibt es aber noch keine Rechtssprechung dazu.

 

                     

[alsuna]

vor 2 Stunden von magicw:

Vermutlich gibt es aber noch keine Rechtssprechung dazu.

Und es ist vermutlich in unser aller Interesse, dass das so bleibt.

[Holgerli]

Allgemein habe ich die Tendenz festgestellt, dass das "Besitz"-Element immer mehr mit "Wissen"-Elementen angereichert wird und immer mehr ein Hybrid wird.

 

Früher reichte es auch, dass man ohne großeres Brimborium einfach den Einlogversuch mit OK bestätigte.

Heute wird defakto bei jeder App mindestens einmal, wenn nicht sogar zweimal der Fingerabdruck oder das Passwort verlangt.

Bei Microsoft ist es übrigens so, dasss einzelne Programme bei der 2FA-Authentifierung ein Wegwerf-"Wissen"-Element einbauen wie eine zweistellige Zahl die auf dem Computer-Monitor angezeigt und auf der Handy-App eingegeben werden muss

[wpf-leser]

vor 18 Stunden von Holgerli:

Ich fand das Interview interessant.

Dito. Weniger wegen der (i.d.R. bekannten) Grundlagen, aber v.a. aufgrund der Darstellungsweisen, operativ-praktischen Verknüpfungen und Einschätzungen.

 

vor 18 Stunden von Holgerli:

Das Fazit war (zumindest habe ich es so verstanden): Auch wenn das aktuelle, bankenübergreifende Sicherheitskonzept nicht optimal ist und sogar ein Rückschritt zu den Hardwaregeräten ist, so gibt es keine breiten Angriffs-Vektoren.

Auf sehr hoher Flughöhe: ja.

 

Deutlich spannender fand ich einige Punkte darum herum. Zum Beispiel, dass heute die soziale Schiene (Phishing) das niederschwelligere und lukrativere Einfallstor zu sein scheint - verbunden mit dem Gedanken, dass die Institute hieran arbeiten (sollten) - und dann die Technik ggf. wieder in den Vordergrund rücken könnte, wenn das gelingen würde.

 

Auch fand ich gut, dass der "Rückschritt" in die (nicht-)manipulierbare Anzeige und Kopierbarkeit aufgedröselt wurde und letzteres keine praktische Relevanz (mehr) zu haben scheint. (Wobei ersteres natürlich auch alles andere als Trivial ist...)

 

Interessant fand ich dann aber doch, dass abseits von App-Lösungen keine weiteren potenziell zukünftigen Authentisierungs-Möglichkeiten gesehen werden. Ich habe es aber auch so verstanden, dass das nicht zwangsläufig sinnvoll wäre bzw. dass das in der Gesamtschau schlicht die beste Lösung sein dürfte. Zeitgleich hindert das ja niemanden daran, andere Lösungen (z.B. TAN-Generatoren) mit anderen Vorzügen und Nachteilen anzubieten.

vor 1 Stunde von Holgerli:

Allgemein habe ich die Tendenz festgestellt, dass das "Besitz"-Element immer mehr mit "Wissen"-Elementen angereichert wird und immer mehr ein Hybrid wird.

Jein.

Zitat

Bei Microsoft ist es übrigens so, dasss einzelne Programme bei der 2FA-Authentifierung ein Wegwerf-"Wissen"-Element einbauen wie eine zweistellige Zahl die auf dem Computer-Monitor angezeigt und auf der Handy-App eingegeben werden muss

Das "Wegwerf-Wissen-Element" dient ja gerade dazu, das Besitz-Element zu verifizieren. Um es dafür besser geeignet zu machen, ist die Gültigkeit stark begrenzt.
"Knopfdruck" geht bei Entra ID übrigens auch noch - per Option "Telefonanruf". Microsoft möchte dann einmal die Raute-Taste und das Thema ist erledigt.

[Holgerli]

Die Fragen, die ich mir stelle sind:

 

1.) Was kann man als Anbieter tun, wenn die zu prüfenden Angaben (z.B. bei der Überweisungsfreigabe) zumindest teilweise ignoriert werden? Hier war ja eine Aussage, dass bei der Überweisungsfreigabe höchstwahrscheinlich oftmals nur noch der Betrag geprüft aber die IBAN-Verifizierung übersprungen wird?

2.) Andererseits frage ich mich, was ich z.B. mit Zusatz-Information mache, die schlicht nicht stimmen. So zeigt z.B. SC bei der Freigabe des Logins am PC in der Handy-App an, dass ich mich von Borken/NRW aus einlogge. Das stimmt schlicht und ergreifend nicht, weil das der Standort meines ISP Deutsche Glasfaser ist. Nutze ich einen Zugang der Telekom, wird auch nur in 50% der Fälle den korrekten Standort zeigen.

 

Was ich z.B. bei der ING vermisse ist, dass ein Konto nur über die eine (Handy-App) oder nur über die andere (Hardware-Leser) Art freigegeben werden kann. Warum kann man nicht beides anbieten wie es die CoDi seit Jahren macht?

[wpf-leser]

vor 20 Minuten von Holgerli:

1.) Was kann man als Anbieter tun, wenn die zu prüfenden Angaben (z.B. bei der Überweisungsfreigabe) zumindest teilweise ignoriert werden? Hier war ja eine Aussage, dass bei der Überweisungsfreigabe höchstwahrscheinlich oftmals nur noch der Betrag geprüft aber die IBAN-Verifizierung übersprungen wird?

Nicht viel. Um das Prozessrisiko zu verringern würde ich spontan einen Timer für die Aktivierung des Bestätigungsbuttons in Erwägung ziehen. Das zwingt den Benutzer aber nach wie vor nicht zur Prüfung.

Eine weitere Alternative wäre es, die Daten getrennt anzuzeigen und einzeln bestätigen zu lassen. Ggf. wieder mit Timer und / oder anderen Hindernissen (wechselnde Button-Positionen, Slider, ... was weiß ich).

Im Grunde liegt aber die Verantwortung hierfür schon heute beim Kunden - die Möglichkeit an sich ist ja da. Darum lautet das Heilbronner Urteil auch so, wie es lautet. Eine Bank muss hier so gesehen nicht mehr tun, als sie es heute i.d.R. macht.

Und das fühlt sich für mich durchaus richtig an.

 

vor 26 Minuten von Holgerli:

2.) Andererseits frage ich mich, was ich z.B. mit Zusatz-Information mache, die schlicht nicht stimmen. So zeigt z.B. SC bei der Freigabe des Logins am PC in der Handy-App an, dass ich mich von Borken/NRW aus einlogge. Das stimmt schlicht und ergreifend nicht, weil das der Standort meines ISP Deutsche Glasfaser ist. Nutze ich einen Zugang der Telekom, wird auch nur in 50% der Fälle den korrekten Standort zeigen.

Auch das ist ja letztlich nur ein Zusatz-Service. Da stoßen wir wieder an andere Grenzen. Wichtig ist, dass die Kerninformationen (mMn. Betrag & Ziel-IBAN) stimmen. Und genau an der Stelle wird das Betrugspotenzial ja kritisiert, wenngleich es gering (für mich: gering genug) ist.

 

vor 29 Minuten von Holgerli:

Warum kann man nicht beides anbieten wie es die CoDi seit Jahren macht?

Als unwissender: Wie macht das denn die CoDi? Will die dann Leser und App oder wahlweise eines von beiden?

Ersteres wäre natürlich für die Sicherheitsbewussten User eine "Hochburg", zweiteres vmtl. abschreckend - man hätte dann ja immer noch die "App mit Vollzugriff" inkl. Authentisierung...

(Insofern finde ich das Vorgehen der ING nicht komplett dumm - auch wenn ich die App-Lösung nutze.)

[franko]

vor 1 Stunde von Holgerli:

Was kann man als Anbieter tun, wenn die zu prüfenden Angaben (z.B. bei der Überweisungsfreigabe) zumindest teilweise ignoriert werden? Hier war ja eine Aussage, dass bei der Überweisungsfreigabe höchstwahrscheinlich oftmals nur noch der Betrag geprüft aber die IBAN-Verifizierung übersprungen wird?

Statt die IBAN nur anzuzeigen, könnte man den Kunden die IBAN (oder zumindest Teile davon) in der Freigabe-App (oder an dem entsprechenden Hardware-Gerät) erneut eingeben lassen.

[Holgerli]

vor 1 Minute von franko:

Statt die IBAN nur anzuzeigen, könnte man den Kunden die IBAN (oder zumindest Teile davon) in der Freigabe-App (oder an dem entsprechenden Hardware-Gerät) erneut eingeben lassen.

Die Frage ist: Wie aufwendig will man es machen? Ich finde es ehrlich gesagt schon jetzt extrem nervig, dass ich mittlerweile die "Besitz"-Elemente nur mit zusätzlichen "Wissen"-Elementen freigeben kann.

Ab einer gewissen Stelle wird man dann das Problem haben, dass die Leute den Prozess einfach abbrechen, weil es ihnen zu kompliziert wird.

 

vor 1 Stunde von wpf-leser:

Auch das ist ja letztlich nur ein Zusatz-Service. Da stoßen wir wieder an andere Grenzen. Wichtig ist, dass die Kerninformationen (mMn. Betrag & Ziel-IBAN) stimmen.

Dann wäre ich da der Meinung, dass man diese Informationen ganz einfach weglässt. Bei der ING muss ich mittlerweile bei jeder Freigabe zusätzlich anklicken, dass ich nur freigeben soll, wenn ich sicher bin, dass die Freigabe von mir ausgelöst wurde.

Man wird einerseits mit unnötigen und teilweise falschen Informationen überflutet, die man getrost ignorieren kann. Anderrerseits soll man alle wichtigen Informationen im Auge behalten und reagieren, wenn diese falsch sind.

 

vor 1 Stunde von wpf-leser:

Als unwissender: Wie macht das denn die CoDi? Will die dann Leser und App oder wahlweise eines von beiden?

Zumindest früher (bis Ende 2022) war es so, dass man sich beim Login-Prozess entscheiden konnte, welches vom beiden man nimmt.

 

vor 1 Stunde von wpf-leser:

...zweiteres vmtl. abschreckend - man hätte dann ja immer noch die "App mit Vollzugriff" inkl. Authentisierung...

Ich muss eigentlich sagen, dass ich das ziemlich gut fand. Sicherheitsbedenken sehe ich da jetzt nicht. Ist ja nun nicht anders als die DKB wo man auch die freie Wahl zwischen PushTAN und ChipTAN hat/hatte.

Ich war ein großer Fan davon, weil die CoDi es in den 7 oder 8 Jahren mindestens 4x geschafft hat die App so zu verschlimmbessern, dass die einzige Möglichkeit nur in einer komplette De- und anschließenden Neuinstallation bestand.

 

Ich frage mich ehrlich gesagt wie Betrugsanfällig die Geldüberweisen-Funktion von PalPal ist: Du bekommst eine Mailadresse von einem Menschen der heisst Max Mustermann. Die Mail soll M.Mustermann@Wasauchimmer.xxxx sein. Du gibst die Mailadresse und den Geldbetrag an. Du bekommst eine Nachricht Sie wollen Max Mustermann 10.00 Euro überweisen, weg und das wars. keine 45 Sekunden.

[franko]

vor 49 Minuten von franko:

Statt die IBAN nur anzuzeigen, könnte man den Kunden die IBAN (oder zumindest Teile davon) in der Freigabe-App (oder an dem entsprechenden Hardware-Gerät) erneut eingeben lassen.

vor 29 Minuten von Holgerli:

Die Frage ist: Wie aufwendig will man es machen? Ich finde es ehrlich gesagt schon jetzt extrem nervig, dass ich mittlerweile die "Besitz"-Elemente nur mit zusätzlichen "Wissen"-Elementen freigeben kann.

Da gebe ich dir vollkommen recht. Als Kunde gefällt mir das auch nicht. Außerdem schmälern die vielen Zusatz-Abfragen nicht nur den Komfort, sondern führen auch zu einer gewissen Abstumpfung bei den Nutzern.

Allerdings hattest du ja gefragt, was ein Anbieter tun könnte, wenn Kunden (die vielleicht schon etwas abgestumpft sind) die angezeigte IBAN nicht kontrollieren. Mehr Sicherheit gibt es halt oft nur unter Verzicht auf Komfort.

[SlowHand7]

Das wäre doch etwas lästig.

Es sollte doch davon auszugehen sein daß man die IBAN prüft.

Da reicht doch ein Blick auf die Prüfsumme und die letzten 4 Ziffern.

 

[wpf-leser]

vor 3 Stunden von Holgerli:

Sicherheitsbedenken sehe ich da jetzt nicht.

Ich auch nicht. Andere offenbar schon. Darum gibt es diesen Faden.

 

vor 3 Stunden von Holgerli:

Ich frage mich ehrlich gesagt wie Betrugsanfällig die Geldüberweisen-Funktion von PalPal ist: Du bekommst eine Mailadresse von einem Menschen der heisst Max Mustermann. Die Mail soll M.Mustermann@Wasauchimmer.xxxx sein. Du gibst die Mailadresse und den Geldbetrag an. Du bekommst eine Nachricht Sie wollen Max Mustermann 10.00 Euro überweisen, weg und das wars. keine 45 Sekunden.

Immerhin ist die Anmeldung vergleichbar sicher. Wenn man im Banking mit denselben Faktoren auch Aufträge freigibt, ist das (vielleicht?) kein großes Ding. Ich weiß auch nicht, wie das mit größeren Summen dort abläuft. Und mir fällt auf, dass solche Zahlungen natürlich auf PayPal-Kunden beschränkt sind. Anders nochmal draufgeschaut plant die EPI (aus dem Hinterkopf) ja ähnliches - mit Mobilfunknummern statt Email-Adressen. Und nochmal "angezeigt" werden Adresse und Betrag zum Bestätigen auch bei PayPal, oder?

Meinem Verständnis nach komplett vergleichbar.

[morini]

Am 29.10.2023 um 02:16 von alsuna:

Und zur Synchronisierung über Geräte hinweg dann deren Server? Tut mir leid, es werden viel zu häufig Kundendaten irgendwo rausgetragen, als dass ich meine Passwörter auf irgendeinem Server lagern würde.

 

Es ist in der Tat so, dass die Bank-Zugangsdaten (also auch Passwörter) über Geräte hinweg synchronisiert werden, wenn man im Browser "Synchronisation" ausgewählt hat, und die Zugangsdaten werden somit sicherlich auf Google-Servern gelagert.

[oktavian]

Am 12.10.2023 um 09:11 von slowandsteady:

funktioniert zB die DKB Tan App nicht, einfach weil Custom ROMs pauschal nicht unterstützt werden. Eine Begründung gibt es nicht.

die app läuft mit lineageos. Vermutlich benötigt die app googledienste wie pushservice. Kenne eh keine Bank, die in anderen repositories die apps anbietet als im playstore. Leider geht google frei und banking nicht. Nutze ein reines banking gerät mit lineageos, aber brauche da (leider) gaaps. Die offline TAN apps laufen i.d.R. ohne. Sind diese neueren ,welche solche Probleme machen.

[morini]

 

vor 23 Stunden von oktavian:

die app läuft mit lineageos. 

 

Ist es seitens der DKB bzw. anderer Banken überhaupt zulässig, die App unter LineageOS bzw. unter einem anderen Custom ROM zu verwenden?

 

Gibt es in einem solchen Fall Schadensersatz, wenn das Konto gehackt werden sollte?

 

Die Bank dürfte nämlich beim Einloggen erkennen können, unter welchem Betriebssystem die App läuft, was einem im Schadensfall auf die Füße fallen könnte.

[Saek]

On 11/10/2023 at 10:04 AM, oktavian said:

Leider geht google frei und banking nicht.

Bei mir laufen unter GrapheneOS und CalyxOS ohne GApps die Apps von Postbank, comdirect, DKB, ING, IBKR, DAB Secure, Barclays, Advanzia. Nur die Hanseatic Secure App ging nicht, als ich sie vor einiger Zeit probiert hatte.