MasterCard/Visacard SecureCode: S-ID-Check oder mTAN (2. Versuch)

[Ulrich Maier]

Bisher hatte ich zur Absicherung der Online-Nutzung meiner Kreditkarte
einen "Securecode", den ich zur Bestätigung einer Online-Nutzung
eingeben musste.

Dieses Verfahren wurde nun abgelöst durch eine App (S-ID-Check) oder ein
mTAN-Verfahren.

Bisher musste jemand, der in den Besitz meiner Kreditkartennummer und
der weiteren auf der Karte aufgedruckten Angaben gelangte, für die
missbräuchliche Online-Nutzung der Karte zusätzlich meinen Securecode in
Erfahrung bringen. (Zumindest bei den Händlern, die den Securecode
unterstützten.)

In Zukunft reicht, dass er in den Besitz meines Handys gelangt und es
öffnen kann (oder anderweitigen Zugriff erlangt hat).

Da ich meinen Securecode sicher verschlüsselt auf meinem Rechner
gespeichert habe, hatte ein Angreifer nur folgende Möglichkeiten, an den
Code zu gelangen:
- Zugriff auf den Rechner
- Abgreifen der Kommunikation mit der Bank oder
- Zugriff auf den beim Kartenherausgeber (vermutlich verschlüsselt)
hinterlegten Securecode.

Bei diesem alten Verfahren habe ich mich sicherer gefühlt. Ein Irrtum?

Ulrich


PS: Zusätzlich wurde ich zur Eingabe einer Sicherheitsabfrage
aufgefordert (wie hieß Ihre erste Freundin u.ä.). Wozu auch immer. Ich
habe meiner Freundin den unaussprechlichen Namen T92Z9a3ewY spendiert
(wie üblich: Name geändert ;-) und diesen auch noch sofort gelöscht.
Aber wer tut das schon!

[Ralph Angenendt]

Well, Ulrich Maier <inv...@invalid.invalid> wrote:
> In Zukunft reicht, dass er in den Besitz meines Handys gelangt und es
> öffnen kann (oder anderweitigen Zugriff erlangt hat).
>
> Da ich meinen Securecode sicher verschlüsselt auf meinem Rechner
> gespeichert habe, hatte ein Angreifer nur folgende Möglichkeiten, an den
> Code zu gelangen:

Und dein Handy ist weder verschlüsselt noch mit einer PIN versehen noch
hat die Applikation "S-ID-Check" ein vorgeschaltetes Passwort? Bei
letzterem würde ich die Bank wechseln.

Ralph
--
His goal in life was to be an echo

[Ulrich Maier]

Am 29.09.2016 um 10:58 schrieb Ralph Angenendt:

>> Da ich meinen Securecode sicher verschlüsselt auf meinem Rechner
>> gespeichert habe, hatte ein Angreifer nur folgende Möglichkeiten, an den
>> Code zu gelangen:
>
> Und dein Handy ist weder verschlüsselt noch mit einer PIN versehen

Da ein Handy meist regelmäßig genutzt wird, wird den Zugang kaum jemand
so schützen, wie es für die Absicherung sensitiver Daten erforderlich
wäre! Das bleibt Freaks vorbehalten, denen ihre Zeit dafür nicht zu
schade ist.

> noch hat die Applikation "S-ID-Check" ein vorgeschaltetes Passwort?

Ich habe die Anwendung nicht installiert.

> Bei letzterem würde ich die Bank wechseln.

Da kann die Bank auch nicht viel tun. Die App wird von Mastercard und
Visa herausgegeben!

Ulrich

[Ralph Angenendt]

Well, Ulrich Maier <inv...@invalid.invalid> wrote:
>
>

> Am 29.09.2016 um 10:58 schrieb Ralph Angenendt:
>
>>> Da ich meinen Securecode sicher verschlüsselt auf meinem Rechner
>>> gespeichert habe, hatte ein Angreifer nur folgende Möglichkeiten, an den
>>> Code zu gelangen:
>>
>> Und dein Handy ist weder verschlüsselt noch mit einer PIN versehen
>
> Da ein Handy meist regelmäßig genutzt wird, wird den Zugang kaum jemand
> so schützen, wie es für die Absicherung sensitiver Daten erforderlich
> wäre! Das bleibt Freaks vorbehalten, denen ihre Zeit dafür nicht zu
> schade ist.

Genau wie deine verschlüsselte Datei auf dem Rechner - das macht auch
niemand "außer Freaks", denen ihre Zeit, das mit der Verschlüsselung zu
lernen, nicht zu schade ist. Da sehe ich keinen Unterschied.

>> noch hat die Applikation "S-ID-Check" ein vorgeschaltetes Passwort?
>
> Ich habe die Anwendung nicht installiert.
>
>> Bei letzterem würde ich die Bank wechseln.
>
> Da kann die Bank auch nicht viel tun. Die App wird von Mastercard und
> Visa herausgegeben!

Gut. Ich habe die App im DKB-Branding, da ist ein beliebig starkes
Passwort zu benutzen, bevor die App funktioniert. Und das kannst du ja
wieder verschlüsselt auf deinem Rechner speichern.

mTan würde ich auch nicht nutzen.

[Andreas M. Kirchwitz]

Ulrich Maier <inv...@invalid.invalid> wrote:

> In Zukunft reicht, dass er in den Besitz meines Handys gelangt und es
> öffnen kann (oder anderweitigen Zugriff erlangt hat).

> [...]

> Bei diesem alten Verfahren habe ich mich sicherer gefühlt. Ein Irrtum?

Das alte Verfahren war sicherer. Wie auch die TAN-Listen auf Papier
(einige Banken bieten das immer noch an) sicherer sind als mTAN.

Passwörter merken oder Zahlenlisten auf Papier sind superuncool.
Spyware-Apps auf dem Handy installieren - das ist cool. mTAN ist
zwar SMS, geht gerade noch so als cool durch, weil noch viele
traditionelle Handys in Benutzung sind (nix App).

Für die Banken ist das billiger so. Tatsächliche Angriffe auf
Papier-TAN, mTAN, Banking-Apps sind meines Wissens ohnehin eher
selten. Bisher jedenfalls.

Es ist viel wahrscheinlicher, Opfer eines manipulierten
Geldautomaten oder Bezahlterminals zu werden. Oder eines
Datenbank-Leaks eines Internet-Shops. Oder eines Irrtums.

Mal schauen, ab wann es für die Diebe attraktiver wird, vermehrt
direkt bei den Kunden anzusetzen. Den Banken kann es nur recht
sein, denn bei Angriffen auf die Infrastruktur muss sie für den
Schaden aufkommen, bei Angriffen auf die Kunden kann sie sich
eher querstellen und die Schuld auf die Kunden abschieben.

Nicht aufregen, hilft eh nix ... Andreas

[Juergen Ilse]

Hallo,

Andreas M. Kirchwitz <a...@spamfence.net> wrote:
> Es ist viel wahrscheinlicher, Opfer eines manipulierten
> Geldautomaten oder Bezahlterminals zu werden. Oder eines
> Datenbank-Leaks eines Internet-Shops. Oder eines Irrtums.

... und anscheinend ist noch nicht einmal ein Datenbank-Leak eines Internet-
Shops notwendig ... Ich habe letztens Rechnungen fuer angeblich von mir ab-
geschlossene Handy-Vertraege (wurden wohl angeblich ueber preis24.de bestellt)
zugesandt. Mittlerweile weiss ich, dass die dort angegebene Mailadresse nicht
meine ist, dass das bei der Bestellung angegebene Geburtsdatum nicht meins
ist, dass die Lieferaddresse fuer die Handys (die *nicht* mit der Rechnungs-
adresse uebereinstimmte) nicht meine ist, dass die Lieferung vermutlich zu
einer Zeit erfolgte, als ich im Urlaub war (mehrere hundert km entfernt von
der Lieferaddresse), also praktisch *gar* *nichts* ausser dem Namen und der
Rechnungsaddresse mit meinen Daten uebereinstimmt. Wie trotzdem jemand auf
meinen Namen im Internet einen Vertrag abschliessen konnte, ist mir ziemlich
raetselhaft. Offenbar genuegten Name, Anschrift und Geburtsdatum fuer die
Bestellung aus, und das Geburtsdatum wurde noch nicht einmal geprueft (evt.
wurde noch nach der Personalausweisnummer gefragt, aber da liegt offenbar
áuch nicht meine echte vor). Ich habe mich beschwert und mitgeteilt, dass
ich den Vertrag nicht geschlossen habe. Mal sehen, was da draus noch wird ...
Dieser "getuerkte Vertrag" war offenbar viel einfacher zu realisieren, als
jeder Online-Banking-Betrug je sein koennte (und die Rechnungssummen beliefen
sich, als ich aus dem Urlaub wieder da war, mittlerweile auf ueber 250,- EURO
pro Vertrag).

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.

[Ralph Angenendt]

Well, Juergen Ilse <jue...@usenet-verwaltung.de> wrote:
> Offenbar genuegten Name, Anschrift und Geburtsdatum fuer die
> Bestellung aus, und das Geburtsdatum wurde noch nicht einmal geprueft (evt.
> wurde noch nach der Personalausweisnummer gefragt, aber da liegt offenbar
> áuch nicht meine echte vor). Ich habe mich beschwert und mitgeteilt, dass
> ich den Vertrag nicht geschlossen habe. Mal sehen, was da draus noch wird ...

Anzeige erstatten. Durfte ich letztes Jahr auch machen, als in mehreren
Shops Markenklamotten auf meinen Namen auf Rechnung bestellt wurden.
Eine Lieferung habe ich sogar bekommen, weil der Laden bei der
Erstbestellung auf Rechnung *immer* an die Rechnungsadresse liefert,
auch wenn man eine andere angibt.

[Rupert Haselbeck]

Ralph Angenendt schrieb:

> Well, Juergen Ilse <jue...@usenet-verwaltung.de> wrote:
>> Offenbar genuegten Name, Anschrift und Geburtsdatum fuer die
>> Bestellung aus, und das Geburtsdatum wurde noch nicht einmal geprueft
>> (evt. wurde noch nach der Personalausweisnummer gefragt, aber da liegt
>> offenbar áuch nicht meine echte vor). Ich habe mich beschwert und
>> mitgeteilt, dass ich den Vertrag nicht geschlossen habe. Mal sehen, was
>> da draus noch wird ...
>
> Anzeige erstatten.

Wozu? Jürgen ist doch überhaupt nicht geschädigt!
Geschädigt ist der Verkäufer. Jürgen wird die Rechnungen für von ihm nicht
abgeschlossene Verträge wohl nicht bezahlen wollen...

> Durfte ich letztes Jahr auch machen, als in mehreren
> Shops Markenklamotten auf meinen Namen auf Rechnung bestellt wurden.
> Eine Lieferung habe ich sogar bekommen, weil der Laden bei der
> Erstbestellung auf Rechnung *immer* an die Rechnungsadresse liefert,
> auch wenn man eine andere angibt.

Nachdem du keinerlei vertragliche Beziehung zu diesen Shops hattest, war es
lediglich zu deren Arbeitserleichterung, dass du ihre Aufgabe erledigt hast.

MfG
Rupert

[Marc Haber]

Ulrich Maier <inv...@invalid.invalid> wrote:
>Bei diesem alten Verfahren habe ich mich sicherer gefühlt. Ein Irrtum?

Nein, das siehst Du völlig richtig. Das Passwort oder - besser - die
(i)TAN-Liste sind nach wie vor das sicherste Verfahren gegen
technische Angriffe.

Getötet wurden diese Verfahren von nicht nachdenkenden Idioten auf
Nutzerseite.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Andreas M. Kirchwitz]

Juergen Ilse <jue...@usenet-verwaltung.de> wrote:

> Dieser "getuerkte Vertrag" war offenbar viel einfacher zu realisieren, als
> jeder Online-Banking-Betrug je sein koennte (und die Rechnungssummen beliefen
> sich, als ich aus dem Urlaub wieder da war, mittlerweile auf ueber 250,- EURO
> pro Vertrag).

Traurige Geschichte. Alles Gute, dass außer der investierten Zeit
zur Aufklärung (was ja schon ärgerlich genug ist) wenigstens am Ende
kein finanzieller Verlust für Dich übrig bleibt.

Man kann nur hoffen, dass man solche Unregelmäßigkeit immer
rechtzeitig entdeckt, solange Rückbuchung/Widerspruch noch
unkompliziert möglich ist.

Früher hat man Abrechnungen monatlich per Post nach Hause bekommen.
Da hat man kurz die Zahlen auf dem Papier überflogen, ob sie in etwa
plausibel sind - und damit war's erledigt.

Heute muss man sich für jedes Konto und jede Kreditkarte irgendwo
einloggen, unterschiedliche Sicherheitssperren bewältigen, durch
verschiedene Webinterfaces hangeln, dann downloadet man aus dem
Online-Postfach einen Haufen PDFs, aus denen man sich dann die
Abrechnungen herauspicken muss, um endlich gucken zu können,
ob alles seine Richtigkeit hat(te).

Einerseits ist's schön, dass sich zu Hause erheblich weniger Papier
ansammelt, andererseits habe ich das Gefühl, dass mich unterm Strich
dieser Aspekt der Online-Kontoführung mehr Zeit kostet als früher.

Warum können Banken einem die Abrechnungen nicht verschlüsselt per
traditioneller E-Mail zuschicken? (PGP, ZIP-File, whatever... so wie
das im beruflichen Umfeld ganz normal ist)

Online-Banking könnte richtig cool sein! ... Andreas

[Dietz Pröpper]

Marc Haber wrote:

> Ulrich Maier <inv...@invalid.invalid> wrote:
>>Bei diesem alten Verfahren habe ich mich sicherer gefühlt. Ein Irrtum?
>
> Nein, das siehst Du völlig richtig. Das Passwort oder - besser - die
> (i)TAN-Liste sind nach wie vor das sicherste Verfahren gegen
> technische Angriffe.

Flackercode ist (wenn richtig umgesetzt) noch besser.

> Getötet wurden diese Verfahren von nicht nachdenkenden Idioten auf
> Nutzerseite.

Sogar bei angemessener Verwendung gab es grundsätzlich interessante Angriffe.

[Andreas Kohlbach]

On Fri, 30 Sep 2016 16:11:39 +0000 (UTC), Andreas M. Kirchwitz wrote:
>
> Warum können Banken einem die Abrechnungen nicht verschlüsselt per
> traditioneller E-Mail zuschicken? (PGP, ZIP-File, whatever... so wie
> das im beruflichen Umfeld ganz normal ist)

Für den Fall, dass dein Email Account kompromittiert ist, und jemand
anderes deine Mails liest. Da hilft auch Verschlüsselung nichts. Zwar
kann der andere dann nicht lesen. Aber dein Passwort für den Account wird
wohl geändert sein, dass auch du nicht lesen kannst.

