On 9/15/2010 3:39 AM, Piotr Gałka wrote:
>
> Użytkownik "witek" <w...@g...pl.invalid> napisał w wiadomości
> news:i6oota$735$3@inews.gazeta.pl...
>> On 9/14/2010 4:09 PM, Krzysztof Halasa wrote:
>>
>>> Bank zawsze ma dostep do hasla usera.
>>
>> no rozroznijmy bank od aplikacji chodzącej na serwerze.
>> to nie to samo.
>
> Według mnie dostęp musi mieć tylko aplikacja chodząca na komputerze
> użytkownika, do serwera leci już skrót (a właściwie wydłużenie ;-) ).

o ile tak została napisana, w co bardzo wątpie.

do góry

Użytkownik "Piotr Gałka" <p...@C...pl> napisał w
wiadomości news:4c908643@news.home.net.pl...
>
> Według mnie dostęp musi mieć tylko aplikacja chodząca na komputerze
> użytkownika, do serwera leci już skrót (a właściwie wydłużenie ;-) ).
Dopiszę jeszcze jedną myśl:
Jeszcze bezpieczniej z podawaniem hasła by było jakby klawiatury PC miały
taką funkcję, że się włącza specjalny tryb, wpisuje hasło i na Enter ten
tryb się kończy, a hasło jest mieszane (i wydłużane) i wysyłane via USB.
Jakby tak jeszcze szyfrowane było nie łącze bank-komputer, a łącze
bank-klawiatura. Zakładam, przy tym, że algorytmy mogły by być ustalone raz
na zawsze, co by oznaczało, że klawiatura nie musi akceptować żadnych
podsyłanych programów, a więc byłaby odporna na włamania. Ta stałość
algorytmów to jest to, co by tę klawiaturę wyróżniało od komputera.
Wszystko, co by choć przez mikrosekundę było w PC (ogólnie mało bezpieczne
miejsce) byłoby bezużyteczne dla różnych trojanów itp.
Myślę, że producenci klawiatur bez problemu by zrealizowali takie nowe
dodatkowe wymaganie i nie powinno to wcale wpłynąć zbyt na cenę klawiatury.
Skoro nic takiego się nie robi, to albo błądzę, albo bankom nie zależy na
bezpieczeństwie logowania.
P.G.

do góry

Użytkownik "witek" <w...@g...pl.invalid> napisał w wiadomości
news:i6q1l6$bj3$1@inews.gazeta.pl...

>>>> Bank zawsze ma dostep do hasla usera.
>>>
>>> no rozroznijmy bank od aplikacji chodzącej na serwerze.
>>> to nie to samo.
>>
>> Według mnie dostęp musi mieć tylko aplikacja chodząca na komputerze
>> użytkownika, do serwera leci już skrót (a właściwie wydłużenie ;-) ).
>
> o ile tak została napisana, w co bardzo wątpie.

Dlatego napisałem "musi mieć tylko", a nie "ma tylko".
Ale właściwie dlaczego wątpić.
Cytat z książki napisanej w 2003 roku (polskie wydanie 2004) "Kryptografia w
praktyce":
"22.2.1. Solenie i rozciąganie..... Techniki te są tak proste i naturalne,
że powinny być stosowane we wszystkich systemach haseł. Ignorowanie ich nie
ma żadnego wytłumaczenia."
Jeśli nie jest to podstawowa wiedza ludzi piszących oprogramowanie dla
banków to coś jest chyba postawione na głowie.
P.G.

do góry

Piotr Gałka pisze:

> Myślę, że producenci klawiatur bez problemu by zrealizowali takie nowe
> dodatkowe wymaganie i nie powinno to wcale wpłynąć zbyt na cenę
> klawiatury. Skoro nic takiego się nie robi, to albo błądzę, albo bankom
> nie zależy na bezpieczeństwie logowania.
> P.G.

Bankom nie zależy.
Bank idzie po linii najmniejszego oporu, po czym formułuje regulamin,
który przerzuca na klienta odpowiedzialność za błędy (wirusy, trojany,
keyloggery, zgubiony tf itp).



--

Dziękuję.
Pozdrawiam.
SQL-wiel.

do góry

On 9/15/2010 4:23 AM, Piotr Gałka wrote:
> Jeśli nie jest to podstawowa wiedza ludzi piszących oprogramowanie dla
> banków to coś jest chyba postawione na głowie.

a coś jest niepostawione na głowie?

do góry

Piotr Gałka <p...@C...pl> writes:

>> Aplikacja sprawdzajaca haslo musi je znac (przynajmniej w momencie
>> sprawdzania), na to nie ma rady oprocz kryptografii asymetrycznej.
>>
> Według mnie nie musi.
> Hasło powinno być na komputerze użytkownika wydłużane kryptograficznie
> (np. milion operacji mieszania)

