Alf/red/ <a...@u...waw.pl> writes:

> To jest możliwe, jeśli te systemy by stosowały 2FA, czyli coś
> dodatkowego. Np. klucz sprzętowy (niebezpiecznik sprzedaje po 150zł)
> albo aplikację w smartfonie.

To w żadnym razie nie może być uznane za panaceum na takie problemy.
Poza tym, gdyby klienci powszechnie stosowaliby wspólne hasło dla
różnych systemów, to to hasło straciłoby swoją rolę, i równie dobrze
można byłoby je zlikwidować, co redukowałoby mechanizm do 1FA, tyle że
w innej postaci, i kompletnie poza kontrolą klienta (a często także
banku). Coś a la primary - backup reversion.

> Banki u nas poszły we własne apki, i
> chyba żeście o tym zapomnieli bo wszyscy dodali swoje komputery jako
> zaufane. Ale od czasu PSD2 (niecały rok) banki są zobowiązane do
> logowania dwuskładnikowego. Więc w zasadzie znajomość hasła nie
> wystarczy, żeby się zalogować do banku na cudze konto.

Chyba że mamy dostęp do tego "zaufanego urządzenia". Jeśli ktoś przejął
hasło np. ze sklepu internetowego (bo klient używał tego samego hasła)
to ok. Ale jeśli ktoś podsłuchał mu to hasło na jego osobistym pececie,
to jest problem.

> No i są apki do drugiego składnika firm trzecich - słowo kluczowe OTP.

One time password?
No pewnie są takie apki, kiedyś się drukowało listy takich haseł. Weźmy
np. takie S/Key, to już ma prawie (jak widzę) 40 lat.

Zasadniczo, jak już mamy w ogóle pozwalać na wykonywanie obcego kodu, to
lepiej to zrobić bezpieczniej. W szczególności, OTP nie zabezpiecza
przed atakiem MITM. Aplikacja bankowa powinna być w stanie zrobić
challenge/response podczas logowania, a każde zlecenie powinno być
podpisane kluczem klienta (niedostępnym dla banku, przynajmniej
teoretycznie).
Tylko co z przypadkiem, gdy ktoś straci telefon (np. z oczu na chwilę),
albo gdy ktoś mu się tam włamie itp.?
--
Krzysztof Hałasa