Diskussion:Transaktionsnummer/Archiv/1

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Transaktionsnummer/Archiv/1#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Transaktionsnummer/Archiv/1#Thema_1

Sicherheit von mTAN und iTAN

Ich habe einige Zeilen zum Thema Sicherheit von mTAN gelöscht, da sie, meiner Meinung nach, am Thema vorbei gehen. Für einen aufmerksamen Kunden bedarfs es keiner mTAN, da ist auch das alte TAN-Verfahren relativ sicher. Nur ein unaufmerksamer Kunde wird auf eine Phishing-Email hereinfallen. --Tische 22:24, 6. Jan 2006 (CET)

Sicherheit von mTAN

Ich habe den Artikel nochmal überarbeitet, denn anders als beim iTAN Verfahren ist Phishing beim mTAN Verfahren durch die erneute Übermittlung der Überweisung nicht mehr so schnell möglich. Zur Aussage von Tische kann ich nur sagen: Wenn alle Profis wären, würde niemand darauf reinfallen. Leider ist dem nicht so, deswegen macht es auch Sinn bessere Verfahren zu etablieren. --Andreas.Blueher 13:31, 10. Mai 2006 (CET)

Habe den Absatz "mTAN ist nur unsicher, wenn das Handy geklaut wird" ersetzt durch eine aktuelle, potentielle Sicherheitslücke (Anmeldung im GSM-Netz unter beliebiger Nummer). --Jvitense 15:27, 5. Mai 2009 (CEST)

Bitte GSM näher erläutern, ansonsten scheint die Änderung ja gut zu sein.--Wilske 18:56, 5. Mai 2009 (CEST)

Der Abschnitt "Seit Anfang 2009 ist eine potentielle Sicherheitslücke bekannt geworden, die auf einer Schwachstelle im GSM-Netz beruht. Betrüger melden sich mit einem modifizierten Handy unter einer beliebigen Mobilfunknummer am GSM-Netz an. Somit erhalten Sie auch die SMS, die an diese Nummer geschickt werden. Insbesondere können so bei einem gezielten Angriff SMS abgefangen werden, die mobile TANs beinhalten." war ja nett gemeint aber ich habe ihn wieder entfernt. Begründung: Seit dem 18 april 2009 hat ultrascan da nichts mehr nachgeliefert. Sie haben es einmal behauptet und wollten noch weitere Erkenntnisse nachliefern, was aber ausgeblieben ist.

---

---

Es ist auch völlig unlogisch wieso das gerade mit dem Nokia 1100 gehen soll und nicht auch mit anderen Handys. Es müsste eine Schwachstelle im GSM Netz sein. Nokia hat das ganze auch dementiert, siehe http://www.pcwelt.de/start/sicherheit/sonstiges/news/196999/kein_firmware_bug_im_nokia_1100/

Als weiteres Argument bringe ich an das außer einigen Newsseiten die darüber berichteten kein anderer je wieder davon berichtet hätte. Daher bleibt es eine stupide Behauptung solange bis das Gegenteil bewiesen ist. (nicht signierter Beitrag von 84.185.187.37 (Diskussion | Beiträge) 17:01, 12. Jan. 2010 (CET))

eTAN und Sm@rtTAN

Hierzu fehlen Informationen. Allgemein fände ich die Struktur angenehmer, wenn Sie in Form von „xTAN“ vereinheitlicht wäre. --Philipp Grunwald 19:47, 29. Jul 2006 (CEST)

Habe die sm@rt-TAN Passage etwas geändert. Ich denke so ist es gemeint. Die alte Version hat keinen Sinn ergeben. neue version: "Allerdings ist die Generierung gültiger TANs nicht an das Lesegerät des jeweiligen Kunden gebunden, so dass bei Verlust des Lesegerätes mithilfe der Karte und einem beliebigen anderen Lesegerät gültige TANs generiert werden können." -- unregistriert 13:55, 02. Jan 2008 (GMT+01.00)

Was mir fehlt: (1) CortalConsors verwendet wie im Artikel angegeben einen eTAN-Generator, aber für interne Überweisungen und Depot-Aufträge ist keine Eingabe irgend welcher Information notwendig. Man schaltet das Gerät ein, es spuckt eine TAN aus und fertig. Wie funktioniert das? Abspielen einer bekannten Sequenz? Generierung aus Uhrzeit?

(2) Die Generierung von TANs sollte genauer beschrieben werden, sofern bekannt. Z.B. kann keine sekundengenaue Uhrzeit verwendet werden, weil die Uhren der Bank und des TAN-Generators mit der Zeit auseinander laufen. Außerdem vergeht eine Zeit zwischen der Anfrage, der Eingabe in den Browser durch den Benutzer und das Absenden durch den Benutzer. Dennoch erstellt z.B. der CortalConsors-Generator alle ca. 20 Sekunden eine neue TAN. Das lässt vermuten, dass für jede Transaktion mehrere generierte TANs gültig sind und die Frage ist: Wie viele TANs aus dem gesamten TAN-Raum sind zu einer Zeit gültig? Kann aus dem Wissen einer gültigen TAN ihre Schwester-TAN errechnet werden? (Daraus ließe sich sofort eine weitere Überweisung nachschieben). Ferner ist es normal möglich, dass der Benutzer einfach mal einige TAN erstellt, ohne sie auch zu benutzen. (nicht signierter Beitrag von 95.89.8.194 (Diskussion) 19:23, 16. Apr. 2011 (CEST))

Tan-Generator

Dass eine Bank "Security-Tokens" verwendet hab ich noch nie gesehen - dann wird meistens gleich HBCI genommen. Der dargestellte Generator ist ein TAN-Generator des Sm@rtTAN Verfahrens. Und das hat nix mit "synchron", "Uhrzeit", oder halbwegs sicher zu tun... Da werden einfach in einer bestimmten Reihenfolge TANs ausgespuckt (in Abhängigkeit von auf dem Chip der EC-Karte verschlüsselt gespeicherter Informationen). Die kann man sich aufschreiben und sind auch in einem Jahr auch noch gültig. Man muss sie nur in der Richtigen Reihenfolge verwenden. Wie das technisch genau funktioniert würde mich aber mal interessieren. Mein Bankberater kann dazu leider nix sagen (hab ich auch nich erwartet) und natürlich ist das alles 100%ig sicher...

Hallo!

So leicht isses auch nicht, denn synchron ist schon korrekt. Es wir "abgeglichen" bei welcher TAN man sich befindet, sind zuviele Übersprungen, muss neu synchronisiert werden. Alte TANs damit also ungültig.

grüße Little 195.200.34.50 13:00, 14. Feb. 2007 (CET)

Berechnung der TAN-Sicherheit

Vielleicht will das nochmal jemand prüfen, aber ich würde sagen, statt "1/(10^4-1)" müsste es heißen "100/(10^6-1)" (entsprechend bei den anderen Termen). Macht aber im Ergebnis praktisch nix aus.

Stimmt! Läßt sich dann aber nicht mehr so elegant vereinfachen. Außerdem sollte dann auch noch darauf hingewiesen werden, dass die Formel nur für einen "frischen" TAN-Brief gilt und ansonsten die 100 noch durch die Anzahl der tatsächlich vorbleibenden TAN zu ersetzen ist. Dies ist meiner Meinung nach hier aber nicht so wichtig im Hinblick auf den Erkenntnisgewinn, sodass ich lieber die Formel als "ungefähr" relativieren werde. Wer mehr präzision für wichtig hält, möge dies ändern. --Palladin 14:10, 12. Jan 2007

Ich habe das zu 100/10^6 geändert, die andere Formel ist schlichtweg falsch. Und wieso sich das dann nicht mehr vereinfachen lassen soll, ist mir nicht ganz klar. Ob ich direkt zu 3/10^4 komme oder über den Zwischenschritt 300/10^6 macht keinen Unterschied. Letzteres könnte man in der Formel noch ergänzen, sehe aber letztendlich keinen Mehrwert... im Endeffekt hat die ganze Vereinfachung keinen, den Leser interessiert nur der Endwert und ob der über eine Vereinfachung zu Stande kommt oder konkret berechnet wird ist egal, am Ergebnis ca. 0,03% ändert das nichts. --Jogy _{sprich mit mir} 11:33, 8. Mär. 2010 (CET)

Kann es sein, dass die Klammern in der Formel falsch gesetzt sind? Ich bin kein Mathematiker und kann das nicht spontan beweisen. Meine Überlegung: Wir haben eine Summierung aus drei Versuchen. Somit erwarte ich eine klare Summenbildung, die durch die Klammernsetzung in dieser Formel verwischt werden. Die zweite "Klmmer-Auf" und die letzte "Klammer-zu" sind meiner Überlegung nach zu eliminieren. -- Michael 01.09.2008

Warum sollten denn die Klammern eliminiert werden? Die Summenbildung ist eigentlich nicht so "klar" wie man dies auf den ersten Blick erwarten möchte. Die Wahrscheinlichkeit für den Erfolg im zweiten Versuch muss nämlich nur für den Fall eingerechnet werden, dass der erste Versuch mißlungen ist. Der dritte Versuch kommt analog erst dann ins Spiel, wenn der erste und der zweite fehlgeschlagen sind. Die Verschachtelung der Summanden ist also durchaus plausibel. Eine andere Frage ist, ob man bestimmte Klammern auflösen möchte, um eine vereinfachte Darstellung der Formel zu erreichen. Ich glaube aber, dass dies die Formel unübersichtlicher machen wird. --Palladin 08:16, 14. Sep 2008

