Użytkownik "Krzysztof Halasa"
> Mysle ze w uproszczeniu mozna przyjac ze wszystkie hasla
> przechowywane
> w banku sa przez ten bank odwracalne - i raczej nie bedzie to zbyt
> duze uproszczenie.

hasla podawane wyrywkowo, tak jak w ING musza byc tak przechowywane
ale podawane w pelnie moga byc szyfrowane jednokierunkowo
np. tak jak to robi unix.
Glupotą byloby trzymanie ich w sposob jawny, a odwracac szyfrowania
nie ma potrzeby, a wrecz byloby to niebezpieczne dla banku
*** blad ***

do góry

"blad" <blad201@_W_Y_T_N_I_J_sezam.pl> writes:

> hasla podawane wyrywkowo, tak jak w ING musza byc tak przechowywane
> ale podawane w pelnie moga byc szyfrowane jednokierunkowo
> np. tak jak to robi unix.

Moga. Ale nie chodzi o to, ze moga byc szyfrowane, a o to, czy mozna
je odszyfrowac albo w inny sposob odwrocic.

Widzisz jakas "drobna" roznice?

> Glupotą byloby trzymanie ich w sposob jawny, a odwracac szyfrowania
> nie ma potrzeby, a wrecz byloby to niebezpieczne dla banku

Bank moze nie miec takiej potrzeby, ale "bankowy informatyk",
np. zwolniony z pracy (ale niekoniecznie) moze juz taka miec, nie?

Tak czy owak, napisalem chyba jasno jak sprawa wyglada, i ona tak
istotnie wyglada.
--
Krzysztof Halasa

do góry

Użytkownik "Krzysztof Halasa"
>> hasla podawane wyrywkowo, tak jak w ING musza byc tak przechowywane
>> ale podawane w pelnie moga byc szyfrowane jednokierunkowo
>> np. tak jak to robi unix.
>
> Moga. Ale nie chodzi o to, ze moga byc szyfrowane, a o to, czy mozna
> je odszyfrowac albo w inny sposob odwrocic.
>
> Widzisz jakas "drobna" roznice?

jesli "mogą" byc szyfrowane to bez sensu szyfrowac je w taki sposo
zeby
dalo sie szyfrowanie odwrocic - odszyfrowanie jest nikomu nie
potrzebne
i jak sam napisales ktos moze sie o nie pokusic.
Czyli - jesli szyfrowac to w jedna strone. Przy odpowiednio dlugim
hasle
moze sie informatyk bawic w zgadywanie hasla - powodzenia

Natomiast przy haslach w ING wiem ze bank musi umiec moje haslo
odszyfrowac i ze jest na to algorytm. Tak wiec wiem na pewno, ze
takie haslo moze zostac w banku odczytane. Hakerom ze sniferami
podsluchujacymi jest za to trudniej - od tego zaczelismy - tym
bardziej
ze krateczki z haslem mozna wypelniac w dowolnej kolejnosci

>> Glupotą byloby trzymanie ich w sposob jawny, a odwracac szyfrowania
>> nie ma potrzeby, a wrecz byloby to niebezpieczne dla banku
>
> Bank moze nie miec takiej potrzeby, ale "bankowy informatyk",
> np. zwolniony z pracy (ale niekoniecznie) moze juz taka miec, nie?
>
> Tak czy owak, napisalem chyba jasno jak sprawa wyglada, i ona tak
> istotnie wyglada.

nic nie napisales jak sprawa wyglada - nie umiesz ocenic jasno dwoch
metod
przechowywania hasel, a glos zabierasz jakbys tylko tym sie zajmowal
*** blad ***

do góry

"blad" <blad201@_W_Y_T_N_I_J_sezam.pl> writes:

> jesli "mogą" byc szyfrowane to bez sensu szyfrowac je w taki sposo zeby
> dalo sie szyfrowanie odwrocic - odszyfrowanie jest nikomu nie potrzebne
> i jak sam napisales ktos moze sie o nie pokusic.
> Czyli - jesli szyfrowac to w jedna strone. Przy odpowiednio dlugim
> hasle
> moze sie informatyk bawic w zgadywanie hasla - powodzenia