Oder der ISP hat den Account für ein paar Wochen "suspendet". Wie bei
einem Nachbarn, der auf eine Phishing Mail für Outlook herein
fiel. Nachdem er das merkte und mich um Hilfe bat, gingen wir den Prozess
durch mit der Authentifizierung über SMS etc. Am Ende wurde gesagt, der
Account sei nun für einige (IIRC vier) Wochen blockiert. Danach konnte er
ihn erst wieder benutzen. Im Fall des Bankings hieße dass, er könnte vier
Wochen seine Mails von der Bank nicht lesen.
--
Andreas
You know you are a redneck if
you have flowers planted in a bathromm appliance in your front yard.

[Andreas Kohlbach]

On Fri, 30 Sep 2016 18:23:46 +0200, Dietz Pröpper wrote:
>
> Marc Haber wrote:
>
>> Ulrich Maier <inv...@invalid.invalid> wrote:
>>>Bei diesem alten Verfahren habe ich mich sicherer gefühlt. Ein Irrtum?
>>
>> Nein, das siehst Du völlig richtig. Das Passwort oder - besser - die
>> (i)TAN-Liste sind nach wie vor das sicherste Verfahren gegen
>> technische Angriffe.
>
> Flackercode ist (wenn richtig umgesetzt) noch besser.

Das setzt zusätzliche Hardware voraus.

[Ulrich Maier]

Am 30.09.2016 um 18:11 schrieb Andreas M. Kirchwitz:

> Warum können Banken einem die Abrechnungen nicht verschlüsselt per
> traditioneller E-Mail zuschicken? (PGP, ZIP-File, whatever... so wie
> das im beruflichen Umfeld ganz normal ist)

Na ja. E-Mails mit verschlüsselten Anhängen werden richtigerweise
ziemlich regelmäßig blockiert.

Ulrich

[Juergen Ilse]

Hallo,

Andreas M. Kirchwitz <a...@spamfence.net> wrote:

> Juergen Ilse <jue...@usenet-verwaltung.de> wrote:
>> Dieser "getuerkte Vertrag" war offenbar viel einfacher zu realisieren, als
>> jeder Online-Banking-Betrug je sein koennte (und die Rechnungssummen beliefen
>> sich, als ich aus dem Urlaub wieder da war, mittlerweile auf ueber 250,- EURO
>> pro Vertrag).
> Traurige Geschichte. Alles Gute, dass außer der investierten Zeit
> zur Aufklärung (was ja schon ärgerlich genug ist) wenigstens am Ende
> kein finanzieller Verlust für Dich übrig bleibt.
> Man kann nur hoffen, dass man solche Unregelmäßigkeit immer
> rechtzeitig entdeckt, solange Rückbuchung/Widerspruch noch
> unkompliziert möglich ist.

Dank SEPA ist die Abbuchung ja nur noch mit "Lastschriftmandat" moeglich,
und das lag nicht vor (abgesehen davon, dass bei der Bestellung nicht meine
Kontonummer sondern die einer anderen Person, die vermutlilch auch kein
Lastschriftmandat fuer den Mobilfunkprovider erteilt hatte, deswegen bekam
ich ja zusammen mit der ersten Rechnung auch ein Formular zugesandt, um
jenes Lastschriftmandat zu erteilen, was ich angesichts der Umstaende
natuerlich *nicht* tat ...).

> Früher hat man Abrechnungen monatlich per Post nach Hause bekommen.
> Da hat man kurz die Zahlen auf dem Papier überflogen, ob sie in etwa
> plausibel sind - und damit war's erledigt.
> Heute muss man sich für jedes Konto und jede Kreditkarte irgendwo
> einloggen, unterschiedliche Sicherheitssperren bewältigen, durch
> verschiedene Webinterfaces hangeln, dann downloadet man aus dem
> Online-Postfach einen Haufen PDFs, aus denen man sich dann die
> Abrechnungen herauspicken muss, um endlich gucken zu können,
> ob alles seine Richtigkeit hat(te).

Ich bekomme von meiner Bank noch immer Kontoauszuege zugesandt, sofern
ich sie mir nicht vorher schon mal vom Kontoauszugsdrucker in der Bank-
filiale habe ausdrucken lassen, und den taeglichen Ueberblick koennte
ich mir per FinTS 3.0 Online-Banking verschaffen (was ich auch tue,
wenn auch nicht taeglich).

> Warum können Banken einem die Abrechnungen nicht verschlüsselt per
> traditioneller E-Mail zuschicken? (PGP, ZIP-File, whatever... so wie
> das im beruflichen Umfeld ganz normal ist)

Wenn man das beantragt (und die Banking-Software das unterstuetzt) kann
man Kontoauszuege auch per Online-Banking erhalten und selbst ausdrucken ...

> Online-Banking könnte richtig cool sein! ... Andreas

Ist es, wenn die Bank das alles unterstuetzt was man machen moechte und
man auf die sicheren Varianten setzt (bei mir: FinTS 3.0 mit RSA Chipkarte
und Klasse3 Chipkartenleser sowie einer Software, die das auch unterstuetzt).

[Juergen Ilse]

Hallo,

Marc Haber <mh+usene...@zugschl.us> wrote:
> Ulrich Maier <inv...@invalid.invalid> wrote:
>>Bei diesem alten Verfahren habe ich mich sicherer gefühlt. Ein Irrtum?
> Nein, das siehst Du völlig richtig. Das Passwort oder - besser - die
> (i)TAN-Liste sind nach wie vor das sicherste Verfahren gegen
> technische Angriffe.

