Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.sci.electronics > #325468 > unrolled thread
| Started by | Helmut Schellong <rip@schellong.biz> |
|---|---|
| First post | 2022-08-25 17:28 +0200 |
| Last post | 2022-09-08 17:46 +0200 |
| Articles | 20 on this page of 170 — 30 participants |
Back to article view | Back to de.sci.electronics
iTAN vs Elektronik Helmut Schellong <rip@schellong.biz> - 2022-08-25 17:28 +0200
Re: iTAN vs Elektronik Wolfgang Martens <na3506b2013@t-online.de> - 2022-08-25 18:17 +0200
Re: iTAN vs Elektronik Helmut Schellong <rip@schellong.biz> - 2022-08-25 18:25 +0200
Re: iTAN vs Elektronik Arno Welzel <usenet@arnowelzel.de> - 2022-08-26 22:40 +0200
Re: iTAN vs Elektronik Helmut Schellong <rip@schellong.biz> - 2022-08-26 23:38 +0200
Re: iTAN vs Elektronik Arno Welzel <usenet@arnowelzel.de> - 2022-08-31 15:48 +0200
Re: iTAN vs Elektronik Helmut Schellong <rip@schellong.biz> - 2022-08-31 16:08 +0200
Re: iTAN vs Elektronik Arno Welzel <usenet@arnowelzel.de> - 2022-09-01 02:27 +0200
Re: iTAN vs Elektronik Helmut Schellong <rip@schellong.biz> - 2022-09-01 12:23 +0200
Re: iTAN vs Elektronik Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-09-01 20:40 +0200
Re: iTAN vs Elektronik Volker Bartheld <news2022@bartheld.net> - 2022-09-02 09:04 +0200
Re: iTAN vs Elektronik Volker Bartheld <news2022@bartheld.net> - 2022-09-02 09:09 +0200
Re: iTAN vs Elektronik Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2022-09-02 12:43 +0200
Re: iTAN vs Elektronik Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-09-03 00:22 +0200
Re: iTAN vs Elektronik Arno Welzel <usenet@arnowelzel.de> - 2022-09-10 17:22 +0200
Re: iTAN vs Elektronik Arno Welzel <usenet@arnowelzel.de> - 2022-09-10 17:20 +0200
Re: iTAN vs Elektronik Arno Welzel <usenet@arnowelzel.de> - 2022-09-10 17:19 +0200
Re: iTAN vs Elektronik Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2022-08-25 20:41 +0200
Re: iTAN vs Elektronik Thomas Einzel <usenet-2022@einzel.de> - 2022-08-25 22:49 +0200
Re: iTAN vs Elektronik Volker Bartheld <news2022@bartheld.net> - 2022-08-25 23:02 +0200
Re: iTAN vs Elektronik Axel Berger <Spam@Berger-Odenthal.De> - 2022-08-25 23:04 +0200
Re: iTAN vs Elektronik Thomas Einzel <usenet-2022@einzel.de> - 2022-08-26 00:09 +0200
Re: iTAN vs Elektronik Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2022-08-26 10:08 +0200
Re: iTAN vs Elektronik Helmut Schellong <rip@schellong.biz> - 2022-08-26 11:39 +0200
Re: iTAN vs Elektronik Thomas Einzel <usenet-2022@einzel.de> - 2022-08-26 14:36 +0200
Re: iTAN vs Elektronik Axel Berger <Spam@Berger-Odenthal.De> - 2022-08-26 16:49 +0200
Re: iTAN vs Elektronik Volker Bartheld <news2022@bartheld.net> - 2022-08-26 18:10 +0200
Re: iTAN vs Elektronik Martin Gerdes <martin.gerdes@gmx.de> - 2022-08-28 22:28 +0200
Re: iTAN vs Elektronik Volker Bartheld <news2022@bartheld.net> - 2022-08-29 09:03 +0200
Re: iTAN vs Elektronik Martin Gerdes <martin.gerdes@gmx.de> - 2022-08-31 01:38 +0200
Re: iTAN vs Elektronik Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2022-08-26 15:09 +0200
Re: iTAN vs Elektronik Jürgen Jänicke <post@j-jaenicke.de> - 2022-08-26 16:48 +0200
Re: iTAN vs Elektronik "Bernd W." <lesichnicht@gmx.com> - 2022-08-28 17:53 +0200
Re: iTAN vs Elektronik Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-08-30 14:57 +0200
Re: iTAN vs Elektronik Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2022-08-30 18:23 +0200
Re: iTAN vs Elektronik Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2022-08-30 19:36 +0200
Re: iTAN vs Elektronik Volker Bartheld <news2022@bartheld.net> - 2022-08-30 21:18 +0200
Re: iTAN vs Elektronik Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2022-08-30 23:38 +0200
Re: iTAN vs Elektronik Volker Bartheld <news2022@bartheld.net> - 2022-08-31 09:17 +0200
Re: iTAN vs Elektronik Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-08-31 13:16 +0200
Re: iTAN vs Elektronik Volker Bartheld <news2022@bartheld.net> - 2022-08-31 14:02 +0200
Re: iTAN vs Elektronik Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-08-31 19:31 +0200
Re: iTAN vs Elektronik Volker Bartheld <news2022@bartheld.net> - 2022-09-01 01:18 +0200
Re: iTAN vs Elektronik Arno Welzel <usenet@arnowelzel.de> - 2022-09-01 02:33 +0200
Re: iTAN vs Elektronik Hanno Foest <hurga-news2@tigress.com> - 2022-09-01 10:13 +0200
Re: iTAN vs Elektronik Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-01 10:59 +0200
Re: iTAN vs Elektronik Hanno Foest <hurga-news2@tigress.com> - 2022-09-01 11:54 +0200
Re: iTAN vs Elektronik Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-01 13:02 +0200
Re: iTAN vs Elektronik Alexander Schreiber <als@usenet.thangorodrim.de> - 2022-09-09 15:27 +0200
Re: iTAN vs Elektronik Marte Schwarz <marte.schwarz@gmx.de> - 2022-09-10 07:17 +0200
Re: iTAN vs Elektronik Juergen <schreibsklave@web.de> - 2022-09-10 12:23 +0200
Re: iTAN vs Elektronik Arno Welzel <usenet@arnowelzel.de> - 2022-09-10 17:26 +0200
Re: iTAN vs Elektronik Hanno Foest <hurga-news2@tigress.com> - 2022-09-10 23:57 +0200
Re: iTAN vs Elektronik Axel Berger <Spam@Berger-Odenthal.De> - 2022-09-11 02:21 +0200
Re: iTAN vs Elektronik Rupert Haselbeck <mein-rest-muell@gmx.de> - 2022-09-11 08:48 +0200
Re: iTAN vs Elektronik Axel Berger <Spam@Berger-Odenthal.De> - 2022-09-11 11:32 +0200
Re: iTAN vs Elektronik Helmut Schellong <rip@schellong.biz> - 2022-09-11 12:50 +0200
Re: iTAN vs Elektronik Arno Welzel <usenet@arnowelzel.de> - 2022-09-12 00:09 +0200
Re: iTAN vs Elektronik Rupert Haselbeck <mein-rest-muell@gmx.de> - 2022-09-12 08:09 +0200
Re: iTAN vs Elektronik Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-12 08:54 +0200
Re: iTAN vs Elektronik Arno Welzel <usenet@arnowelzel.de> - 2022-09-12 09:21 +0200
Re: iTAN vs Elektronik Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-12 09:51 +0200
Re: iTAN vs Elektronik Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2022-09-12 10:18 +0200
Re: iTAN vs Elektronik Helmut Schellong <rip@schellong.biz> - 2022-09-12 14:49 +0200
Re: iTAN vs Elektronik Volker Bartheld <news2022@bartheld.net> - 2022-09-12 20:30 +0200
Re: iTAN vs Elektronik Helmut Schellong <rip@schellong.biz> - 2022-09-12 21:05 +0200
Re: iTAN vs Elektronik Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-12 22:06 +0200
Re: iTAN vs Elektronik Helmut Schellong <rip@schellong.biz> - 2022-09-12 22:30 +0200
Re: iTAN vs Elektronik Rupert Haselbeck <mein-rest-muell@gmx.de> - 2022-09-12 23:56 +0200
Re: iTAN vs Elektronik Hanno Foest <hurga-news2@tigress.com> - 2022-09-13 01:00 +0200
Re: iTAN vs Elektronik Volker Bartheld <news2022@bartheld.net> - 2022-09-13 09:43 +0200
Re: iTAN vs Elektronik Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-13 13:07 +0200
Re: iTAN vs Elektronik Axel Berger <Spam@Berger-Odenthal.De> - 2022-09-13 14:20 +0200
Re: iTAN vs Elektronik Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2022-09-13 14:35 +0200
Re: iTAN vs Elektronik Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-13 15:32 +0200
Internationale Bestellungen (was Re: iTAN vs Elektronik "Wolfgang Allinger" <all2001@spambog.com> - 2022-09-13 19:32 -0400
Re: Internationale Bestellungen (was Re: iTAN vs Elektronik Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2022-09-14 08:14 +0200
Re: Internationale Bestellungen (was Re: iTAN vs Elektronik Volker Bartheld <news2022@bartheld.net> - 2022-09-14 09:52 +0200
Re: Internationale Bestellungen (was Re: iTAN vs Elektronik Frank Scheffski <usenet@alles-moppelkotze.de> - 2022-09-14 19:47 +0200
Re: Internationale Bestellungen (was Re: iTAN vs Elektronik "Wolfgang Allinger" <all2001@spambog.com> - 2022-09-15 07:20 -0400
Re: Internationale Bestellungen (was Re: iTAN vs Elektronik Rupert Haselbeck <mein-rest-muell@gmx.de> - 2022-09-15 14:16 +0200
Re: Internationale Bestellungen (was Re: iTAN vs Elektronik Frank Scheffski <usenet@alles-moppelkotze.de> - 2022-09-15 21:46 +0200
Re: Internationale Bestellungen (was Re: iTAN vs Elektronik Rupert Haselbeck <mein-rest-muell@gmx.de> - 2022-09-15 23:50 +0200
Re: iTAN vs Elektronik Rupert Haselbeck <mein-rest-muell@gmx.de> - 2022-09-13 16:20 +0200
Re: iTAN vs Elektronik Hanno Foest <hurga-news2@tigress.com> - 2022-09-13 17:42 +0200
Re: iTAN vs Elektronik Axel Berger <Spam@Berger-Odenthal.De> - 2022-09-13 17:54 +0200
Re: iTAN vs Elektronik Volker Bartheld <news2022@bartheld.net> - 2022-09-14 09:34 +0200
Re: iTAN vs Elektronik Volker Bartheld <news2022@bartheld.net> - 2022-09-14 09:18 +0200
Re: iTAN vs Elektronik Guido Grohmann <guido.grohmann@gmx.de> - 2022-09-13 18:39 +0200
Re: iTAN vs Elektronik "Wolfgang Allinger" <all2001@spambog.com> - 2022-09-13 19:35 -0400
Re: iTAN vs Elektronik Axel Berger <Spam@Berger-Odenthal.De> - 2022-09-12 22:52 +0200
Re: iTAN vs Elektronik Helmut Schellong <rip@schellong.biz> - 2022-09-12 14:35 +0200
Re: iTAN vs Elektronik Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-01 10:59 +0200
Re: iTAN vs Elektronik Volker Bartheld <news2022@bartheld.net> - 2022-09-02 08:39 +0200
Re: iTAN vs Elektronik Holger Schieferdecker <spamless@gmx.de> - 2022-09-22 10:04 +0200
Re: iTAN vs Elektronik Helmut Schellong <rip@schellong.biz> - 2022-09-01 12:13 +0200
Re: iTAN vs Elektronik Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-01 13:03 +0200
Re: iTAN vs Elektronik Volker Bartheld <news2022@bartheld.net> - 2022-08-31 14:17 +0200
Re: iTAN vs Elektronik Arno Welzel <usenet@arnowelzel.de> - 2022-08-31 15:51 +0200
Re: iTAN vs Elektronik Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-08-31 19:36 +0200
Re: iTAN vs Elektronik Volker Bartheld <news2022@bartheld.net> - 2022-09-01 01:16 +0200
Re: iTAN vs Elektronik Volker Bartheld <news2022@bartheld.net> - 2022-09-01 01:19 +0200
Re: iTAN vs Elektronik Arno Welzel <usenet@arnowelzel.de> - 2022-09-01 02:38 +0200
Re: iTAN vs Elektronik Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-01 11:07 +0200
Re: iTAN vs Elektronik Arno Welzel <usenet@arnowelzel.de> - 2022-09-10 18:54 +0200
Re: iTAN vs Elektronik Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-09-11 10:57 +0200
Re: iTAN vs Elektronik Arno Welzel <usenet@arnowelzel.de> - 2022-09-11 11:27 +0200
Re: iTAN vs Elektronik Marcel Mueller <news.5.maazl@spamgourmet.org> - 2022-08-27 17:42 +0200
Re: iTAN vs Elektronik Axel Berger <Spam@Berger-Odenthal.De> - 2022-08-27 19:24 +0200
Re: iTAN vs Elektronik Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-08-27 20:56 +0200
Re: iTAN vs Elektronik Axel Berger <Spam@Berger-Odenthal.De> - 2022-08-27 23:01 +0200
Re: iTAN vs Elektronik Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2022-08-28 20:45 +0200
Re: iTAN vs Elektronik Volker Bartheld <news2022@bartheld.net> - 2022-08-28 09:39 +0200
Re: iTAN vs Elektronik Marcel Mueller <news.5.maazl@spamgourmet.org> - 2022-08-28 11:59 +0200
Re: iTAN vs Elektronik Volker Bartheld <news2022@bartheld.net> - 2022-08-28 12:41 +0200
Re: iTAN vs Elektronik Heinz Schmitz <HeinzSchmitz@kra.org> - 2022-08-27 19:54 +0200
Re: iTAN vs Elektronik Karl Schippe <Karl.Schippe@mail.invalid> - 2022-08-30 09:19 +0200
Re: iTAN vs Elektronik Thomas Einzel <usenet-2022@einzel.de> - 2022-08-27 22:20 +0200
Re: iTAN vs Elektronik Axel Berger <Spam@Berger-Odenthal.De> - 2022-08-27 23:12 +0200
Re: iTAN vs Elektronik Thomas Einzel <usenet-2022@einzel.de> - 2022-08-28 00:11 +0200
Re: iTAN vs Elektronik Axel Berger <Spam@Berger-Odenthal.De> - 2022-08-28 11:54 +0200
Re: iTAN vs Elektronik Rupert Haselbeck <mein-rest-muell@gmx.de> - 2022-08-28 13:00 +0200
Re: iTAN vs Elektronik Marcel Mueller <news.5.maazl@spamgourmet.org> - 2022-08-28 12:03 +0200
Re: iTAN vs Elektronik Volker Bartheld <news2022@bartheld.net> - 2022-08-28 10:23 +0200
Re: iTAN vs Elektronik Marcel Mueller <news.5.maazl@spamgourmet.org> - 2022-08-28 12:30 +0200
Re: iTAN vs Elektronik Helmut Schellong <rip@schellong.biz> - 2022-08-28 13:02 +0200
Re: iTAN vs Elektronik Volker Bartheld <news2022@bartheld.net> - 2022-08-28 13:19 +0200
Re: iTAN vs Elektronik Rupert Haselbeck <mein-rest-muell@gmx.de> - 2022-08-28 13:20 +0200
Re: iTAN vs Elektronik Volker Bartheld <news2022@bartheld.net> - 2022-08-28 14:15 +0200
Re: iTAN vs Elektronik Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2022-08-28 15:23 +0200
Re: iTAN vs Elektronik Volker Bartheld <news2022@bartheld.net> - 2022-08-28 18:06 +0200
Re: iTAN vs Elektronik Volker Bartheld <news2022@bartheld.net> - 2022-08-28 18:07 +0200
Re: iTAN vs Elektronik Axel Berger <Spam@Berger-Odenthal.De> - 2022-08-28 15:38 +0200
Re: iTAN vs Elektronik Rupert Haselbeck <mein-rest-muell@gmx.de> - 2022-08-28 20:20 +0200
Re: iTAN vs Elektronik Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2022-08-28 20:53 +0200
Re: iTAN vs Elektronik Rolf Bombach <rolfnospambombach@invalid.invalid> - 2022-08-28 21:28 +0200
Re: iTAN vs Elektronik Volker Bartheld <news2022@bartheld.net> - 2022-08-29 08:53 +0200
Re: iTAN vs Elektronik Axel Berger <Spam@Berger-Odenthal.De> - 2022-08-29 09:47 +0200
Re: iTAN vs Elektronik Helmut Schellong <rip@schellong.biz> - 2022-08-29 13:32 +0200
Re: iTAN vs Elektronik Volker Bartheld <volker.bartheld@3ds.com> - 2022-08-29 08:30 -0700
Re: iTAN vs Elektronik Rolf Bombach <rolfnospambombach@invalid.invalid> - 2022-08-28 21:12 +0200
Re: iTAN vs Elektronik Martin Gerdes <martin.gerdes@gmx.de> - 2022-08-28 22:28 +0200
Re: iTAN vs Elektronik Arno Welzel <usenet@arnowelzel.de> - 2022-08-31 15:56 +0200
Re: iTAN vs Elektronik Axel Berger <Spam@Berger-Odenthal.De> - 2022-08-31 17:54 +0200
Re: iTAN vs Elektronik Arno Welzel <usenet@arnowelzel.de> - 2022-09-01 02:40 +0200
Re: iTAN vs Elektronik Volker Bartheld <news2022@bartheld.net> - 2022-08-25 23:01 +0200
Re: iTAN vs Elektronik Axel Berger <Spam@Berger-Odenthal.De> - 2022-08-25 23:14 +0200
Re: iTAN vs Elektronik Helmut Schellong <rip@schellong.biz> - 2022-08-25 23:33 +0200
Re: iTAN vs Elektronik Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2022-08-26 07:37 +0200
Re: iTAN vs Elektronik Volker Bartheld <news2022@bartheld.net> - 2022-08-26 16:55 +0200
Re: iTAN vs Elektronik Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2022-08-27 09:27 +0200
Re: iTAN vs Elektronik Volker Bartheld <news2022@bartheld.net> - 2022-08-27 09:47 +0200
Re: iTAN vs Elektronik Gerhard Hoffmann <dk4xp@arcor.de> - 2022-08-27 09:51 +0200
Re: iTAN vs Elektronik Rupert Haselbeck <mein-rest-muell@gmx.de> - 2022-08-27 11:44 +0200
Re: iTAN vs Elektronik Rolf Bombach <rolfnospambombach@invalid.invalid> - 2022-08-28 21:39 +0200
Re: iTAN vs Elektronik Helmut Schellong <rip@schellong.biz> - 2022-08-25 23:11 +0200
Re: iTAN vs Elektronik Arno Welzel <usenet@arnowelzel.de> - 2022-08-26 22:48 +0200
Re: iTAN vs Elektronik Helmut Schellong <rip@schellong.biz> - 2022-08-26 23:53 +0200
Re: iTAN vs Elektronik Mirko Siederik <ui3748-559@online.de> - 2022-08-26 11:49 +0200
Re: iTAN vs Elektronik Arno Welzel <usenet@arnowelzel.de> - 2022-08-26 22:40 +0200
Re: iTAN vs Elektronik Helmut Schellong <rip@schellong.biz> - 2022-08-26 23:33 +0200
Re: iTAN vs Elektronik Martin Gerdes <martin.gerdes@gmx.de> - 2022-08-28 22:28 +0200
Re: iTAN vs Elektronik Helmut Schellong <rip@schellong.biz> - 2022-08-29 13:03 +0200
Re: iTAN vs Elektronik Martin Gerdes <martin.gerdes@gmx.de> - 2022-08-28 22:28 +0200
Re: iTAN vs Elektronik Helmut Schellong <rip@schellong.biz> - 2022-08-29 12:36 +0200
Re: iTAN vs Elektronik Martin Gerdes <martin.gerdes@gmx.de> - 2022-08-31 01:38 +0200
Re: iTAN vs Elektronik Helmut Schellong <rip@schellong.biz> - 2022-09-04 00:00 +0200
Re: iTAN vs Elektronik Juergen <schreibsklave@web.de> - 2022-09-08 13:05 +0200
Re: iTAN vs Elektronik Helmut Schellong <rip@schellong.biz> - 2022-09-08 14:56 +0200
Re: iTAN vs Elektronik Juergen <schreibsklave@web.de> - 2022-09-08 17:46 +0200
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
| From | Volker Bartheld <news2022@bartheld.net> |
|---|---|
| Date | 2022-09-01 01:16 +0200 |
| Message-ID | <pb6n7r6syy2r$.dlg@news.bartheld.net> |
| In reply to | #325726 |
On Wed, 31 Aug 2022 19:36:40 +0200, Marc Haber wrote: > Arno Welzel <usenet@arnowelzel.de> wrote: >>Hast Du dazu ein paar weiterführende Quellen? Insbesondere zur >>Kompromittierung von Apps, die für Banking genutzt werden und dem >>Abgreifen von TANs etc. bei den Apps durch Angreifer? > Leider nein, ich kann nur die Konzepte bewerten. Hab irgendwann mal einenunterhaltsamen Def Con Talk gesehen, wo jemand eine Android App entsprechend instrumentiert hat. Schien mir - als bekennender Android- und Java-Laie - gar nicht so extrem kompliziert zu sein. Leider spuckte mir jetzt eine schnelle Suche nach "hack android app trojan" nichts darauf Passendes aus, die Resultate trotzdem sehr aufschlußreich. Nach Blick auf... https://www.threatfabric.com/blogs/deceive-the-heavens-to-cross-the-sea.html ... würde ich beim Google Play Store jedenfalls ziemlich vorsichtig sein, etliche deutsche Banken unter den Zielen. Volker
[toc] | [prev] | [next] | [standalone]
| From | Volker Bartheld <news2022@bartheld.net> |
|---|---|
| Date | 2022-09-01 01:19 +0200 |
| Message-ID | <bkjtepf3ytq9.dlg@news.bartheld.net> |
| In reply to | #325726 |
On Wed, 31 Aug 2022 19:36:40 +0200, Marc Haber wrote: > Arno Welzel <usenet@arnowelzel.de> wrote: >>Hast Du dazu ein paar weiterführende Quellen? Insbesondere zur >>Kompromittierung von Apps, die für Banking genutzt werden und dem >>Abgreifen von TANs etc. bei den Apps durch Angreifer? > Leider nein, ich kann nur die Konzepte bewerten. Hab irgendwann mal einen unterhaltsamen Def Con Talk gesehen, wo jemand Android Apps entsprechend instrumentiert hat. Schien mir - als bekennender Android- und Java-Laie - gar nicht so extrem kompliziert zu sein. Leider spuckte mir jetzt eine schnelle Suche nach "hack android app trojan" nichts darauf Passendes aus, die Resultate trotzdem sehr aufschlußreich. Nach Blick auf... https://www.threatfabric.com/blogs/deceive-the-heavens-to-cross-the-sea.html ... würde ich beim Google Play Store jedenfalls ziemlich vorsichtig sein, etliche deutsche Banken unter den Zielen. Volker
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2022-09-01 02:38 +0200 |
| Message-ID | <jnad90F1o9aU1@mid.individual.net> |
| In reply to | #325751 |
Volker Bartheld, 2022-09-01 01:19: [...] > Nach Blick auf... > https://www.threatfabric.com/blogs/deceive-the-heavens-to-cross-the-sea.html > ... würde ich beim Google Play Store jedenfalls ziemlich vorsichtig > sein, etliche deutsche Banken unter den Zielen. Na ja - das übliche Muster halt. Malware wird bevorzugt in "Free XYZ Supertolle App" verpackt, die dann von so "seriösen" Anbietern wie "Supertolle App Free LLC" angeboten wird. Oder Apps, die den echten Apps sehr ähnlich sehen, aber zusätzlich Malware enthalten. Weiterer Weg sind vermeintliche Ankündigungen via E-Mail oder Messenger für Paketzustellungen oder vermeintliche Kontosperren, auf die man unbedingt reagieren soll. Wer auf sowas reinfällt, hat Pech, ja - aber das ist alles nicht neu und keine Smartphone-spezifische Problematik. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2022-09-01 11:07 +0200 |
| Message-ID | <tepsp2$10ker$1@news1.tnib.de> |
| In reply to | #325751 |
Volker Bartheld <news2022@bartheld.net> wrote: >On Wed, 31 Aug 2022 19:36:40 +0200, Marc Haber wrote: >> Arno Welzel <usenet@arnowelzel.de> wrote: >>>Hast Du dazu ein paar weiterführende Quellen? Insbesondere zur >>>Kompromittierung von Apps, die für Banking genutzt werden und dem >>>Abgreifen von TANs etc. bei den Apps durch Angreifer? >> Leider nein, ich kann nur die Konzepte bewerten. > >Hab irgendwann mal einen unterhaltsamen Def Con Talk gesehen, wo jemand >Android Apps entsprechend instrumentiert hat. Mit "irgendwann" wäre ich da vorsichtig, auch Android hat dazugelernt und wird von Version zu Version sicherer. Als Anwender merkt man das leider nur daran, dass manche Dinge, die früher ganz einfach gingen, plötzlich nicht mehr so einfach möglich sind, weil diese Funktion halt auf anfänglich schlecht gemachten und dann nachträglich abgesicherten Eigenschaften des Betriebssystems basiert. Dennoch ist Android noch weit von dem Sicherheitsniveau entfernt, auf dem Apple seit Jahren ist (und auch mit gewissem Ehrgeiz daran arbeitet, dass das niemand aushöhlt) Auch in Android-Telefonen gibt es inzwischen "secure enclaves", sie heißen nur bei jedem Hersteller anders und werden nicht mit der gebotenen Aggressivität vermarktet. Außerdem müsste man wissen (was ich nicht tue), ob auf Geräten mit "secure enclave" diese automatisch über dieselben API-Calls benutzt wird, über die auch die Software-Crypto-Funktionen auf Geräten ohne "secure enclave" angesprochen werden, oder ob sich jede App einzeln entscheiden muss (vielleicht gar für jeden Hersteller), ob sie ein vorhandenes "secure enclave" benutzt oder ob sie weiterhin ihren Simpel-Code verwendet, den sie eh braucht weil es noch Geräte "ohne" gibt. Apple traue ich die notwendige Attitüde "da ist unser Secure Enclave, das benutzt Du bitte in Deiner App, sonst kommst Du nicht in den Appstore" einfach eher zu als den ganzen Chinakracher-Herstellern. Grüße Marc, der dennoch ein Androidtelefon hat -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2022-09-10 18:54 +0200 |
| Message-ID | <jo3tquF2hssU1@mid.individual.net> |
| In reply to | #325765 |
Marc Haber, 2022-09-01 11:07: [...] > Auch in Android-Telefonen gibt es inzwischen "secure enclaves", sie > heißen nur bei jedem Hersteller anders und werden nicht mit der > gebotenen Aggressivität vermarktet. Wer auf sowas Wert legt, sollte primär Geräte von Samsung verwenden. Deren Konzept "Knox" ist durchaus mehr als reines Marketingbeblubber. Ich hatte damit schon vor etlichen Jahren zu tun in einer Firma die u.A. auch Software für Mobile Device Management für Geschäftskunden entwickelt hat. > Außerdem müsste man wissen (was ich nicht tue), ob auf Geräten mit > "secure enclave" diese automatisch über dieselben API-Calls benutzt > wird, über die auch die Software-Crypto-Funktionen auf Geräten ohne > "secure enclave" angesprochen werden, oder ob sich jede App einzeln > entscheiden muss (vielleicht gar für jeden Hersteller), ob sie ein > vorhandenes "secure enclave" benutzt oder ob sie weiterhin ihren > Simpel-Code verwendet, den sie eh braucht weil es noch Geräte "ohne" > gibt. AFAIK funktionieren die nötigen API-Calls nicht, wenn die nötige Hardware nicht vorhanden ist. Ansonsten siehe: <https://developer.android.com/training/articles/security-key-attestation> <https://developer.android.com/training/articles/keystore> > Apple traue ich die notwendige Attitüde "da ist unser Secure Enclave, > das benutzt Du bitte in Deiner App, sonst kommst Du nicht in den > Appstore" einfach eher zu als den ganzen Chinakracher-Herstellern. Google schmeißt Apps auch raus, wenn sie bestimmte Mindestanforderungen nicht erfüllen - passiert auch immer wieder mal. Manchmal auch zum Leidwesen der App-Anbieter, die dann mitunter laut jammern, dass sie Google seine Marktmacht völlig ungerechtfertigt ausnutzt. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2022-09-11 10:57 +0200 |
| Message-ID | <tfk7ud$2mo9n$1@news1.tnib.de> |
| In reply to | #326135 |
Arno Welzel <usenet@arnowelzel.de> wrote: >Marc Haber, 2022-09-01 11:07: >> Außerdem müsste man wissen (was ich nicht tue), ob auf Geräten mit >> "secure enclave" diese automatisch über dieselben API-Calls benutzt >> wird, über die auch die Software-Crypto-Funktionen auf Geräten ohne >> "secure enclave" angesprochen werden, oder ob sich jede App einzeln >> entscheiden muss (vielleicht gar für jeden Hersteller), ob sie ein >> vorhandenes "secure enclave" benutzt oder ob sie weiterhin ihren >> Simpel-Code verwendet, den sie eh braucht weil es noch Geräte "ohne" >> gibt. > >AFAIK funktionieren die nötigen API-Calls nicht, wenn die nötige >Hardware nicht vorhanden ist. Was halt nicht auffällt wenn die App diese API-Calls gar nicht erst benutzt. >> Apple traue ich die notwendige Attitüde "da ist unser Secure Enclave, >> das benutzt Du bitte in Deiner App, sonst kommst Du nicht in den >> Appstore" einfach eher zu als den ganzen Chinakracher-Herstellern. > >Google schmeißt Apps auch raus, wenn sie bestimmte Mindestanforderungen >nicht erfüllen Ein Secure Enclave einzubauen ist nichtmal Mindestanforderung für Hardware, wie soll man da verlangen dass Apps sie benutzen? Grüße Marc -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2022-09-11 11:27 +0200 |
| Message-ID | <jo5nv5Fcjo8U1@mid.individual.net> |
| In reply to | #326152 |
Marc Haber, 2022-09-11 10:57: > Arno Welzel <usenet@arnowelzel.de> wrote: >> Marc Haber, 2022-09-01 11:07: >>> Außerdem müsste man wissen (was ich nicht tue), ob auf Geräten mit >>> "secure enclave" diese automatisch über dieselben API-Calls benutzt >>> wird, über die auch die Software-Crypto-Funktionen auf Geräten ohne >>> "secure enclave" angesprochen werden, oder ob sich jede App einzeln >>> entscheiden muss (vielleicht gar für jeden Hersteller), ob sie ein >>> vorhandenes "secure enclave" benutzt oder ob sie weiterhin ihren >>> Simpel-Code verwendet, den sie eh braucht weil es noch Geräte "ohne" >>> gibt. >> >> AFAIK funktionieren die nötigen API-Calls nicht, wenn die nötige >> Hardware nicht vorhanden ist. > > Was halt nicht auffällt wenn die App diese API-Calls gar nicht erst > benutzt. Wenn Banking-Apps mindestens Android 9 verlangen, ist das ein starkes Indiz, dass dann auch das entsprechende API genutzt wird - das gibt es nämlich erst seit Android 9. >>> Apple traue ich die notwendige Attitüde "da ist unser Secure Enclave, >>> das benutzt Du bitte in Deiner App, sonst kommst Du nicht in den >>> Appstore" einfach eher zu als den ganzen Chinakracher-Herstellern. >> >> Google schmeißt Apps auch raus, wenn sie bestimmte Mindestanforderungen >> nicht erfüllen > > Ein Secure Enclave einzubauen ist nichtmal Mindestanforderung für > Hardware, wie soll man da verlangen dass Apps sie benutzen? Android verlangt abhängig von der Kategorie, in der man eine App veröffentlicht, regelmäßig ein Update der Apps auf aktuelle APIs, wenn sie drin bleiben soll - BTDT. Ich war zwar noch nie an Banking-Apps beteiligt, aber andere Apps mussten immer wieder angepasst werden *und* die entsprechenden API-Aufrufe verwendet werden, damit sie nicht rausfliegen. Zeitweise kann man sich mit Libs behelfen, das das kapseln und der App die alte API vorgaukeln, obwohl Android selbst die gar nicht mehr anbietet, wenn die App als "kompatibel zu Android 9 oder neuer" im Manifest gekennzeichnet wurde - aber ewig geht das auch nicht. So wie man auch HTML5 mit shims für alte Browser mittlerweile kaum noch sinnvoll emulieren kann. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Marcel Mueller <news.5.maazl@spamgourmet.org> |
|---|---|
| Date | 2022-08-27 17:42 +0200 |
| Message-ID | <tede0c$eac$1@news.nntp4.net> |
| In reply to | #325477 |
Am 25.08.22 um 22:49 schrieb Thomas Einzel: > Die Tendenz ist klar, die Dummen bestimmen was passiert und alle müssen > mit den Nachteilen leben. Eigentlich nicht. Es bestimmen aber nicht primär Leute, die in _meinem_ Interesse handeln. >> Die meisten Banken sind daher schon vor Jahren davon abgekommen. > > Das alte TAN verfahren ahtte uch Vorteile. Man konnte eine oder wenige > TAN mit nehmen um ggf. im Urlaubbo.ä. eien Überweisung machen zu können. > Bei iTAN musste man die gesamte Lsite einpaken. Kein Sicherheitsgewinn. iTAN ist _wesentlich_ sicherer als TAN, denn eine per gefälschter Webseite abgegriffene iTAN ist für alles außer der Transaktion, für die sie gedacht war, wertlos. Eine einzelne TAN hingegen reicht, um das Konto zu räumen. > Heute mit der 2 Faktor, Multi Faktor, wie auch immer Authentifizierung > darf man entweder alles Equipment mitschleppen, oder mobil geht gar > nichts. Das ist der Preis für die Sicherheit. > Super sicher immer alles dabei zu haben. Wer mTAN nutzt und sich > die TANs schlauer weise _nicht_ auf sein Smartphone senden läßt, darf > ein weiteres "Dumm"-Mobilfunkgerät mitschleppen und hat die Chance dass > am betreffenden Ort das betreffende Netz nicht da ist, oder man das > andere adegerät nicht mit hat. Alles mit/auf einem Gerät ist natürlich > die absolut "sicherste" Art und entspricht in Puncto Sicherheit ungefähr > dem iTAN verfahren und "die ganze Liste immer mit dabei". Alles auf einem Gerät ist unsicherer als iTAN. Ein Trojaner auf den Gerät genügt, um die Sache auszuhebeln. >>> Eine App auf SmartPhone ist beträchtlich unsicherer als iTAN >> >> Nein! Die Kopplung an ein Stück Hardware ist sogar extrem effektiv, um >> Phishing zu vereiteln. > > Phishing zu vereiteln geht am besten durch Wissen, nicht durch die > neuste coole Methode, die in ein paar Wochen ausgehebelt wird. Graue Theorie. Einen gut gemachten Phishing-Test dürfte kaum ein normal sterblicher bestehen, auch IT-Fachleute nicht, so meine Erfahrung. > Selbst wenn ich eine Mail auf dem korrekten Informationskanal bekommen > sollte, wo ich mich einloggen soll um dieses und jenes zu tun, klicke > ich _nicht_ auf einen link sondern logge mich über die selbst > eingegebene Adresse ein und überprüfe neben dem SSL Zertifikat den > Sachverhalt. Kann man niemandem beibringen? Dem widerspreche ich. Dann registriere ich eine (zertifizierte) Domain mit einem Tippfehler und warte 10 Minuten... > Marketing "einfach nur 1x klicken" ist eher das Problem. Komplexe Sachen > bleiben komplex, auch wenn man sie bunt anmalt. Eigentlich ist nur die Vernetzung und die daraus resultierende Geschwindigkeit und Entfernung das Problem. Früher musste Ganoven zumindest für einige Teilschritte immer irgendwo vor Ort sein. Das ist immer ein Risiko. Und man konnte nicht so schnell so großen Schaden anrichten. > ChipTAN finde ich ok und zumindest zu Hause gut nutzbar. Angenehm ist es nicht. Notwendig und hinreichend sicher i.a. schon. > 2FA ist zu einer oft unnützen Seuche wie die Cookie Zustimmung auf > Webseiten geworden, Sinn und Zweck mittlerweile oft verfehlt, leider. 2FA ist einfach nur eine Sache von Wahrscheinlichkeit und Aufwand. Der Aufwand, um 2 Faktoren _gleichzeitig_ zu knacken steigt in erster Näherung quadratisch. Der Aufwand für den User für 2FA nur linear. Verbrechen müssen in erster Linie ökonomisch rentabel sein. Ist der Aufwand zu hoch lohnt es sich nicht mehr. Das ist der primäre Ansatzpunkt für Sicherheitsmaßnahmen. Es geht niemals darum 100% sicher zu sein. Marcel
[toc] | [prev] | [next] | [standalone]
| From | Axel Berger <Spam@Berger-Odenthal.De> |
|---|---|
| Date | 2022-08-27 19:24 +0200 |
| Message-ID | <630A5341.9FC1162D@Berger-Odenthal.De> |
| In reply to | #325560 |
Marcel Mueller wrote: > Einen gut gemachten Phishing-Test dürfte kaum ein normal sterblicher > bestehen, auch IT-Fachleute nicht, so meine Erfahrung. Mag sein. Wenn es so ist, warum sind dann ausschließlich so extrem schlecht gemachte im realen Umlauf? > Dann registriere ich eine (zertifizierte) Domain mit einem Tippfehler > und warte 10 Minuten... Der Eerfolg ist nicht null aber um den Faktor 100 reduziert. (Grobe Schätzung. Wieviele potentielle Opfer vertippen sich und wieviele auf genau eine ganz bestimmte Weise?) -- /¯\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067 \ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069 X in | D-50829 Köln-Ossendorf http://berger-odenthal.de / \ Mail | -- No unannounced, large, binary attachments, please! --
[toc] | [prev] | [next] | [standalone]
| From | Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> |
|---|---|
| Date | 2022-08-27 20:56 +0200 |
| Message-ID | <20220827205640.0acbe59ef3b35c7c47ee9633@SchS.de> |
| In reply to | #325565 |
Hallo Axel Berger, Du schriebst am Sat, 27 Aug 2022 19:24:17 +0200: > Schätzung. Wieviele potentielle Opfer vertippen sich und wieviele auf > genau eine ganz bestimmte Weise?) Alle, die die Web-Seite per Link aufrufen. Also die weitaus überwiegende Mehrzahl. Unddazu kommt noch, daß der _Text_ des Links und dessen _Inhalt_ nichts miteinander zu tun haben. Und wer schaut sich schon bei einem Link an, was der Browser ggfs. am unteren Fensterrand als Link-Ziel anzeigt? Falls der (oder evtl. auch der Mail-Editor oder gar ein PDF-Reader) das _überhaupt_ anzeigt.) -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz -----------------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | Axel Berger <Spam@Berger-Odenthal.De> |
|---|---|
| Date | 2022-08-27 23:01 +0200 |
| Message-ID | <630A8612.DF4D2032@Berger-Odenthal.De> |
| In reply to | #325573 |
Sieghard Schicktanz wrote: > Unddazu kommt noch, daß der _Text_ des Links und dessen _Inhalt_ nichts > miteinander zu tun haben. Und wer schaut sich schon bei einem Link an, > was der Browser ggfs. am unteren Fensterrand als Link-Ziel anzeigt? Toll wie schön Du Selbstverständlichkeiten, die jeder hier weiß, Mansplainen kannst. Das funktioniert also genau dann, wenn jemand den Link klickt. Und worum ging es eigentlich? Marcel Mueller wrote: > Am 25.08.22 um 22:49 schrieb Thomas Einzel: > > klicke > > ich _nicht_ auf einen link sondern logge mich über die selbst > > eingegebene Adresse ein > > Dann registriere ich eine (zertifizierte) Domain mit einem Tippfehler > und warte 10 Minuten... Und nu? -- /¯\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067 \ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069 X in | D-50829 Köln-Ossendorf http://berger-odenthal.de / \ Mail | -- No unannounced, large, binary attachments, please! --
[toc] | [prev] | [next] | [standalone]
| From | Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> |
|---|---|
| Date | 2022-08-28 20:45 +0200 |
| Message-ID | <20220828204542.521b4a30e1ef47c5d324149e@SchS.de> |
| In reply to | #325576 |
Hallo Axel Berger, Du schriebst am Sat, 27 Aug 2022 23:01:07 +0200: > > Unddazu kommt noch, daß der _Text_ des Links und dessen _Inhalt_ > > nichts miteinander zu tun haben. Und wer schaut sich schon bei > > einem Link an, was der Browser ggfs. am unteren Fensterrand als > > Link-Ziel anzeigt? > > Toll wie schön Du Selbstverständlichkeiten, die jeder hier weiß, Ahja? _Hier_ vielleicht, aber "draußen"? > > > ich _nicht_ auf einen link sondern logge mich über die selbst > > > eingegebene Adresse ein > > > > Dann registriere ich eine (zertifizierte) Domain mit einem > > Tippfehler und warte 10 Minuten... > > Und nu? Schreibt er eine Anforderungs-EMail, vielleicht sogar eine kopierte Original-EMail von der Original-Web-Site, in der er _nur_ das Link-_Ziel_ auf seine neue Domain umbiegt. Was kümmert's, wenn einer von 10000 da Sperenzien macht und die Adresse direkt eintippt. Der wundert sich dann halt, daß da nix über den EMail- Inhalt zu finden ist. Oder er hat den Schreibfehler auch im Link-_Text_ angegeben. Was tippst Du dann in das Adressfeld des Browsers? Vor allem, wenn Du die Adresse nicht schon zig Male genutzt hast. -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz -----------------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | Volker Bartheld <news2022@bartheld.net> |
|---|---|
| Date | 2022-08-28 09:39 +0200 |
| Message-ID | <12fq3pn6zxpfr.dlg@news.bartheld.net> |
| In reply to | #325573 |
On Sat, 27 Aug 2022 20:56:40 +0200, Sieghard Schicktanz wrote: > Du schriebst am Sat, 27 Aug 2022 19:24:17 +0200: >> Schätzung. Wieviele potentielle Opfer vertippen sich und wieviele auf >> genau eine ganz bestimmte Weise?) > Alle, die die Web-Seite per Link aufrufen. [...] dazu kommt noch, daß > der _Text_ des Links und dessen _Inhalt_ nichts miteinander zu tun > haben. Und wer schaut sich schon bei einem Link an, was der Browser > ggfs. am unteren Fensterrand als Link-Ziel anzeigt? Und ob da ein Schloß dran ist oder nicht. Und ob beim Rechtsklick auf das Schloß ein Kontextmenü mit Zertifikat kommt, welches zum erwarteten Inhalt bzw. Betreiber paßt. Und für dynamisches Website-Spoofing gibts heutzutage natürlich ausgereifte Tools. Zur Not muß man eben tatsächlich ein bisserl programmieren und mit einem HTML-Parser herumtun, der sich die relevanten Infos aus der imitierten Bankwebsite kratzt. Muß ja nicht in 99.99% der Fälle funktionieren. 1% reicht auch. Volker
[toc] | [prev] | [next] | [standalone]
| From | Marcel Mueller <news.5.maazl@spamgourmet.org> |
|---|---|
| Date | 2022-08-28 11:59 +0200 |
| Message-ID | <tefeae$gbc$1@news.nntp4.net> |
| In reply to | #325573 |
Am 27.08.22 um 20:56 schrieb Sieghard Schicktanz: > Unddazu kommt noch, daß der _Text_ des Links und dessen _Inhalt_ nichts > miteinander zu tun haben. Und wer schaut sich schon bei einem Link an, > was der Browser ggfs. am unteren Fensterrand als Link-Ziel anzeigt? Und selbst wenn. Es gibt dutzende von Unicode-Zeichen, die lateinischen Buchstaben hinreichend ähnlich sehen. Ich nutze das seit Jahren für die Benamung von Musikdateien, wenn Zeichen darin vorkommen, die in Betriebssystemen in Dateinamen Probleme machen oder gar verboten sind. > Falls der (oder evtl. auch der Mail-Editor oder gar ein PDF-Reader) das > _überhaupt_ anzeigt.) Die geöffnete Seite in Browser wäre immer noch hinreichend. Wenn man die nur ansieht, ist nicht mehr verifiziert, als dass die Mail gelesen und der Link geklickt wurde. Marcel
[toc] | [prev] | [next] | [standalone]
| From | Volker Bartheld <news2022@bartheld.net> |
|---|---|
| Date | 2022-08-28 12:41 +0200 |
| Message-ID | <1ni1o6vt20tt5$.dlg@news.bartheld.net> |
| In reply to | #325602 |
On Sun, 28 Aug 2022 11:59:40 +0200, Marcel Mueller wrote: > [Website-Spoofing] Es gibt dutzende von Unicode-Zeichen, die lateinischen > Buchstaben hinreichend ähnlich sehen. >> Falls der (oder evtl. auch der Mail-Editor oder gar ein PDF-Reader) das >> _überhaupt_ anzeigt.) > Die geöffnete Seite in Browser wäre immer noch hinreichend. Wenn man die > nur ansieht, ist nicht mehr verifiziert, als dass die Mail gelesen und > der Link geklickt wurde. ... sowie der (natürlich veraltete) Browser mit irgendwelchen Exploits infiziert. ;-) Volker
[toc] | [prev] | [next] | [standalone]
| From | Heinz Schmitz <HeinzSchmitz@kra.org> |
|---|---|
| Date | 2022-08-27 19:54 +0200 |
| Message-ID | <umlkgh1koaho7s56l8alcv8952ad71j3ok@4ax.com> |
| In reply to | #325560 |
Marcel Mueller wrote: >Am 25.08.22 um 22:49 schrieb Thomas Einzel: >> Die Tendenz ist klar, die Dummen bestimmen was passiert und alle müssen >> mit den Nachteilen leben. >Eigentlich nicht. Es bestimmen aber nicht primär Leute, die in _meinem_ >Interesse handeln. Das auch. Man macht es sich aber auch gerne bequem und kassiert ab. >> Das alte TAN verfahren ahtte uch Vorteile. Man konnte eine oder wenige >> TAN mit nehmen um ggf. im Urlaubbo.ä. eien Überweisung machen zu können. >> Bei iTAN musste man die gesamte Lsite einpaken. Kein Sicherheitsgewinn. >iTAN ist _wesentlich_ sicherer als TAN, denn eine per gefälschter >Webseite abgegriffene iTAN ist für alles außer der Transaktion, für die >sie gedacht war, wertlos. Eine einzelne TAN hingegen reicht, um das >Konto zu räumen. Das sehe ich noch nicht. Kannst Du das etwas mehr ausführen? >> Heute mit der 2 Faktor, Multi Faktor, wie auch immer Authentifizierung >> darf man entweder alles Equipment mitschleppen, oder mobil geht gar >> nichts. >Das ist der Preis für die Sicherheit. >> Super sicher immer alles dabei zu haben. Wer mTAN nutzt und sich >> die TANs schlauer weise _nicht_ auf sein Smartphone senden läßt, darf >> ein weiteres "Dumm"-Mobilfunkgerät mitschleppen und hat die Chance dass >> am betreffenden Ort das betreffende Netz nicht da ist, oder man das >> andere adegerät nicht mit hat. Alles mit/auf einem Gerät ist natürlich >> die absolut "sicherste" Art und entspricht in Puncto Sicherheit ungefähr >> dem iTAN verfahren und "die ganze Liste immer mit dabei". Funk und Handy haben meiner Ansicht nach nichts in der Nähe meines Kontos zu suchen. >Graue Theorie. >Einen gut gemachten Phishing-Test dürfte kaum ein normal sterblicher >bestehen, auch IT-Fachleute nicht, so meine Erfahrung. Dazu müßte zunächst die von mir aufgerufene Webseiten-URL gefälscht sein. Das verursacht soviel Aufwand, dass es sich kaum rentiert. >Eigentlich ist nur die Vernetzung und die daraus resultierende >Geschwindigkeit und Entfernung das Problem. Früher musste Ganoven >zumindest für einige Teilschritte immer irgendwo vor Ort sein. Das ist >immer ein Risiko. Und man konnte nicht so schnell so großen Schaden >anrichten. Ist es nicht so, dass die meisten Schäden noch immer durch social engineering angerichtet werden (Im persönlichen Bereich)? Kürzlich kam in RTL eine Sendung über nigerianische Lover Boys. Es war schon tragisch, wie sich die gezeigten Witwen ihr Geld abnehmen liessen. >Verbrechen müssen in erster Linie ökonomisch rentabel sein. Ist der >Aufwand zu hoch lohnt es sich nicht mehr. Das ist der primäre >Ansatzpunkt für Sicherheitsmaßnahmen. Es geht niemals darum 100% sicher >zu sein. So ist e, wohl. Grüße, H.
[toc] | [prev] | [next] | [standalone]
| From | Karl Schippe <Karl.Schippe@mail.invalid> |
|---|---|
| Date | 2022-08-30 09:19 +0200 |
| Message-ID | <tekdll$3d4$1@gioia.aioe.org> |
| In reply to | #325568 |
On 27.08.2022 19:54, Heinz Schmitz wrote: > Funk und Handy haben meiner Ansicht nach nichts in der Nähe meines > Kontos zu suchen. Du betreibst Online-Banking? Dann wohnt dein Konto überall. Auch in der Nähe von Funk und Handy. :-)
[toc] | [prev] | [next] | [standalone]
| From | Thomas Einzel <usenet-2022@einzel.de> |
|---|---|
| Date | 2022-08-27 22:20 +0200 |
| Message-ID | <6c60f84c-2e61-79d0-c7a4-47cf48760e71@news.einzel.de> |
| In reply to | #325560 |
Am 27.08.2022 um 17:42 schrieb Marcel Mueller: > Am 25.08.22 um 22:49 schrieb Thomas Einzel: >> Die Tendenz ist klar, die Dummen bestimmen was passiert und alle >> müssen mit den Nachteilen leben. > > Eigentlich nicht. Es bestimmen aber nicht primär Leute, die in _meinem_ > Interesse handeln. Es ist natürlich richtig dass nicht die Dummen bestimmen, sondern die, die versuchen es den Menschen mit mangelndem Wissen scheinbar einfach zu machen und dabei Nachteile für viele andere schaffen. Das ist aber offenbar für die Mehrheit ok. >>> Die meisten Banken sind daher schon vor Jahren davon abgekommen. >> >> Das alte TAN verfahren hatte auch Vorteile. Man konnte eine oder >> wenige TAN mit nehmen um ggf. im Urlaub o.ä. eine Überweisung machen >> zu können. Bei iTAN musste man die gesamte Liste einpacken. Kein >> Sicherheitsgewinn. > > iTAN ist _wesentlich_ sicherer als TAN, denn eine per gefälschter > Webseite abgegriffene iTAN ist für alles außer der Transaktion, für die > sie gedacht war, wertlos. Eine einzelne TAN hingegen reicht, um das > Konto zu räumen. Wie setzt man mit einer TAN das Limit herauf und räumt gleichzeitig das Konto ab? Aber ich schrieb "eine oder wenige TAN", ok stimmt. Allerdings benötigt man zum Ändern des Limits mehr Angaben als nur Kontonummer, Pin und TAN. Den nur historischen Hinweis, dass man bei iTAN immer die gesamte Liste mitnehmen muss - was ich für noch unsicherer halte - hast du sicher gelesen, aber für nicht relevant befunden. Bei der gesamten Liste steigt das IMO Risiko. >> Heute mit der 2 Faktor, Multi Faktor, wie auch immer Authentifizierung >> darf man entweder alles Equipment mitschleppen, oder mobil geht gar >> nichts. > > Das ist der Preis für die Sicherheit. IMO wird es dadurch unsicher oder: Ich bin aus eigenem Entschluss praktisch nicht in der Lage _mobil_ Überweisungen am Rechner zu tätigen, weil ich nicht den ganzen Krimskrams mit mir herum schleppe, aus Sicherheitserwägungen. >> Super sicher immer alles dabei zu haben. Wer mTAN nutzt und sich die >> TANs schlauer weise _nicht_ auf sein Smartphone senden läßt, darf ein >> weiteres "Dumm"-Mobilfunkgerät mitschleppen und hat die Chance dass am >> betreffenden Ort das betreffende Netz nicht da ist, oder man das >> andere Ladegerät nicht mit hat. Alles mit/auf einem Gerät ist natürlich >> die absolut "sicherste" Art und entspricht in Puncto Sicherheit >> ungefähr dem iTAN verfahren und "die ganze Liste immer mit dabei". > > Alles auf einem Gerät ist unsicherer als iTAN. Ein Trojaner auf den > Gerät genügt, um die Sache auszuhebeln. Ja, genau das machen aber leider viele Leute, sie haben nur ein Smartphone und nur eine Rufnummer. Damit wird es nach deinen Worten sogar noch unsicherer als iTAN. Kein Sicherheitsgewinn. ... >> Phishing zu vereiteln geht am besten durch Wissen, nicht durch die >> neuste coole Methode, die in ein paar Wochen ausgehebelt wird. > > Graue Theorie. > Einen gut gemachten Phishing-Test dürfte kaum ein normal sterblicher > bestehen, auch IT-Fachleute nicht, so meine Erfahrung. (A)* Nie auf entsprechende links zu klicken und bei entsprechenden Anrufen einfach aufzulegen halte ich für mündige Menschen für prinzipiell erlernbar. Ich verlange ja _nicht_ von jedem die fingerprints des TLS Zertifikates seiner Bank vorher aufzuschreiben und dann stets zu prüfen. Aber das ist eben nicht ganz "einfach mit einem Klick von der Couch..." lt. gerade amtierenden Marketingdruiden. >> Selbst wenn ich eine Mail auf dem korrekten Informationskanal bekommen >> sollte, wo ich mich einloggen soll um dieses und jenes zu tun, klicke >> ich _nicht_ auf einen link sondern logge mich über die selbst >> eingegebene Adresse ein und überprüfe neben dem SSL Zertifikat den >> Sachverhalt. Kann man niemandem beibringen? Dem widerspreche ich. > > Dann registriere ich eine (zertifizierte) Domain mit einem Tippfehler > und warte 10 Minuten... siehe oben (A)* Ja, minimal mehr Aufwand, der aber nicht genannt werden soll, man könnte eventuell Kunden verlieren, die mehr als 1x clicken sollen. Dass die grüne Kennzeichnung bei TLS EV-Zertifikaten (seit 2019?) bei den meisten Browsern weggefallen ist, ist auch so ein Ding. "Grün" konnte ich jedem erklären... es ist zum verzweifeln. >> Marketing "einfach nur 1x klicken" ist eher das Problem. Komplexe >> Sachen bleiben komplex, auch wenn man sie bunt anmalt. > > Eigentlich ist nur die Vernetzung und die daraus resultierende > Geschwindigkeit und Entfernung das Problem. Früher musste Ganoven > zumindest für einige Teilschritte immer irgendwo vor Ort sein. Das ist > immer ein Risiko. Und man konnte nicht so schnell so großen Schaden > anrichten. Ja, was außer Bildung, Aufklärung, Wissen,... soll sonst dagegen real helfen? >> ChipTAN finde ich ok und zumindest zu Hause gut nutzbar. > > Angenehm ist es nicht. Notwendig und hinreichend sicher i.a. schon. IMO nicht unangenehmer als irgendeine andere 2FA die es derzeit gibt. ... >> 2FA ist zu einer oft unnützen Seuche wie die Cookie Zustimmung auf >> Webseiten geworden, Sinn und Zweck mittlerweile oft verfehlt, leider. > > 2FA ist einfach nur eine Sache von Wahrscheinlichkeit und Aufwand. > Der Aufwand, um 2 Faktoren _gleichzeitig_ zu knacken steigt in erster > Näherung quadratisch. Der Aufwand für den User für 2FA nur linear. Ich habe überhaupt nichts gegen 2FA, im Gegenteil, es muss nur gut gemacht sein, es kommt darauf an, wie sie angewendet wird. Heute 5 Banken, 5 Verfahren, teilweise muss man sich bei jedem login doppelt authentifizieren, teilweise auch wenn man sich mal Kontoauszüge von vor einigen Monaten ansieht. -- Thomas
[toc] | [prev] | [next] | [standalone]
| From | Axel Berger <Spam@Berger-Odenthal.De> |
|---|---|
| Date | 2022-08-27 23:12 +0200 |
| Message-ID | <630A88B1.F4B7701D@Berger-Odenthal.De> |
| In reply to | #325575 |
Thomas Einzel wrote: > teilweise muss man sich bei jedem login > doppelt authentifizieren, teilweise auch wenn man sich mal Kontoauszüge > von vor einigen Monaten ansieht. Dahinter sehe ich einen ganz anderen Grund. Es begann mit der SMS-TAN. Die kostete für jeden nachvollziehbar Fremdgebühr. Das war zwar ärgerlich aber verständlich. Die Nachrichten an die App kosten die Bank genau gar nichts. Trotzdem werden die Gebühren, an die sich Kunden ja gewöhnt haben, einfach weiter erhoben und im Vergleich zu anderen Buchungsgebühren pro Posten sind sie recht heftig. Auf Rückfrage faselt man dann etwas von den -- unbestrittenen -- Fixkosten aus der App-Entwicklung. Natürlich suchen und finden sie jetzt jede Eingabe, bei der sich noch eine zusätzliche Bestätigung mehr anfordern läßt. "Nice little earner" nennen das die Briten. -- /¯\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067 \ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069 X in | D-50829 Köln-Ossendorf http://berger-odenthal.de / \ Mail | -- No unannounced, large, binary attachments, please! --
[toc] | [prev] | [next] | [standalone]
| From | Thomas Einzel <usenet-2022@einzel.de> |
|---|---|
| Date | 2022-08-28 00:11 +0200 |
| Message-ID | <41460e9a-7d8b-39e9-9343-85aed846237f@news.einzel.de> |
| In reply to | #325577 |
Am 27.08.2022 um 23:12 schrieb Axel Berger: > Thomas Einzel wrote: >> teilweise muss man sich bei jedem login >> doppelt authentifizieren, teilweise auch wenn man sich mal Kontoauszüge >> von vor einigen Monaten ansieht. > > Dahinter sehe ich einen ganz anderen Grund. Es begann mit der SMS-TAN. > Die kostete für jeden nachvollziehbar Fremdgebühr. Das war zwar > ärgerlich aber verständlich. Die Nachrichten an die App kosten die Bank > genau gar nichts. Trotzdem werden die Gebühren, an die sich Kunden ja > gewöhnt haben, einfach weiter erhoben und im Vergleich zu anderen > Buchungsgebühren pro Posten sind sie recht heftig. Auf Rückfrage faselt > man dann etwas von den -- unbestrittenen -- Fixkosten aus der > App-Entwicklung. Natürlich suchen und finden sie jetzt jede Eingabe, bei > der sich noch eine zusätzliche Bestätigung mehr anfordern läßt. "Nice > little earner" nennen das die Briten. Mir begegnet das mit PhotoTAN für die 2FA bei jedem login - das dürfte zwar bei häufiger Nutzung den Kunden auf Trab halten, aber keine Buchungsgebühren pro Posten zur Folge haben. Die Kontoauszüge von vor einigen Monaten begegnet mir mit der ChipTAN, was keine Buchungsgebühren pro Posten zur Folge hat. -- Thomas
[toc] | [prev] | [next] | [standalone]
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
Back to top | Article view | de.sci.electronics
csiph-web