Der Vollständigkeit halber und/oder um Vergleiche anstellen zu können, sollte jemand die Wahrscheinlichkeit fürs Erraten einer mTAN mit sechs Ziffern und einer mit sechs Buchstaben/Ziffern ergänzen. --77.21.193.67 23:39, 30. Mai 2010 (CEST)

Zweifelhafter Vorteil des iTAN-Verfahrens

Was im Artikel als Vorteil des iTAN-Verfahrens aufgeführt wird, ist doch in Wahrheit ein Sicherheitsrisiko. Ersten sollte der Kunde keine Kopien der TAN-Liste erstellen. Aber vor allem kann ein Betrüger, der die komplette TAN-Liste und die PIN kopieren kann, damit maximalen Schaden anrichten. Es braucht ihn beim iTAN-Verfahren nicht zu stören, dass einige TAN bereits verbraucht sind und er nicht weiß welche. Er wird ja von der Bank niemals aufgefordert eine verbrauchte TAN einzugeben. --84.59.35.64 10:25, 13. Feb. 2008 (CET)

mTAN und iTAN: mTAN nicht gebührenfrei zu haben

Leider wälzen die Banken bei der Verwendung des sicheren mTAN-Verfahrens die Kosten der dabei verschickten SMS auf den Kunden ab, ohne einzelne Verbindungsnachweise zu führen. Der Redlichkeit halber sollte auch das häßliche Wort "Gebühren" im Rahmen des mTAN-Verfahrens in den Artikel aufgenommen werden.

Welches sind denn DIE Banken? Es gibt solche und solche. Die einen verlangen Gebühren für die mTan, andere -- wie z.B. die Postbank -- nicht. Falls das mit rein kommt, sollte das schon spezifiziert werden. 178.24.252.101 15:35, 16. Mai 2011 (CEST)

Auch chipTAN ist nicht (ganz) kostenlos

Auch bei chipTAN kommen (einmalige) Kosten auf den Kunden zu: Im Artikel steht "Kunden erhalten" einen TAN-Generator. Jedenfalls bei der Postbank muss man sich einen TAN-Generator selbst beschaffen. Nach meiner Recherche kosten die so ca. 15€. (nicht signierter Beitrag von LarsB (Diskussion | Beiträge) 17:35, 23. Dez. 2010 (CET))

Ich hab's mal angepasst. --AchimP 18:47, 23. Dez. 2010 (CET)

Flickering

Meine Sparkasse plant das Flickeringverfahren einzuführen. Kennt jemand hierzu nähere Informationen? --Manerr 20:14, 5. Mai 2009 (CEST) Nö!

iTAN

„Immer mehr Banken sehen die iTAN-Liste nur noch als Mindestschutz und empfehlen Ihren Kunden sicherere Verfahren (siehe unten).“

Wieso bieten diese Banken denn dann überhaupt noch iTAN an? --Seth Cohen 19:00, 2. Dez. 2009 (CET)

Weil ein (i)TAN-Brief ungeschlagen günstig ist und so unsicher wie alle tun, ist er in der Praxis auch wieder nicht. Wenn man die Betrugsfälle in Beziehung zu den über iTAN abgewickelten Transaktionen setzt (so argumentiert man ja auch gerne bei der Kreditkarte) so sieht das Verfahren gar nicht so schlecht aus. Im übrigen muss sich die Sicherheit vieler Alternativen auch erst in der Praxis beweisen. Viele Verfahren werden erst gar nicht angegriffen, weil die Marktdurchdringung nicht vorhanden ist (der Firefox galt ja auch mal als sicherer als der IE, bis immer mehr Leute ihn nutzten).

Letztlich ist Sicherheit immer ein Abwägung zwischen Kosten und Risiko. --Palladin 15:29, 6. Dez 2009

Dritte Angriffsmöglichkeit bei chipTAN comfort / smartTAN optic gelöscht

Die Anzeige der Auftragsdaten im Display des TAN-Generators ist die wesentliche Sicherheit bei diesem Verfahren. Wenn der Nutzer die angezeigten Daten nicht prüft, ist natürlich ein Mißbrauch möglich. Dies kann jedoch nicht als Angriffsmöglichkeit gelten. (nicht signierter Beitrag von 195.140.44.146 (Diskussion) 11:34, 21. Jun. 2010 (CEST))

Bitte benutze nächstes Mal die Zusammenfassungszeile und weise dort auf die Diskussionsseite hin. Ich habe deinen Beitrag hier nur per Zufall gesehen.

Wenn ein System auf der aufwendigen Kontrolle des Benutzers beruht, der ja bekanntlich faul ist, dann sollte das bei diesem Endbenutzersystem auch erwähnt werden, dass es zu einem Layer 8-Problem kommen kann. Viele Grüße --Saibo (Δ) 03:27, 30. Jun. 2010 (CEST)

Die dritte Angriffsmöglichkeit ist unlogisch. Wenn ein Angreifer darauf hofft, dass der Nutzer die Displayanzeige nicht beachtet, braucht er nicht in eine Sammelüberweisung umwandeln. Dann kann er ohne Probleme auch direkt eine betrügerische Einzelüberweisung durchführen.

Das Prüfen des Betrags und der Kontonummer im Display des TAN-Generators ist keine aufwendige Kontrolle. Wer das nicht prüft, der schaut auch bei den anderen TAN-Verfahren nicht genau hin, was auf dem Bildschirm steht, was in der SMS steht usw. Wenn das bei chipTAN comfort / smartTAN optic als Angriffsmethode zählt, muss dies bei anderen TAN-Verfahren auch noch aufgenommen werden. (nicht signierter Beitrag von 78.42.77.243 (Diskussion) 17:04, 13. Jul 2010 (CEST))

Hallo und danke für deinen Kommentar. (Es geht hierum.) Ziel: "Dieses Verfahren schützt vor Phishing- bzw. Man-in-the-Middle-Angriffen, sofern die im Display angezeigten Daten vor der Bestätigung auf ihre Richtigkeit geprüft werden." Beim klassischen TAN-Verfahren wird ja auch nicht behauptet, dass es vor Phishing oder MitM schützt, oder? Wären die Leute beim klassischen TAN-Verfahren nicht so nachlässig gäbe es auch dort keine Probleme und chipTAN könnte nicht als tolle Neuerung angepriesen werden. Viele Grüße --Saibo (Δ) 23:37, 13. Jul. 2010 (CEST)

Bei der Nachlässigkeit muss ich dir widersprechen. Auch ein sehr aufmerksamer Nutzer kann bei der klassischen TAN bzw. iTAN nur der Bildschirmanzeige vertrauen. Und genau diese Bildschirmanzeige kann ein Trojaner verändern. Ich meine dabei nicht die Abfrage von 10 oder 20 TANs sondern aktuelle Echtzeitangriffe. Warum sollte ein iTAN-Nutzer böses vermuten, wenn nach wie vor "seine" Überweisung am Bildschirm angezeigt wird und wie gewohnt eine TAN dafür eingegeben werden soll? Dass die angeforderte TAN dann für eine Betrugsüberweisung genutzt wird, ist für ihn nicht erkennbar. Selbst der Kontostand und die Umsatzanzeige wird bei aktuellen Trojanern im Anschluss verändert, so dass die Betrugsüberweisung nicht auffällt. (nicht signierter Beitrag von 195.140.44.146 (Diskussion) 12:22, 14. Jul 2010 (CEST))

Deine Aussage zur Bildschirmanzeige ist richtig. Wenn man davon ausgeht, dass das System des Benutzers nicht vertrauenswürdig ist, der User aber die angezeigten Überweisungsdaten überprüft, dann ist (i)TAN natürlich anfällig für Man-in-the-Middle-Angriffe und chipTAN nicht. Der Man-in-the-Middle-Schutz hängt aber von der Sorgfalt beim Kontrollieren ab - was ich beim Durchschnittsnutzer sehr infrage stellen würde. Insbesondere bei Personen mit Trojanern auf dem Computer. Aber nun gut, dann kommt es eben raus. Aufgrund des, wohl von dir auch nicht bestrittenen, Layer 8-Problems, sollte aber das Verfahren nicht in den Himmel gelobt werden. Viele Grüße --Saibo (Δ) 02:52, 15. Jul. 2010 (CEST)

überschaubare Gefahr

"Da für Transaktionen auch die PIN notwendig ist, stellt dies eine überschaubare Gefahr dar." Sicherheitskritische Einstufungen müssten durch Expertenmeinungen belegt werden. In diesem Fall halte ich etwa den Umstand für relevant, dass die PIN kompromittiert sein kann, ohne dass der Kontoinhaber dies ahnt. --217.232.161.103 12:26, 25. Okt. 2010 (CEST)