IBTD.
Ich wueste nicht, was an FinTS 3.0 mit RSA Chipkarte unsicherer sein sollte
(wenn man nicht fahrlaessig handelt): Die Schluessel von der Karte koennen
nicht kopiert werden, signieren und pruefen von Signaturen findet auf der
Karte statt, die Nutzung der Karte erfordert die Eingabe einer mindestens
6-stelligen PIN, die am Chipkarenleser eingegeben werden muss (und daher
selbst mittels keylogger nicht vom Rechner abgegriffen werden kann, alle
Transaktionen mit der Bank laufen verschluesselt und mittels des Schluessels
auf der Karte signiert ab. Wo soll da gegenueber iTAN die groessere Angriffs-
flaeche da sein?

> Getötet wurden diese Verfahren von nicht nachdenkenden Idioten auf
> Nutzerseite.

Das mag sein, aber waehrend eine geklaute iTAN Liste sofort auch von unbe-
rechtigten verwendet werden koennte, ist das bei geklauter Chipkarte nur
in Verbindung mit der zugehoerigen PIN moeglich (und nach 5-malig aufein-
anderfolgender Falscheingabe der PIN wird die Karte gesperrt).

[Juergen P. Meier]

Juergen Ilse <jue...@usenet-verwaltung.de>:

> Ich wueste nicht, was an FinTS 3.0 mit RSA Chipkarte unsicherer sein sollte
> (wenn man nicht fahrlaessig handelt): Die Schluessel von der Karte koennen

Ach.

> nicht kopiert werden, signieren und pruefen von Signaturen findet auf der

Die TANs auf der Liste koennen ebensowenig kompromittiert werden.

> Karte statt, die Nutzung der Karte erfordert die Eingabe einer mindestens
> 6-stelligen PIN, die am Chipkarenleser eingegeben werden muss (und daher
> selbst mittels keylogger nicht vom Rechner abgegriffen werden kann, alle
> Transaktionen mit der Bank laufen verschluesselt und mittels des Schluessels
> auf der Karte signiert ab. Wo soll da gegenueber iTAN die groessere Angriffs-
> flaeche da sein?

TAN ist das Verfahren mit der hoechsten moeglichen Summe aus Sicherheit
und Bequemlichkeit. (das variiert mit der Faehigkeit des Nutzers)

Alle anderen Verfahren mit hoeherer Sicherheit haben eine so viel
geringere Bequemlichkeit, dass dieser Faktor kaum erreicht wird.

>> Getötet wurden diese Verfahren von nicht nachdenkenden Idioten auf
>> Nutzerseite.

Die einzige - aber leider auch groesste Angriffsflaeche bei TAN ist
der Benutzer selbst. Fuer die Allgmeienheit eignet sich das deswegen
nicht, nur Benutzer die ihre Angriffsflaeche zu mitigieren wissen,
haben mit TAN ein sicheres Verfahren.

Alle anderen muessen Geld fuer Chipkarte, Kartenleser und die
Gebuehren, die das Backend bei der Bank finanzieren, bezahlen.

> Das mag sein, aber waehrend eine geklaute iTAN Liste sofort auch von unbe-
> rechtigten verwendet werden koennte, ist das bei geklauter Chipkarte nur

Wenn man dir Kartenleser, PIn und Karte klaut, kann man das auch
sofort unberechtigt verwenden.

> in Verbindung mit der zugehoerigen PIN moeglich (und nach 5-malig aufein-
> anderfolgender Falscheingabe der PIN wird die Karte gesperrt).

Das laesst sich umgehen.

[Marc Haber]

Ulrich Maier <inv...@invalid.invalid> wrote:
>Na ja. E-Mails mit verschlüsselten Anhängen werden richtigerweise
>ziemlich regelmäßig blockiert.

Warum ist das richtig?

[Marc Haber]

Dietz Pröpper <dietz...@rotfl.franken.de> wrote:
>Marc Haber wrote:
>> Ulrich Maier <inv...@invalid.invalid> wrote:
>>>Bei diesem alten Verfahren habe ich mich sicherer gefühlt. Ein Irrtum?
>>
>> Nein, das siehst Du völlig richtig. Das Passwort oder - besser - die
>> (i)TAN-Liste sind nach wie vor das sicherste Verfahren gegen
>> technische Angriffe.
>
>Flackercode ist (wenn richtig umgesetzt) noch besser.

Da muss man halt immer einen Kartenleser dabei haben. Und zwar einen,
der funktioniert.

[Marc Haber]

Juergen Ilse <jue...@usenet-verwaltung.de> wrote:
>Hallo,
>
>Marc Haber <mh+usene...@zugschl.us> wrote:
>> Ulrich Maier <inv...@invalid.invalid> wrote:
>>>Bei diesem alten Verfahren habe ich mich sicherer gefühlt. Ein Irrtum?
>> Nein, das siehst Du völlig richtig. Das Passwort oder - besser - die
>> (i)TAN-Liste sind nach wie vor das sicherste Verfahren gegen
>> technische Angriffe.
>
>IBTD.

Ich wusste dass Du den Pferdefuß findest, nur um mir zu widersprechen.

Ich meinte natürlich die Verfahren mit signifikanter Verbreitung, die
auch mit freien Betriebssystemen nutzbar sind.

>> Getötet wurden diese Verfahren von nicht nachdenkenden Idioten auf
>> Nutzerseite.
>
>Das mag sein, aber waehrend eine geklaute iTAN Liste sofort auch von unbe-
>rechtigten verwendet werden koennte,

Wenn die PIN bekannt ist.

Ich tippe meine iTAN-Listen in den Passwortsafe ab, in dem stehen
Dinge mit mehr Wert als der Zugang zu meinem Bankkonto. Und früher, zu
TAN-Zeiten hatte ich dort auch immer nur zwei, drei TANs. Seit iTAN
muss ich sie alle dabei haben, ein Sicherheitsverlust.

[Franklin Schiftan]

Marc Haber schrieb am 01.10.2016 um 09:22 Uhr:

> Ulrich Maier <inv...@invalid.invalid> wrote:
>>Na ja. E-Mails mit verschlüsselten Anhängen werden richtigerweise
>>ziemlich regelmäßig blockiert.
>
> Warum ist das richtig?

Nun ja, ich nehme mal an, dass Ulrich damit meinte, dass nicht die
komplette E-Mail blockiert wird, sondern lediglich der
verschlüsselte Anhang, weil der eben so nicht ausgepackt und an
zentraler Stelle vorab und separat auf möglichen schädlichen Inhalt
geprüft werden kann.

So kannte ich das übrigens von meinem früheren Arbeitgeber auch.

> Marc

--
..... und tschüss

Franklin

[Franklin Schiftan]

Juergen P. Meier schrieb am 01.10.2016 um 08:51 Uhr:

> Juergen Ilse <jue...@usenet-verwaltung.de>:

>> Das mag sein, aber waehrend eine geklaute iTAN Liste sofort auch von unbe-
>> rechtigten verwendet werden koennte, ist das bei geklauter Chipkarte nur
>
> Wenn man dir Kartenleser, PIn und Karte klaut, kann man das auch
> sofort unberechtigt verwenden.

Ähm, wozu muss der Kartenleser geklaut werden?

>> in Verbindung mit der zugehoerigen PIN moeglich (und nach 5-malig aufein-
>> anderfolgender Falscheingabe der PIN wird die Karte gesperrt).
>
> Das laesst sich umgehen.

Wie?

[Juergen Ilse]

Hallo,

Juergen P. Meier <nospa...@jors.net> wrote:
> Die einzige - aber leider auch groesste Angriffsflaeche bei TAN ist
> der Benutzer selbst. Fuer die Allgmeienheit eignet sich das deswegen
> nicht, nur Benutzer die ihre Angriffsflaeche zu mitigieren wissen,
> haben mit TAN ein sicheres Verfahren.
> Alle anderen muessen Geld fuer Chipkarte, Kartenleser und die
> Gebuehren, die das Backend bei der Bank finanzieren, bezahlen.

Der Kartenleser ist eine einmalige Investition, und meine Bank brechnet
IIRC fuer das Verfahren selbst keine Gebuehren, nur alle 3 Jahre wird
einmal ein Betrag fuer eine neue Karte faellig.

>> Das mag sein, aber waehrend eine geklaute iTAN Liste sofort auch von unbe-
>> rechtigten verwendet werden koennte, ist das bei geklauter Chipkarte nur
> Wenn man dir Kartenleser, PIn und Karte klaut, kann man das auch
> sofort unberechtigt verwenden.

Wer die PIN aufschreibt, so dass sie geklaut werden kann, macht da gewaltig
etwas falsch ...

>> in Verbindung mit der zugehoerigen PIN moeglich (und nach 5-malig aufein-
>> anderfolgender Falscheingabe der PIN wird die Karte gesperrt).
> Das laesst sich umgehen.

Bei SECCOS Karten? Wie?

[Marc Haber]

Franklin Schiftan <fraschi...@arcor.de> wrote:
>So kannte ich das übrigens von meinem früheren Arbeitgeber auch.

Das macht es nicht richtiger.

[Juergen Ilse]

Hallo,

Marc Haber <mh+usene...@zugschl.us> wrote:

> Juergen Ilse <jue...@usenet-verwaltung.de> wrote:
>>Marc Haber <mh+usene...@zugschl.us> wrote:
>>> Ulrich Maier <inv...@invalid.invalid> wrote:
>>>>Bei diesem alten Verfahren habe ich mich sicherer gefühlt. Ein Irrtum?
>>> Nein, das siehst Du völlig richtig. Das Passwort oder - besser - die
>>> (i)TAN-Liste sind nach wie vor das sicherste Verfahren gegen
>>> technische Angriffe.
>>IBTD.
> Ich wusste dass Du den Pferdefuß findest, nur um mir zu widersprechen.
> Ich meinte natürlich die Verfahren mit signifikanter Verbreitung, die
> auch mit freien Betriebssystemen nutzbar sind.

Ich nutze das ausschliesslich mit einem freien Betriebssystem (allerdings
nicht mit freier Software, sondern mit der Linux-Version von moneyplex).

>>> Getötet wurden diese Verfahren von nicht nachdenkenden Idioten auf
>>> Nutzerseite.
>>Das mag sein, aber waehrend eine geklaute iTAN Liste sofort auch von unbe-
>>rechtigten verwendet werden koennte,
> Wenn die PIN bekannt ist.

Ich gebe zu, mich mit dem TAN-Verfahren nicht allzu ausfuehrlich befasst
zu haben. Benoetigt man zusaetzlich zur gueltigen TAN noch eine separate
PIN?

Der Sicherheitsvorteil bei FinTS 3.0 mit Chipkarte ist IMHO, dass der
fuer Transaktionen benoetigte private Schluessel nicht kopiert werden
kann und selbst dem Kunden der ihn verwendet nicht bekannt ist. Das
ist auch der Vorteil gegenueber einer "Schluesseldatei" (den Vorteil
der "Schluesseldatei" keinen Kartenleser zu nenoetigen erkauft man
sich mit einem Sicherheitsverlust).

[Ulrich Maier]

Am 01.10.2016 um 08:51 schrieb Juergen P. Meier:

> TAN ist das Verfahren mit der hoechsten moeglichen Summe aus Sicherheit
> und Bequemlichkeit. (das variiert mit der Faehigkeit des Nutzers)

Hier wurde nun das Thema gewchselt.

Meine Ausgangsfrage betraf die Bezahlung über das Internet mit
Kreditkarten. Da gibt es als einzige mögliche Absicherung das
SecureID-Verfahren. Alle übrigen abgefragten Daten stehen auf der Karte.

Meine Bedenken, die Absicherung der Online-Kreditkartenzahlung auf das
Mobiltelefon zu verlegen, sind folgende: Beides, Kreditkarte und
Telefon, trägt man üblicherweise bei sich. Da ist dann das Risiko hoch,
dass beides gleichzeitig abhanden kommt. Der PC befindet sich dagegen
einigermaßen abgesichert an einem verschlossenem Ort.

Ich behandle das Mobiltelefon als unsicher, habe keine kritischen Daten
drauf. Ich bin auch nicht bereit, mich damit auseinanderzusetezn, ob und
wie man das Mobiltelefon sicher bekommt. Bei allem, was man liest, ist
das schwieriger, als einen PC abzusichern.

TAN-Verfahren werden dagegen für die Kommunikation mit Banken verwendet.
Daneben gibt es auch HBCI. (Seit einigen Tagen nutze ich auch die
photoTAN, auf jeden Fall sehr komfortabel zu nutzen, und deutlich
bequemer, schneller und stabiler als die ChipTAN. Man kann ein codiertes
Lesegerät verwenden (ca. 20 Euro) oder wieder eine App auf dem Handy!
Ich habe aus den oben dargelegten Gründen in das Lesegerät investiert.)

Ulrich

[David Seppi]

Juergen Ilse schrieb:

> Ich gebe zu, mich mit dem TAN-Verfahren nicht allzu ausfuehrlich befasst
> zu haben. Benoetigt man zusaetzlich zur gueltigen TAN noch eine separate
> PIN?

Ja, fürs Login im Online-Banking.

--
David Seppi
1220 Wien

[David Seppi]

Marc Haber schrieb:

> Ich meinte natürlich die Verfahren mit signifikanter Verbreitung, die
> auch mit freien Betriebssystemen nutzbar sind.

Tangeneratoren sowohl mit als auch ohne Chipkartenleser sind gar nicht
so selten (und als Standalone-Geräte betriebssystem-unabhängig).

[Franklin Schiftan]

Marc Haber schrieb am 01.10.2016 um 14:05 Uhr:

> Franklin Schiftan <fraschi...@arcor.de> wrote:
>>So kannte ich das übrigens von meinem früheren Arbeitgeber auch.
>
> Das macht es nicht richtiger.

Ich fand es nachvollziehbar und voll in Ordnung.

Wie würde Deine Lösung aussehen?

[Ulrich Maier]

Am 01.10.2016 um 14:05 schrieb Marc Haber:

>> So kannte ich das übrigens von meinem früheren Arbeitgeber auch.
>
> Das macht es nicht richtiger.

Dann lass uns doch einmal wissen, was Du daran für falsch hältst,
verschlüsselte, also auch nicht überprüfbare Dateien zu blockieren?

Ulrich

[Ulrich Maier]

Am 01.10.2016 um 14:13 schrieb Juergen Ilse:

> Ich gebe zu, mich mit dem TAN-Verfahren nicht allzu ausfuehrlich befasst
> zu haben. Benoetigt man zusaetzlich zur gueltigen TAN noch eine separate
> PIN?

Bei allen Verfahren, die ich kenne, benötigt man (nur) eine PIN -
entweder, um sich beim Bankkono einzuloggen (danach kann die Karte ohne
PIN genutzt werden), oder - am Bankautomaten - zur Nutzung des Automaten.

Ulrich

[Ulrich Maier]

Am 01.10.2016 um 14:03 schrieb Juergen Ilse:

> Wer die PIN aufschreibt, so dass sie geklaut werden kann, macht da gewaltig
> etwas falsch ...

Es ist auch ziemlich aufwendig! Man kann den Block auch einscannen und
dann verschlüsselt ablegen. Das ist sicherer als das Papier irgendwo
abzulegen (aber für DAUs kaum eine Lösung).

Ulrich

[Juergen Ilse]

Hallo,

Bei Onlinebanking mit Chipkarte muss man fuer die Nutzung der Karte jedes-
mal die PIN eingeben. Wenn ich dieaktualisierten Daten abrufe einmal, wenn
ich dann eine Ueberweisung fertig mache und die uebermittle nochmals.

[Ulrich Maier]

Am 01.10.2016 um 16:14 schrieb Juergen Ilse:

> Ulrich Maier <inv...@invalid.invalid> wrote:

>>> Ich gebe zu, mich mit dem TAN-Verfahren nicht allzu ausfuehrlich befasst
>>> zu haben. Benoetigt man zusaetzlich zur gueltigen TAN noch eine separate
>>> PIN?
>> Bei allen Verfahren, die ich kenne, benötigt man (nur) eine PIN -

Stimmt nicht ganz, s. unten.

>> entweder, um sich beim Bankkono einzuloggen (danach kann die Karte ohne
>> PIN genutzt werden), oder - am Bankautomaten - zur Nutzung des Automaten.
>
> Bei Onlinebanking mit Chipkarte muss man fuer die Nutzung der Karte jedes-
> mal die PIN eingeben.

Beim Online-Banking über das Internetportal der Bank wird die PIN einmal
beim Log-in abgefragt, und dann nicht mehr. (Zumindest bei den drei
Banken, mit denen ich arbeite: DB, Comdirekt, SSKM.)

Mit Starmoney (Business) in Verbindung mit einer HCBI-Karte wird die PIN
zu Beginn einer Transaktion (Auftragsstapel, Eingabe am Kartenleser)
abgefragt, also ggf. mehrfach.

Ulrich

[Ralph Angenendt]

Well, Marc Haber <mh+usene...@zugschl.us> wrote:
> Nein, das siehst Du völlig richtig. Das Passwort oder - besser - die
> (i)TAN-Liste sind nach wie vor das sicherste Verfahren gegen
> technische Angriffe.

iTAN ist Dreck, weil man das nicht ohne Sicherheitsrisiko in den Urlaub
mitnehmen kann.

Ralph
--
His goal in life was to be an echo

[Andreas M. Kirchwitz]

Andreas Kohlbach <octmanp20...@spamgourmet.net> wrote:

>> Ich bekomme von meiner Bank noch immer Kontoauszuege zugesandt, sofern
>> ich sie mir nicht vorher schon mal vom Kontoauszugsdrucker in der Bank-
>> filiale habe ausdrucken lassen, und den taeglichen Ueberblick koennte
>> ich mir per FinTS 3.0 Online-Banking verschaffen (was ich auch tue,
>> wenn auch nicht taeglich).
>

> Stellt die Bank die Zusendung nicht in Rechnung?

Wenn die Bank von sich aus meint, innerhalb einer Frist nicht
abgeholte/abgerufene Kontoauszüge dem Kunden per Post zwecks
Kenntnisnahme zuzuschicken, so darf dies nicht in Rechnung
gestellt werden, anderslautende Vereinbarungen sind ungültig.

So kommt man indirekt an kostenlose Kontoauszüge zu Hause.

Die Bank dürfte das allerdings sehr wohl in Rechnung stellen,
wenn die Zusendung per Post der primäre Zustellungsweg wäre.

Eine ziemlich absurde Konstellation.

Es gibt andererseits Banken, die sind nicht der Meinung,
dass ihre Kunden von irgendwas Kenntnis nehmen müssten.
Wenn der Kunde das Zeug nicht abholt, ist's eben sein
Problem, wenn er Missbrauch nicht rechtzeitig erkennt.
Dann ist sein Geld halt futsch.

Grüße, Andreas

[Andreas M. Kirchwitz]

Ralph Angenendt <dein...@strg-alt-entf.org> wrote:

>> Nein, das siehst Du völlig richtig. Das Passwort oder - besser - die
>> (i)TAN-Liste sind nach wie vor das sicherste Verfahren gegen
>> technische Angriffe.
>
> iTAN ist Dreck, weil man das nicht ohne Sicherheitsrisiko in den Urlaub
> mitnehmen kann.

Man macht vom (i)TAN-Zettel einfach ein Foto, und das kann man sicher
speichern, je nach persönlicher Paranoia kann man das nach Belieben
verschlüsseln, mit Passwörtern absichern usw.

Kartenleser oder TAN-Generatoren auf Reisen machen keinen Spaß.
SMS im Ausland ist nicht immer zuverlässig (zeitnah), außerdem
nervt der SIM-Karten-Wechsel, falls man eine lokale verwendet.
Auch blöd, falls das Handy kaputt geht und TAN-Apps an das
spezielle Gerät gebunden waren.

Natürlich hat jeder Kunde andere Anforderungen. Es gibt zum Glück
noch Banken, die ihren Kunden verschiedene Verfahren zur Auswahl
stellen, zwischen denen man auch später wechseln darf, falls man
mit der initialen Wahl unglücklich ist.

Von allen bisher getesteten Verfahren ist mein persönlicher Favorit
immer noch die iTAN. Unerreichte Flexibilität und Unabhängigkeit.

Lang möge sie leben, die iTAN ... Andreas

[Marc Haber]

Es verhindert die dringend notwendige Durchsetzung von
Ende-zu-Ende-Verschlüsselung im Mailverkehr.

[Ulrich Maier]

Am 02.10.2016 um 14:59 schrieb Marc Haber:
> Ulrich Maier <inv...@invalid.invalid> wrote:
>> Am 01.10.2016 um 14:05 schrieb Marc Haber:
>>>> So kannte ich das übrigens von meinem früheren Arbeitgeber auch.
>>>
>>> Das macht es nicht richtiger.
>>
>> Dann lass uns doch einmal wissen, was Du daran für falsch hältst,
>> verschlüsselte, also auch nicht überprüfbare Dateien zu blockieren?
>
> Es verhindert die dringend notwendige Durchsetzung von
> Ende-zu-Ende-Verschlüsselung im Mailverkehr.

Andererseits eröffnet Verschlüsselung den Weg für die Einschleusung von
ungeprüfter Software (ggf. auch als Word-/Excel-Makros). Solange
Ende-zu-Ende-Verschlüsselung praktisch nicht existiert, ist die
Gefahrenabwehr sicher wichtiger.

(Das hindert nicht daran, einzelne verschlüsselte Kommunikationen
freizuschalten.)

Ulrich

[Marc Haber]

Ulrich Maier <inv...@invalid.invalid> wrote:
>Am 02.10.2016 um 14:59 schrieb Marc Haber:
>> Ulrich Maier <inv...@invalid.invalid> wrote:
>>> Am 01.10.2016 um 14:05 schrieb Marc Haber:
>>>>> So kannte ich das übrigens von meinem früheren Arbeitgeber auch.
>>>>
>>>> Das macht es nicht richtiger.
>>>
>>> Dann lass uns doch einmal wissen, was Du daran für falsch hältst,
>>> verschlüsselte, also auch nicht überprüfbare Dateien zu blockieren?
>>
>> Es verhindert die dringend notwendige Durchsetzung von
>> Ende-zu-Ende-Verschlüsselung im Mailverkehr.
>
>Andererseits eröffnet Verschlüsselung den Weg für die Einschleusung von
>ungeprüfter Software (ggf. auch als Word-/Excel-Makros). Solange
>Ende-zu-Ende-Verschlüsselung praktisch nicht existiert, ist die
>Gefahrenabwehr sicher wichtiger.

Sinnvolle Gefahrenabwehr sieht anders aus. Es ist unser größtes
Problem, dass wir bis heute keine brauchbare Methode zum Schutz der
Endsysteme haben.

>(Das hindert nicht daran, einzelne verschlüsselte Kommunikationen
>freizuschalten.)

Das Aufstellen weiterer brennender Reifen auf dem Weg zur
Ende-zu-Ende-Verschlüsselung wird die Verbreitung der auf die Dauer
lebenswichtigen Veschlüsselung sicher erleichtern.


Nicht.

[Ulrich Maier]

Am 02.10.2016 um 16:05 schrieb Marc Haber:

>>>>> Das macht es nicht richtiger.
>>>>
>>>> Dann lass uns doch einmal wissen, was Du daran für falsch hältst,
>>>> verschlüsselte, also auch nicht überprüfbare Dateien zu blockieren?
>>>
>>> Es verhindert die dringend notwendige Durchsetzung von
>>> Ende-zu-Ende-Verschlüsselung im Mailverkehr.
>>
>> Andererseits eröffnet Verschlüsselung den Weg für die Einschleusung von
>> ungeprüfter Software (ggf. auch als Word-/Excel-Makros). Solange
>> Ende-zu-Ende-Verschlüsselung praktisch nicht existiert, ist die
>> Gefahrenabwehr sicher wichtiger.
>
> Sinnvolle Gefahrenabwehr sieht anders aus. Es ist unser größtes
> Problem,

Das wird nicht jeder so sehen.

> dass wir bis heute keine brauchbare Methode zum Schutz der Endsysteme haben.

Eben.

>> (Das hindert nicht daran, einzelne verschlüsselte Kommunikationen
>> freizuschalten.)
>
> Das Aufstellen weiterer brennender Reifen auf dem Weg zur
> Ende-zu-Ende-Verschlüsselung wird die Verbreitung der auf die Dauer
> lebenswichtigen Veschlüsselung sicher erleichtern.

Ein Unternehmer wird allerdings kaum auf Sicherheitsmaßnahmen
verzichten, um dadurch ein Zeichen für die Ende-zu-Ende-Verschlüsselung
zu setzen! Er würde dadurch auch nichts erreichen, außer sich einem
vermeidbaren Risiko auszusetzen.

Ulrich

[Marc Haber]

Ulrich Maier <inv...@invalid.invalid> wrote:
>Ein Unternehmer wird allerdings kaum auf Sicherheitsmaßnahmen
>verzichten, um dadurch ein Zeichen für die Ende-zu-Ende-Verschlüsselung
>zu setzen! Er würde dadurch auch nichts erreichen, außer sich einem
>vermeidbaren Risiko auszusetzen.

Ja, Risikoschutz war immer schon eine einfache Ausrede, um mit
übertriebenen Maßnahmen das Kind mit dem Bade auszuschütten.

[Ulrich Maier]

Am 03.10.2016 um 11:57 schrieb Marc Haber:

>> Ein Unternehmer wird allerdings kaum auf Sicherheitsmaßnahmen
>> verzichten, um dadurch ein Zeichen für die Ende-zu-Ende-Verschlüsselung
>> zu setzen! Er würde dadurch auch nichts erreichen, außer sich einem
>> vermeidbaren Risiko auszusetzen.
>
> Ja, Risikoschutz war immer schon eine einfache Ausrede, um mit
> übertriebenen Maßnahmen das Kind mit dem Bade auszuschütten.

Du hältst es also für übertrieben, wenn Unternehmen sicherstellen
wollen, dass nur geprüfte Dateien auf Unternehmensrechner gelangen.
Interessant!

Ulrich

[Stefan Reuther]

Diese Fragestellung scheitert im Normalfall schon daran, dass niemand
genau definieren kann, nach welchen Kriterien diese Prüfung erfolgen
soll. Das sind alles Heuristiken. Tipp: Eine Heuristik heißt deswegen
Heuristik, weil sie grundsätzlich Fehler macht. Sonst hieße sie Algorithmus.

Und die false-positive-Raten der üblichen Prüfer sind halt einfach mal
lächerlich schlecht.

Der Mailserver vom Kunden schneidet S-MIME-Zertifikate weg ("aus
Sicherheitsgründen"), was das Bootstrappen von Verschlüsselung
erschwert. Unser Mailserver verschlüsselt eingehende Anhänge ("aus
Sicherheitsgründen"), man möge sich für die Dekodierung an die Admins
wenden (die, die einem bei jeder Gelegenheit klarmachen, was für ein
Störfaktor man als Nutzer ist), was sinnvolle Dateiübertragung quasi
unmöglich macht.

Die paar Malware-Dateien, die der Scanner schon gefunden hat, hätte ich
zehn Meilen gegen den Wind auch erkannt.


Stefan

[Ulrich Maier]

Am 03.10.2016 um 13:03 schrieb Stefan Reuther:

>>>> Ein Unternehmer wird allerdings kaum auf Sicherheitsmaßnahmen
>>>> verzichten, um dadurch ein Zeichen für die Ende-zu-Ende-Verschlüsselung
>>>> zu setzen! Er würde dadurch auch nichts erreichen, außer sich einem
>>>> vermeidbaren Risiko auszusetzen.
>>>
>>> Ja, Risikoschutz war immer schon eine einfache Ausrede, um mit
>>> übertriebenen Maßnahmen das Kind mit dem Bade auszuschütten.
>>
>> Du hältst es also für übertrieben, wenn Unternehmen sicherstellen
>> wollen, dass nur geprüfte Dateien auf Unternehmensrechner gelangen.
>> Interessant!
>
> Diese Fragestellung scheitert im Normalfall schon daran, dass niemand
> genau definieren kann, nach welchen Kriterien diese Prüfung erfolgen

> soll. Das sind alles Heuristiken...

Die Policy könnte deswegen natürlich auch besagen: Keine Dateien mit
ausführbarem Code (von der exe bis zum Macro). Der normale Mitarbeiter
braucht regelmäßig nichts davon. Überprüfen lässt sich das nur bei
unverschlüsselten Anhängen.

Wer ausführbare Dateien berechtigterweise erhalten soll, leitet die dann
über bestimmte Mitarbeiter (ein durchaus gängiges Verfahren). Die
Kontrolle schränkt das Versenden ausführbarer Programme "mal so eben"
wirksam ein.

Eine Lösung kann so aussehen, das die Ver- und Entschlüsselung vom
Mailserver (bzw. einer in dessen Nähe laufender Anwendung) miterledigt
wird. Solche Lösungen gibt es. Aber es funktioniert nur mit
Kommunikatinspartnern, die mit kompatiblen Lösungen arbeiten.

Ulrich

[Marc Haber]

Ulrich Maier <inv...@invalid.invalid> wrote:
>Eine Lösung kann so aussehen, das die Ver- und Entschlüsselung vom
>Mailserver (bzw. einer in dessen Nähe laufender Anwendung) miterledigt
>wird. Solche Lösungen gibt es. Aber es funktioniert nur mit
>Kommunikatinspartnern, die mit kompatiblen Lösungen arbeiten.

Das ist dann halt keine Ende-zu-Ende-Verschlüsselung und schon lange
mal keine irgendwie verlässliche Authentifikation. Solche "Lösungen"
haben nicht selten schon zu digital signiert übersandter Malware
geführt.

[Ulrich Maier]

Am 03.10.2016 um 17:01 schrieb Marc Haber:
> Ulrich Maier <inv...@invalid.invalid> wrote:
>> Eine Lösung kann so aussehen, das die Ver- und Entschlüsselung vom
>> Mailserver (bzw. einer in dessen Nähe laufender Anwendung) miterledigt
>> wird. Solche Lösungen gibt es. Aber es funktioniert nur mit
>> Kommunikatinspartnern, die mit kompatiblen Lösungen arbeiten.
>
> Das ist dann halt keine Ende-zu-Ende-Verschlüsselung und schon lange
> mal keine irgendwie verlässliche Authentifikation.

Wieso sollen Mails innerhalb des Unternehmens verschlüsselt werden? (Von
wenigen Einzelfällen abgesehen.) Es reicht m.E. die Verbindungen (u.a.
LAN) zu verschlüsseln.

Ulrich

[Florian Weimer]

* Ulrich Maier:

> Am 03.10.2016 um 17:01 schrieb Marc Haber:
>> Ulrich Maier <inv...@invalid.invalid> wrote:
>>> Eine Lösung kann so aussehen, das die Ver- und Entschlüsselung vom
>>> Mailserver (bzw. einer in dessen Nähe laufender Anwendung) miterledigt
>>> wird. Solche Lösungen gibt es. Aber es funktioniert nur mit
>>> Kommunikatinspartnern, die mit kompatiblen Lösungen arbeiten.
>>
>> Das ist dann halt keine Ende-zu-Ende-Verschlüsselung und schon lange
>> mal keine irgendwie verlässliche Authentifikation.
>
> Wieso sollen Mails innerhalb des Unternehmens verschlüsselt werden?

Weil die Verkabelung zwischen Racks im Rechenzentrum von der
zuständigen örtlichen Behörde mitgeschnitten wird.

[Marc Haber]

d.E., ja. Ich sehe vor allen Dingen die Notwendigkeit, die privaten
Schlüssel der Mitarbeiter auf einem zentralen System zu hinterlegen,
von dort sie dann ohne Eingabe weiterer Authentifikationsdaten
automatisch verwendet werden.

[Ulrich Maier]

Welche zuständige Behörde?

Wie kommen die da ran, wenn der LAN-Verkehr zwischen den verschiedenen
Rechnern verschlüsselt ist?

Wie kommen die überhaupt an das unternehmensinterne Netz?

Ulrich

[Stefan Reuther]

Am 03.10.2016 um 15:18 schrieb Ulrich Maier:
> Am 03.10.2016 um 13:03 schrieb Stefan Reuther:
>>>> Ja, Risikoschutz war immer schon eine einfache Ausrede, um mit
>>>> übertriebenen Maßnahmen das Kind mit dem Bade auszuschütten.
>>>
>>> Du hältst es also für übertrieben, wenn Unternehmen sicherstellen
>>> wollen, dass nur geprüfte Dateien auf Unternehmensrechner gelangen.
>>> Interessant!
>>
>> Diese Fragestellung scheitert im Normalfall schon daran, dass niemand
>> genau definieren kann, nach welchen Kriterien diese Prüfung erfolgen
>> soll. Das sind alles Heuristiken...
>
> Die Policy könnte deswegen natürlich auch besagen: Keine Dateien mit
> ausführbarem Code (von der exe bis zum Macro). Der normale Mitarbeiter
> braucht regelmäßig nichts davon. Überprüfen lässt sich das nur bei
> unverschlüsselten Anhängen.

Es ist denn ausführbarer Code? *.exe? *.com? *.scr? *.pif? *.doc?
*.docm? *.htm? *.js? *.bas? *.pas? *.c? *.pl? *.dxe? *.el? *.bat? *.msg?

> Wer ausführbare Dateien berechtigterweise erhalten soll, leitet die dann
> über bestimmte Mitarbeiter (ein durchaus gängiges Verfahren). Die
> Kontrolle schränkt das Versenden ausführbarer Programme "mal so eben"
> wirksam ein.

Mein Job ist halt das Erstellen ausführbarer Programme.

Neben der Erschwernis der Kommunikation durch gefräßige Mailprogramme
wird der unter anderem dadurch erschwert, dass Windows mit seiner
großartigen Heuristik meint, ich dürfe den Unittest eines
$zeug-Dispatchers nicht test.dispatch.zeug.exe nennen, und lässt mich
den dann nicht ausführen, auch, wenn es gesehen hat, dass diese Datei
gerade vor fünf Sekunden aus dem Linker gefallen ist (und nicht vom Netz
heruntergeladen wurde).

(Auflösung: Windows meint, vermutlich aufgrund des Namensteils 'patch',
dass dieses Programm mit Admin-Rechten ausgeführt werden müsse und das
implizite Erhalten dieser scheitert; eine "lass halt und mach" Option
gibt es nicht.)

> Eine Lösung kann so aussehen, das die Ver- und Entschlüsselung vom
> Mailserver (bzw. einer in dessen Nähe laufender Anwendung) miterledigt
> wird. Solche Lösungen gibt es. Aber es funktioniert nur mit
> Kommunikatinspartnern, die mit kompatiblen Lösungen arbeiten.

Für das Sicherheitsniveau reicht auch, zwischen Mailservern sowie
zwischen Servern und Clients TLS zu sprechen. Also genau das, was als
"Email made in Germany" vermarktet wird.


Stefan

[Ulrich Maier]

Am 04.10.2016 um 17:55 schrieb Stefan Reuther:

> Für das Sicherheitsniveau reicht auch, zwischen Mailservern ... TLS zu sprechen.

Davon sind wir aber doch wohl weit entfernt?

Ulrich

[Stefan Kanthak]

"Stefan Reuther" <stefa...@arcor.de> schrieb:

[...]

> Mein Job ist halt das Erstellen ausführbarer Programme.

Dann solltest Du lernen, wie dieser Job richtig gemacht wird!

> Neben der Erschwernis der Kommunikation durch gefräßige Mailprogramme
> wird der unter anderem dadurch erschwert, dass Windows mit seiner
> großartigen Heuristik meint, ich dürfe den Unittest eines
> $zeug-Dispatchers nicht test.dispatch.zeug.exe nennen, und lässt mich
> den dann nicht ausführen, auch, wenn es gesehen hat, dass diese Datei
> gerade vor fünf Sekunden aus dem Linker gefallen ist (und nicht vom Netz
> heruntergeladen wurde).
>
> (Auflösung: Windows meint, vermutlich aufgrund des Namensteils 'patch',
> dass dieses Programm mit Admin-Rechten ausgeführt werden müsse und das
> implizite Erhalten dieser scheitert; eine "lass halt und mach" Option
> gibt es nicht.)

Selbstverstaendlich gibt es diese Option!
Schalte die "installer dectection" der Benutzerkontensteuerung aus.

Du hast zwei Moeglichkeiten.

Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)


--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Stefan Reuther]

Am 04.10.2016 um 20:30 schrieb Stefan Kanthak:
> "Stefan Reuther" <stefa...@arcor.de> schrieb:
> [...]
>> Mein Job ist halt das Erstellen ausführbarer Programme.
>
> Dann solltest Du lernen, wie dieser Job richtig gemacht wird!

Ich höre?

(Nein, dass ich meine Unittests für das Embedded-Gerümpel in
.msi-Installer verpacke, damit ich sie per Group Policy irgendwohin
deployen kann, bevor ich sie ausführe, gehört nicht dazu.)

>> (Auflösung: Windows meint, vermutlich aufgrund des Namensteils 'patch',
>> dass dieses Programm mit Admin-Rechten ausgeführt werden müsse und das
>> implizite Erhalten dieser scheitert; eine "lass halt und mach" Option
>> gibt es nicht.)
>
> Selbstverstaendlich gibt es diese Option!
> Schalte die "installer dectection" der Benutzerkontensteuerung aus.

Braucht Adminrechte. Wenn ich die einmal hab, gibt es meines Wissens
auch die "lass halt und mach"-Option. Und dann bin ich auch nicht auf
Ticket-Agenten angewiesen, die einem bei jeder Gelegenheit klarmachen,
wie sehr man doch ihre perfekte Infrastruktur stört.


Stefan

[Stefan Kanthak]

"Stefan Reuther" <stefa...@arcor.de> schrieb:

> Am 04.10.2016 um 20:30 schrieb Stefan Kanthak:
>> "Stefan Reuther" <stefa...@arcor.de> schrieb:
>> [...]
>>> Mein Job ist halt das Erstellen ausführbarer Programme.
>>
>> Dann solltest Du lernen, wie dieser Job richtig gemacht wird!
>
> Ich höre?

Zuerst die Dokumentation des jeweiligen Betruebssystems lesen und
verstehen.

[ Bloedsinn entsorgt ]

>>> (Auflösung: Windows meint, vermutlich aufgrund des Namensteils 'patch',
>>> dass dieses Programm mit Admin-Rechten ausgeführt werden müsse und das
>>> implizite Erhalten dieser scheitert; eine "lass halt und mach" Option
>>> gibt es nicht.)
>>
>> Selbstverstaendlich gibt es diese Option!
>> Schalte die "installer dectection" der Benutzerkontensteuerung aus.
>
> Braucht Adminrechte.

Falsch. S.o.: Du bist fuer Deinen Job nicht geeignet!
Lies die Dokumentation!

[Stefan Reuther]

Am 05.10.2016 um 20:13 schrieb Stefan Kanthak:
> "Stefan Reuther" <stefa...@arcor.de> schrieb:
>>> [...]
>>>> Mein Job ist halt das Erstellen ausführbarer Programme.
>>>
>>> Dann solltest Du lernen, wie dieser Job richtig gemacht wird!
>>
>> Ich höre?
>
> Zuerst die Dokumentation des jeweiligen Betruebssystems lesen und
> verstehen.

Getan. Findet sich für meinen Job hauptsächlich auf kernel.org, qnx.com,
ghs.com, ti.com.

Und nu?

>>>> (Auflösung: Windows meint, vermutlich aufgrund des Namensteils 'patch',
>>>> dass dieses Programm mit Admin-Rechten ausgeführt werden müsse und das
>>>> implizite Erhalten dieser scheitert; eine "lass halt und mach" Option
>>>> gibt es nicht.)
>>>
>>> Selbstverstaendlich gibt es diese Option!
>>> Schalte die "installer dectection" der Benutzerkontensteuerung aus.
>>
>> Braucht Adminrechte.
>
> Falsch. S.o.: Du bist fuer Deinen Job nicht geeignet!
> Lies die Dokumentation!

Zeig doch einfach, wo man als (Domänen)User ohne Adminrechte an der
Benutzerkontensteuerung rumfummeln kann.

Wo ich das auf der Daddelkiste kann, weiß ich.


Stefan

[Stefan Kanthak]

"Stefan Reuther" <stefa...@arcor.de> schrieb:

> Am 05.10.2016 um 20:13 schrieb Stefan Kanthak:
>> "Stefan Reuther" <stefa...@arcor.de> schrieb:
>>>> [...]
>>>>> Mein Job ist halt das Erstellen ausführbarer Programme.
>>>>
>>>> Dann solltest Du lernen, wie dieser Job richtig gemacht wird!
>>>
>>> Ich höre?
>>
>> Zuerst die Dokumentation des jeweiligen Betruebssystems lesen und
>> verstehen.
>
> Getan. Findet sich für meinen Job hauptsächlich auf kernel.org, qnx.com,
> ghs.com, ti.com.
>
> Und nu?

Welcher Trottel hat hierzufred ein Problem mit (s)einem selbstgefrickelten
Programm unter Windows?
Wieso beschraenkst Du Dich nicht auf den Missbrauch der von Dir
aufgezaehlten Betruebssysteme?

>>>>> (Auflösung: Windows meint, vermutlich aufgrund des Namensteils 'patch',
>>>>> dass dieses Programm mit Admin-Rechten ausgeführt werden müsse und das
>>>>> implizite Erhalten dieser scheitert; eine "lass halt und mach" Option
>>>>> gibt es nicht.)
>>>>
>>>> Selbstverstaendlich gibt es diese Option!
>>>> Schalte die "installer dectection" der Benutzerkontensteuerung aus.
>>>
>>> Braucht Adminrechte.
>>
>> Falsch. S.o.: Du bist fuer Deinen Job nicht geeignet!
>> Lies die Dokumentation!
>
> Zeig doch einfach, wo man als (Domänen)User ohne Adminrechte an der
> Benutzerkontensteuerung rumfummeln kann.

S.o.: Du bist fuer "Mein Job ist das Erstellen ausfuehrbarer Programme"
NICHT geeignet!

man "application manifest"

> Wo ich das auf der Daddelkiste kann, weiß ich.

Ganz offensichtlich bist Du nur zum Daddeln geeignet.

[Marc Stibane]

Ulrich Maier <inv...@invalid.invalid> wrote:

> TAN-Verfahren werden dagegen für die Kommunikation mit Banken verwendet.
> Daneben gibt es auch HBCI. (Seit einigen Tagen nutze ich auch die
> photoTAN, auf jeden Fall sehr komfortabel zu nutzen, und deutlich
> bequemer, schneller und stabiler als die ChipTAN. Man kann ein codiertes
> Lesegerät verwenden (ca. 20 Euro) oder wieder eine App auf dem Handy!
> Ich habe aus den oben dargelegten Gründen in das Lesegerät investiert.)

Ist auch besser so. Gerade wurden Apps gehackt:
http://www.pcspezialist.de/blog/2016/10/20/phototan-verfahren-gehackt/

--
In a world without walls and fences,
who needs windows and gates?

[Dietz Pröpper]

Marc Stibane wrote:

> Ulrich Maier <inv...@invalid.invalid> wrote:
>
>> TAN-Verfahren werden dagegen für die Kommunikation mit Banken verwendet.
>> Daneben gibt es auch HBCI. (Seit einigen Tagen nutze ich auch die
>> photoTAN, auf jeden Fall sehr komfortabel zu nutzen, und deutlich
>> bequemer, schneller und stabiler als die ChipTAN. Man kann ein codiertes
>> Lesegerät verwenden (ca. 20 Euro) oder wieder eine App auf dem Handy!
>> Ich habe aus den oben dargelegten Gründen in das Lesegerät investiert.)
>
> Ist auch besser so. Gerade wurden Apps gehackt:
> http://www.pcspezialist.de/blog/2016/10/20/phototan-verfahren-gehackt/

Das ist aber wieder ein anderes Problem - Banking- und TAN-App auf *einem*
Gerät. Dass das fett Moppelkotze ist weiß man seit Anbeginn der Zeit.

Nur die Bankster, die haben mal wieder keinen Durchblick und bringen ihre
Kunden in Gefahr.

[Florian Weimer]

* Dietz Pröpper:

Als Kunde ist es besser, ein bekanntermaßen unsicheres System
einzusetzen, weil man dann betrügerische Transaktionen abstreiten
kann.

Bei einem bekanntermaßen sicheren Verfahren muß man dagegen den
Nachweis füheren, daß man Opfer eines Betruges wurde, was in der
Praxis regelmäßig unmöglich ist.

[Lars Gebauer]

* Florian Weimer:

> * Dietz Pröpper:
>> Marc Stibane wrote:
>>> Ulrich Maier <inv...@invalid.invalid> wrote:
>>>> TAN-Verfahren werden dagegen für die Kommunikation mit Banken verwendet.
>>>> Daneben gibt es auch HBCI. (Seit einigen Tagen nutze ich auch die
>>>> photoTAN, auf jeden Fall sehr komfortabel zu nutzen, und deutlich
>>>> bequemer, schneller und stabiler als die ChipTAN. Man kann ein codiertes
>>>> Lesegerät verwenden (ca. 20 Euro) oder wieder eine App auf dem Handy!
>>>> Ich habe aus den oben dargelegten Gründen in das Lesegerät investiert.)
>>>
>>> Ist auch besser so. Gerade wurden Apps gehackt:
>>> http://www.pcspezialist.de/blog/2016/10/20/phototan-verfahren-gehackt/
>>
>> Das ist aber wieder ein anderes Problem - Banking- und TAN-App auf *einem*
>> Gerät. Dass das fett Moppelkotze ist weiß man seit Anbeginn der Zeit.
>>
>> Nur die Bankster, die haben mal wieder keinen Durchblick und bringen ihre
>> Kunden in Gefahr.
>
> Als Kunde ist es besser, ein bekanntermaßen unsicheres System
> einzusetzen, weil man dann betrügerische Transaktionen abstreiten
> kann.

ACK Die Frage ist regelmäßig nur, wie die Haftung konkret geregelt
ist.

> Bei einem bekanntermaßen sicheren Verfahren muß man dagegen den
> Nachweis füheren, daß man Opfer eines Betruges wurde, was in der
> Praxis regelmäßig unmöglich ist.

ACK

[Dietz Pröpper]

Florian Weimer wrote:

> * Dietz Pröpper:
>
>> Marc Stibane wrote:
>>
>>> Ulrich Maier <inv...@invalid.invalid> wrote:
>>>
>>>> TAN-Verfahren werden dagegen für die Kommunikation mit Banken verwendet.
>>>> Daneben gibt es auch HBCI. (Seit einigen Tagen nutze ich auch die
>>>> photoTAN, auf jeden Fall sehr komfortabel zu nutzen, und deutlich
>>>> bequemer, schneller und stabiler als die ChipTAN. Man kann ein codiertes
>>>> Lesegerät verwenden (ca. 20 Euro) oder wieder eine App auf dem Handy!
>>>> Ich habe aus den oben dargelegten Gründen in das Lesegerät investiert.)
>>>
>>> Ist auch besser so. Gerade wurden Apps gehackt:
>>> http://www.pcspezialist.de/blog/2016/10/20/phototan-verfahren-gehackt/
>>
>> Das ist aber wieder ein anderes Problem - Banking- und TAN-App auf *einem*
>> Gerät. Dass das fett Moppelkotze ist weiß man seit Anbeginn der Zeit.
>>
>> Nur die Bankster, die haben mal wieder keinen Durchblick und bringen ihre
>> Kunden in Gefahr.
>
> Als Kunde ist es besser, ein bekanntermaßen unsicheres System
> einzusetzen, weil man dann betrügerische Transaktionen abstreiten
> kann.

Wenn man dies dann auch belegen kann.

> Bei einem bekanntermaßen sicheren Verfahren muß man dagegen den
> Nachweis füheren, daß man Opfer eines Betruges wurde, was in der
> Praxis regelmäßig unmöglich ist.

Bei einem bekanntermaßen sicheren System ist die Chance, dass man betrogen
wird wesentlich geringer.

[Andreas M. Kirchwitz]

Ulrich Maier <inv...@invalid.invalid> wrote:

> Bisher hatte ich zur Absicherung der Online-Nutzung meiner Kreditkarte
> einen "Securecode", den ich zur Bestätigung einer Online-Nutzung
> eingeben musste.
>
> Dieses Verfahren wurde nun abgelöst durch eine App (S-ID-Check) oder ein
> mTAN-Verfahren.

Der Thread ist zwar schon etwas älter, aber gestern hatte ich
einen Fall, wo die Gegenseite mit SecureCode arbeiten wollte
(was auch Jahre nach Einführung eher Ausnahme statt Regel ist).

Eingebettet in die Webseite des Fremdanbieters erschien ein
Frame mit dem Bank-Logo meiner Visakarten-Bank. Na ja, so ist
man das vom SecureCode gewohnt.

Nun sollte ich nicht mehr das alte SecureCode-Passwort eintippen,
sondern eine wertvolle iTAN von meiner Liste herausgeben.

Hmmm?!

Das widerspricht allem, was man in den letzten Jahrzehnten mühsam
gelernt hat: GIB NIEMALS EINE TAN EIN AUF FREMDEN WEBSEITEN!

Jetzt wurde mir erst bewusst, was für ein Quark das ist.

SecureCode ist das perfekte Ziel für Hacker. In einem mies
gemachten Frame mit einem pixeligen Logo meiner Bank soll ich
ohne jeden weiteren Nachweis der Echtheit meines Gegenübers
nun eine TAN preisgeben.

Wer sein Geld zur Bank bringt, kann es auch gleich wegschmeißen.
Es ist ein Wunder, dass sämtliche Banken nicht längst komplett
ausgeraubt worden sind. Die Hacker sind offenbar noch dämlicher
als die Banken.

SecureCode macht Online-Banking maximal unsicher.

Es ist einfach nur traurig :-( ... Andreas

[Heiko Rost]

Andreas M. Kirchwitz schrieb:

> Nun sollte ich nicht mehr das alte SecureCode-Passwort eintippen,
> sondern eine wertvolle iTAN von meiner Liste herausgeben.
>
> Hmmm?!
>
> Das widerspricht allem, was man in den letzten Jahrzehnten mühsam
> gelernt hat: GIB NIEMALS EINE TAN EIN AUF FREMDEN WEBSEITEN!

Freu' Dich, daß die Webseite nicht Sofortüberweisung
<https://de.wikipedia.org/wiki/Sofort%C3%BCberweisung> benutzt. Dort
mußt Du zu einer TAN zusätzlich noch die PIN eingeben.

> Jetzt wurde mir erst bewusst, was für ein Quark das ist.
>
> SecureCode ist das perfekte Ziel für Hacker. In einem mies
> gemachten Frame mit einem pixeligen Logo meiner Bank soll ich
> ohne jeden weiteren Nachweis der Echtheit meines Gegenübers
> nun eine TAN preisgeben.

Sicherheit interessiert nicht mehr. Hauptsache schnell, einfach und
DAU-kompatibel.

> Es ist einfach nur traurig :-( ... Andreas

Stimmt.

Gruß Heiko
--
Es gibt ein Auge der Seele, mit ihm allein kann man die Wahrheit sehen.
Platon

[Lars Gebauer]

* Heiko Rost:

> Freu' Dich, daß die Webseite nicht Sofortüberweisung
><https://de.wikipedia.org/wiki/Sofort%C3%BCberweisung> benutzt. Dort
> mußt Du zu einer TAN zusätzlich noch die PIN eingeben.

Nein.

> Sicherheit interessiert nicht mehr. Hauptsache schnell, einfach und
> DAU-kompatibel.

Klar. Eine Lösung, die so kompliziert ist, daß sie nur von Experten
benutzt werden kann, ist ja um Größenordnungen besser.

JFTR: Für den *Kunden* ist einzig und allein interessant, wer im Falle
des Falles haftet. Alles andere ist unnötiges Geweine.

[Heiko Rost]

Lars Gebauer schrieb:

> * Heiko Rost:
>> Freu' Dich, daß die Webseite nicht Sofortüberweisung
>><https://de.wikipedia.org/wiki/Sofort%C3%BCberweisung> benutzt. Dort
>> mußt Du zu einer TAN zusätzlich noch die PIN eingeben.
>
> Nein.

Die Schritte zwei und drei auf
<https://www.sofort.com/ger-DE/kaeufer/su/so-funktioniert-sofort-ueberweisung/>
lesen sich für mich so, daß die Daten in ein Formular auf der Webseite
der Sofort GmbH eingegeben werden. Und auch die ersten zwei Punkte der
Sicherheitserklärung unter
<https://www.sofort.com/ger-DE/kaeufer/su/so-sicher-ist-sofort-ueberweisung/>
interpretiere ich so.

>> Sicherheit interessiert nicht mehr. Hauptsache schnell, einfach und
>> DAU-kompatibel.
>
> Klar. Eine Lösung, die so kompliziert ist, daß sie nur von Experten
> benutzt werden kann, ist ja um Größenordnungen besser.

Das Ausfüllen des Formulars beim Onlinebanking meiner Sparkasse ist
nicht komplizierter als das Papierformular. Und wenn die nicht auf den
glorreichen Einfall gekommen wäre, an Stelle eine TAN auf Papier ChipTAN
oder mTAN anzubieten, wäre der Umgang mit PIN und TAN auch problemlos.

> JFTR: Für den *Kunden* ist einzig und allein interessant, wer im Falle
> des Falles haftet. Alles andere ist unnötiges Geweine.

Letztendlich zahlen alle Kunden der Bank den Schaden.

Gruß Heiko
--
Faule Engel taugen weniger als fleißige Teufel.
Emil Gött

[Juergen Ilse]

Hallo,

Lars Gebauer <lars.g...@yahoo.de> wrote:
> * Heiko Rost:

>> Sicherheit interessiert nicht mehr. Hauptsache schnell, einfach und
>> DAU-kompatibel.
> Klar. Eine Lösung, die so kompliziert ist, daß sie nur von Experten
> benutzt werden kann, ist ja um Größenordnungen besser.

Fuer Onlinebanking verwende ich FinTS 3.0 mit eienr RSA Chipkarte und
Chipkartenleser. Ich halte das hantieren mit irgendwelchen TAN-Listen
oder das hantieren mit diesem Geraet, das "Flickercodes" einliest oder
eine TAN per SMS anzufordern oder dergleichen fuer viel komplizierter
aber keineswegs sicherer als das Verfahren mit Chipkarte und Lesegeraet.

> JFTR: Für den *Kunden* ist einzig und allein interessant, wer im Falle
> des Falles haftet. Alles andere ist unnötiges Geweine.

Wenn TANs und ggfs. noch die PIN aus der Hand gegeben werden, koennte
es durchaus sein, dass die Baqnk damit bei der Haftung aussen vor ist,
da sie vorschreibt, PIN und TANs nicht aus der Hand zu geben (bzw. nur
fuer eigene Transaktionen direkt mit der Bank zu verwenden), womit der
Kunde bei Weitergabe solcher Daten gegen die Sicherheitsbestimmungen
der Bank verstossen haette (auch bei "Sofortueberweisung" oder aehnli-
chen Diensten).

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Lars Gebauer]

* Juergen Ilse:

> Lars Gebauer <lars.g...@yahoo.de> wrote:
>> JFTR: Für den *Kunden* ist einzig und allein interessant, wer im Falle
>> des Falles haftet. Alles andere ist unnötiges Geweine.
>
> Wenn TANs und ggfs. noch die PIN aus der Hand gegeben werden, koennte
> es durchaus sein, dass die Baqnk damit bei der Haftung aussen vor ist,
> da sie vorschreibt, PIN und TANs nicht aus der Hand zu geben (bzw. nur
> fuer eigene Transaktionen direkt mit der Bank zu verwenden), womit der
> Kunde bei Weitergabe solcher Daten gegen die Sicherheitsbestimmungen
> der Bank verstossen haette (auch bei "Sofortueberweisung" oder aehnli-
> chen Diensten).

Wie häufig ist das schon vorgekommen?

[Juergen Ilse]

Hallo,

Lars Gebauer <lars.g...@yahoo.de> wrote:

Das weiss ich nicht, aber ich denke, dass die Bank damit eine Argumenta-
tionsgrundlage hat, die ihr im Zweifelsfall nuetzen koennte, wenn so ein
Fall vor Gericht geht ... Fuer mich ist der notwendige Verstoss gegen die
von der Bank genannten Sicherheitsbestimmungen fuer den Umgang mit TANs
ein klares Argument *gegen* die Nutzung eines solchen Dienstes.
Abgesehen davon ist mir der Umgang mit TANs zu umstaendlich, was auch ein
Grund fuer mich ist, FinTS 3.0 mit chipkarte vorzuziehen (auch wenn die
Anschaffung des Chipkartenlesers einmalig und die Bezahlung der Chipkarte
alle paar Jahre zusaetzliche Kosten verursacht. Das duerfte das zur Zeit
sicherste Verfahren sein, da der private Key aus der Chipkarte nicht aus-
gelesen werden kann und die Karte nach 5 mal hintereinander Falscheingabe
der PIN sperrt. Allerdings ist mir die vor einigen Jahren neu hinzugefuegte
"SuperPin" zum entsprerren einer einmal gesperrten Karte ein Dorn im Auge:
Ich haette es lieber gesehen, wenn eine wegen Falscheingabe gesperrte Karte
nicht mehr reaktivierbar waere ...

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Lars Gebauer]

* Juergen Ilse:
> Lars Gebauer <lars.g...@yahoo.de> wrote:
>> * Juergen Ilse:
>>> Lars Gebauer <lars.g...@yahoo.de> wrote:
>>>> JFTR: Für den *Kunden* ist einzig und allein interessant, wer im Falle
>>>> des Falles haftet. Alles andere ist unnötiges Geweine.
>>> Wenn TANs und ggfs. noch die PIN aus der Hand gegeben werden, koennte
>>> es durchaus sein, dass die Baqnk damit bei der Haftung aussen vor ist,
>>> da sie vorschreibt, PIN und TANs nicht aus der Hand zu geben (bzw. nur
>>> fuer eigene Transaktionen direkt mit der Bank zu verwenden), womit der
>>> Kunde bei Weitergabe solcher Daten gegen die Sicherheitsbestimmungen
>>> der Bank verstossen haette (auch bei "Sofortueberweisung" oder aehnli-
>>> chen Diensten).
>> Wie häufig ist das schon vorgekommen?
>
> Das weiss ich nicht, aber ich denke, dass die Bank damit eine Argumenta-
> tionsgrundlage hat, die ihr im Zweifelsfall nuetzen koennte, wenn so ein
> Fall vor Gericht geht ... Fuer mich ist der notwendige Verstoss gegen die
> von der Bank genannten Sicherheitsbestimmungen fuer den Umgang mit TANs
> ein klares Argument *gegen* die Nutzung eines solchen Dienstes.

Hätte irgendeine der involvierten Banken irgendein Problem mit dem
Dienst "Sofortüberweisung", so könntest Du getrost davon ausgehen, daß
dessen Treiben schon längst unterbunden wäre.

Tatsächlich werden aber täglich - vermutlich - Tausende von
Transaktionen abgewickelt. Und das nicht erst seit gestern früh
sondern schon seit Jahren. Da dürften schon etliche Mio. € durch
Sofortüberweisung bewegt worden sein.

Ich gehe also einfach davon aus, daß Sofortüberweisung das Verhältnis
zu den Banken vertraglich geklärt und gesichert hat. Womit sich
allerdings das Gedankengestrüpp betreffs "AGB-Verstoß" in den Bereich
der Märchen, Sagen und Legenden verweist. Dumm gelaufen.

[Juergen Ilse]

Hallo,

Lars Gebauer <lars.g...@yahoo.de> wrote:
> * Juergen Ilse:

>> Das weiss ich nicht, aber ich denke, dass die Bank damit eine Argumenta-
>> tionsgrundlage hat, die ihr im Zweifelsfall nuetzen koennte, wenn so ein
>> Fall vor Gericht geht ... Fuer mich ist der notwendige Verstoss gegen die
>> von der Bank genannten Sicherheitsbestimmungen fuer den Umgang mit TANs
>> ein klares Argument *gegen* die Nutzung eines solchen Dienstes.
> Hätte irgendeine der involvierten Banken irgendein Problem mit dem
> Dienst "Sofortüberweisung", so könntest Du getrost davon ausgehen, daß
> dessen Treiben schon längst unterbunden wäre.

Wieso? Wenn es zu einem Schaden kommt, hat die Bank das Argument, dass der
Kunde gegen die Sicherheitsbestimmungen verstossen habe und der Kunde ggfs.
das nachsehen ... Welchen Grund sollte es fuer die Bank geben, im Vorfeld
etwas gegen eine solche Praxis zu tun: es ist schlicht nicht ihr Problem.

> Tatsächlich werden aber täglich - vermutlich - Tausende von
> Transaktionen abgewickelt. Und das nicht erst seit gestern früh
> sondern schon seit Jahren. Da dürften schon etliche Mio. € durch
> Sofortüberweisung bewegt worden sein.

Tatsache ist, dass man damit Daten in fremde Haende gibt, die man laut den
Sicherheitsempfehlungen der Bank niemals in fremde Haende geben soll. Fuer
mich ist das ein Grund, die Finger von so etwas zu lassen, denn im Zweifels-
fall besteht ein Risiko, dass im Falle von Betrug der Mist auf mich statt
auf die Bank zurueckfaellt.

> Ich gehe also einfach davon aus, daß Sofortüberweisung das Verhältnis
> zu den Banken vertraglich geklärt und gesichert hat.

Eine fromme Hoffnung. Hast du dafuer wirklich Belege oder ist das pure
Vermutung?

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Lars Gebauer]

* Juergen Ilse:

> Lars Gebauer <lars.g...@yahoo.de> wrote:
>> * Juergen Ilse:
>>> Das weiss ich nicht, aber ich denke, dass die Bank damit eine Argumenta-
>>> tionsgrundlage hat, die ihr im Zweifelsfall nuetzen koennte, wenn so ein
>>> Fall vor Gericht geht ... Fuer mich ist der notwendige Verstoss gegen die
>>> von der Bank genannten Sicherheitsbestimmungen fuer den Umgang mit TANs
>>> ein klares Argument *gegen* die Nutzung eines solchen Dienstes.
>> Hätte irgendeine der involvierten Banken irgendein Problem mit dem
>> Dienst "Sofortüberweisung", so könntest Du getrost davon ausgehen, daß
>> dessen Treiben schon längst unterbunden wäre.
>
> Wieso?

Hast Du an meiner Aussagae einen Zweifel? Bezweifelst Du, daß die
Banken mitspielen würden, wenn sie nicht wollten?

> Wenn es zu einem Schaden kommt, hat die Bank das Argument, dass der
> Kunde gegen die Sicherheitsbestimmungen verstossen habe und der Kunde ggfs.
> das nachsehen ... Welchen Grund sollte es fuer die Bank geben, im Vorfeld
> etwas gegen eine solche Praxis zu tun: es ist schlicht nicht ihr Problem.

Es ist sogar ein sehr großes Problem, wenn eine Bank über Jahre hinweg
etwas massenhaft duldet und sich dann - ganz plötzlich - quer stellen
will.

>> Ich gehe also einfach davon aus, daß Sofortüberweisung das Verhältnis
>> zu den Banken vertraglich geklärt und gesichert hat.
>
> Eine fromme Hoffnung. Hast du dafuer wirklich Belege oder ist das pure
> Vermutung?

Es ist eine simple Betrachtung der Realität. Ohne die aktive
Mitwirkung der Banken wäre es kaum möglich, einen Dienst wie
Sofortüberweisung über Jahre hinweg zu betreiben.

[Juergen Ilse]

Hallo,

Lars Gebauer <lars.g...@yahoo.de> wrote:
> * Juergen Ilse:

>> Wenn es zu einem Schaden kommt, hat die Bank das Argument, dass der
>> Kunde gegen die Sicherheitsbestimmungen verstossen habe und der Kunde ggfs.
>> das nachsehen ... Welchen Grund sollte es fuer die Bank geben, im Vorfeld
>> etwas gegen eine solche Praxis zu tun: es ist schlicht nicht ihr Problem.
> Es ist sogar ein sehr großes Problem, wenn eine Bank über Jahre hinweg
> etwas massenhaft duldet und sich dann - ganz plötzlich - quer stellen
> will.

Der Kunde muesste beweisen, dass die Bank zvom geschaedigten Kunden zweifels-
frei gewusst hat, dass er diesen Dienst entgegen ihrer Sicherheitsvorschriften
genutzt hat und dies tatsaechlich bei genau diesem Kunden so geduldet hat.
Kann er das? Sofoern er sich von der Bank nicht hat schriftlich geben lassen,
dass in diesem Fall die Weitergabe von PIN und TAN in Ordnung ist, duerfte
er das ehger nicht koennen.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Willi Marquart]

Juergen Ilse schrieb:

>Der Kunde muesste beweisen, dass die Bank zvom geschaedigten Kunden zweifels-
>frei gewusst hat, dass er diesen Dienst entgegen ihrer Sicherheitsvorschriften
>genutzt hat und dies tatsaechlich bei genau diesem Kunden so geduldet hat.
>Kann er das? Sofoern er sich von der Bank nicht hat schriftlich geben lassen,
>dass in diesem Fall die Weitergabe von PIN und TAN in Ordnung ist, duerfte
>er das ehger nicht koennen.

Manche Banken verbieten in ihren AGB die Nutzung der PIN außerhalb der
von den Banken für sicher angesehenen Verfahren. Die Nutzung der
Sofortüberweisung kann danach eine Sorgfaltspflichtverletzung sein und
gegebenenfalls negative Konsequenzen mit sich bringen. In den letzten
Jahren hat das Bundeskartellamt dieses Verbot der Weitergabe der PIN
auf seine Gültigkeit überprüft und kam 2016 zu einem Urteil: "Das Amt
bestätigte nun, dass die Klausel rechtswidrig ist."[6] Bereits nach
Einleiten des Kartellverfahrens hatten die meisten Banken ihre AGB
geändert. Einige Banken wie die Deutsche Kreditbank und die
Raiffeisenbank in Österreich empfehlen ihren Kunden bereits die
Nutzung von Sofortüberweisung.

Quelle: Wikipedia.de

Gruß Willi

[Lars Gebauer]

* Juergen Ilse:

> Lars Gebauer <lars.g...@yahoo.de> wrote:
>> * Juergen Ilse:
>>> Wenn es zu einem Schaden kommt, hat die Bank das Argument, dass der
>>> Kunde gegen die Sicherheitsbestimmungen verstossen habe und der Kunde ggfs.
>>> das nachsehen ... Welchen Grund sollte es fuer die Bank geben, im Vorfeld
>>> etwas gegen eine solche Praxis zu tun: es ist schlicht nicht ihr Problem.
>> Es ist sogar ein sehr großes Problem, wenn eine Bank über Jahre hinweg
>> etwas massenhaft duldet und sich dann - ganz plötzlich - quer stellen
>> will.
>
> Der Kunde muesste beweisen, dass die Bank zvom geschaedigten Kunden zweifels-
> frei gewusst hat, dass er diesen Dienst entgegen ihrer Sicherheitsvorschriften
> genutzt hat und dies tatsaechlich bei genau diesem Kunden so geduldet hat.

Blödsinn. Die Nutzung von Sofortüberweisung.de ist eine seit Jahren
gelebte gängige Praxis. Möchtest Du das bezweifeln?

Außerdem: Wenn der Kunde etwas tut was er - nach Ansicht der Bank -
nicht tun sollte, so ist die Bank verpflichtet dieses Verhalten zu
monieren. Tut sie es nicht, so kann sich der Kunde darauf verlassen,
daß die Bank gegen sein Verhalten nichts einzuwenden hat.

Ist bei jedem Vertrag so: Wenn Du meinst daß sich Dein Vertragspartner
vertragswidrig verhält, dann *mußt* Du dieses Verhalten rügen.
Andernfalls handelt Dein Vertragspartner nämlich in gutem Glauben und
Du gehst sämtlicher Ansprüche aus der vermeintlichen Verletzung
verlustig.

> Kann er das?

Wenn jemand das Offenkundige bezweifelt, so könnte evtl.
Sofortüberweisung mit ein paar Zahlen zur Nutzung usw. aushelfen.

Aber das wird gar nicht nötig sein. Womöglich haben nämlich der
Richter, die Schöffen oder andere das Verfahren ebenfalls schon
genutzt.

> Sofoern er sich von der Bank nicht hat schriftlich geben lassen,
> dass in diesem Fall die Weitergabe von PIN und TAN in Ordnung ist, duerfte
> er das ehger nicht koennen.

Abgeshen davon: Ich habe bei Sofortüberweisung *noch nie* meine PIN
eingeben müssen.

[Juergen Ilse]

Hallo,

Dass zumindest vor diesem Urteil eine Gefahr bestand, dass die Weitergabe
von PIN und TAN zu Ungunsten des Bankkunden ausgelkegt werden koennte, ist
bereits dadurch bestaetigt, dass es ueberhaupt zu dieser Klage kam. Auch
wenn nun entschieden wurde, dass im Falle con "Sofortueberweisung" die
Weitergabe von den Banken akzeptiert werden muesse, ist fuer mich die
Notwendigkeit einer solchen Weitergabe Grund genug, einen Riesenbogen um
derartige Dienstleister zu machen. Wer haftet denn bei abfangen der PIN
und TAN bei der uebermittlung, wenn der Kunde nicht zweifelsfrei beweisen
kann, dass er diese Daten *ausschliesslich* an Sofortueberweisung ueber-
mittelt hat und wirklich an niemanden anderen? Wer haftet fuer Phishing
bzgl. der Sofortueberweisung Webseite? Welche Einhaltung von Sorgfalts-
pflichten muss im Zweifelsfall der Bankkunde nachweisen? Steht er da wirk-
lich niemals schlechter da, als wenn er diese Daten an niemanden (auch
nicht an Sofortueberweisung) weitergegeben haette?

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Willi Marquart]