To jaki konkretnie algorytm proponujesz? Taki, ktory da Tobie (klientom)
pewnosc, ze go bank ("informatyk") nie bedzie potrafil odwrocic? :-)

> Natomiast przy haslach w ING wiem ze bank musi umiec moje haslo
> odszyfrowac i ze jest na to algorytm. Tak wiec wiem na pewno, ze
> takie haslo moze zostac w banku odczytane.

Owszem. Bo w ta strone to dziala - mozesz wiedziec, ze bank moze haslo
rozszyfrowac, ale nie mozesz wiedziec, ze nie moze.

Chyba ze sam wygenerujesz sobie pare kluczy asymetrycznych, i bank nie
bedzie mial prywatnej czesci - wtedy (modulo ew. lamanie samego
algorytmu albo wadliwy klucz, ale bez przesady z paranoja) masz racje.

> Hakerom ze sniferami
> podsluchujacymi jest za to trudniej - od tego zaczelismy - tym bardziej
> ze krateczki z haslem mozna wypelniac w dowolnej kolejnosci

Snifery akurat do SSL maja sie nijak. Ew. ataki MITM, ale przy
poprawnie skonfigurowanym komputerze teoretycznie spowoduje to
ostrzezenia, i wymaga ingerencji w przesylane informacje (aktywne
dzialanie, nie pasywne skanowanie). W praktyce wyglada to troche
gorzej ale tak czy owak jest zdecydowanie trudniejsze niz poznanie
hasla usera jesli sie ma do maszyny pelny dostep.

> nic nie napisales jak sprawa wyglada - nie umiesz ocenic jasno dwoch
> metod
> przechowywania hasel, a glos zabierasz jakbys tylko tym sie zajmowal

Zajmuje sie roznymi rzeczami (aczkolwiek akurat tym od dluzszego czasu
niz innymi rzeczami). Jakbys konkretnie napisal czego nie rozumiesz albo
z czym sie nie zgadzasz to zapewne bede w stanie Ci to wytlumaczyc.
To sa dosc podstawowe rzeczy zreszta.
--
Krzysztof Halasa

do góry

Użytkownik "Krzysztof Halasa"
>> Czyli - jesli szyfrowac to w jedna strone. Przy odpowiednio dlugim
>> hasle moze sie informatyk bawic w zgadywanie hasla - powodzenia
>
> To jaki konkretnie algorytm proponujesz? Taki, ktory da Tobie
> (klientom)
> pewnosc, ze go bank ("informatyk") nie bedzie potrafil odwrocic? :-)

niech będzie np hasz md5

>> Natomiast przy haslach w ING wiem ze bank musi umiec moje haslo
>> odszyfrowac i ze jest na to algorytm. Tak wiec wiem na pewno, ze
>> takie haslo moze zostac w banku odczytane.
>
> Owszem. Bo w ta strone to dziala - mozesz wiedziec, ze bank moze
> haslo
> rozszyfrowac, ale nie mozesz wiedziec, ze nie moze.

w ING bank MUSI umiec rozszyfrowac haslo zeby porownac wybrane
jego znaki. W innych bankach nic noie MUSZĄ - mogą za to zaszyfrowac
hasla jednokierunkowo i nawet powinni - nie ma powodu by
hasło pozostawić nie zaszyfrowane lub tworzyc
procedure odszyfrowania - jesli znasz takie powody to podaj

>> Hakerom ze sniferami podsluchujacymi jest za to trudniej
>
> Snifery akurat do SSL maja sie nijak.

OK - moja pomylka - te podsluchujące hasło trojany to key-loggery

