Piotr napisał(a):
> Zgadzam się.

Pytanie brzmiało "co złego jest w kluczu", a nie "co złego jest w kluczu
przechowywanym na serwerze bankowym".

--
Marcin Nowakowski
MCR@IRC, ICQ UIN: 53375070, GG: 1824096, GSM: +48 504 583105,
mcr[at]wroclaw[dot]net[dot]pl
GCM/O d- s-:- a-- C++ L P- L+ E---- W+ N++ K- PS+ X++ R- tv b D+ h z+

do góry

Jacek Osiecki napisał(a):
> 2. Monitorowanie dostępu do plików - klucz BPH ma charakterystyczne
> rozszerzenie.

Mój ma rozszerzenie *.avi :>

--
Marcin Nowakowski
MCR@IRC, ICQ UIN: 53375070, GG: 1824096, GSM: +48 504 583105,
mcr[at]wroclaw[dot]net[dot]pl
GCM/O d- s-:- a-- C++ L P- L+ E---- W+ N++ K- PS+ X++ R- tv b D+ h z+

do góry

Dnia Fri, 10 Jun 2005 22:23:50 +0000 (UTC),
osoba podpisana: Jacek Osiecki <j...@c...pl>
napisała:
> tylko jeden przelew, przy kradzieży PINu do karty - może natrzaskać tyle
> operacji ile tylko zechce...
Niby w jaki sposób? (Dla przypomnienia: klucz karty nie opuszcza)

KJ

>
> Pozdrawiam,


--
Rowery treningowe, sprzęt sportowy, siłownie
http://strony.aster.pl/kjonca/aster.xhtml#f4y
"Uchodzic za idiote w oczach kretyna - to rozkosz dla smakosza"
[Georges Courteline]

do góry

Pojawiła się (chyba w piątek) informacja o ostatnim udanym i nieudanym
logowaniu.

--
Marcin Nowakowski
MCR@IRC, ICQ UIN: 53375070, GG: 1824096, GSM: +48 504 583105,
mcr[at]wroclaw[dot]net[dot]pl
GCM/O d- s-:- a-- C++ L P- L+ E---- W+ N++ K- PS+ X++ R- tv b D+ h z+

do góry

Dnia Sat, 11 Jun 2005 22:29:05 +0000 (UTC), Kamil Jonca napisał(a):
> Dnia Fri, 10 Jun 2005 22:23:50 +0000 (UTC),
> osoba podpisana: Jacek Osiecki <j...@c...pl>
> napisała:
>> tylko jeden przelew, przy kradzieży PINu do karty - może natrzaskać tyle
>> operacji ile tylko zechce...
> Niby w jaki sposób? (Dla przypomnienia: klucz karty nie opuszcza)

Ale PIN jest niezmienny, prawda?
Jak karta siedzi w czytniku, a trojan przeczyta sobie PIN do karty - to może
wykonywać kolejne operacje.
W przypadku tokena/kodów jednorazowych jeśli nawet ukradnie ten kod -
może wykonać tylko jedną operację. Owszem, w większości systemów to
wystarczy - bo przelewów zdefiniowanych z użyciem hasła jednorazowego nie
trzeba już potwierdzać kolejnymi hasłami jednorazowymi. Ale gdyby taka
konieczność istniała - dla trojana byłby to problem nie do przejścia.
Zwłaszcza, że przy np. tokenie wprowadzenie konieczności wpisywania hasła
tokenowego przy KAŻDEJ zmianie/operacji nie jest tak problematyczne jak przy
kodach jednorazowych...

Pozdrawiam,
--
Jacek Osiecki j...@c...pl GG:3828944
"Poglądy polityczne mają takie znaczenie w sejmie jak upierzenie u krokodyla"
(c) Tomasz Olbratowski 2004

do góry

Jacek Osiecki wrote:
[...]

> Ale PIN jest niezmienny, prawda?
> Jak karta siedzi w czytniku, a trojan przeczyta sobie PIN do karty - to może
> wykonywać kolejne operacje.
To prawda i (tylko ?) to jest problemem.

> W przypadku tokena/kodów jednorazowych jeśli nawet ukradnie ten kod -
> może wykonać tylko jedną operację.
Z drugiej strony "płachtę' z hasłami można skserować. Więc jedynie token
pozostaje i to taki chroniony hasłem
Z drugiej strony bardzo chciałbym wiedzieć jak wygląda weryfikacja
wskazań tokena po stronie banku.
KJ

do góry

Dnia Wed, 15 Jun 2005 15:32:06 +0200, Kamil Jońca napisał(a):
> Jacek Osiecki wrote:
> [...]

>> Ale PIN jest niezmienny, prawda?
>> Jak karta siedzi w czytniku, a trojan przeczyta sobie PIN do karty - to może
>> wykonywać kolejne operacje.
> To prawda i (tylko ?) to jest problemem.