Oczywiscie zwieksza to nieco moc obliczeniowa potrzebna do zlamania
(milion = 20 bitow), ale to dosc nieefektywne, jaka to ma zalete
w stosunku do kryptografii asymetrycznej? Bo ta ostatnia ma potezna
zalete, bank nie moze takiej operacji sam spreparowac.

Takie wydluzanie zwiekszy czas generowania teczowych tablic, ale ani nie
beda one wieksze, ani szukanie w nich nie bedzie wolniejsze.
--
Krzysztof Halasa

do góry

Kamil "Jońca" <k...@p...onet.pl> dared to write:
> Jacek Kalinski <jacek_kal@go2._NOSPAMPLEASE_.pl> writes:
>
>> W artykule <i68ujj$fmm$1@news.task.gda.pl>, AW napisał(a):
>>
>>> Mam np takie info:
>>> mBank - Login : 8 cyfr + dowolne hasło otwarte
>>> dbNet - Login 10 cyfr + hasło 6 cyfr otwarte
>>> Alior - Login : 8 cyfr + hasło dowolne maskowane + obrazek
>>> Openonline - Login 8 cyfr + hasło dowolne maskowane wirtualna klawiatura
>>> Polbank - Login 9 cyfr + hasło otwarte , wymuszona zmiana hasła co 3
>>> miesiące hasło musi się składać z min 8 znaków
>>
>> Millennium dla indywidualnych - millekod (login - 8 cyfr) + hasło +
> millekod + hasło (8 cyfr!, to samo hasło do logowania przez telefon) + 2
> znaki z DO/PESEL/Paszport
>
>> Openonline - nie zgodzę się - 8 cyfr login + hasło pełne
>
> To zależy, jeśli nie zmieniałeś hasła do lokat lub kis to masz pełne,
> wpp. masz chyba maskowane.
>
> Nordea - login (10 cyfr) + ( hasło ze zdrapki (4 cyfry) lub token)
> Citi - login (własnoręczny) + hasło - (Mam wrażenie, że login jest
> trzymany w ciasteczku w przeglądarce)
> Toyota - login (8 cyfr) + (hasło + wskazanie tokena w jednym polu)
> Eurobank - login (9 cyfr) + hasło + (opcjonalnie) wskazanie tokena gsm
> lub sprzętowego Inteligo - login 8 cyfr + hasło
>
>
> Należy nadmienić, że w aliorze, bzbwk, na 1. ekranie podaje się login, a
> dopiero na następnym hasło.


BPH, dawniejszy GE Bank - login (własny, ale niezmienialny) + hasło otwarte

Uzupełnienie do Citi: login można dowolnie zmieniać; sam login nie jest dosłownie
przechowywany w cookie - cookie tylko identyfikuje użytkownika dla banku, który to
wtedy zwraca przeglądarce odpowiedni login do wyświetlenia.

do góry

Krzysztof Halasa <k...@p...waw.pl> dared to write:
> witek <w...@g...pl.invalid> writes:
>
>>> Bank zawsze ma dostep do hasla usera.
>>
>> no rozroznijmy bank od aplikacji chodzącej na serwerze.
>> to nie to samo.
>
> No ale przeciez nie chodzi o system dostepny dla "zwyklego" personelu.
> Aplikacja sprawdzajaca haslo musi je znac (przynajmniej w momencie
> sprawdzania), na to nie ma rady oprocz kryptografii asymetrycznej.
>
> Z tym, ze to jest nieco trudniejsze dla "Kowalskiego" niz haslo
> i formularz na WWW. Zwlaszcza jesli ma byc zrobione dobrze.


Aplikacja dostępna dla "zwykłego" personelu w brytyjskim banku HSBC pokazuje hasło w
całości. Wystarczy, że personel w dowolnym oddziale wpisze numer okazanej karty
debetowej, aby pokazał się login i hasło klienta. Byłem zszokowany, kiedy to
zobaczyłem - również tym, że HSBC jak by nie patrzeć ma jakąś renomę.

k.

do góry

Użytkownik "Krzysztof Halasa" <k...@p...waw.pl> napisał w wiadomości
news:m31v8uq3z3.fsf@intrepid.localdomain...

>> Według mnie nie musi.
>> Hasło powinno być na komputerze użytkownika wydłużane kryptograficznie
>> (np. milion operacji mieszania)
>
> Oczywiscie zwieksza to nieco moc obliczeniowa potrzebna do zlamania
> (milion = 20 bitow),

Nieco = milion razy. Jeśli coś teraz nie daje się (w rozsądnym czasie)
złamać, ale za 10 lat dostępna moc obliczeniowa pozwoliłaby to złamać w
jeden dzień to stosowanie wydłużenia powoduje, że za te 10 lat trzeba będzie
milion dni. Dopiero za kolejne 10 lat wystarczy jeden dzień.

> ale to dosc nieefektywne,