>> nic nie napisales jak sprawa wyglada - nie umiesz ocenic jasno
>> dwoch
>> metod przechowywania hasel, a glos zabierasz jakbys tylko tym sie
>> zajmowal
>
> Zajmuje sie roznymi rzeczami (aczkolwiek akurat tym od dluzszego
> czasu
> niz innymi rzeczami). Jakbys konkretnie napisal czego nie rozumiesz
> albo
> z czym sie nie zgadzasz to zapewne bede w stanie Ci to wytlumaczyc.
> To sa dosc podstawowe rzeczy zreszta.

no wlasnie - dla mnie tez sa oczywiste, i ja te dwie metody loginow
porownuje
a ty nie chcesz sie na temat porownania wypowiedziec
1 - logowanie - pelne haslo mozna podsluchac keylogerem,
wyrywkowe potrzebuje wielu prob podsluchu
2 - przechowanie hasla - pelne haslo mozna przechowac jako skrót,
bezpiecznie
wyrywkowe - musimy w banku miec algorytm na
odszyfrowanie hasla
Oba sposoby mają więc swoje "plusy dodatnie i ujemne" :-)
A teraz powiedz czego nie rozumiesz i o czym my dyskutujemy
*** blad ***

do góry

"blad" <blad201@_W_Y_T_N_I_J_sezam.pl> writes:

>> To jaki konkretnie algorytm proponujesz? Taki, ktory da Tobie
>> (klientom)
>> pewnosc, ze go bank ("informatyk") nie bedzie potrafil odwrocic? :-)
>
> niech będzie np hasz md5

Musisz sprobowac jeszcze raz, mialem na mysli caly algorytm zaczynajac
od momentu podania hasla przez usera do jego "zapamietania" (w formie
np. skrotu) przez bank i nastepnie od podania hasla do stwierdzenia ze
jest ono prawidlowe.

Wiesz jak sie robi migracje z hasel MD5 do innego formatu? Kiedys
musialem cos takiego zrobic na jednej maszynce - userzy musieli miec
hasla w LM czy jak sie to tam nazywa (BTW: slabsze od MD5). Nikt
nawet nie wiedzial o migracji, i oczywiscie nie musieli hasla
zmieniac - jedyne co musieli zrobic to sie normalnie zalogowac.

Natomiast jesli chodzi o uzywanie MD5 w sprawach zwiazanych
z bezpieczenstwem bankowym, to opieranie (zwlaszcza nowych)
rozwiazan na tym algorytmie w sytuacji, gdy wszyscy (wlaczajac
Rona Rivesta, czyli autora) zgodnie twierdza, ze jest on martwy,
wydaje sie raczej srednim pomyslem. Nawet jesli akurat dla tego
konkretnego zastosowania jest on nieco mniej martwy niz dla
pozostalych.

>> Owszem. Bo w ta strone to dziala - mozesz wiedziec, ze bank moze
>> haslo
>> rozszyfrowac, ale nie mozesz wiedziec, ze nie moze.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> w ING bank MUSI umiec rozszyfrowac haslo zeby porownac wybrane
> jego znaki. W innych bankach nic noie MUSZĄ - mogą za to zaszyfrowac
> hasla jednokierunkowo i nawet powinni - nie ma powodu by
> hasło pozostawić nie zaszyfrowane lub tworzyc
> procedure odszyfrowania - jesli znasz takie powody to podaj

Sprobuj przeczytac jeszcze raz (lub wiecej) podkreslony fragment.

Uparcie trzymasz sie koncepcji w ktorej to bank (jego "informatyk"
itd) zabiega o nieodwracalnosc Twojego hasla. Jesli zakladasz ze
"informatyk" moze miec ochote na poznanie (i uzycie) hasla, to nie
mozesz jednoczesnie zakladac ze bedzie robil wszystko by to nie
nastapilo. Jesli jestes pewien banku i "jego informatyka" to nie
ma zasadniczego powodu do szyfrowania hasel.

Rozumiesz ogolna idee?

Zwykly pracownik banku i tak nie ma dostepu do zadnych hasel (chyba
ze je sobie bedzie zapisywal podczas rozmowy telefonicznej
z klientami), wiec tu nic to nie zmienia.

