Im STiNE-Thread ist ja eine recht lange Diskussion um TANs entstanden, ich versuche mal, alle Beiträge hier zu zitieren, damit hier weitergemacht werden kann:

Newton:

Meine Tans habe ich auch noch nicht. Was mich wundert:

STiNE benutzt iTANs, allerdings will STiNE bei jedem Neu-Laden der Seite eine andere TAN haben. Die Idee hinter indizierten TANs ist doch gerade, dass wenn jemand per Phishing eine TAN herauskriegt, die Wahrscheinlichkeit sehr gering ist, dass er damit was anfangen kann.

So wie es in STiNE umgesetzt ist, braucht der Angreifer doch nur solange F5 zu drücken bis das System die TAN haben will die er auch hat.

Popcorn:

Meine Tans habe ich auch noch nicht. Was mich wundert:

STiNE benutzt iTANs, allerdings will STiNE bei jedem Neu-Laden der Seite eine andere TAN haben. Die Idee hinter indizierten TANs ist doch gerade, dass wenn jemand per Phishing eine TAN herauskriegt, die Wahrscheinlichkeit sehr gering ist, dass er damit was anfangen kann.

So wie es in STiNE umgesetzt ist, braucht der Angreifer doch nur solange F5 zu drücken bis das System die TAN haben will die er auch hat.

Wenn jemand per Phishing eine TAN rauskriegt, hat er aber noch nicht die Nummer dazu. Und dann bleibt die Frage was passiert, wenn jemand eine gültige TAN an falscher Stelle eingibt. Vielleicht wird die dann ja aus der internen Datenbank gestrichen. Wer stellt seine Daten zum Test zur Verfügung? [img]http://www.fb18.de/gfx/24.gif[/img]

DeGT:

Meine Tans habe ich auch noch nicht. Was mich wundert:

STiNE benutzt iTANs, allerdings will STiNE bei jedem Neu-Laden der Seite eine andere TAN haben. Die Idee hinter indizierten TANs ist doch gerade, dass wenn jemand per Phishing eine TAN herauskriegt, die Wahrscheinlichkeit sehr gering ist, dass er damit was anfangen kann.

Durch iTans steigt die Sicherheit nicht. Der Zeitpunkt des Angriffs ist einfach auf den Zeitpunkt des Phishings beschränkt. Die iTan-Abfrage wird an den Benutzer weitergegeben und das wars.
(@Tri: Das ist das, was ich bei der STiNE-Vorstellung sagen wollte)

Siehe auch http://www.heise.de/security/news/meldung/63249

Faleiro:

Durch iTans steigt die Sicherheit nicht. Der Zeitpunkt des Angriffs ist einfach auf den Zeitpunkt des Phishings beschränkt. Die iTan-Abfrage wird an den Benutzer weitergegeben und das wars.

Eben, was die Huerde fuer einen Angriff (extrem) hoeherlegt. –> Sicherheit steigt.

DeGT:

Durch iTans steigt die Sicherheit nicht. Der Zeitpunkt des Angriffs ist einfach auf den Zeitpunkt des Phishings beschränkt. Die iTan-Abfrage wird an den Benutzer weitergegeben und das wars.

Eben, was die Huerde fuer einen Angriff (extrem) hoeherlegt. –> Sicherheit steigt.

Lies dir doch einfach den Artikel durch. Diese Art von Phishing ist auch schon in der Wildnis vorgekommen. Nur Leute, die zu dumm/faul zum geskripteten Abrufen von Webseiten sind, hindert iTan in irgendeiner Weise.

Faleiro:

Durch iTans steigt die Sicherheit nicht. Der Zeitpunkt des Angriffs ist einfach auf den Zeitpunkt des Phishings beschränkt. Die iTan-Abfrage wird an den Benutzer weitergegeben und das wars.

Eben, was die Huerde fuer einen Angriff (extrem) hoeherlegt. –> Sicherheit steigt.

Lies dir doch einfach den Artikel durch. Diese Art von Phishing ist auch schon in der Wildnis vorgekommen. Nur Leute, die zu dumm/faul zum geskripteten Abrufen von Webseiten sind, hindert iTan in irgendeiner Weise.