To jest jedna sekunda zwłoki na moim (chyba 5 letnim) PC i wydaje mi się, że
to nigdy nie musi być wykonywane nigdzie indziej jak tylko na komputerze
logującego się użytkownika.

> jaka to ma zalete
> w stosunku do kryptografii asymetrycznej? Bo ta ostatnia ma potezna
> zalete, bank nie moze takiej operacji sam spreparowac.
>
O kryptografii asymetrycznej wiem za mało, aby się odpowiedzialnie
wypowiadać.
Nie rozumiem dlaczego bank nie może sam spreparować. Jeśli jak wynika z
poprzednich dyskusji przynajmniej niektóre banki przechowują hasła klientów
czyli znają wszystkie informacje, którymi posługuje się klient wykonując
jakąś operację (kod jednorazowy wysyłany SMS-em też bank zna).

> Takie wydluzanie zwiekszy czas generowania teczowych tablic, ale ani nie
> beda one wieksze, ani szukanie w nich nie bedzie wolniejsze.

Z tego co wiem o kryptografii (wiem niewiele, bo tylko z konieczności
musiałem jedną książkę przeczytać (asymetryczną pominąłem)) to przy
określaniu złożoności ataku czas jednego porównania z zawartością tabeli
przyjmuje się za jedną operację bez względu na wielkość porównywanych
obiektów. Hasła mają to do siebie, że zazwyczaj są za krótkie. Jakieś
badania pokazały, że typowo na jeden znak przypada około 3..4 bitów
niepewności (bo ludzie nie stosują w pełni losowego następstwa znaków). 12
znakowe hasło to byłoby około 48 bitów. Jego wydłużenie o 20 bitów to zawsze
coś (wydłuża czas ataku milion razy).
Dodatkowo wydłużanie z dodaniem pewnej jawnej liczby, ale dla każdego
użytkownika innej powoduje, że atakujący nie może stworzyć jednej tablicy
dla wszystkich użytkowników, ale musi tworzyć osobne tablice dla każdego
użytkownika.
Jeśli atakujący atakuje system haseł dla 1000 użytkowników to bez wydłużania
dla każdego domniemanego hasła musi wykonać jedno porównanie czyli 1000
operacji. Z wydłużaniem dla tego jednego hasła musi wykonać 1 001 000
operacji (wydłużenie milion i 1000 porównań), dla wydłużenia z dodaniem tej
jawnej liczby musi wykonać 1 000 001 000 operacji (1000 wydłużeń po milion i
1000 porównań). Z tysiąca operacji zrobił się miliard operacji dla
sprawdzenia jednego domniemanego hasła u wszystkich. To jest chyba pewna
różnica, a jedyny koszt to dodatkowa 1s czekania przy każdym logowaniu.
Gdyby jedna operacja zajmowała 1ns (1000 razy szybciej niż na moim PC) to
sprawdzenie 2^48 haseł bez wydłużania zajmie 3.2 dnia (dla jednego
użytkownika), a z wydłużaniem 3200000 dni - prawie 10 tysięcy lat. Faktyczna
różnica będzie większa, bo jednak porównanie trwa znacznie krócej niż
pojedyncza operacja mieszania.
P.G.

do góry

On Thu, 16 Sep 2010 11:23:39 +0200, Piotr Gałka
<p...@C...pl> wrote:

>
>Użytkownik "Krzysztof Halasa" <k...@p...waw.pl> napisał w wiadomości
>news:m31v8uq3z3.fsf@intrepid.localdomain...
>
>>> Według mnie nie musi.
>>> Hasło powinno być na komputerze użytkownika wydłużane kryptograficznie
>>> (np. milion operacji mieszania)
>>
>> Oczywiscie zwieksza to nieco moc obliczeniowa potrzebna do zlamania
>> (milion = 20 bitow),
>
>Nieco = milion razy. Jeśli coś teraz nie daje się (w rozsądnym czasie)
>złamać, ale za 10 lat dostępna moc obliczeniowa pozwoliłaby to złamać w
>jeden dzień to stosowanie wydłużenia powoduje, że za te 10 lat trzeba będzie
>milion dni. Dopiero za kolejne 10 lat wystarczy jeden dzień.

ale milion mieszań wcale nie oznacza, że złamanie tego będzie
trudniejsze niż po mieszaniu 1-krotnym.

BTW: co rozumiesz przez "mieszanie"? Permutację bitów?

>O kryptografii asymetrycznej wiem za mało, aby się odpowiedzialnie
>wypowiadać.
>Nie rozumiem dlaczego bank nie może sam spreparować. Jeśli jak wynika z

Bo tak właśnie działa kryptografia asymetryczna: jeden klucz ma
użytkownik i nikomu go nie ujawnia, a mimo to można stwierdzic
zgodność jawnego klucza publicznego z tym prywatnym.
--
pozdrawiam,
Jarek Andrzejewski

do góry