> no wlasnie - dla mnie tez sa oczywiste, i ja te dwie metody loginow
> porownuje
> a ty nie chcesz sie na temat porownania wypowiedziec
> 1 - logowanie - pelne haslo mozna podsluchac keylogerem,
> wyrywkowe potrzebuje wielu prob podsluchu

Zgadza sie, do keyloggerow nie mam uwag choc oczywiscie jesli ktos
moze klientowi banku zainstalowac (podlozyc itd) keylogger to ten
ostatni jest w kiepskiej sytuacji.

> 2 - przechowanie hasla - pelne haslo mozna przechowac jako skrót,
> bezpiecznie
> wyrywkowe - musimy w banku miec algorytm na
> odszyfrowanie hasla

Slowem kluczowym jest "mozna". Owszem, bank = jego pracownicy moga to
zrobic ze wzgledu na swoj interes (np. jesli przypadkiem ktos wywali
na smietnik liste hasel to przecietny czlowiek nie bedzie w stanie
poznac zadnego, a kryptoanalityk, pod kilkoma warunkami, nie bedzie
w stanie poznac wszystkich).

Z tym ze mam wrazenie ze Ty nie chcesz zabezpieczac sie przed takim
przypadkiem, a raczej przez samym bankiem i jego pracownikami
(np. adminami maszyn, na ktorych sa owe hasla przechowywane).
A tu niestety sprawa jest przegrana, jedyne co Ci pozostaje to wiara
w ich uczciwosc i/lub w to, ze nie bedzie im sie chcialo (nie beda
potrafili) grzebac w systemie, i/lub w to, ze kara za to jest
surowa i nieuchronna.
--
Krzysztof Halasa

do góry

Użytkownik "Krzysztof Halasa"
> Uparcie trzymasz sie koncepcji w ktorej to bank (jego "informatyk"
> itd) zabiega o nieodwracalnosc Twojego hasla. Jesli zakladasz ze
> "informatyk" moze miec ochote na poznanie (i uzycie) hasla, to nie
> mozesz jednoczesnie zakladac ze bedzie robil wszystko by to nie
> nastapilo. Jesli jestes pewien banku i "jego informatyka" to nie
> ma zasadniczego powodu do szyfrowania hasel.

moge zakladac ze informatyk nie bedzie niczego robil co by sugerowalo
ze moze poznac hasla - czyli bank nie zamowi algorytmu na odwracanie
hasel bo nie ma do tego uzasadnienia a musialby za to zaplacic. Jak
klient zapomni haslo to wystarczy wpisac mu nowe jednorazowe, ktore
sam sobie zmieni - tak banki robią, tak dziala to na unixie i nawet w
windowsach.
Administrator nie zna twojego hasla - moze je co najwyzej skasowac

A powod do szyfrowania hasel jest - przeciez nie moga zostac jawne
- to by byla jawna granda i bląd w projekcie systemu bankowego

> Z tym ze mam wrazenie ze Ty nie chcesz zabezpieczac sie przed takim
> przypadkiem, a raczej przez samym bankiem i jego pracownikami
> (np. adminami maszyn, na ktorych sa owe hasla przechowywane).
> A tu niestety sprawa jest przegrana, jedyne co Ci pozostaje to wiara
> w ich uczciwosc

wierze w rozsadne projekty - odpowiednio dlugie haslo zaszyfrowane
jednokierunkowo daje zabezpieczenie przez bankowymi informatykami.
A hasla z zalozenia odwracalne (jak w ING) moga byc przechowywane
nawet jawnie - nie trzeba by bylo robic procedury odszyfrowania hasla
:-)
*** blad ***

do góry

"blad" <blad201@_W_Y_T_N_I_J_sezam.pl> writes:

> moge zakladac ze informatyk nie bedzie niczego robil co by sugerowalo
> ze moze poznac hasla - czyli bank nie zamowi algorytmu na odwracanie
> hasel bo nie ma do tego uzasadnienia a musialby za to zaplacic.