Juergen Ilse schrieb:

>Dass zumindest vor diesem Urteil eine Gefahr bestand, dass die Weitergabe
>von PIN und TAN zu Ungunsten des Bankkunden ausgelkegt werden koennte, ist
>bereits dadurch bestaetigt, dass es ueberhaupt zu dieser Klage kam. Auch
>wenn nun entschieden wurde, dass im Falle con "Sofortueberweisung" die
>Weitergabe von den Banken akzeptiert werden muesse, ist fuer mich die
>Notwendigkeit einer solchen Weitergabe Grund genug, einen Riesenbogen um
>derartige Dienstleister zu machen. Wer haftet denn bei abfangen der PIN
>und TAN bei der uebermittlung, wenn der Kunde nicht zweifelsfrei beweisen
>kann, dass er diese Daten *ausschliesslich* an Sofortueberweisung ueber-
>mittelt hat und wirklich an niemanden anderen? Wer haftet fuer Phishing
>bzgl. der Sofortueberweisung Webseite? Welche Einhaltung von Sorgfalts-
>pflichten muss im Zweifelsfall der Bankkunde nachweisen? Steht er da wirk-
>lich niemals schlechter da, als wenn er diese Daten an niemanden (auch
>nicht an Sofortueberweisung) weitergegeben haette?

