witek
Gość
|
 2010-09-15, 02:57 Re: Sposoby logowania się .
|
 |
| Cytat: |
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.
|
|
|
|
|
Reklamy
|
|
witek
Gość
|
|
2010-09-15, 05:16 Re: Sposoby logowania się .
|
|
| Cytat: | 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?
|
|
|
|
Piotr Gałka
Gość
|
|
2010-09-15, 09:36 Re: Sposoby logowania się .
|
|
| Cytat: | 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) i dopiero takie wysyłane do systemu banku i w
systemie tylko takie przechowywane. Przy zmianie hasła również do systemu
trafiają tylko wersje wydłużone starego i nowego.
P.G.
|
|
|
|
Piotr Gałka
Gość
|
|
2010-09-15, 09:39 Re: Sposoby logowania się .
|
|
| Cytat: |
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 ).
P.G.
|
|
|
|
Piotr Gałka
Gość
|
|
2010-09-15, 10:23 Re: Sposoby logowania się .
|
|
| Cytat: | 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.
|
|
|
|
SQLwiel
Gość
|
|
2010-09-15, 10:57 Re: Sposoby logowania się .
|
|
| Cytat: | 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.
|
|
|
|
Krzysztof Halasa
Gość
|
|
2010-09-15, 19:03 Re: Sposoby logowania się .
|
|
s:
| Cytat: | 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
|
|
|
|
kashmiri
Gość
|
|
2010-09-15, 21:19 Re: Sposoby logowania się .
|
|
| Cytat: |
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.
|
|
|
|
Piotr Gałka
Gość
|
|
2010-09-16, 10:23 Re: Sposoby logowania się .
|
|
| Cytat: | 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ń.
| Cytat: | 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.
| Cytat: | 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).
| Cytat: | 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.
|
|
|
|
Jarek Andrzejewski
Gość
|
|
2010-09-16, 10:37 Re: Sposoby logowania s ię .
|
|
| Cytat: |
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?
| Cytat: | 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
|
|
|
|
Piotr Gałka
Gość
|
|
2010-09-16, 12:31 Re: Sposoby logowania się .
|
|
| Cytat: |
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?
|
Nie. Założenie jest zawsze takie, że algorytm jest znany atakującemu. Milion
znanych!! permutacji zastąpiłby jedną wynikową.
Przez mieszanie rozumiem np. SHA-256. Miliona mieszań SHA-256 nie da się
zastąpić jednym innym (przynajmniej na razie algorytm SHA-256 nie jest
złamany).
A chodzi o nakład obliczeń potrzebny atakującemu do sprawdzenia jednej
hipotezy.
| Cytat: |
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 stwierdzić
zgodność jawnego klucza publicznego z tym prywatnym.
|
Przypuszczałem, że ustanowienie sesji między komputerem a systemem banku
opiera się na kryptografii asymetrycznej i że to jest to, co ma uniemożliwić
bankowi spreparowanie operacji.
Teraz rozumiem, że chodzi o sytuację, gdy każdy użytkownik posiada klucz
prywatny - pewnie to jest najlepsze rozwiązanie.
Generalnie wypowiadałem się na temat: Jak powinno wyglądać logowanie, przy
założeniu, że użytkownik identyfikuje się zestawem login, hasło.
P.G.
|
|
|
|
Jarek Andrzejewski
Gość
|
|
2010-09-16, 12:57 Re: Sposoby logowania s ię .
|
|
| Cytat: |
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?
Nie. Założenie jest zawsze takie, że algorytm jest znany atakującemu. Milion
znanych!! permutacji zastąpiłby jedną wynikową.
Przez mieszanie rozumiem np. SHA-256. Miliona mieszań SHA-256 nie da się
zastąpić jednym innym (przynajmniej na razie algorytm SHA-256 nie jest
złamany).
A chodzi o nakład obliczeń potrzebny atakującemu do sprawdzenia jednej
hipotezy.
|
A masz coś na poparcie tezy, że SHA-256 wykonany milion razy będzie
bezpieczniejszy niż wykonany 1 raz?
Tak naprawdę idea łamania funkcji skrótu sprowadza się do jednego: tak
zmodyfikować wiadomość (lub inaczej: znaleźć taką wiadomość), aby
skrót był taki sam, jak dla wiadomości oryginalnej.
Można wielokrotnie wykonywać przekształcenie, ale idea jest taka:
http://en.wikipedia.org/wiki/Hash_chain
albo taka (połączenie wyniku kilku algprytmów):
http://en.wikipedia.org/wiki/Cryptographic_hash_function#Concatenation_of_cryptographic_hash_functions
A zamiast "mieszania" chyba lepiej użyć nazwy "funkcji skrótu".
| Cytat: | Teraz rozumiem, że chodzi o sytuację, gdy każdy użytkownik posiada klucz
prywatny - pewnie to jest najlepsze rozwiązanie.
|
to właśnie jest istota algorytmu _asymetrycznego_. Jeśli klucz jest
znany obu stronom - to jest kryptografia symetryczna.
|
|
|
|
Piotr Gałka
Gość
|
|
2010-09-16, 13:54 Re: Sposoby logowania się .
|
|
| Cytat: |
A masz coś na poparcie tezy, że SHA-256 wykonany milion razy będzie
bezpieczniejszy niż wykonany 1 raz?
|
A ja stawiałem taką tezę ?
Nie mówię o łamaniu SHA-256 tylko o ataku na hasła poprzez sprawdzanie
pewnej listy prawdopodobnych haseł w oparciu o domniemane zwyczaje
użytkowników. Chodzi jedynie o pozorne "wydłużenie" hasła użytkownika o
jakieś 20 bitów. Jeśli atakujący sprawdzałby hasła z przestrzeni 2^48 to po
takim "wydłużeniu" nadal musi sprawdzić 2^48, ale pracy będzie miał przy tym
jakby sprawdzał hasła z przestrzeni 2^68 (licząc liczbę niezbędnych operacji
kryptograficznych do wykonania, porównanie=operacja, SHA=operacja). Gdyby
chciał pominąć to "wydłużenie" i atakować poprzez sprawdzanie wszystkich
możliwych wyników to musiałby sprawdzać 2^256 kombinacji, bo tu nie da się
stworzyć listy prawdopodobnych wybranych przez użytkownika wartości.
Zakładam, że taki atak jest znacznie prostszy od próby łamania SHA-256 i
wykonanie SHA-256 milion razy nie ma na celu jego wzmacniania.
| Cytat: | Tak naprawdę idea łamania funkcji skrótu sprowadza się do jednego:
|
To (według mnie) nie jest tematem tej dyskusji.
Rzuciłem (niedokładnie) okiem - to jest jakaś zupełnie inna bajka - chodzi o
to, aby za każdym razem inne hasło było przesyłane. Jeśli łącze jest
odpowiednio zabezpieczone to nie widzę takiej potrzeby.
Nie mam powodów aby wątpić, że poskładanie wielu funkcji hash nie jest
bezpieczniejsze od wykonania jedynie najmocniejszej z nich.
| Cytat: | A zamiast "mieszania" chyba lepiej użyć nazwy "funkcji skrótu".
Zgodzę się, choć dla mnie słowo "mieszanie" lepiej oddaje wykonywaną |
operację, a "funkcja skrótu" sugeruje, że wynik jest krótszy od oryginału, a
to akurat w tym przypadku raczej nie jest prawdą (nigdy nie stosowałem
jeszcze 32 znakowych haseł).
P.G.
|
|
|
|
Jarek Andrzejewski
Gość
|
|
2010-09-16, 14:17 Re: Sposoby logowania s ię .
|
|
| Cytat: |
A masz coś na poparcie tezy, że SHA-256 wykonany milion razy będzie
bezpieczniejszy niż wykonany 1 raz?
A ja stawiałem taką tezę ?
|
Tak.
Cytat (Message-ID: ):
Hasło powinno być na komputerze użytkownika wydłużane kryptograficznie
(np. milion operacji mieszania) i dopiero takie wysyłane do systemu
banku /.../
Teraz piszesz:
| Cytat: | Chodzi jedynie o pozorne "wydłużenie" hasła użytkownika o
jakieś 20 bitów. Jeśli atakujący sprawdzałby hasła z przestrzeni 2^48 to po
|
a to nic nowego: jest to tak zwany "salt" (czyli dodanie jawnych
bitów) i od zarania dziejów jest stosowany np. w linuksie (tam jest
bodajże 12-bitowy).
A "salt" ma tę przewagę nad Twoją propozycją, że nawet dla
identycznych haseł da różne skróty.
--
pozdrawiam,
Jarek Andrzejewski
|
|
|
|
Piotr Gałka
Gość
|
|
2010-09-16, 15:28 Re: Sposoby logowania się .
|
|
| Cytat: | A masz coś na poparcie tezy, że SHA-256 wykonany milion razy będzie
bezpieczniejszy niż wykonany 1 raz?
A ja stawiałem taką tezę ?
Tak.
Cytat (Message-ID: ):
Hasło powinno być na komputerze użytkownika wydłużane kryptograficznie
(np. milion operacji mieszania) i dopiero takie wysyłane do systemu
banku /.../
|
Tu nie ma nic o zwiększeniu bezpieczeństwa funkcji hash przez jej
wielokrotne wykonanie, a jedynie o wydłużeniu hasła.
| Cytat: | Teraz piszesz:
Chodzi jedynie o pozorne "wydłużenie" hasła użytkownika o
jakieś 20 bitów. Jeśli atakujący sprawdzałby hasła z przestrzeni 2^48 to
po
Czyli powtarzam to samo, co wcześniej napisałem, bo wygląda, że nie zostało |
zrozumiane.
| Cytat: | a to nic nowego: jest to tak zwany "salt" (czyli dodanie jawnych
bitów) i od zarania dziejów jest stosowany np. w linuksie (tam jest
bodajże 12-bitowy).
|
W tym fragmencie nic nie piszę o dodaniu jawnych bitów. "Wydłużenie" to nie
jest dodanie soli tylko wielokrotne przeliczenie funkcji skrótu.
O soli pisałem tak: (Message-ID: )
----------
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.
----------
| Cytat: | A "salt" ma tę przewagę nad Twoją propozycją, że nawet dla
identycznych haseł da różne skróty.
|
Sól da różne skróty dla identycznych haseł, a wydłużenie zwiększa nakład
obliczeniowy atakującego.
Chodzi o obliczenie typu: X0=0; Xi=SHA(Xi-1||p||s), dla i=1,...,r, p-hasło,
s-sól, || - połączenie tekstów, Xi-1 - X o indeksie i-1.
Wydłużenie o 20 bitów to r = milion, a sól to s w tym algorytmie.
Wydłużenie to co innego, a sól to co innego. Ja piszę o wydłużeniu to Ty
zauważasz: "a to nic nowego to sól".
Jak napiszę o soli (już pisałem wczoraj koło 11-tej) to w odpowiedzi
zobaczę: "a to nic nowego to wydłużanie".
Dla mnie chaos nie dyskusja.
P.G.
|
|
|
|
GPW: Realizacja zysków, ale WIG20 powyżej 2500 pkt
Tak samo jak poniedziałkowa, tak i wtorkowa sesja na rodzimym rynku rozpoczęła się od...
McLaren z rekordami sprzedaży w 2017 roku
McLaren wypuszczając na rynek model 12C rozpoczął nowy rozdział swojej historii. Model...
MyLiFi - lampka LED dostarczająca internet
MyLiFi jest pozornie zwykłą lampka na biurko zaprezentowaną przez firmę Oledcomm na...
+0,17%
-0,30%