>> W przypadku tokena/kodów jednorazowych jeśli nawet ukradnie ten kod -
>> może wykonać tylko jedną operację.
> Z drugiej strony "płachtę' z hasłami można skserować.

Ale tylko taką "nie-zdrapkową". Zdrapywalnej nie skserujesz, bo i tak
właściciel będzie wiedział że ktoś go próbuje okraść. Zresztą - jak mamy w
rękach listę haseł jednorazowych ofiary to w ogóle nie ma co kombinować ;)

> Więc jedynie token pozostaje i to taki chroniony hasłem

To jest jedyna dopuszczalna forma tokena - wszystko inne to marna
namiastka...

> Z drugiej strony bardzo chciałbym wiedzieć jak wygląda weryfikacja
> wskazań tokena po stronie banku.

http://www.ebanki.px.pl/technika/uwierz_bankowi.html

Pozdrawiam,
--
Jacek Osiecki j...@c...pl GG:3828944
"Poglądy polityczne mają takie znaczenie w sejmie jak upierzenie u krokodyla"
(c) Tomasz Olbratowski 2004

do góry

Jacek Osiecki wrote:
[...]

>>Z drugiej strony bardzo chciałbym wiedzieć jak wygląda weryfikacja
>>wskazań tokena po stronie banku.
>
>
> http://www.ebanki.px.pl/technika/uwierz_bankowi.html

"System internetowy oczywiście potrafi zweryfikować czy hasło jest
prawidłowe"

To bardzo mało mówi :-(
Bo jeśli bank sobie liczy hasło tak jak to robi token, to pojawia się
dziura ze strony pracowników banku, a jeśli tylko jest w stanie
zweryfikować, to może to i dobrze ?
KJ

do góry

Dnia Wed, 15 Jun 2005 23:08:37 +0200, Kamil Jońca napisał(a):
> Jacek Osiecki wrote:
> [...]

>>>Z drugiej strony bardzo chciałbym wiedzieć jak wygląda weryfikacja
>>>wskazań tokena po stronie banku.

>> http://www.ebanki.px.pl/technika/uwierz_bankowi.html

> "System internetowy oczywiście potrafi zweryfikować czy hasło jest
> prawidłowe"

> To bardzo mało mówi :-(

Ale to że token ma wszyty DES i "tajny klucz" - już trochę mówi.

> Bo jeśli bank sobie liczy hasło tak jak to robi token, to pojawia się
> dziura ze strony pracowników banku, a jeśli tylko jest w stanie
> zweryfikować, to może to i dobrze ?

Otóż mówi tyle, że generalnie to żaden pracownik banku nie musi mieć
możliwości dostępu do kodu przypisanego klientowi - wszystko odbywa się
automagicznie. Owszem, jakiś tam programista czy inny "insajder" może
wszystko - ale tego zagrożenia prawie nie da się wyeliminować. Taki człowiek
zresztą może ukraść pieniądze znacznie łatwiej :)

Większe bezpieczeństwo by było, gdybyśmy w takim tokenie mieli algorytm
niesymetryczny i bank by posiadał tylko klucz publiczny. Tylko że... i tak
przecież bank będzie generował tę parę kluczy :)

Pozdrawiam,
--
Jacek Osiecki j...@c...pl GG:3828944
"Poglądy polityczne mają takie znaczenie w sejmie jak upierzenie u krokodyla"
(c) Tomasz Olbratowski 2004

do góry

Dnia Thu, 16 Jun 2005 06:44:35 +0000 (UTC),
osoba podpisana: Jacek Osiecki <j...@c...pl>
napisała:
> Dnia Wed, 15 Jun 2005 23:08:37 +0200, Kamil Jońca napisał(a):
[...]
> Ale to że token ma wszyty DES i "tajny klucz" - już trochę mówi.
>
No tak ale nie wiemy jak jest weryfikowana odpowiedź tokena.
[...]
>
> Otóż mówi tyle, że generalnie to żaden pracownik banku nie musi mieć
> możliwości dostępu do kodu przypisanego klientowi - wszystko odbywa się
A gdzie to wyczytałeś ? Moze tak jest ale wcale nie musi.
Jeszcze raz: Jeśli bank u siebie "symuluje" token i sprawdza porównuje
wynik swojej symulacji z tym co dostał od klienta, to mamy dziurę.
Jeżeli "tylko" weryfikuje (trochę tak jak z kluczem publiczbny-prywatny)
to nawet tu dziury nie ma i mamy rozwiązanie idealne :-)


[...]
> Większe bezpieczeństwo by było, gdybyśmy w takim tokenie mieli algorytm
O to,to. I
> niesymetryczny i bank by posiadał tylko klucz publiczny. Tylko że... i tak
> przecież bank będzie generował tę parę kluczy :)
W tokenie ? Wątpię.
KJ

--
Rowery treningowe, sprzęt sportowy, siłownie
http://strony.aster.pl/kjonca/aster.xhtml#f4y
People who make no mistakes do not usually make anything.

do góry