Ich würde Sofortüberweisung auch vermeiden, aber als Kunde bei der ING
DiBa hilft im Zweifelsfall auch diese:

Sie haben unser Wort:
Falls Dritte Ihre Zugangsdaten zum Internetbanking + Brokerage
missbrauchen, ersetzen wir Ihren finanziellen Schaden.

So funktioniert's
Informieren Sie uns sofort, wenn Sie den Schaden oder verdächtige
Kontobewegungen bemerken.
Erstatten Sie Strafanzeige bei der Polizei, wegen missbräuchlicher
Verwendung Ihrer Zugangsdaten und / oder TANs.

Gruß Willi

[Andreas M. Kirchwitz]

Willi Marquart <use...@neppi.net> wrote:

> Manche Banken verbieten in ihren AGB die Nutzung der PIN außerhalb der
> von den Banken für sicher angesehenen Verfahren. Die Nutzung der
> Sofortüberweisung kann danach eine Sorgfaltspflichtverletzung sein und
> gegebenenfalls negative Konsequenzen mit sich bringen. In den letzten
> Jahren hat das Bundeskartellamt dieses Verbot der Weitergabe der PIN
> auf seine Gültigkeit überprüft und kam 2016 zu einem Urteil: "Das Amt
> bestätigte nun, dass die Klausel rechtswidrig ist."