To sa dwie zupelnie inne rzeczy. Myslisz ze w banku pracuje jeden
informatyk, ktory zamawia projekt systemu i pozniej zajmuje sie jego
obsluga? Bez zartow.

Chociaz moze w jakims malym spoldzielczym...

> Jak
> klient zapomni haslo to wystarczy wpisac mu nowe jednorazowe, ktore
> sam sobie zmieni - tak banki robią, tak dziala to na unixie i nawet w
> windowsach.
> Administrator nie zna twojego hasla - moze je co najwyzej skasowac

Tak zwykle jest :-)
Ale tak jest dlatego, ze wlasnie ten administrator a) nie chce znac
Twojego hasla (bo i po co mu ono, jesli bez niego moze robic w systemie
co mu sie podoba), b) nie chce by ktos mu spojrzal przez ramie podczas
edycji np. /etc/shadow albo innego /etc/passwd.master i by tym sposobem
poznal hasla, c) nie chce by w przypadku np. wlamania, kradziezy
backupu itp. ktos poznal _jego_ haslo, ktore moze dzialac takze na
innych maszynach.

Ok?

Teraz sytuacja z bankiem jest zupelnie inna: a) admin moglby chciec
znac hasla klientow banku i wykorzystac je, b) jest mu zupelnie
obojetne czy po kompromitacji hasel klientow da sie przy ich uzyciu
uzyskac dostep do innych rzeczy (poza bankiem), c) hasla admina,
uprawniajacego do czegos wiecej niz uprawnienia dowolnego klienta,
w ogole nie ma w bazie klientow.

Widzisz roznice?

> A powod do szyfrowania hasel jest - przeciez nie moga zostac jawne
> - to by byla jawna granda i bląd w projekcie systemu bankowego

Moge sie zgodzic co do ostatecznego wniosku jednakze powody sa
zupelnie inne niz "jawna granda i błąd" :-)

> wierze w rozsadne projekty - odpowiednio dlugie haslo zaszyfrowane
> jednokierunkowo daje zabezpieczenie przez bankowymi informatykami.

Musisz mi uwierzyc na slowo ze nie ma takiej gwarancji. Tak jak
napisalem, przeprowadzilem kiedys migracje (calkowicie niewidoczna
dla uzytkownikow) z MD5. Rownie dobrze moglbym wydrukowac hasla
(poprzednio zaszyfrowane MD5) na tablicy ogloszen. Jesli ja moglem
to jak mozesz zakladac ze w banku nie da sie tego zrobic?

Skad wiesz ze bank w ogole uzywa MD5 albo innego SHA-* a nie
np. ROT-13? Tez szyfr :-)

> A hasla z zalozenia odwracalne (jak w ING) moga byc przechowywane
> nawet jawnie - nie trzeba by bylo robic procedury odszyfrowania hasla

Jasne.
Aczkolwiek zwykle dane tego typu sie w jakis sposob szyfruje
(odwracalnie) - po to, by nie bylo widac np. hasel jesli przypadkowo
wydruk albo inna tasma znajdzie sie na smietniku.

Welcome to the real world.
--
Krzysztof Halasa

do góry

Użytkownik "Krzysztof Halasa"
>> ze moze poznac hasla - czyli bank nie zamowi algorytmu na
>> odwracanie
>> hasel bo nie ma do tego uzasadnienia a musialby za to zaplacic.
>
> To sa dwie zupelnie inne rzeczy. Myslisz ze w banku pracuje jeden
> informatyk, ktory zamawia projekt systemu i pozniej zajmuje sie jego
> obsluga? Bez zartow.

odwracasz kota ogonem - napisalem ze BANK nie ma potrzeby
odszyfrowywac hasel wiec dla bezpieczenstwa kazdy rozsadny projekt
przewidzi uzycie haszu czyli szyfrowania w jedna strone

a pojedynczy informatyk nie ma nic do gadania

> Teraz sytuacja z bankiem jest zupelnie inna: a) admin moglby chciec
> znac hasla klientow banku i wykorzystac je, b) jest mu zupelnie
> obojetne czy po kompromitacji hasel klientow da sie przy ich uzyciu