Ich habe den Artikel gelesen. (Auch damals schon.)

Dass man immer noch mit einer Interkontinentalrakete den neuen, besseren Panzerschutz einer Bank brechen kann, ist kein Argument gegen diesen neuen, besseren Panzerschutz.
Es sind deutlich weniger Bankeinbrueche mit Interkontinentalraketen zu erwarten als herkoemmliche Aufschweiss-Aktionen. –> Bank wird sicherer durch den neuen, besseren Panzerschutz.

Da macht ein kleines Brunni-Team von einer Hochschule ein wenig von sich reden und geht in der Behauptung nicht einmal so weit wie du: Schon in der Ueberschrift steht recht vorsichtig "iTAN-Verfahren unsicherer als von Banken behauptet". Auf der Basis, die Banken wuerden angeblich behaupten, mit den iTANS sei das Verfahren hundertprozentig sicher.

Das sieht die Forschungsgruppe etwas anders. Ihrem veröffentlichten Advisory zufolge wird durch das iTAN-Verfahren nur der Zeitraum eines erfolgreichen Angriffs und einer Überweisung eingeschränkt.

LOL, ihrem Advisory zufolge. Das kann ich auch. Das direkte Weiterreichen von Zugriffen ist doch ein alter Hut, egal wie langwierig das dann auf Heise beschrieben wird. Aber eben eine andere, aufwendigere Angriffsart als ein bisschen Phishen, was wahnsinnig viel Gestaltungsspielraum hat.
Phishen kann auch ohne zeitgebundene Onlineverbindung geschehen! Hauptsache, PIN und eine TAN finden ihren Weg "relativ bald" zum Angreifer, etwa ueber schlecht ueberwachbare Wege wie Newsgroups etc.

Anonym:

Eben, was die Huerde fuer einen Angriff (extrem) hoeherlegt. –> Sicherheit steigt.

Lies dir doch einfach den Artikel durch.

Dort steht: "nur der Zeitraum eines erfolgreichen Angriffs und einer Überweisung eingeschränkt". Dieses "nur" läßt das wie eine Nebensächlichkeit erscheinen, tatsächlich wird hierdurch die Hürde aber schon spürbar erhöht. Nicht ins Unermessliche, aber auch nicht gar nicht.

Falls man bei STiNE aber tatsächlich mit jedem Reload der Webseite einfach einen anderen Index angezeigt bekommt, so ist da für mich wirklich quasi kein Zugewinn an Sicherheit gegenüber normalen TANs: Wenn man eine noch gültige TAN auspähen/erfragen kann, so wird dies meist auch zusammen mit dem Index möglich sein.

LEIFer

Newton:

Wg. Phishing und iTANs:
iTANs sind schon erheblich sicherer, da das Risiko durch Phishing irgendwie… 50mal geringer ist. iTANs schützen nur nicht vor Man in the middle-Zeugs (also Pharming, Trojaner…).
Und es irritiert mich eben, dass bei jedem erneutem Versuch sein Kennwort zu ändern (F5), eine andere iTAN gefordert wird. Das untergräbt doch komplett den Sinn von iTANs… so wird es doch wirklch nicht sicherer - es sei denn diese TANs gelten dann als "verbraucht".