Für die Sicherheit der Gelder von Bankkunden ist diese Entscheidung
zwar fragwürdig, aber unterm Strich haben Banken eigentlich überhaupt
keine Chance mehr, Kunden für irgend etwas haftbar zu machen.

Sofortüberweisung, MasterCard SecureCode oder Visa Verifiy by Visa
sind von Banken (zwangsweise) geduldete oder sogar selbst eingeführte
Verfahren, wo man auf völlig fremden Webseiten PIN und/oder TAN
eingeben muss.

Für den Kunden ist inzwischen überhaupt nicht mehr unterscheidbar,
wer PIN/TAN haben darf und wer nicht. Man *muss* PIN/TAN sogar Fremden
geben, damit eine gewünschte Geldübertragung funktioniert.

Sollte ein Kunde das Opfer von Betrügern werden, gibt es kaum noch
eine Konstellation, wo Banken einen Hebel ansetzen können, sondern
sie müssen für den Schaden aufkommen. (Die meisten Urteile der letzten
Jahre bzw. Jahrzehnte gingen sowieso fast übereinstimmend in diese
Richtung, egal wie absurd dämlich sich Kunden verhalten hatten.)

Eigentlich wäre es an der Zeit, PIN und TAN abzuschaffen. Man sichert
sein Online-Banking mit einem Passwort, so wie jeden anderen Dienst
auch. Geht was schief, zahlt die Bank die Zeche. Fertig.