Zudem besteht in diesem Fall die Gefahr, daß der TAN-Generator nicht einfach entwendet wird, sodern durch ein baugleiches Gehäuse ersetzt wird, daß eine Funkverbindung zu über einige 10m zu einem in der Nähe deponierten größeren Gerät übernimmt, das:

  - Den originalen TAN-Generator enthält, dessen Tasten elektromechanisch betätigt werden
  - Eine weitere Funkverbindung zum Bösewicht (z.B. altes Handy) aufbaut

Sobald der Besitzer nach dem Austausch die erste Transaktion durchführt, scheint alles in Ordnung zu sein, da die in den ausgetauschten Tan-Generator eingegebenen Daten (PIN, Kontonummer, etc) an das Originalgerät weitergegeben werden.

Anschließend kann der Bösewicht von irgendwo aus genüßlich das Konto leerräumen, da er über die Pin und den ferngesteuerten Original-Keygenerator verfügt.

Solch ein Gerät ist für einen halbwegs talentierten Hacker sicherlich mit etwa einem Mannjahr Aufwand zu entwickeln und für wenige hundert Euro in kleinen Stückzahlen zu fertigen - für eine größere Bande also kein Hindernis.

Daher verstehe ich nicht, warum man den wegen der Bedienbarkeit zwangsläufig klobigen Keygenerator nicht dadurch sichert, daß man etwa eine vorhandene EC-Karte, die man immer in der Tasche hat, einstecken muß, die gegenüber einem solchen Szenario durch harte Echtzeitanforderungen beim Datentaustausch zu sichern wäre. --92.228.204.100 23:40, 9. Jan. 2011 (CET)

Die EC-Karte muß beim Chip-Tan Verfahren eingesteckt werden! (siehe Link/Anleitung bei Kobil ..)--89.0.7.158 14:10, 11. Jan. 2011 (CET)

CHIP-TAN comfort

"Da für Transaktionen auch die PIN notwendig ist, stellt dies eine überschaubare Gefahr dar." (Text im zweiten Abschnitt) Für den eigentlichen Vorgang z.B. Überweisungsauftrag ist die PIN nicht erforderlich. Es wird zwar die EC-Karte benötigt (s.o.) aber ohne PIN-Eingabe. Eventuell könnte gemeint sein, daß man zuvor bei der Online-Anmeldung die PIN benötigt. Kann man den Text zur Klarstellung ändern?--89.0.7.158 14:10, 11. Jan. 2011 (CET)

TAN = Transaktion Authentifizierungsnummer

TAN steht nicht (nur) für Transaktionsnummer, sondern vollständig für Transaktion Authentifizierungsnummer.

Im englischen sagt man auch nicht transactionsnumber sondern es heißt Transaction authentication number (nicht signierter Beitrag von 91.64.32.242 (Diskussion) 20:50, 7. Mai 2011 (CEST))

Hersteller/Entwickler des ChipTAN Verfahrens?

Wer hat das System eigentlich entwickelt? An wen müsste man sich wenden, wenn man so ein System auch verwenden möchte? Elvis untot 12:50, 25. Aug. 2011 (CEST)

Ganz andere Sicherheitslücke von chipTan!?

Seit dem ich auch auf dieses neue "bessere" Verfahren umgestellt habe/"wurde" und ich die praktische Realisation kenne, stellt sich mir die Frage nach einem ganz anderen, geradezu banalen Sicherheitsrisiko beim chipTan, das anscheinend sonst NIRGENDS diskutiert wird: (Die meisten Sicherheitsmaßnahmen werden nicht durch aufwendig mathematisches Rekonstruieren des "Algorithmus" umgangen, sondern durch Schwächen im Protokoll, und das scheint mir bei chipTan dagegen schwach!)

0) Ich dachte, wenn man den Tan-Generator bekommt, personalisiert man den durch die Eingabe einer eigenen Pin nur an diesem. Da war/ist aber nix.

So basiert die Sicherheit von chipTan nur (noch) auf:

1) Kenntnis des Bank-Pins:

- Es ist seit Jahren bekannt, dass es genügend Trojaner etc. gibt, die diesen abfangen können

2) Besitz der zugehörigen EC-Karte

- Diebstahl einer EC-Karte in Zusammenhang mit EC-Pin Auspionierung ist "gang und gäbe"

Also, wo ist der *faktische* Vorteil?

iTan hat dagegen immerhin noch den Vorteil, dass ich diese Liste normalerweise nicht den ganzen Tag mit mir rum trage wie meine EC-Karte.

Das Sicherste scheint mir zur Zeit noch zu sein, sich für das ach so sichere chipTan eine eigene getrennte HBCI-Karte zu besorgen (ist bei mir der Fall, da ich an einer Bank kein Girokonto habe) und diese getrennt aufzubewahren, nicht mitzunehmen!

XW (nicht signierter Beitrag von 79.202.230.254 (Diskussion) 21:12, 25. Aug. 2011 (CEST))

Das steht zwar nicht im Artikel (und kann auf die schnelle auch nicht von mir belegt werden), aber als zusätzliches Sicherheitsmerkmal gibt's den ATC, einen Zähler für bisher generierte TANs. Der wird beim registrieren an die Bank übermittelt und darf nicht beliebig abweichen. Ganz so einfach ist's also nicht mit "Karte finden -> TANs generieren", weil man insgesamt die Karte, den Generator (oder sehr genaues Wissen über diesen) und die Online-Banking PIN[sic!] besitzen muss. Wenn der Nutzer alle drei Sachen, die ja normalerweise getrennt aufbewahrt werden, weitergibt hat er's nicht besser verdient :) 124.170.105.71 04:26, 17. Nov. 2011 (CET)

Keine PIN notwendig in machen Verfahren

Es taucht im Artikel mehrmals der Hinweis auf, "Da für Transaktionen auch die PIN notwendig ist, ...". Das ist so nicht korrekt. Ob die PIN notwendig für die Transaktion ist oder nicht, hängt vom Verfahren und von der Implementierung der Bank/des Herstellers ab. -- Paradrop 20:24, 30. Aug. 2011 (CEST)

theoretische Sicherheitslücke bei chipTAN

Laut Sparkassen-Video wird die BLZ nicht angezeigt! Wenn jemand jetzt z.B. ein Onlinekauf bei einem Renommierten Onlinegeschäft machen will, wo er überweisen muss, z.B. ZooPlus, etc, brauch der Angreifer nur eine identische Kontonummer zu haben, wo die BLZ anders ist. Somit kann er durch Man-In-The-Middle die Überweisung umleiten.

https://www.ostsaechsische-sparkasse-dresden.de/privatkunden/banking/chiptan/info-tour/index.php?n=%2Fprivatkunden%2Fbanking%2Fchiptan%2Finfo-tour%2F&IFLBSERVERID=IF@@041@@IF

-- BennySep 19:22, 17. Sep. 2011 (CEST)

Abschnitt chipTAN manuell/sm@rtTAN-Plus

Hallo, die folgende Satzkombination in o.g. Abschnitt scheint mir weitgehend unverständlich formuliert zu sein:

"Aus den am TAN-Generator eingegebenen Daten errechnet der TAN-Generator eine auftragsbezogene TAN, die im Online-Banking erneut manuell mit der Tastatur des Online-Platzes eingegeben wird."

Bis hierher noch einigermaßen verständlich.

"Dieses Verfahren schützt vor Phishing- bzw. Man-in-the-middle-Angriffen, nachdem die Empfängerkontonummer und der Betrag genauso, wie am TAN-Generator erneut eingegeben sind."

Scheint unlogisch. Warum sollte dieses Verfahren erst schützen, nachdem etwas eingegeben wurde?

"Die Relevanz solcher Botschaften ist zeitlich beschränkt, da die Anbieter stets versuchen werden, die Lücken zu schließen."

Hier fehlt der Bezug, welche Botschaften, welchen zeitlichen Beschränkungen, welche Anbieter und welche Lücken gemeint sind.-- RöntgenTechniker 20:30, 16. Jan. 2012 (CET)

sms tan vs datenschutz?

Wenn ich das richtig sehe, wird die sms unverschluesselt verschickt, das heisst, beim mobilfunkprovider kann deine ganze ueberweisungshistorie abgehoert werden. (nicht signierter Beitrag von 188.29.203.162 (Diskussion) 21:44, 23. Jan. 2012 (CET))

eTAN

Die BW-Bank hat damit aber kein neues Verfahren eingeführt. Dieses Verfahren wird bereits im Bereich des RZ GAD genutzt und heisst dort Sm@rt-Tan-Plus. Insofern würde ich diesen Eintrag relativieren. grüße Little 195.200.34.50 13:02, 14. Feb. 2007 (CET)

Sicherheit

Mal eine dumme Frage: gibt es nun eigentlich konkrete Sicherheitsbedenken beim klassischen PIN/TAN-Verfahren solange der Kunde nicht selbst seine PIN/TAN Dritten preisgibt? Also weder PIN noch TAN auf der Festplatte speichert noch die Bank anders, als durch eintippen in die Adresszeile oder Lesezeichen eingibt? Ist da irgendein erfolgreicher Angriff bekannt?

Ralph 22:16, 14. Okt 2008