Nebenbei: Wie ist es eigentlich möglich, zwei statt einem DNS zu befragen welche IP nun die Addresse hat? (Hab' grad bischen über Pharming gelesen…)

Faleiro:

Und es irritiert mich eben, dass bei jedem erneutem Versuch sein Kennwort zu ändern (F5), eine andere iTAN gefordert wird. Das untergräbt doch komplett den Sinn von iTANs… so wird es doch wirklch nicht sicherer - es sei denn diese TANs gelten dann als "verbraucht".

Auch wenn die weggedrueckten iTAN-Abfragen als verbraucht gelten, ist das System nicht sicherer als normale TANs… der Angreifer drueckt halt so lange, bis der Index von seiner gephishten iTAN abgefragt wird und tut seine boesen Dinge.

low_level:

Auch wenn die weggedrueckten iTAN-Abfragen als verbraucht gelten, ist das System nicht sicherer als normale TANs… der Angreifer drueckt halt so lange, bis der Index von seiner gephishten iTAN abgefragt wird und tut seine boesen Dinge.

Es könnte aber schneller auffallen …

Wie auch immer, bei STiNE werden die iTANs erst mit dem Abschicken eines Formulars verbraucht, vielleicht auch nur bei _erfolgreichem_ Abschicken, das weiß ich noch nicht.

Ich hab einfach ein paarmal F5 gedrückt, bis eine iTAN, die bereits angezeigt worden war, wieder angezeigt wurde. Das ist zwar kein strenger Beweis, aber zumindest ein Indiz.

guilyguy:

Auch wenn die weggedrueckten iTAN-Abfragen als verbraucht gelten, ist das System nicht sicherer als normale TANs… der Angreifer drueckt halt so lange, bis der Index von seiner gephishten iTAN abgefragt wird und tut seine boesen Dinge.

Es könnte aber schneller auffallen …

Wie auch immer, bei STiNE werden die iTANs erst mit dem Abschicken eines Formulars verbraucht, vielleicht auch nur bei _erfolgreichem_ Abschicken, das weiß ich noch nicht.

Ich hab einfach ein paarmal F5 gedrückt, bis eine iTAN, die bereits angezeigt worden war, wieder angezeigt wurde. Das ist zwar kein strenger Beweis, aber zumindest ein Indiz.

Je nachdem was Du mit "erfolgreich" meinst kann ich sagen: Nein.
Zumindest wollte ich das Passwort ändern, was nicht geklappt hat, die Tan war aber danach weg.

Harzilein:

Auch wenn die weggedrueckten iTAN-Abfragen als verbraucht gelten, ist das System nicht sicherer als normale TANs… der Angreifer drueckt halt so lange, bis der Index von seiner gephishten iTAN abgefragt wird und tut seine boesen Dinge.

Es könnte aber schneller auffallen …

Die ursprüngliche Idee beim iTAN-Phishen ist ja, dass man versucht die Systemanfrage einfach möglichst direkt an den bephishten zu liefern.

Cool find ich in dem Zusammenhang ja z.B. http://www.boingboing.net/2004/01/27/solving_and_creating.html

Denn ich kann ja auch statt einen Haufen iTANs abzufragen und es klappt nur bei einer nen haufen Leute jeweils eine iTAN fragen und bei dem wo die Umstände gerade günstig sind direkt meine Transaktion machen (bzw. vorbereiten und später abschließen, noch besser, wenn vom System erlaubt).

Faleiro:

Cool find ich in dem Zusammenhang ja z.B. http://www.boingboing.net/2004/01/27/solving_and_creating.html

LOL, das ist doch mal eine Idee [img]http://www.fb18.de/gfx/15.gif[/img]

Farcon:

Cool find ich in dem Zusammenhang ja z.B. http://www.boingboing.net/2004/01/27/solving_and_creating.html

LOL, das ist doch mal eine Idee [img]http://www.fb18.de/gfx/15.gif[/img]

Da gibt es auch schon eine funktionierende Implementierung:

http://hotcaptcha.com/

Das sollten alle wichtigen Beiträge zu TANs gewesen sein. Sollte ich etwas vergessen haben, Nachricht an mich. [img]http://www.fb18.de/gfx/23.gif[/img]

Ich habe zwar nicht verstanden, was der Zusammenhang zwischen iTANs und CAPTCHAs ist, aber zu letzteren will ich noch anmerken: Pr0n gegen CAPTCHA-Lösungen zu tauschen bekommt sicherlich einen Bonuspunkt für einen kreativen Hack, allerdings sind die meisten derzeitigen CAPTCHAs sowieso so schlecht, dass sie auch durch einen Computer gelöst werden können. Die Wikipedia-Seite zu CAPTCHAs fasst das ganz gut zusammen und hat am Ende noch ein paar weiterführende Links.

Besonders unangenehm ist bei Blogs, dass dort einige Spammer wohl mittlerweile soweit aufgerüstet haben, dass die Kommentare selbst von einem Menschen nicht unbedingt gleich als Spam zu identifizieren sind. :-(

LEIFer.