Die ursprüngliche Idee, Transaktionen voneinander zu trennen und
abzusichern (-> TAN) ist spätestens seit mTAN sowieso Geschichte.
Ein Angreifer kann sich heutzutage so viele TANs erzeugen, wie er
möchte (bis das Konto leer ist).

PIN/TAN sind nur noch Kundenschikane ... Andreas

[Dietz Pröpper]

Willi Marquart wrote:

> Juergen Ilse schrieb:
>
>>Dass zumindest vor diesem Urteil eine Gefahr bestand, dass die Weitergabe
>>von PIN und TAN zu Ungunsten des Bankkunden ausgelkegt werden koennte, ist
>>bereits dadurch bestaetigt, dass es ueberhaupt zu dieser Klage kam. Auch
>>wenn nun entschieden wurde, dass im Falle con "Sofortueberweisung" die
>>Weitergabe von den Banken akzeptiert werden muesse, ist fuer mich die
>>Notwendigkeit einer solchen Weitergabe Grund genug, einen Riesenbogen um
>>derartige Dienstleister zu machen. Wer haftet denn bei abfangen der PIN
>>und TAN bei der uebermittlung, wenn der Kunde nicht zweifelsfrei beweisen
>>kann, dass er diese Daten *ausschliesslich* an Sofortueberweisung ueber-
>>mittelt hat und wirklich an niemanden anderen? Wer haftet fuer Phishing
>>bzgl. der Sofortueberweisung Webseite? Welche Einhaltung von Sorgfalts-
>>pflichten muss im Zweifelsfall der Bankkunde nachweisen? Steht er da wirk-
>>lich niemals schlechter da, als wenn er diese Daten an niemanden (auch
>>nicht an Sofortueberweisung) weitergegeben haette?
>
>
> Ich würde Sofortüberweisung auch vermeiden,

Mit Chiptan sollte auch das eher unproblematisch sein.

> aber als Kunde bei der ING
> DiBa hilft im Zweifelsfall auch diese:
>
> Sie haben unser Wort:
> Falls Dritte Ihre Zugangsdaten zum Internetbanking + Brokerage
> missbrauchen, ersetzen wir Ihren finanziellen Schaden.
>
> So funktioniert's
> Informieren Sie uns sofort, wenn Sie den Schaden oder verdächtige
> Kontobewegungen bemerken.
> Erstatten Sie Strafanzeige bei der Polizei, wegen missbräuchlicher
> Verwendung Ihrer Zugangsdaten und / oder TANs.

Hmm, da würde mich das Kleingedruckte interessieren. Dort steht dann
vermutlich was über Deine Sorgfaltspflichten. Und wenn Dein Banking-Endgerät
z.B. keinen Virenscanner sein Eigen nennt, dann könnte dies schon als
Fahrlässigkeit Deinerseits gewertet werden.

"Sie haben unser Wort" hört sich gut an, dürfte aber gerichtlich nur schwer
verwertbar sein.

[Willi Marquart]

Dietz Pröpper schrieb:

>Willi Marquart wrote:
>
>> Sie haben unser Wort:
>> Falls Dritte Ihre Zugangsdaten zum Internetbanking + Brokerage
>> missbrauchen, ersetzen wir Ihren finanziellen Schaden.

>Hmm, da würde mich das Kleingedruckte interessieren. Dort steht dann
>vermutlich was über Deine Sorgfaltspflichten. Und wenn Dein Banking-Endgerät
>z.B. keinen Virenscanner sein Eigen nennt, dann könnte dies schon als
>Fahrlässigkeit Deinerseits gewertet werden.
>
>"Sie haben unser Wort" hört sich gut an, dürfte aber gerichtlich nur schwer
>verwertbar sein.

Ich würde mich auch eher auf den folgenden Satz berufen:

>> Falls Dritte Ihre Zugangsdaten zum Internetbanking + Brokerage
>> missbrauchen, ersetzen wir Ihren finanziellen Schaden.

Das wird sich durch Kleingedrucktes nicht so leicht außer Kraft setzen
lassen.

Bisher konnte ich das Versprechen nur einmal testen, vor ca. 2 Jahren
wurde mein Konto per VISA aus Shenzhen belastet. Anzeige erstatten ist
zwar umständlich, aber mehr hatte ich nicht zu tun und nach ein paar
Tagen war das Geld wieder auf dem Konto.

Gruß Willi

[Marc Haber]

Lars Gebauer <lars.g...@yahoo.de> wrote:
>Hätte irgendeine der involvierten Banken irgendein Problem mit dem
>Dienst "Sofortüberweisung", so könntest Du getrost davon ausgehen, daß
>dessen Treiben schon längst unterbunden wäre.
>
>Tatsächlich werden aber täglich - vermutlich - Tausende von
>Transaktionen abgewickelt. Und das nicht erst seit gestern früh
>sondern schon seit Jahren. Da dürften schon etliche Mio. € durch
>Sofortüberweisung bewegt worden sein.
>
>Ich gehe also einfach davon aus, daß Sofortüberweisung das Verhältnis
>zu den Banken vertraglich geklärt und gesichert hat. Womit sich
>allerdings das Gedankengestrüpp betreffs "AGB-Verstoß" in den Bereich
>der Märchen, Sagen und Legenden verweist. Dumm gelaufen.

Als ich vor ein paar Jahren bei meinen Banken diesbezüglich queruliert
habe, kam unisono zurück "die Nutzung von Sofortüberweisung ist in der
Tat ein Verstoß gegen unsere AGB, machen Sie das nicht".

Meine Rückfrage, warum man das nicht technisch unterbindet, wurde von
einer Bank beantwortet ("können wir aus technischen Gründen nicht",
eine klassische Nebelkerze) und von den anderen Banken ignoriert.

Die DKB sagt inzwischen offiziell "Sofortüberweisung ist Ok".
https://www.dkb.de/kundenservice/haeufige_fragen/zahlungsauftraege/035_sofort%C3%BCberweisung.html

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Lars Gebauer]

* Marc Haber:

> Lars Gebauer <lars.g...@yahoo.de> wrote:
>>Ich gehe also einfach davon aus, daß Sofortüberweisung das Verhältnis
>>zu den Banken vertraglich geklärt und gesichert hat. Womit sich
>>allerdings das Gedankengestrüpp betreffs "AGB-Verstoß" in den Bereich
>>der Märchen, Sagen und Legenden verweist. Dumm gelaufen.
>
> Als ich vor ein paar Jahren bei meinen Banken diesbezüglich queruliert
> habe, kam unisono zurück "die Nutzung von Sofortüberweisung ist in der
> Tat ein Verstoß gegen unsere AGB, machen Sie das nicht".

Klar. Da war's halt "neu" und die mußten sich erstmal was ausdenken.

Ich müßte nachschauen, wie viele Jahre es her ist daß ich das zum 1.
Mal benutzt habe. Aber irgendeine Rückfrage/Nachfrage/Verwarnung
seitens meiner Bank kam da nie. Gut, ich habe auch nie gefragt.

> Meine Rückfrage, warum man das nicht technisch unterbindet, wurde von
> einer Bank beantwortet ("können wir aus technischen Gründen nicht",
> eine klassische Nebelkerze) und von den anderen Banken ignoriert.

Die Banken (manche Banken) woll(t)en ja immer gerne eigene Lösungen
etablieren, sind aber damit nie aus dem Knick gekommen.

> Die DKB sagt inzwischen offiziell "Sofortüberweisung ist Ok".

Eben, geht ja auch nicht mehr zu ignorieren.

Bei diesen Zahlungsdienstleistern gewinnt der, der die meisten Händler
hat.

Wie heißt dieses (neue?) Pendant zu PayPal? - Ist egal. Ist tot, bevor
es aus dem Startloch kommt.

[Marc Haber]

Lars Gebauer <lars.g...@yahoo.de> wrote:
>* Marc Haber:
>> Lars Gebauer <lars.g...@yahoo.de> wrote:
>>>Ich gehe also einfach davon aus, daß Sofortüberweisung das Verhältnis
>>>zu den Banken vertraglich geklärt und gesichert hat. Womit sich
>>>allerdings das Gedankengestrüpp betreffs "AGB-Verstoß" in den Bereich
>>>der Märchen, Sagen und Legenden verweist. Dumm gelaufen.
>>
>> Als ich vor ein paar Jahren bei meinen Banken diesbezüglich queruliert
>> habe, kam unisono zurück "die Nutzung von Sofortüberweisung ist in der
>> Tat ein Verstoß gegen unsere AGB, machen Sie das nicht".
>
>Klar. Da war's halt "neu" und die mußten sich erstmal was ausdenken.

Nein, da war Sofortüberweisung schon jahrelang am Markt.

>> Meine Rückfrage, warum man das nicht technisch unterbindet, wurde von
>> einer Bank beantwortet ("können wir aus technischen Gründen nicht",
>> eine klassische Nebelkerze) und von den anderen Banken ignoriert.
>
>Die Banken (manche Banken) woll(t)en ja immer gerne eigene Lösungen
>etablieren, sind aber damit nie aus dem Knick gekommen.

Wenn sie das wirklich hätten etablieren wollen, hätten sie ja ganz
einfach technische Maßnahmen gegen Sofortüberweisung ergriffen.

[Thomas Einzel]

Am 02.12.2016 um 13:58 schrieb Lars Gebauer:
...

> Es ist eine simple Betrachtung der Realität. Ohne die aktive
> Mitwirkung der Banken wäre es kaum möglich, einen Dienst wie
> Sofortüberweisung über Jahre hinweg zu betreiben.

Na Klasse.

https://de.wikipedia.org/wiki/Sofort%C3%BCberweisung#Kritik
und da die Fußnote [6]

"Bundeskartellamt...bestätigte ...ungerechtfertigter
Wettbewerbsbeschränkung... AGB-Klausel... rechtswidrig" (bitte selber
lesen).
Soweit zur Mitwirkung der Banken. Wer Zweifelsfall tatsächlich auf einem
Schaden sitzen bliebt ist vermutlich einfach der mit dem kürzeren Atem
vor Gericht, oder? Klar hat da jeder Verbraucher einen besseren
Ausgangspunkt als irgendeine kleine Firma mit Banklizenz...

--
Thomas

Ironietags sind kostenlos an der Abendkasse erhältlich.

[Lars Gebauer]

* Thomas Einzel:

> Am 02.12.2016 um 13:58 schrieb Lars Gebauer:
>> Es ist eine simple Betrachtung der Realität. Ohne die aktive
>> Mitwirkung der Banken wäre es kaum möglich, einen Dienst wie
>> Sofortüberweisung über Jahre hinweg zu betreiben.
>
> Na Klasse.