Im Artikel steht "Inwieweit sich dieser neue Ansatz in der Praxis als sicher erweist, ist unklar." Ich denke, das gilt einfach für alle Verfahren und muss hier nicht gesondert hervorgehoben werden. Man könnte höchstens im Abschnitt "Sicherheit" etwas zu eTAN sagen. Die BW-Bank sagt übrigens, dass sie seit 2008 wg. des TAN-Generators keine Phishing-Fälle mehr hatte (http://www.bw-bank.de/imperia/md/content/bwbankde/presse/2009/BW-Bank_TAN-Generator_ausgezeichnet_0309-6.pdf) -- 93.198.152.237 10:22, 10. Mai 2009 (CEST)

Belege fehlen / Falscher Begriff im Abschnitt "iTANplus: CAPTCHA"

Die in diesem Absatz zitierte Quelle belegt nicht den Begriff "CAPTCHA" als Bezeichnung für die im Online-Banking üblichen Kontrollbilder. Die Verwendung des Begriffes erscheint mir äußerst fragwürdig. Kurzes googlen zeigt, das alle relevanten Ergebnisse (zumindest auf der ersten Seite) scheinbar aus diesem Artikel abgeschrieben wurden, außer diesem Artikel.

Ein CAPTCHA hat den Zweck, zu unterscheiden, ob eine Aktion durch einen Menschen oder automatisiert durchgeführt wird, und letzteres zu verhindern.

Die Sicherheitsbilder im Onlinebanking haben den Zweck, die Identität des Onlinebakingservices gegenüber dem Nutzer zu verifizieren, indem nur dem Institut zugängliche Kundeninformationen gezeigt werden.

Der Unterschied ist so grundlegend, dass ich mir nicht vorstellen kann, dass für letzteres der Begriff CAPTCHA verwendet wird (und wenn doch, so ist das eine krasse Fehlbezeichnung).

Ob es einen treffenden deutschen Fachbegriff gibt, weiß ich nicht. Im Englischen wird von "security image", "SiteKey image" und "site-authentication image" gesprochen 123. -- 178.201.100.215 13:22, 2. Feb. 2012 (CET)

Captcha triffts tatsächlich überhaupt nicht, hab (vorerst) mal Kontrollbild eingebaut, so wie es der IT-Dienstleister Fiducia selbst in der Vorstellung nennt. SDI Fragen? 13:50, 2. Feb. 2012 (CET)

chipTan wirklich sicher?

Laut einer Heise Nachricht, ist chipTan compfort nicht vor Man-in-the-middle geschützt. http://www.heise.de/security/meldung/chipTAN-Verfahren-der-Sparkassen-ausgetrickst-866115.html (nicht signierter Beitrag von BennySep (Diskussion | Beiträge) 12:31, 26. Mär. 2010 (CET))

na kommt drauf an, wenn man nicht nachprüft/sich ans Protokoll hält dann nicht (nicht signierter Beitrag von 87.146.150.141 (Diskussion) 16:48, 24. Apr. 2012 (CEST))

smartT@N plus

Ich habe bei smartT@N plus bei der Volksbank üblicherweise nur einen Teil der Kontonummer und niemals irgendeinen Betrag eingeben müssen. Das Verfahren habe ich bis zum bitteren Ende im September genutzt. Der Generator hat nie nach einem Betrag gefragt und von der Bankkarte scheint das, wonach es fragt, auch nicht abhängig zu sein, da bei meinem Wüstenrot-Konto kein Data-Feld vorgegeben aber vom Gerät danach gefragt wird. --Яedeemer 01:37, 6. Mai 2012 (CEST)

Sm@rtTAN - Nur für Nachtaktive

Im Abschnitt über Sm@rtTAN sollte meiner Meinung nach erwähnt werden, dass die optische Erkennung tagsüber regelmäßig scheitert, wenn der Raum taghell erleuchtet ist oder die Schaltgeschwindigkeit des Bildschirm nicht zur Erkennungsrate des Sm@rtTAN-Geräts passt. Ich muss meine TANs immer manuell eingeben, weil die optische Erkennung in 80 % aller Fälle, an denen ich Sm@rtTAN bisher an verschiedenen Bildschirmen verwendet hatte, scheiterte. Sehr ärgerlich und sehr kundenunfreundlich.

Abgesehen davon ist die Anzahl der für einen Dieb verfügbaren TANs durch Sm@rtTAN unendlich, während sie bei TAN oder iTAN-Bögen auf die Zahl der noch restlich verfügbaren TANs beschränkt ist und außerdem dort voraussetzt, dass der Dieb erst einmal Zugriff auf den TAN-Bogen und die EC-Karte erlangen muss. Bei Sm@rtTAN benötigt der Dieb nur noch die EC-Karte, sonst nichts. Nicht wirklich ein Sicherheitsplus.

Sm@rtTAN = unsicher und unhandlich.

--My2Cents (Diskussion) 02:30, 20. Nov. 2012 (CET)

Die optische Erkennung geht selbstverfreilich auch tagsüber, sondern hätten einige Hunderttausend Nutzer (Millionen?) mehr Probleme. Und zum Diebstahl: Das ist Polemik und unterschlägt die nötigen Zugriffsdaten. Und nach dieser Logik unterscheiden sich auch die anderen Systeme nicht in der Sicherheit: iTAN-Liste oder Handy sind auch schnell weg. SDI Fragen? 10:15, 20. Nov. 2012 (CET)

Haben Sie belastbare Zahlen zur problemlosen Anwendung? Oder werfen Sie einfach mal lax Ihre Behauptung in den Raum?

Ihre Unterstellung von Polemik zeigt, dass Sie sich offensichtlich gar nicht erst die Mühe gemacht haben, sich mit meiner Argumentation auseinanderzusetzen. Polemik hätte keine Argumente verwendet - ich jedoch schon.

Bei TAN müssen Sie sich genauso erst Zugang zu den Zugangsdaten verschaffen. Also wo liegt für Sie der Unterschied?

Zudem zeigt Ihr letzter Satz, dass der Kern meiner Aussage offensichtlich nicht zu Ihnen durchgedrungen ist. Schnell weg ist alles. Was soll diese sinnlose Aussage? Es geht hier nicht um "schnell weg", sondern um das "was kann der Dieb damit anfangen". Darin steckt schließlich das zusätzliche Gefahrenpotential von Sm@rtTAN und mTAN.

--My2Cents (Diskussion) 18:03, 6. Dez. 2012 (CET)

Moin, einer der vier großen Hersteller der TAN-Generatoren verkauft derzeit in Deutschland mehr als 4 Mio. Geräte, das scheint mir wohl ein Anhaltspunkt dafür zu sein, dass SmartTAN oder chipTAN kein Nischenprodukt ist. Zum konkreten Supportaufwand kann ich ganz allgemein nur soviel sagen: In unserem Unternehmen arbeiten knapp 200.000 Kunden mit SmartTAN/chipTAN, davon 95% mit dem optischen Verfahren. Die Supportquoten sind seit der Umstellung von iTAN etwas erhöht. Das liegt aber an der Implementierung und nicht an nicht vorhandenen Erkennungsraten am Tag. Es ist für den Supporter bei dem Verfahren einfach komplexer geworden, was zu prüfen ist (zB Java-Versionen, Adblocker, wo hält der Kunde das Teil hin usw.). Das war mit den Listen einfacher.

Die gebrachten Argumente sind eben keine wirklichen: Der neue Sicherheitsvorteil im Vergleich zu den alten Verfahren ist die Koppelung der TAN-Gültigkeit an einen konkreten Vorgang und das ist unabhängig vom Zugriff auf die nötigen Medien. Also muss der pöhse Bube die Zugangsdaten zum OnlineBanking sowie ec-Karte an sich bringen. Bei iTAN war/ist es Liste und Zugangsdaten. Die ec-Karte kann (wie eine TAN-Liste auch) gesperrt werden, dann ist auch kein Smart/chipTAN mehr möglich. Somit soll das Verfahren vor allem gg. Man in the Middle-Angriffe schützen, das tut es momentan wohl auch wirksam. Aber das ganze ist hier OT. Gruß, SDI Fragen? 09:50, 7. Dez. 2012 (CET)

Tach auch,

> das scheint mir wohl ein Anhaltspunkt dafür zu sein, dass SmartTAN oder chipTAN kein Nischenprodukt ist.

Stimmt. Aber das hat auch niemand behauptet. Ich behaupte, dass es ein schlecht funktionierendes Produkt ist. ...und kann das anhand von Tests jederzeit belegen. Eigentlich kann das im Sommer tagsüber jeder selbst sogar nachtesten.

Da die Anwender keine Wahl haben, ob sie es einsetzen wollen oder nicht, ist die Angabe der Nutzerzahl hier nicht relevant. Oder können diese Benutzer Alternativen nutzen, um ihr Online-Banking im Internet durchzuführen?

Sie schreiben "davon 95% mit dem optischen Verfahren.". Können Sie die Anwendungskennzahlen nach Tageszeit aufschlüsseln? Hierin liegt das Problem des Verfahrens.

Der neue Sicherheitsvorteil im Vergleich zu den alten Verfahren ist die Koppelung der TAN-Gültigkeit an einen konkreten Vorgang

Das ist im Vergleich zum iTAN kein Vorteil, denn dort war genau dies auch der Fall. Auch dort wurde bereits durch den konkreten Fall der Index angegeben, anhand dessen die passende iTAN-Nummer eingegeben werden musste. Es gab auch hier keinerlei Entscheidungsfreiheit des Anwenders.

Fragen Sie sich selbst einmal, was für einen - wie Sie schreiben - "pöhsen Buben" schwieriger ist: Sich Zugang zu einer iTAN-Liste zu verschaffen oder zu einer EC-Karte? - Womit bezahlen Sie in der Regel an der Kasse, wenn Sie kein Bargeld haben? Mit einer iTAN-Liste? Wahrscheinlich nicht... Da die Erlangung der Zugangsdaten bei beiden Verfahren identisch ist, ist somit nach Adam Riese das Sm@artTAN-Verfahren unsicherer. (nicht signierter Beitrag von My2Cents (Diskussion | Beiträge) 00:53, 22. Dez. 2012 (CET))

Das kannst du anhand deiner eigenen Tests evtl. belegen, die Statistiken zu grösseren Nutzerzahlen sagen aber definitiv etwas anderes. Was ist wohl aussagekräftiger? Zur Koppelung an den Vorgang hast du das Berechnungsmodell der TAN in den neueren Verfahren nicht verstanden. Es reicht eben nicht eine TAN zu wissen (also die Liste der iTANs zu haben). Bei iTAN war der Vorgang egal, es wird einfach nur eine TAN mit einer Nummer angefordert. Zur Tageszeit: Hauptnutzungszeit ist im Online Banking bei uns einmal die Mittagszeit 11-13 Uhr und dann die früheren Abendstunden. Also jeweils scheinbar in der Mittagspause und nach Feierabend der Nutzer. Und nochmal: Es sollte nicht die physische "Diebstahlsicherheit" der verwendeten Medien erhöht werden, sondern die Manipulierbarkeit bei vom Nutzer kaum bemerkbaren Man in the Middle-Angriffen. Und das ist erfolgt. Von meiner Seite ist jetzt aber EOD, die Artikel-Disk. dient zur Diskussion von Inhalten und nicht der Klärung von persönlichen Fragen. --SDI Fragen? 11:44, 23. Dez. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: SDI Fragen? 14:49, 30. Apr. 2013 (CEST)

Erfolgreicher Angriff

Sollte in diesem und/oder in einem verwandten Artikel auf http://www.e-recht24.de/news/it-sicherheit/7357-online-banking-kriminelle-erbeuten-mit-handy-trojaner-36-millionen-euro.html hingewiesen werden? --I-user (Diskussion) 01:54, 11. Dez. 2012 (CET)

Moin. Der Schädling ist ja nicht neu, nur die Presse hat ihn wiederentdeckt. Hier wird das Ding schon beschrieben: „Im September 2010 wurde berichtet, dass neue Varianten des Banking-Trojaners ZeuS jetzt auch das mTAN-Verfahren ins Visier nehmen.“ Könnte man evtl. etwas ausbauen und aktualisieren. Mach ich gleich mal. SDI Fragen? 09:17, 11. Dez. 2012 (CET)

photoTAN/QR-TAN - Betrachtung

Hallo Calypso10, erst mal Willkomen bei der Wikipedia und Dank Dir für die Ergänzungen und Korrekturen in Transaktionsnummer. Dass ich den von Dir eingefügten Teilsatz "solange die Sicherheit des Smartphones bzw. des photoTAN Lesegeräts gewährleistet ist." entfernt habe ist nicht als Angriff gedacht. Aus meiner Sicht ist die Aussage so nicht korrekt, denn auch wenn das Smartphone oder photoTAN Lesegerät infiziert wäre, müsste der gleiche Urheber auch den PC infiziert haben und quasi zeitgleich die falschen Daten abgleichen, was z.B. nur mit Internetzugang des des Lesegerätes funktioniert. Natürlich ist auch das photoTAN verfahren angreifbar, aber die Ausssage kann "geschützter gegen Angriffe von Trojanern oder Man-in-the-Browser-Attacken angesehen werden" stimmt aus meienr Sicht auch noch bei einer infizierung des Lesegerätes.--Unimog404 (Diskussion) 19:20, 24. Apr. 2014 (CEST)

Hallo, wie bereits in der Versionshistorie angemerkt, impliziert der Ausdruck "Angriffe von Trojanern oder Man-in-the-Browser-Attacken" im Abschnitt "Betrachtung" bereits automatisch eine Infizierung des PCs. Die Sicherheit des Verfahrens gegen etwa Man-in-the-Browser-Attacken hängt daher davon ab wie sicher das Signatur-(bzw. bei PhotoTAN Lese-)gerät ist, was, wie die Angriffe gegen mTAN zeigen, gerade beim Einsatz von Smartphones kritisch ist. Calypso10 (Diskussion) 23:02, 24. Apr. 2014 (CEST)

Es ist korrekt, dass Angriffe von "Trojanern oder Man-in-the-Browser-Attacken" die infizierung des PC impliziert. Die Urspüngliche Aussage im Artikel war, dass bei einer solchen Infizierung die Sicherheit höher ist als bei iTAN. Das ist aus meiner Sicht die korektere Formulierung. Da selbst bei einem zusätzlich kompomitierten PhotoTAN Lesegherät meines Erachtens die Sicherheit immernoch höher ist als bei iTAN da der gleiche Angreifer beide Geräte unter kontrolle haben muss und in der der Lage sein müsste die notwendigen Daten in Echtzeit zwischen ihnen auszutauschen.--Unimog404 (Diskussion) 11:21, 25. Apr. 2014 (CEST)

Von iTAN steht im Wikipedia-Artikel aber nichts. Die Aussage dort lautet "Beide Verfahren können als geschützter gegen Angriffe von Trojanern oder Man-in-the-Browser-Attacken angesehen werden".

Ich habe allerdings bereits beim editieren überlegt den Satz im Gegenzug zur Anmerkung zur Smartphone-Sicherheit in "Beide Verfahren können als geschützt gegen Angriffe von Trojanern oder Man-in-the-Browser-Attacken angesehen werden[, solange die Sicherheit des Smartphones bzw. des photoTAN Lesegeräts gewährleistet ist.]" zu ändern, also aus dem "geschützter" ein "geschützt" zu machen. Habe es dann aber so wie bisher stehen gelassen, da man streng genommen auch noch kombinierte Trojaner und Social Engineering Attacken, wie sie bereits beim Parallel-Verfahren "chipTAN" ausgeführt wurden, als möglichen Angriff ins Feld führen könnte, gegen den auch ein nicht-kompromittiertes Smartphone oder Lesegerät nicht hilft. Man könnte die Formulierung aber vielleicht auch in "geschützt" ändern, wenn man argumentiert, dass es sich bei Social Engineering nicht um einen rein technischen Angriff handelt.

Grüße, Calypso10 Calypso10 (Diskussion) 16:43, 25. Apr. 2014 (CEST)

Guter Vorschlag, aber eigentlich finde ich "geschützter" passender, "geschützt" klingt so absolut. Aber was hällst Du davon den Bezug zu iTAN mit reinzunehmen, denn so steht es in der Quelle. Mir ist auch schon aufgefallen, dass das im Artikel nicht eindeutig erkennbar ist.--Unimog404 (Diskussion) 18:59, 25. Apr. 2014 (CEST)

"Guter Vorschlag, aber eigentlich finde ich "geschützter" passender, "geschützt" klingt so absolut."

Aus genau diesem Grund habe ich, mit den Social Engineering Trojanern im Hinterkopf, die Formulierung so beibehalten.

"Aber was hällst Du davon den Bezug zu iTAN mit reinzunehmen, denn so steht es in der Quelle. Mir ist auch schon aufgefallen, dass das im Artikel nicht eindeutig erkennbar ist."

OK, die Aussage würde dann lauten "Beide Verfahren können als geschützter als iTAN gegen Angriffe von Trojanern oder Man-in-the-Browser-Attacken angesehen werden." oder "Beide Verfahren können im Vergleich zu iTAN als geschützter gegen Angriffe von Trojanern oder Man-in-the-Browser-Attacken angesehen werden." egal ob mit oder ohne den Zusatz ", solange die Sicherheit des Smartphones bzw. des photoTAN Lesegeräts gewährleistet ist.", denn sicherer als iTAN sind beide Verfahren durchaus, da bei einem Angriff 2 Geräte (PC + Smartphone) statt nur einem kompromittiert werden müssten.

Calypso10 (Diskussion) 03:22, 27. Apr. 2014 (CEST)

Das passt aus meiner Sicht, ich habe das mal in den Artikel übertragen und das war ursprüglich der Grund weshalb ich Deinen Zusatz nicht übernommen hatte.--Unimog404 (Diskussion) 09:32, 27. Apr. 2014 (CEST)

Ich habe noch eine erklärende Ergänzung hinzugefügt, warum das Verfahren "geschützter als iTAN" ist. Calypso10 (Diskussion) 01:49, 12. Mai 2014 (CEST)

mTAN "Unsicherheit" und Smartphone-Kamera

Im Artikelabschnitt zur mTAN-Sicherheit steht aktuell:

"Das ganze funktioniert natürlich auch, wenn der Angreifer Benutzernamen und Passwort des Online-Bankings auf einem anderen Wege in Erfahrung gebracht hat, z.B. durch einen Trojaner auf dem PC oder Aktivierung der Smartphonekamera bei deren Eingabe am PC."

Ich frage mich dabei, wie das mit der Smartphone-Kamera funktionieren soll: Hat ein Smartphone-Kamera-Trojaner auch gleichzeitig Zugriff auf mein Rückenmark um meinen Arm so zu steuern, dass er die Kamera auf den PC-Bildschirm hält? Oder werden schwenkbare Minidüsentriebwerke am Smartphone aktiviert, um es in Position zu heben? Ich bin verwirrt :-D --37.120.107.92 15:36, 13. Jun. 2014 (CEST)

chipTAN comfort/SmartTAN optic (Flickering) von KOBIL einstellen

Mein Gerät (KOBIL), frisch gekauft über die empfohlene Adresse der Bank, war wirklich sehr blind. Es machte keinen Spass, damit zu arbeiten. Jeder 4. Versuch gelang manchmal, wenn die Zeit nicht abgelaufen war. Nachdem ich irgendwann mal den richtigen Fachmann (Telefonnummer über die Bank) am Telefon hatte, erklärte er mir, wie da vorzugehen sei:

Es gibt eine Einstellmöglichkeit der Leseempfindlichkeit. Dazu muss man ins Einstellmenü des Gerätes gehen und den Wert auf die maximale Empfindlichkeit stellen. Die Softwareabteilung der Bank hilft da weiter. Ferner die Geschwindigkeit des Flickercodes am Bildschirm (Maus) auf 70% stellen, da hier das Gerät am besten liest. Die Größe des Flickercodes entsprechend einstellen, und - ganz wichtig! - den Bildschirm auf die größte oder fast größte Helligkeit stellen. Das Gerät im Winkel von 45 Grad auf den Flickercode positionieren (bei meinem Labtop die Tasten verwenden, um das herausragende Ende bez.w. die Karte auf die Tastaturzwischenräume zu legen). Ihr werdet staunen, was dieses Gerätchen jetzt für eine Lesebrille hat.

Das Gerät hat noch den Fehler, daß es nicht warten kann, bis man alles kontrolliert hat. Ist für Schnelleser gebaut. Ich behelfe mich da folgendermassen: Ich mache nur - TERMINÜBERWEISUNGEN -für den nächsten Tag und kann jetzt in aller Ruhe kontrollieren, ob sich ein Fehler eingeschlichen hat. Des weiteren verwende ich die Karte, die man in das Gerät reinschiebt, niemals für einen anderen Zweck. Aus Sicherheitsgründen. Wenn man sie zum Bezahlen in einen Schlitz reinsteckt, könnte sie ja ausgelesen werden. --Voss-seligenstadt (Diskussion) 18:39, 28. Dez. 2014 (CET)

Verbessertes iTAN-Verfahren soll vor Manipulationen durch Trojaner schützen

Das iTAN-Verfahren ist gegen einen Trojaner, der Auftragsdaten manipuliert, nicht gefeit. Abhilfe soll hier das iTANplus-Verfahren schaffen, da die Rückmeldung vom Bankrechner nicht nur in Textform sondern zusätzlich als Captcha erfolgt - vielleicht sollte ein Verweis auf den Heise-Artikel http://www.heise.de/newsticker/meldung/98025 aufgenommen werden.

Ein entsprechender Abschnitt wurde dem Artikel inzwischen (Stand November 2015) hinzugefügt. Calypso10 (Diskussion) 00:27, 28. Nov. 2015 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Calypso10 (Diskussion) 00:27, 28. Nov. 2015 (CET)

secTAN

Die Bawag bietet ab sofort einen sog. secTAN an. Was ist das?Fehlt im Artikel. --213.162.68.79 15:52, 30. Aug. 2016 (CEST)

Folgender Artikel beschäftigt sich damit: BAWAG P.S.K. führt Security App mit secTAN ein von Futurezone. --Abu-Dun Diskussion 16:01, 30. Aug. 2016 (CEST)

Sparda SecurApp

Informationen wurden entfernt https://de.wikipedia.org/w/index.php?title=Transaktionsnummer&diff=162334984&oldid=162334272 (nicht signierter Beitrag von 2003:86:2D5D:5200:F424:4AD4:B8C6:A67 (Diskussion) 11:39, 5. Februar 2017 (CET))

Ja, das ist wirklich wichtig und muss in den Artikel. --79.220.76.121 12:02, 5. Feb. 2017 (CET)

wie schon anderwo geschrieben: diese informationen hältst du für wichtig. bitte beachte hierbei aber WP:KTF. die deinige ist wie auch meine meinung in dieser sache völlig irrelevant. --JD {æ} 20:15, 5. Feb. 2017 (CET)

Auch wenn der Dauerstörer, u.a. bekannt als KK-Troll und hier unter wechselnder IP auftretend, diese Informationen für wichtig hält, so sind sie es enzyklopädisch frühestens dann, wenn sie entsprechend außerhalb der Wikipedia rezipiert wurden (vgl. WP:TF). In diesem Sinne: Bitte weiterziehen, danke. --GUMPi (Diskussion) 10:49, 6. Feb. 2017 (CET)

3M: Theoriefindung.--Zweifelfreund (Diskussion) 19:56, 6. Feb. 2017 (CET)

Aktualität

Diese Seite ist leider in vielen Punkten hoffnungslos veraltet. Oft stehen Zeitangaben, die 10 und mehr Jahre alt sind und sicher nicht mehr den aktuellen Stand widerspiegeln; andernorts stehen vage Hinweise wie "heutzutage", bei denen ohne Zeitangabe völlig unklar ist, ob das Frühjahr 2017 ist oder vielleicht auch 10 Jahre alt. Die Sicherheit der TAN-Verfahren ändert sich ständig. Wenn die Seite schon nicht regelmäßig aktualisiert werden kann, braucht es m.E. mindestens einen Hinweis, dass die Angaben veraltet sind, und besser noch wenigstens eine Zeitangabe, auf wann sich das jeweilige "heute" bezieht bzw. bezog. (nicht signierter Beitrag von DSS65 (Diskussion | Beiträge) 13:27, 27. Feb. 2017 (CET))

@DSS65: trau dich - und bitte signieren deine Beiträge und setze neue Diskussionsthemen immer unten drunter, was meinst du warum steht dies beides (!) ganz oben drüber? Ansonsten ist Pauschalkritik nicht so sinnvoll, dafür ist der Artikel schon zu umfangreich und es ist sicher nicht alles so veraltet (ist aber ein prinzipielles Problem mit hochvergänglichen "Informationen" wie "heute", "aktuell", "vor kurzem " etc. - sollte man so nie machen). Besser wäre es, wenn Du einzelne Probleme explizit erwähnst (oder selber verbesserst). -- WikiMax - 17:41, 27. Feb. 2017 (CET)

Mobile TAN (mTAN)

Zu den Abschnitten "Angriff auf das Mobiltelefon" und "Angriff auf das Mobilfunk-Netz" fehlt hier unbedingt noch "Angriff auf das Festnetztelefon" und "Angriff auf das Festnetztelefon-Netz". Oft wird heute in Zeiten des Smarthones in Vermutung auf höhere Sicherheit für die smsTAN die Festnetz-SMS benutzt. --Wiki1939 (Diskussion) 17:18, 21. Nov. 2017 (CET)

Leseprobleme bei chipTAN (Flickering)

Neben den im Artikel aufgeführten Problemen habe ich das (über Jahre) reproduzierbare Problem, dass der Flickercode in einem mit Leuchtstoffröhren beleuchteten Raum nicht erkannt wird (Büroumfeld!). Sobald die Leuchtstoffröhren ausgeschaltet und statt dessen etwa Leuchten mit Halogenlampen eingeschaltet werden, wird der Flickercode einwandfrei gelesen.

Auch eine schwache Batterie kann zu Leseproblemen führen. Nach Austausch der Batterien geht es dann wieder.

Beide Probleme werden in den typischen FAQs nicht aufgeführt, obwohl sie zumindest bei mir reproduzierbar sind.--ULupus (Diskussion) 23:30, 27. Nov. 2017 (CET)

Titel ändern zu "Transaktionsnummer (TAN)"

Der Titel der Seite sollte mMn die Abkürzung TAN beinhalten. Auf diese Anforderung wurde ich aufmerksam gemacht, da auf einer hierher verlinkenden Seite eben dieser Link nicht über die "TAN" suche gefunden werden konnte.

Auf der verlinkenden Seite ist interessanterweise eine weitere Seite eben zusätzlich mit ihrer Abkürzung auffindbar << Siehe auch Transaktionsnummer UAF (FIDO) Zwei-Faktor-Authentifizierung >> https://de.wikipedia.org/wiki/Einmalkennwort#Siehe_auch

Daher schlage ich vor, den Titel des Artikels Transaktionsnummer (https://de.wikipedia.org/wiki/Transaktionsnummer) in "Transaktionsnummer (TAN)" zu ändern. --Daddelbob 10:19, 30. Mai 2018‎

Wieso, wird unter TAN gefunden! Die Abkürzung TAN steht für mehrere Begriffe. --Wiki1939 (Diskussion) 13:59, 30. Mai 2018 (CEST)

TAN Generatoren mit Bluetooth

Es gibt mittlerweile ja auch die Möglichkeit TAN Generatoren mit Bluetooth zu verwenden. Die Daten werden vom Handy auf das Gerät drahtlos übertragen und nach Prüfung und OK drücken am TAN Generator wieder drahtlos zurück zum Handy. Das ist sehr komfortabel.

Geräte z.B.: Reiner SCT tanJack Bluetooth oder VASCO DP875 Bluetooth

Quellen: https://www.berliner-volksbank.de/banking/tangenerator.html https://genostore.de/BVB/online-banking/smatrt-tan-leser/

Interessanterweise wissen viele Bankmitarbeiter gar nichts davon. Obwohl es z.B. mit allen Volksbanken die die App auf dem Handy unterstützen funktioniert.

Vielleicht kann das jemand in den Artikel einpflegen? Das wäre nett. Ich hab das noch nie gemacht. --217.110.34.186 17:47, 19. Okt. 2018 (CEST)

iTAN in DE gesetzlich verboten?

Die DKB schaltet derzeit iTAN ab, mit der Begruendung gesetzlicher Vorgaben. Es waere sehr schoen, wenn diese gesetzlichen Vorgaben im Text erlaeutert und verlinkt waeren. --Meillo (Diskussion) 11:23, 30. Nov. 2018 (CET)

Habe es eingefügt. --Wiki1939 (Diskussion) 15:26, 30. Nov. 2018 (CET)

Sicherheit

Zitat: "Während beim klassischen TAN-Verfahren 50 TANs auf einem TAN-Bogen gültig sind (der TAN_Bogen enthält 100 TANs, von denen im statistischen Mittel die Hälfte bereits verbraucht sind. Es verbleiben im statistischen Mittel also 50 gültige TANs), ist beim iTAN-Verfahren jeweils nur die einzige TAN gültig, welche die Bank während der Transaktion abfragt."

Bei meinem Kreditinstitut wird die iTAN-Liste bereits durch eine neue ersetzt, wenn 75% der TANs verbraucht sind. Wenn dies bei den klassischen TAN-Verfahren ebenso sein sollte, ist die Wahrscheinlichkeit, eine gültige TAN-Nummer durch zufällige Auswahl zu treffen, im Mittel sogar etwas höher als 50%. (Wenn man die selbe Überlegung zu Grunde legt, sollten es dann 62,5% sein.) Ist natürlich gehopst wie gesprungen...

Allerdings werden die Benutzer von klassischen TANs bereits verbrauchte Nummern wahrscheinlich irgendwie kennzeichen, und machen es somit also für Fremde recht einfach, gültige Nummern zu finden.

Gruss Martin

Diese Diskussion müßte eigentlich noch weiter gehen. Es gibt viele Gründe dafür, an einer linearen Rest-TAN-Funktion zu zweifeln (z.B. hohe Anzahl von Neuanmeldungen oder Personen, die zwar einen TAN-Brief haben, aber keine (oder sehr selten) Transaktionen durchführen. Es ist eher anzunehmen, dass der Erwartungswert der Rest-TANs über eine hohe Kundenzahl betrachtet dichter an der maximal möglichen TAN-Anzahl pro Brief liegt. Das statistische (arithmetische) Mittel (unter Berücksichtigung der Nachbestellungsschwelle) wird sich höchstens bei einer Gruppe von sehr aktiven Nutzern einstellen. --Palladin 14:45, 28. Feb 2007

Archivierung dieses Abschnittes wurde gewünscht von: SDI Fragen? 11:05, 29. Okt. 2019 (CET)

Übersetzungsfehler?

Im englischen bedeutet TAN ja „Transaction Authentication Number“. Das deutsche Backronym „Transaktionsnummer“ ist vor dem Hintergrund doch sicherlich ein unwissend übernommener Übersetzungsfehler, oder? Das wäre ja so, als ob ich die PIN („Personal Identification Number“) als „persönliche Nummer“ statt „persönliche Identifikationsnummer“ rückübersetze. --Dexter3player (Diskussion) 19:36, 2. Mär. 2019 (CET)

Du scheinst recht zu haben. In anderen Sprachen ist das besser gelöst (bzw. hat sich womöglich auch einfach nur die korrekte Version durchgesetzt und hier nicht...?). --JD {æ} 19:45, 2. Mär. 2019 (CET)

Kleines Update. Ich hab mal Google etwas ausgereizt. Die älteste Webseite mit dieser fragwürdigen Übersetzung, die ich gefunden habe: Hinweise für den Umgang mit verschlüsselten EMails. 23. November 1998; abgerufen am 1. Oktober 2019.  Da diese Webseite EMail in ihrer ursprünglichen Schreibweise verwendet, nehm ich das mal als sichere Authentizität. --Dexter3player (Diskussion) 23:12, 1. Okt. 2019 (CEST)

kann man so oder so sehen = ergo persönliche Betrachtung, die nicht auf diese Diskuseite gehört. Für Schnellleser ist das OK, für Erbsenzähler nicht. Gruß Monk! Aber richtig einrücken, gleiche Nutzer immer gleich einrücken, sonst rollen die Erbsen falsch.--2A02:810D:4640:2238:F8BD:8525:E6AD:362C 11:17, 4. Nov. 2019 (CET)

Kein Verweis auf die genauen Standards vorhanden?!

Ich habe den gesamten Artikel nicht gelesen. Suche nach Standard, Norm, oder Spezifikation liefern jedoch keine überzeugenden Informationen. Ein solches Thema sollte einen Link auf die Standarddokumente haben. Hier sehe ich jedoch teilweise die Wiederholung des Informationsniveau der Banken. Ok, der Artikel ist schon besser. Aber wo sind die genauen Standards zu finden? Danke trotzdem für den Artikel. --2A00:1398:300:201:0:0:0:1028 20:05, 24. Apr. 2019 (CEST)

interessiert hier niemanden, genauso wie der ganze ungepflegte Artikel mit veralteten Angaben zu Banken und keinerlei Angaben zur Umstellung nach PSD2 - so ist das hier nicht mehr informativ, sondern irreführend und der WP unwürdig (nicht signierter Beitrag von 47.71.4.130 (Diskussion) 20:40, 8. Sep. 2019 (CEST))

Ich erlebe gerade unsinnige Missstände beim Aktivieren von Homebanking. Was dies oder das mit PSD2 zu tun haben soll, sehe ich (noch) nicht. Den Gesamtüberblick hier (auch historisch) finde ich informativ. – Fritz Jörn (Diskussion) 19:34, 12. Sep. 2019 (CEST)

Ich verstehe das Problem ehrlich gesagt gar nicht. Welcher Standard? Kann es sein, dass hier gerade eine Verwechselung mit FinTS erfolgt? --SDI Fragen? 11:12, 13. Sep. 2019 (CEST)

Lesedefizite. Schweiz gehört nicht zur EU, somit gar kein Standard - dennoch Persönliches, das nichts mit der Artikelverbesserung zu tun hat und schon gar nichts mit dieser Diskuseite . WP ist kein Forum, trollt Euch!--2A02:810D:4640:2238:F8BD:8525:E6AD:362C 11:25, 4. Nov. 2019 (CET)

Mit »Standard« ist vielleicht die genaue Spezifikation oder Anforderung ans Verfahren gemeint. Am nächsten dran kommt eine EU-Vorschrift, siehe Referenz in meinem Einschub »Vorteile«. Ärgerlich empfinde ich nur die kropfunnötige Erwähnung von »SEPA«. Schleichwerbung … – Fritz Jörn (Diskussion) 20:22, 21. Nov. 2019 (CET)

Deine Ergänzung "Vorteile" ist zu Recht revertiert worden. Wikipedia bildet keine Meinungen ab. Eine genaue Spezifikation o.ä. gibt es eben nicht. Es gibt gewisse Rahmenbedingungen aber selbst hier herrscht aufgrund der sehr allgemeinen Formulierungen Unklarheit, ob bei smsTAN/mTAN die eigentlich geforderte vollständige Verschlüsselung zwingend erforderlich ist oder eben nicht. Mehrheitlich wird das wohl aktuell verneint. Gruß, --SDI Fragen? 13:06, 22. Nov. 2019 (CET)

Nun denn, ob zu Recht oder nicht ist Auffassungsssache. Du hast revertiert, weil du das für Meinung hieltest. Bei Techniken findet man sogar ganze Absätze über Vor- und Nachteile [1], vielleicht wäre das auch hier angebracht. In diesem verkorksten (pardon, auch nicht nett) Artikel über Tans gehört neben der Latte von allerlei hypothetischen Gefahren auch mal die Einfachheit, konkret die Applosigkeit des lange Jahre bewährten mobilen Tan-Verfahrens genannt. Du magst Recht haben, dass die Mehrheit einen Zwang zur Verschlüsselung der Tan-Übermittlung aktuell verneint: 1. ist die nicht, wie du meinst, gefordert, und 2. (Meinung:) halten die Leute die Verschlüsselung schon deshalb für überflüssig, weil inzwischen jeder Schmarren wie Fotos verschlüsselt wird – aber das würde zu weit führen. – Fritz Jörn (Diskussion) 06:48, 27. Nov. 2019 (CET)

Ich habe nicht revertiert, das war ein anderer Benutzer. Ich habe mit meinem Beitrag hier nur dieser Revertierung zugestimmt. Vor- und Nachteile können ja gern eingebaut werden, jedoch dürfen diese nicht aufgrund von Privatmeinungen sondern aufgrund von neutralen, vertrauenswürdigen Belegen dargestellt werden. Und zu "nicht gefordert" lehnst du dich auch weit aus dem Fenster. Die EBA RTS fordern eine "Ende zu Ende Verschlüsselung". Unklar bleibt (da nicht genau definiert) ob damit "nur" der eigentliche Zahlungsauftrag gemeint ist. Einige vertreten deshalb die Auffassung, dass auch die Transaktionsfreigabekommunikation (ergo hier die smsTAN) verschlüsselt übertragen werden muss, da Sie zumindest Teile der freizugebenen Transaktion (zB Betrag/Empfänger/IBAN) enthält. Eine klare Auslegung bzw. ein entsprechendes Urteil dazu gibt es nicht. Somit also unklar. Und was eine Fotoverschlüsselung mit dem Thema zu tun hat, erschließt sich mir überhaupt nicht. Gruß, --SDI Fragen? 11:24, 27. Nov. 2019 (CET)

Ergänzung: Ich halte den Artikel übrigens auch für schlecht. Mir fehlt im Moment aber eine Idee der Neustrukturierung. Und leider auch etwas die Zeit... --SDI Fragen? 11:29, 27. Nov. 2019 (CET)

Danke für den freundlichen Austausch, SDI. Ich möchte hier nur meine Referenzstelle festhalten. In der »Delegierten Verordnung« – die mir im Übrigen schon im Namen Rätsel aufgibt, denn Verordnungen kann man nicht delegieren, wem? – verordnet in Artikel 35 »Sicherheit von Kommunikationssitzungen« unter (1) Kontoführende Zahlungsdienstleister, Zahlungsdienstleister, die kartengebundene Zahlungsinstrumente ausstellen, Kontoinformationsdienstleister und Zahlungsauslösedienstleister gewährleisten, dass beim Datenaustausch über das Internet während der jeweiligen Kommunikationssitzung eine sichere Verschlüsselung unter Einsatz weithin anerkannter Verschlüsselungstechnologien zwischen den kommunizierenden Parteien angewendet wird, damit der Schutz der Vertraulichkeit und der Integrität der Daten gewährleistet ist. – Soweit das Zitat[2]. Bei der Übertragung der Tan über SMS wird eben gerade nicht das Internet genutzt, auf dem verschlüsselt werden muss, sondern der zweite Weg des Zweifaktorenverfahrens: über Mobilfunk und nicht Internet. Expressis verbis ist da kein Verschlüsselungszwang erwähnt, der TÜV hat 2006 und 2007 das Verfahren aber als sicher zertifiziert, wie im Artikel zu lesen ist. Was noch gerne berücksichtigt werden soll, sind die (Betrugs-)Erfahrungen mit dem jeweiligen Verfahren (in der Verordnung Grund 16 und ev. Grund 6). Da SMS-Tan seit über einem Jahrzehnt geht, müssten da Statistiken vorliegen, die aber vermutlich nicht einfach zugänglich sind. Dabei sind Einzelfälle (wie hier genannt) nette “proofs of concept”, allgemein aber nicht relevant für eine Enzyklopädie. Ich meine, auch einen »Bestandsschutz« müsste es geben – und einstweilen gibt’s den auch. – Wo ist denn ein Beleg für geforderte Ende-zu-Ende-Verschlüsselung für den »2. Weg« bitte? Und ist eine einmalige Nachricht eine Kommunikation? (Eher ja). Heute bieten die Banken, Beispiel Volksbank, mit zwei Apps (VR-Banking-App plus VR-Secure-Go für die Tan), das komplette Banking auf einem Smartphone an, sodass die Argumente im Abschnitt »Entsprechend …« da auch gelten. Rat meiner Bank: Banking mit PC und nicht mit Smartphone, SMS über (Smart)phone. Literatur: selbstgemacht …[3] – Viele Grüße, Fritz Jörn (Diskussion) 16:54, 2. Dez. 2019 (CET)

Ich verstehe noch nicht, was du mir/uns sagen willst, außer immer mal wieder deinen Blog einzuflechten. Deine private Meinung ist irrelevant, jedenfalls hier - in der Wikipedia. Wir arbeiten mit Belegen, idealerweise mit reputablen Sekundärquellen. Deine Analyse ist schön und gut aber eben nicht zielführend. Du kannst mir glauben, dass ich zu diesem Thema mehr als nur "das Thema interessiert mich also schaue ich mal was es so gibt"-Wissen habe. Zum Thema Delegierten Verordnung kannst du dich hier belesen. Zur Verschlüsselung lies bitte meinen obigen Beitrag nochmal. Ich habe nicht geschrieben, dass es gefordert wird. Zum Thema smsTAN: Wiwo schreibt, dass die Bitkom smsTAN als "unsicher" einstuft. Das BSI ebenso. Öffentliche Schadensquoten finde ich gerade nicht, wird es aber sicherlich bald geben, da die Banken per PSD2 inzwischen für den gesamten beleglosen und auch beleghaften Zahlungsverkehr Schadensquoten ermitteln und melden müssen. --SDI Fragen? 17:44, 3. Dez. 2019 (CET)

»Für die Banken haben beide Verfahren [QR- und Foto-Tan]den Vorteil, dass trotz hoher Sicherheit die Investitions- und Transaktionskosten verhältnismäßig niedrig sind, da keine eigenen TAN-Generatoren erforderlich sind und z. B. im Unterschied zum mTAN-Verfahren keine SMS versandt werden müssen.«  Woher stammt denn diese Meinung? Inzwischen schicken einem schon kostenlose Dienste wie E-Mail-Provider (etwa Gmail) oder Finanzdienste SMS zur Zweiwegeauthorisierung. Eigene Tan-Generatoren«, zentral bei der Bank oder einem Bankdienstleister sind billiger als ersteinmal halbstündige Kundenführungen am Telefon zu 1. Finden der App ober Abhomen des Generators, 2. »Registrieren« der App, also deren Kopplung zur Bankidentität des Kunden, und schließlich der Benutzung. Die Meinung, was teurer ist, gehört hier heraus oder belegt. – Fritz Jörn (Diskussion) 17:06, 9. Jan. 2020 (CET)

Satz gelöscht, der machte so tatsächlich kaum Sinn. Allerdings begründest du wieder falsch, nämlich wieder mit deiner persönlichen Meinung ;). Zu kostenlosen sms-Dienste: Ja, die gibt es. Aber hast du da Anspruch auf Service-Level bzgl. Verfügbarkeit, Zustellgeschwindigkeit oder auch Zertifizierungen zum Datenschutz etc.? Wenn du hier vertraglich abgesichert Anforderungen stellst, bist du sofort raus aus kostenfreien Diensten. Und (mal wieder) zu komplizierteren Apps: Ich suche nicht, ich telefoniere nicht, ich richte meine Push-Apps selbst ein und brauche kein separates Gerät, Handy hab ich sowieso immer dabei. Also kein allgemeingültiges Argument. Gruß, --SDI Fragen? 18:09, 9. Jan. 2020 (CET)

Und wie wird nun die TAN bei chipTAN berechnet?

Hatte gehofft, der Artikel enthält Informationen darüber. Leider vergeblich. :-( --RokerHRO (Diskussion) 23:52, 5. Nov. 2020 (CET)

Wahrscheinlichkeiten

Im Abschnitt "Sicherheit" ist zu lesen: (... die Wahrscheinlichkeit ist) 1 : 1.000.000, eine bestimmte TAN mit einem Versuch zu erraten.

Das stimmt m.E. so nicht. Ich kann einen QR-Code mehrmals einscannen (ohne die TAN tatsächlich einzugeben, also zu verwenden), und bekomme dann weitere neue (gültige) TANs. Wie oft man das wiederholen kann, weiß ich nicht. Ich erhalte also zu einem QR-Code mindestens drei gültige TANs (mehr habe ich nicht versucht). Die Wahrscheinlichkeit erhöht dadurch auf (mindestens) 1:333.333.

Außerdem ist in der TAN auch noch die Karte codiert, denn die falsche Karte führt auf einen Fehler. Das schränkt, wenn man den Algorithmus kennt, die Anzahl der Möglichkeiten möglicherweise weiter ein.

(Aus diesen Gründen hatte ich den Artikel aufgesucht, um etwas zum Algorithmus zu erfahren und zu verstehen, wieso mehrere alternative TANs zu einem QR-Code möglich sind und wie die Kartennummer einfließt.) --ULupus (Diskussion) 15:37, 22. Feb. 2021 (CET)

Habe gerade die selbe Beobachtung gemacht, aus einem QR lassen sich mindestens 20 verschiedene TANs generieren, zu mehr hatte ich nicht die Muße. Allerdings kann ich auch bestätigen, dass es möglich ist eine TAN abgelehnt zu bekommen ;) -- Theoprakt (Diskussion) 11:14, 3. Jul. 2021 (CEST)