MarcinF <m...@i...pl> writes:

>> Token to nie sa hasla jednorazowe.
>
> nie zgodze sie

To juz nie moj problem.

Roznica jest zasadnicza, wskazania tokena opieraja sie na "shared
secret" (ktory musza znac obie strony, tzn. bank i token).

> ani haslo stale ani jednorazowe nie chronia przed atakiem z wewnatrz
> o ktorym teraz piszesz

Zalezy od scenariusza, jesli ktos np. bedzie mial dostep do backupu,
to hasla stale i jednorazowe moga byc juz dawno nieaktualne, zas
seedy tokenow (pomijajac dryft, ktory moze byc pewnym utrudnieniem)
sa jak najbardziej mozliwe do uzycia.

> z tokenem challenge-response, gdzie challenge jest generowany
> na podstawie podpisywanej tresci to raczej ta szansa jest marna

W ktorym banku tak jest?
Jaka jest dlugosc zapytania?

> ale faktycznie, zwykly token czy zdrapka w przypadku w pelni
> online'owego ataku MITM nie pomoga, na szczescie takie ataki
> to rzadkosc

Nie wiem. Takie ataki sa latwiejsze do przeprowadzenia niz jakies
cuda z keyloggerami. Jesli takich nie ma w praktyce, to tylko
swiadczy o tym, ze ludzie z odpowiednimi umiejetnosciami sa albo
uczciwi, albo maja lepsze zajecia.

> ale tak naprawde dyskutowalismy o bezpieczenstwie hasel stalych
> i jednorazowych, to ze hasla jednorazowe nie sa idealnie
> bezpieczne to oczywiste, ja twierdze tylko ze sa o wiele
> bezpieczeniejsze od stalych

A ja twierdze, ze w ogolnym przypadku wcale nie sa (co zreszta
powinno byc oczywiste nawet bez moich dowodow). W szczegolnym
przypadku, gdy klient uzywa hasel w stylu "${WLASNE_IMIE}1",
niewatpliwie masz racje.
--
Krzysztof Halasa