Allerdings.

> Soweit zur Mitwirkung der Banken. Wer Zweifelsfall tatsächlich auf einem
> Schaden sitzen bliebt ist vermutlich einfach der mit dem kürzeren Atem
> vor Gericht, oder?

Na fragen wir doch einfach mal, wie oft dieser Fall bereits
eingetreten ist?

Und wie gesagt: Betrachten wir die Realität. Nicht das, was eventuell,
vielleicht, hätte, sein können, ... und vergleichbares Voodoo.

> Klar hat da jeder Verbraucher einen besseren
> Ausgangspunkt als irgendeine kleine Firma mit Banklizenz...

Ja, in Anbetracht dessen, daß Gerichte eher dazu neigen,
verbraucherfreundliche Urteile zu fällen, ...

[Rupert Haselbeck]

Thomas Einzel schrieb:

> Soweit zur Mitwirkung der Banken. Wer Zweifelsfall tatsächlich auf einem
> Schaden sitzen bliebt ist vermutlich einfach der mit dem kürzeren Atem
> vor Gericht, oder? Klar hat da jeder Verbraucher einen besseren
> Ausgangspunkt als irgendeine kleine Firma mit Banklizenz...

Abgesehen von der mittlerweile wohl recht klaren Rechtslage, wonach Banken
die Nutzung von "Sofortüberweisung" und ähnlichen Diensten nicht behindern
dürfen, (und der Versuch, den Kunden bei einem Schaden dafür haftbar zu
machen, ist wohl der grösstmögliche Versuch einer Behinderung), verspricht
die Sofort GmbH dem Nutzer die Übernahme aller Schäden, welche durch die
Eingabe von PIN und TAN auf der sofort-Webseite entstehen könnten.
Das ist ganz öffentlich nachzulesen auf deren Webseiten.
Die mehr oder (meist eher...) minder sinnigen Versuche der Klärung der
Rechtslage in den Artikeln hier sind eher wenig zielführend

MfG
Rupert

[Thomas Einzel]

Am 03.12.2016 um 09:24 schrieb Lars Gebauer:
...

> Na fragen wir doch einfach mal, wie oft dieser Fall bereits
> eingetreten ist?
>
> Und wie gesagt: Betrachten wir die Realität. Nicht das, was eventuell,
> vielleicht, hätte, sein können, ... und vergleichbares Voodoo.

Hast du ein Fahrzeug mit Sicherheitsgurten und/oder Airbags? Wie oft
schon benötigt?

Unabhängig davon: Allein die PIN von Konten weiter zu geben ist für mich
ein No.
--
Thomas

[Lars Gebauer]

* Thomas Einzel:

> Am 03.12.2016 um 09:24 schrieb Lars Gebauer:
>> Na fragen wir doch einfach mal, wie oft dieser Fall bereits
>> eingetreten ist?
>>
>> Und wie gesagt: Betrachten wir die Realität. Nicht das, was eventuell,
>> vielleicht, hätte, sein können, ... und vergleichbares Voodoo.
>
> Hast du ein Fahrzeug mit Sicherheitsgurten und/oder Airbags? Wie oft
> schon benötigt?

Gehst Du nur mit Helm auf die Straße? Wegen herabstürzenden
Dachziegeln? Wie oft schon benötigt?

Wie schon gesagt: Betrachten wir die Realität.

> Unabhängig davon: Allein die PIN von Konten weiter zu geben ist für mich
> ein No.

Unabhängig davon: Sofortüberweisung.de hat mich noch nie nach meiner
PIN gefragt.

[Andreas M. Kirchwitz]

Lars Gebauer <lars.g...@yahoo.de> wrote:

>> Unabhängig davon: Allein die PIN von Konten weiter zu geben ist für mich
>> ein No.
>
> Unabhängig davon: Sofortüberweisung.de hat mich noch nie nach meiner
> PIN gefragt.

Sofortüberweisung benötigt die Zugangsdaten fürs Online-Banking,
die man historisch PIN nennt, aber inzwischen gibt es verschiedene
Verfahren dafür.

Inzwischen hat das Bundeskartellamt bekanntlich entschieden, dass
Banken den Kunden nicht verbieten dürfen, PIN/TAN an Dienstleister
ihres Vertrauens weiterzugeben.

Nach einem jüngsten Urteil ist Sofortüberweisung sogar ein
gängiger Bezahldienst und darf von Händlern als einzig kostenlose
Bezahlmethode angeboten werden. :-(

Sofortüberweisung hat unbeschränkten Zugang zum Online-Banking,
"sieht" dort alles, nicht nur die aktuellen Vermögensverhältnisse
(das geht ja weit übers Girokonto hinaus), sondern auch sämtliche
Transaktionen über Monate zurück (man denke auch an sensible
Zahlungen wie Arztrechnungen). Was Sofortüberweisung sich davon
greift, was es wie verarbeitet und was es bei sich speichert,
das weiß niemand. Was Sofortüberweisung diesbezüglich behauptet,
ist rein gar nichts wert, dann nachprüfen kann man es nicht.

Grüße, Andreas

[Heiko Rost]

Lars Gebauer schrieb:

> Unabhängig davon: Sofortüberweisung.de hat mich noch nie nach meiner
> PIN gefragt.

Redest Du vielleicht von einem anderen Anbieter?

Ich meine die SOFORT GmbH <https://www.sofort.com/> und deren Angebot
SOFORT Überweisung. Auf der Webseite und in der Demoanwendung unter
<https://www.sofort.com/payment/payment/go/select_transport?SOFUEB=njsvnelht2cp1e7850vb256lt5>
(von der Startseite "So Funktionierts" - "Jetzt Demo starten") ist von
der Online-Banking PIN die Rede. Und die Daten, die man dort eingibt,
gehen zuerst an die SOFORT GmbH, die das dann an die Bank weiterleitet.

Gruß Heiko
--
Der Mensch ist gut, nur die Nerven sind schlecht.
Mose Ya'aqob Ben-Gavriêl

[Lars Gebauer]

* Andreas M. Kirchwitz:

> Lars Gebauer <lars.g...@yahoo.de> wrote:
>>> Unabhängig davon: Allein die PIN von Konten weiter zu geben ist für mich
>>> ein No.
>>
>> Unabhängig davon: Sofortüberweisung.de hat mich noch nie nach meiner
>> PIN gefragt.
>
> Sofortüberweisung benötigt die Zugangsdaten fürs Online-Banking,
> die man historisch PIN nennt, aber inzwischen gibt es verschiedene
> Verfahren dafür.

Die PIN ist für mich die Zahl, die ich bspw. am Geldautomaten eingeben
muß.

> Nach einem jüngsten Urteil ist Sofortüberweisung sogar ein
> gängiger Bezahldienst und darf von Händlern als einzig kostenlose
> Bezahlmethode angeboten werden. :-(

Was ich ziemlich gut finde. Schnell, unkompliziert, ... Für Händler
wie auch Kunden.

> Sofortüberweisung hat unbeschränkten Zugang zum Online-Banking,

Zur Erinnerung für die, die das stört: Wirklich niemand ist gezwungen,
Sofortüberweisung.de zu benutzen. Wirklich *niemand*.

[Lars Gebauer]

* Heiko Rost:

> Lars Gebauer schrieb:
>> Unabhängig davon: Sofortüberweisung.de hat mich noch nie nach meiner
>> PIN gefragt.
>
> Redest Du vielleicht von einem anderen Anbieter?

Nein. Der Vollständigkeit halber: Die PIN ist für mich die Zahl, die
ich bspw. am Geldautomaten eingeben muß. Oder beim Zahlen mit dieser
Karte am Terminal des Händlers.

[Michael Limburg]

Thomas Einzel wrote:

Hallo

> Unabhängig davon: Allein die PIN von Konten weiter zu geben ist für mich
> ein No.

Bei jeder Kartenzahlung mit PIN beim Einkaufen oder Tanken gibst Du
die Daten ebenso weiter. Schlimmer noch, Du tippst die PIN im Gegensatz
zu Deiner Tastatur und PC in ein Gerät, daß nicht mal Deiner Kontrolle
unterliegt.
Wichtig ist halt, daß in beiden Fällen der Dienstleister vertauenswürdig
(zertifiziert, unter Ausicht der entsprechenden Behörden usw.) ist.

MfG

[Heiko Rost]

Lars Gebauer schrieb:

> Nein. Der Vollständigkeit halber: Die PIN ist für mich die Zahl, die
> ich bspw. am Geldautomaten eingeben muß. Oder beim Zahlen mit dieser
> Karte am Terminal des Händlers.

Dann meinst Du also eine andere PIN. Auf der Webseite der SOFORT GmbH
ist von der Online-Banking PIN die Rede, das sind die Zugangsdaten, mit
denen man sich im Online-Banking anmeldet. Und warum es nicht unbedingt
eine gute Idee ist, die jemanden anderen mitzuteilen, hat Andreas schon
erklärt.

Gruß Heiko
--
Der Wille, gesund zu werden, ist stärker als der Wille, gesund zu bleiben.
Gerhard Kocher

[Marc Haber]

Lars Gebauer <lars.g...@yahoo.de> wrote:
>* Andreas M. Kirchwitz:
>> Lars Gebauer <lars.g...@yahoo.de> wrote:
>>>> Unabhängig davon: Allein die PIN von Konten weiter zu geben ist für mich
>>>> ein No.
>>>
>>> Unabhängig davon: Sofortüberweisung.de hat mich noch nie nach meiner
>>> PIN gefragt.
>>
>> Sofortüberweisung benötigt die Zugangsdaten fürs Online-Banking,
>> die man historisch PIN nennt, aber inzwischen gibt es verschiedene
>> Verfahren dafür.
>
>Die PIN ist für mich die Zahl, die ich bspw. am Geldautomaten eingeben
>muß.

Unabhängig davon, was Du als "PIN" bezeichnest, ist dieser Begriff
selbst dann, wenn man sich nur auf die Branche "Banken" beschränkt,
mindestens doppelt belegt.

[Heiko Rost]

Heiko 'Ingrid' Rost schrieb:

> Lars Gebauer schrieb:
>
>> Nein. Der Vollständigkeit halber: Die PIN ist für mich die Zahl, die
>> ich bspw. am Geldautomaten eingeben muß. Oder beim Zahlen mit dieser
>> Karte am Terminal des Händlers.
>
> Dann meinst Du also eine andere PIN. Auf der Webseite der SOFORT GmbH
> ist von der Online-Banking PIN die Rede, das sind die Zugangsdaten, mit
> denen man sich im Online-Banking anmeldet. Und warum es nicht unbedingt
> eine gute Idee ist, die jemanden anderen mitzuteilen, hat Andreas schon
> erklärt.

Und jetzt wird mir auch klar, wie

| Die Eingabe der Online-Banking-Zugangsdaten und TAN erfolgt
| ausschließlich im gesicherten Zahlformular der SOFORT GmbH und nicht
| beim Händler.

zu lesen ist. Ich habe schon gerätselt, bei welchem Zahlungssystem man
beim Händler eine TAN eingeben muß.

Gruß Heiko
--
Es gibt ein Auge der Seele, mit ihm allein kann man die Wahrheit sehen.
Platon

[Lars Gebauer]

* Michael Limburg:

> Thomas Einzel wrote:
>> Unabhängig davon: Allein die PIN von Konten weiter zu geben ist für mich
>> ein No.
>
> Bei jeder Kartenzahlung mit PIN beim Einkaufen oder Tanken gibst Du
> die Daten ebenso weiter. Schlimmer noch, Du tippst die PIN im Gegensatz
> zu Deiner Tastatur und PC in ein Gerät, daß nicht mal Deiner Kontrolle
> unterliegt.

Unter der (stillschweigenden) Annahme, das Tastatur und PC noch unter
Deiner Kontrolle stehen ...

> Wichtig ist halt, daß in beiden Fällen der Dienstleister vertauenswürdig
> (zertifiziert, unter Ausicht der entsprechenden Behörden usw.) ist.

Korrekt.

[Thomas Einzel]

Am 03.12.2016 um 17:49 schrieb Lars Gebauer:
> * Andreas M. Kirchwitz:
...

>> Sofortüberweisung benötigt die Zugangsdaten fürs Online-Banking,
>> die man historisch PIN nennt, aber inzwischen gibt es verschiedene
>> Verfahren dafür.
>
> Die PIN ist für mich die Zahl, die ich bspw. am Geldautomaten eingeben
> muß.

Ich sprach von "Allein die PIN von Konten weiter zu geben ist für mich
ein No" - also von Konto nicht von der EC Karte. Das war offensichtlich,
es sei den man wollte dem anderen zeigen, dass er Unrecht hat, ok, ein
Irrtum meinerseits, Entschuldigung.
--
Thomas

[Thomas Einzel]

Am 03.12.2016 um 17:56 schrieb Michael Limburg:
> Thomas Einzel wrote:
>
> Hallo
>
>> Unabhängig davon: Allein die PIN von Konten weiter zu geben ist für mich
>> ein No.
>
> Bei jeder Kartenzahlung mit PIN beim Einkaufen oder Tanken gibst Du
> die Daten ebenso weiter. Schlimmer noch, Du tippst die PIN im Gegensatz
> zu Deiner Tastatur und PC in ein Gerät, daß nicht mal Deiner Kontrolle
> unterliegt.

Interessant, ich hätte ein https Webinterface mit
Kontonummer+Passwort+TAN nicht direkt mit einem EC Terminal mit
eingesteckter EC-Karte Karte verglichen. Aber du hast Recht, EC Card
Skimming hat einen ähnlichen Angriffsvector, der allerdings ein anderer
als Kontonummer+Passwort+TAN ist.

> Wichtig ist halt, daß in beiden Fällen der Dienstleister vertauenswürdig
> (zertifiziert, unter Ausicht der entsprechenden Behörden usw.) ist.

Auch das, ja.

--
Thomas

[Andreas M. Kirchwitz]

Michael Limburg <ml...@gmx.de> wrote:

>> Unabhängig davon: Allein die PIN von Konten weiter zu geben ist für mich
>> ein No.
>
> Bei jeder Kartenzahlung mit PIN beim Einkaufen oder Tanken gibst Du
> die Daten ebenso weiter. Schlimmer noch, Du tippst die PIN im Gegensatz
> zu Deiner Tastatur und PC in ein Gerät, daß nicht mal Deiner Kontrolle
> unterliegt.

Hierbei handelt es sich um die PIN der Karte, nicht um die "PIN"
(Passwort) vom Online-Banking mit vollständigem Zugang zu den
Vermögensverhältnissen. Das ist ein gewaltiger Unterschied.

Ist natürlich nicht schön, wenn die Karte missbräuchlich verwendet
wird (manipulierte Terminals im Supermarkt & Co. sind ja heutzutage
ein alltägliches Risiko), aber so eine Karte hat Limits und dem
Ärger sind somit enge Grenzen gesetzt. Kalkuliertes Risiko.

Beim Zugang zum kompletten Online-Banking kann der Hacker erheblich
größeren Ärger verursachen.

Grüße, Andreas