i dlatego, ze admin moglby tego chciec zaden bank tego nie zrobi :-)
c.b.d.o

> napisalem, przeprowadzilem kiedys migracje (calkowicie niewidoczna
> dla uzytkownikow) z MD5.

to proste drogi Watsonie: hash MD5 z podanego hasla sprawdzamy
w starej bazie, ze jest poprawnie podane a nowy zapisujemy w nowej
bazie. Na pewien czas system transakcyjny musialby podsylac dwa hasze
- wg starego i nowego algorytmu
Na dodatek wymusilbym szybsza zmiane hasla i po robocie

> Aczkolwiek zwykle dane tego typu sie w jakis sposob szyfruje
> (odwracalnie) - po to, by nie bylo widac np. hasel jesli przypadkowo
> wydruk albo inna tasma znajdzie sie na smietniku.

nie musisz dodawac ze odwracalnie bo to wlasnie jest jasne
nie wiem dlaczego nie jest jasne ze w innych przypadkach
odracalne szyfrowanie hasla nie jest wskazane
*** blad ***

do góry

"blad" <blad201@_W_Y_T_N_I_J_sezam.pl> writes:

>> To sa dwie zupelnie inne rzeczy. Myslisz ze w banku pracuje jeden
>> informatyk, ktory zamawia projekt systemu i pozniej zajmuje sie jego
>> obsluga? Bez zartow.
>
> odwracasz kota ogonem

Nic z tych rzeczy

> - napisalem ze BANK nie ma potrzeby
> odszyfrowywac hasel wiec dla bezpieczenstwa kazdy rozsadny projekt
> przewidzi uzycie haszu czyli szyfrowania w jedna strone

W porzadku. Wiesz, w tamtym przykladzie ja rowniez uzywalem
szyfrowania w jedna strone. Do momentu w ktorym potrzeby sie
zmienily (LM hash to tez jakies tam szyfrowanie w jedna strone
zreszta, tyle ze inne).

> a pojedynczy informatyk nie ma nic do gadania

Np. admin ktory wlasnie dowiedzial sie od sekretarki ze od pierwszego
jest zwolniony?

> i dlatego, ze admin moglby tego chciec zaden bank tego nie zrobi :-)

Ale bank sklada sie z ludzi. Sam budynek z pewnoscia nic nie zrobi,
najwyzej moze sie zawalic.

> to proste drogi Watsonie: hash MD5 z podanego hasla sprawdzamy
> w starej bazie, ze jest poprawnie podane a nowy zapisujemy w nowej
> bazie. Na pewien czas system transakcyjny musialby podsylac dwa hasze
> - wg starego i nowego algorytmu
> Na dodatek wymusilbym szybsza zmiane hasla i po robocie

No widzisz. To teraz napisz dlaczego admin nie moze tego zrobic.
Moze myslisz ze tak trudno jest zmodyfikowac np. cgi (+ js itd.)?

W ogole nie trzeba dotykac systemu transakcyjnego (w sensie bazy danych
i tej czesci interface HTTP, ktory jej dotyczy).

> nie musisz dodawac ze odwracalnie bo to wlasnie jest jasne
> nie wiem dlaczego nie jest jasne ze w innych przypadkach
> odracalne szyfrowanie hasla nie jest wskazane

Nie ma czegos takiego jak uniwersalne "jest" albo "nie jest wskazane".
Punkt widzenia zalezy od punktu siedzenia.

Przyjmij do wiadomosci ze takie hasla jakie sa uzywane w bankach
(a wiec nie kryptografia asymetryczna) nie sa bezpieczne w sytuacji,
gdy osoba majaca dostep do komputera np. autoryzacyjnego chce ich
uzyc. Nie zalezy to od zadnego szyfrowania itp. Albo dalej wierz
w szyfrowanie w banku, ja w kazdym razie pasuje.
--
Krzysztof Halasa

do góry