zabezpieczenia w bankowosci elektronicznej
Piotr W
Jak to wygląda pod względem bezpieczeństwa dla tzw podpisów
elektronicznych np oferowany obecnie system SBE w InvestBanku
Nie jest to jakikolwiek token lub lista haseł jakie są oferowane przez inne
banki
( tokena używam od roku i jest OK )
Jaka jest szansa na złamanie klucza elektronicznego ?
Co sądzą inni na ten temat ?
--
Piotr W
ts...@poczta.onet.pl
Wojtek Frabinski
wrote:
>Coraz bardziej powszechne są dostępy do konta przez i-net
>Jak to wygląda pod względem bezpieczeństwa dla tzw podpisów
>elektronicznych np oferowany obecnie system SBE w InvestBanku
>Nie jest to jakikolwiek token lub lista haseł jakie są oferowane przez inne
>banki
>( tokena używam od roku i jest OK )
W wypadki IB to warto zwrocic uwage, ze mimo, ze w inecie jest tzw
podpis elektroniczny to przez WAP te same operacje mozna zrobic
wylacznie na haslo,
>Jaka jest szansa na złamanie klucza elektronicznego ?
>Co sądzą inni na ten temat ?
Zastanawialbym sie raczej nie nad problemem zlamania klucza ale nad
mozliwoscia przechwycenia pliku klucza (ktory jest przciez zwyklym
plikiem zapisanym na dyskietce / dysku) i hasla do niego przez
jakiegos trojana.
--
Wojtek Frabinski ICQ 50443653
wojt...@alpha.net.pl
Moja strona Meat Loafa http://www.meatloaf.3a.pl/
galeria kart bankowych http://www.karty.3a.pl/
Richard
To jest taka możliwość???
TZN że ktos wyslalby na mojego kompa jakiegos trojana i wtedy jak ja bym się
logował on by widział moije hasło????
Nie rozumiem, bo przeciez haslo jest szyfrowane 128 bnitowym kluczem, i do
tego jest szyfrowane z pewnym pseudolosowym rozrzutem
przynajmniej tak mi sie wydawalo...
A jest inaczej????
Użytkownik "Wojtek Frabinski" <wojt...@alpha.net.pl> napisał w wiadomości
news:po8iiu4tq3tb6jlj4...@4ax.com...
Pawel Kierski
> O kurde...
> To jest taka możliwość???
>
> TZN że ktos wyslalby na mojego kompa jakiegos trojana i wtedy jak ja bym się
> logował on by widział moije hasło????
Jasne. System nie szyfruje faktu naciśnięcia takiego a nie innego
klawisza. W Windows można to spokojnie przechwycić, zapisywać, filtrować
itp.
Paweł Kierski
pkie...@mks.com.pl
Marcin F
A czy przechwycenie, odszyfrowanie pakietow i wyodrebnienie hasla
jest niemozliwe? Nie mysle oczywiscie o takiej operacji przeprowadzanej
w "czasie rzeczywistym", chodzi mi o bezpieczenstwo bankow ktore nie
stosuja tanow lub tokenow.
Pawel Kierski
> Pawel Kierski wrote:
[...]
> > Jasne. System nie szyfruje faktu naciśnięcia takiego a nie innego
> > klawisza. W Windows można to spokojnie przechwycić, zapisywać, filtrować
> > itp.
>
> A czy przechwycenie, odszyfrowanie pakietow i wyodrebnienie hasla
> jest niemozliwe? Nie mysle oczywiscie o takiej operacji przeprowadzanej
> w "czasie rzeczywistym", chodzi mi o bezpieczenstwo bankow ktore nie
> stosuja tanow lub tokenow.
Przechwycenie nie stanowi zbytnich problemów w Internecie. No,
ewentualnie potrzeba trochę włamań do providerów 8-) Obecnie się
pewnie porawiło, ale kilka lat temu było fatalnie...
Znalezienie hasła na podstawie jednorazowej transakcji - pewnie
też. Im dłuższe i mniej "słownikowe" hasło, tym trudniej. Trudności
rosną wykładniczo, przy pewnym poziomie skomplikowania inne metody
(gazrurka, bejsbol itp. jako argument przekonujący właściciela,
żeby jednak powiedział 8-), podstawienie komuś trojana logującego
naciśnięcia klawisza) są tańsze i szybsze.
Paweł Kierski
pkie...@mks.com.pl
Piotr W
Użytkownik Pawel Kierski <pkie...@mks.com.pl> w wiadomości do grup
dyskusyjnych napisał:agc23t$8ka$1...@news.polbox.pl...
> > > Jasne. System nie szyfruje faktu naciśnięcia takiego a nie innego
> > > klawisza. W Windows można to spokojnie przechwycić, zapisywać,
filtrować
> też. Im dłuższe i mniej "słownikowe" hasło, tym trudniej. Trudności
> rosną wykładniczo, przy pewnym poziomie skomplikowania inne metody
> (gazrurka, bejsbol itp. jako argument przekonujący właściciela,
> żeby jednak powiedział 8-), podstawienie komuś trojana logującego
> naciśnięcia klawisza) są tańsze i szybsze.
> Paweł Kierski
No dobrze, dobrze . . .
To jak wygląda tak głośny ostatnio podpis elektroniczny ?
Jeżeli dobrze trybie to przecież to to samo ?
Jeszcze jedno :
mamy tu do czynienia z zahasłowanym kluczem elektronicznym
trojan przechwyci hasło do klucza a co z samym kluczem ?
Znajduje się on tylko na "moim" nośniku , który był wysyłany do mnie tylko 1
raz.
Przecież w trakcie podpisywania elektronicznego nie jest wysyłany cały klucz
a jedynie jego sciśle określony ciąg przez niego generowany
na dany moment , połączenie . . . etc.
Może się mylę ?
Robert Wicik
news:agc33b$n5$1...@news.tpi.pl...
> No dobrze, dobrze . . .
> To jak wygląda tak głośny ostatnio podpis elektroniczny ?
> Jeżeli dobrze trybie to przecież to to samo ?
Hasło nie wiąże w sposób jednoznaczny wiadomości z nadawcą, a podpis (także
elektroniczny) ma takie zadanie spełniać.
Hasło ktoś może przechwycić i wykorzystać do podpisania innej wiadomości,
niż zamierzał właściciel hasła. To samo może się stać, gdy kotoś przechwyci
nośnik z kluczami do podpisu i hasło do tego nośnika, ale to już mniej
prawdobne.
Myślę, że dopuki klucze do podpisu są chronione, to podpis elektroniczny
jest bezpieczny, zakładając że nie będziemy mieli do czynienia z
przeciwnikiem o nieograniczonych zasobach :-)).
Pozdrawiam
Wojtek Frabinski
<Rich...@poczta.onet.pl> wrote:
>O kurde...
>To jest taka możliwość???
>
>TZN że ktos wyslalby na mojego kompa jakiegos trojana i wtedy jak ja bym się
>logował on by widział moije hasło????
tak.
>Nie rozumiem, bo przeciez haslo jest szyfrowane 128 bnitowym kluczem, i do
>tego jest szyfrowane z pewnym pseudolosowym rozrzutem
Haslo jest szyfrowane ale na drodze do banku. A nie na drodze od
klawiatury do przegladarki. Tutaj mozna przechwycic je stosunkowo
latwo.
I dlatego rozwiazania oparte wylacznie na statycznym hasle sa IMO nie
do przyjecia. Natomiast jesli chodzi o korzystanie z klucza zapisanego
w zwyklym pliku to sprawa jest nieco bardziej skomplkowana.
Teoretycznie wydaje sie, ze nie powinno byc wiekszego problemu, zeby
trojan oprocz przechwytywania klawiatury (w tym rowniez hasla do
klucza) zgral i przeslalal dalej caly plik klucza. O takim programie
jeszcze nie slyszalem ale nie znaczy to ze go nie ma :-).
Dopiero podpis elektorniczny na pozadnie zrealizowanej karcie chipowej
powinien byc odporny na take sztuczki (czyli np podpis w rozumienu
ustawy o podpisie elektronicznym).
Pewnym rozwiazaniem jest tez dodatkowy certyfikat zainstalowany w
przegladarca - jak w Fortisie.
Piotr W
dyskusyjnych napisał:heajiu01alfhf6slk...@4ax.com...
> Haslo jest szyfrowane ale na drodze do banku. A nie na drodze od
> klawiatury do przegladarki. Tutaj mozna przechwycic je stosunkowo
> latwo.
tutaj zgoda
> I dlatego rozwiazania oparte wylacznie na statycznym hasle sa IMO nie
> do przyjecia. Natomiast jesli chodzi o korzystanie z klucza zapisanego
> w zwyklym pliku to sprawa jest nieco bardziej skomplkowana.
> Teoretycznie wydaje sie, ze nie powinno byc wiekszego problemu, zeby
> trojan oprocz przechwytywania klawiatury (w tym rowniez hasla do
> klucza) zgral i przeslalal dalej caly plik klucza. O takim programie
> jeszcze nie slyszalem ale nie znaczy to ze go nie ma :-).
tak też zgoda
> Dopiero podpis elektorniczny na pozadnie zrealizowanej karcie chipowej
> powinien byc odporny na take sztuczki (czyli np podpis w rozumienu
> ustawy o podpisie elektronicznym).
ale tego w bankach ja bynajmniej nie słyszałem
> Pewnym rozwiazaniem jest tez dodatkowy certyfikat zainstalowany w
> przegladarca - jak w Fortisie.
> Wojtek Frabinski ICQ 50443653
ale tutaj, czyli w IB jest instalowany "jakiś" certyfikat IB
+ klucz w pliku ( zahasłowany )
piszę jakiś bo nie do końca kumam
Jak tu się mają zabezpieczenia ?
--
Piotr W
ts...@poczta.onet.pl
Wojtek Frabinski
wrote:
>> Dopiero podpis elektorniczny na pozadnie zrealizowanej karcie chipowej
>> powinien byc odporny na take sztuczki (czyli np podpis w rozumienu
>> ustawy o podpisie elektronicznym).
>
>ale tego w bankach ja bynajmniej nie słyszałem
Ustawa dopiero staruje.
A czytniki kart chipowych sa stosowane obecbie np, w internetowych
biurach maklerskich.
>
>ale tutaj, czyli w IB jest instalowany "jakiś" certyfikat IB
>+ klucz w pliku ( zahasłowany )
>piszę jakiś bo nie do końca kumam
>
>Jak tu się mają zabezpieczenia ?
logowanie nr klienta i numrycznym haslem
Przelew w inecie "podpisuje" sie kluczem -po prostu wskazuje sie na
dysku/dyskietce plik i podaje haslo klucza.
Marcin F
Wojtek Frabinski wrote:
>
> Teoretycznie wydaje sie, ze nie powinno byc wiekszego problemu, zeby
> trojan oprocz przechwytywania klawiatury (w tym rowniez hasla do
> klucza) zgral i przeslalal dalej caly plik klucza. O takim programie
> jeszcze nie slyszalem ale nie znaczy to ze go nie ma :-).
a to dziwne bo trojanow uzywalem wlasnie po to by miec dostep do dyskow
--
Sława, pieniądze i kobiety - Medżik DiscoPolo Mejker
Odwiedź już dziś: http://www.mdpm.bzi.pl !!!
(zanim zrobi to Twoja konkurencja!)
Vizvary II Istvan
"Piotr W" <ts...@poczta.onet.pl> wrote in message
news:agb629$c96$1...@news.tpi.pl...
> Coraz bardziej powszechne są dostępy do konta przez i-net
> Jak to wygląda pod względem bezpieczeństwa dla tzw podpisów
> elektronicznych np oferowany obecnie system SBE w InvestBanku
> Nie jest to jakikolwiek token lub lista haseł jakie są oferowane przez
inne
> banki
> ( tokena używam od roku i jest OK )
Co do tokenow, list hasel jedno i wielorazowych : wszelkie tego typu
narzedzia sa oparte na zasadach takich, że bank jest w posiadaniu tych
samych informacji (sluzacych do autoryzacji) co uzytkownik. W efekcie
rozmywa sie odpowiedzialnosc - w razie udanego ataku na bank (czy tez raczej
na konto klienta) nie wiadomo czy dokonal to cwany klient i sie wypiera
transakcji, jego znajomy (tesciowa ?) - czy tez dokonal to jakis pracownik
banku podszywajac sie pod tozsamosc klienta. Ten aspekt sprawy z oczywistych
wzgledow nie jest to zbytnio naglosniony przez bankow .
W przypadku prawidlowo zrealizowanego systemu opartego o podpis cyfrowy
roznica jest taka, ze
1. bank nigdy nie byl i nie jest w posiadaniu tej "tajemnicy" co klientowu
sluzy do autoryzacji (Bank jest w posiadaniu tylko danych służacych do
weryfikacji podpisu, ale nie danych służacych do ich sporzadzania)
2. bank do kazdej transakcji posiada autoryzowany przez klienta dokument.
Dokument którego autentyczność można bez kłopotów sprawdzić.
W razie udanego ataku na bank(na konto klienta) sprawa jest jasna
- jest dokument : "atak" dokonał klient, niech szuka winowajce u siebie (w
firmie)
- nie ma dokumentu : przepraszamy klienta, "zle zaksiegowana operacja",
idzie w straty, dochodzenie jest wewnetrzne.
Bynajmniej nie wynika z tego, że klient jest bardziej bezpieczny. To znaczy
jest całkowicie bezpieczny od manipulacji ze strony pracownikow banku. Bank
też jest bezpieczny - nawet cien podejrzenia nie może paść na pracownikow
banku - oni fizycznie nie sa w stanie podrobic podpisu klienta. Nawet
wszyscy najbardziej uprawnieni informatycy bankowi na kupie.
> Jaka jest szansa na złamanie klucza elektronicznego ?
Już podpisany dokument jest pewny. Kradziez klucza tez można wykluczyć (gdy
jest w karcie kryptograficznej). Inne ataki nie sa jeszcze znane, ale
teoretycznie sa mozliwe (wyłudzenie podpisu)
Generalnie jest taka zasada - podpis cyfrowy nie uwalnia od dbania o
bezpieczenstwo komputera. Wprost przeciwnie. Stacja robocza, która służy do
tego by na nim dokonac poważne operacje finansowe, niezaleznie od rodzaju
stosowanej autoryzacji, powinno być maksymalnie bezpieczna.
Vizvary Istvan
Robert Wicik
news:agcmgm$2ls$1...@news2.tpi.pl...
> na konto klienta) nie wiadomo czy dokonal to cwany klient i sie wypiera
> transakcji, jego znajomy (tesciowa ?) - czy tez dokonal to jakis pracownik
> banku podszywajac sie pod tozsamosc klienta. Ten aspekt sprawy z
oczywistych
Właśnie w skrócie wyjasniłeś różnice między zabezpieczeniami-kryptografią
symetryczną i asymetryczną.
W symetrycznej dwie strony mają ten sam klucz, w asymetrycznje tylko jedna
:-).
> Już podpisany dokument jest pewny. Kradziez klucza tez można wykluczyć
(gdy
> jest w karcie kryptograficznej). Inne ataki nie sa jeszcze znane, ale
> teoretycznie sa mozliwe (wyłudzenie podpisu)
//...//
A tu podstawowy problem - podpisał Kowalski, czy ktoś kto akurat był w
posiadaniu kluczy Kowalskiego, dlatego trzeba chronić klucze. Kopia zapasowa
kluczy może się jeszcze znajdować w instytucji je generującej na wypadek np.
odtworzenia w przypadku zagubienia ...
Pozdrawiam
Robert Wicik
Pawel Kierski
> Użytkownik "Vizvary II Istvan" <vi...@poczta.onet.pl> napisał w wiadomości
> news:agcmgm$2ls$1...@news2.tpi.pl...
> > Już podpisany dokument jest pewny. Kradziez klucza tez można wykluczyć
> (gdy
> > jest w karcie kryptograficznej). Inne ataki nie sa jeszcze znane, ale
> > teoretycznie sa mozliwe (wyłudzenie podpisu)
> //...//
> A tu podstawowy problem - podpisał Kowalski, czy ktoś kto akurat był w
> posiadaniu kluczy Kowalskiego, dlatego trzeba chronić klucze.
Albo dodatkowo zabezpieczać urządzenia/procedury PIN-em lub
identyfikacją biometryczną.
> Kopia zapasowa
> kluczy może się jeszcze znajdować w instytucji je generującej na wypadek np.
> odtworzenia w przypadku zagubienia ...
To chyba nawet w ustawie zostało przewidziane.
Paweł Kierski
pkie...@mks.com.pl
Pawel Kierski
> > Przechwycenie nie stanowi zbytnich problemów w Internecie. No,
> > Znalezienie hasła na podstawie jednorazowej transakcji - pewnie
> > też. Im dłuższe i mniej "słownikowe" hasło, tym trudniej. Trudności
> > rosną wykładniczo, przy pewnym poziomie skomplikowania inne metody
> > (gazrurka, bejsbol itp. jako argument przekonujący właściciela,
> > żeby jednak powiedział 8-), podstawienie komuś trojana logującego
> > naciśnięcia klawisza) są tańsze i szybsze.
> > Paweł Kierski
>
> No dobrze, dobrze . . .
> To jak wygląda tak głośny ostatnio podpis elektroniczny ?
> Jeżeli dobrze trybie to przecież to to samo ?
Doczytałem - wygląda to na asymetryczne klucze. Czyli coś takiego,
na czym będzie funkcjonować podpis elektroniczny.
> Jeszcze jedno :
> mamy tu do czynienia z zahasłowanym kluczem elektronicznym
> trojan przechwyci hasło do klucza a co z samym kluczem ?
Jak jest w praktyce przechowywany? Jeśli gdzieś w pliku, i to
jeszcze o w miarę dobrze ustalonych parametrach, to do "wyłuskania"
żaden problem...
Ideałem jest zewnętrzne urządzenie, które od strony komputera
można jedynie poprosić o podpisanie/zaszyfrowanie ciągu danych.
Dodatkowo takie urządzenie w momencie przyjęcia żądania powinno
prosić o PIN, albo jakoś inaczej weryfikować osobę "podpisującą".
> Znajduje się on tylko na "moim" nośniku , który był wysyłany do mnie
> tylko 1 raz.
> Przecież w trakcie podpisywania elektronicznego nie jest wysyłany cały
> klucz a jedynie jego sciśle określony ciąg przez niego generowany
> na dany moment , połączenie . . . etc.
W przypadku kluczy asymetrycznych - faktycznie na podstawie jednej
transakcji nie da się nic sensownego uzyskać. Poprzednio pisałem
o sytuacji, gdy hasło służy do autoryzacji (nawet, jeśli przesyłane
jest nie hasło, ale np. losowany przez serwer ciąg szyfrowany
przy użyciu hasła). Ale jak widać system InvestBanku ma dużo słabszy
punkt w innym miejscu: klucz prywatny i hasło można stosunkowo łatwo
przechwycić.
Paweł Kierski
pkie...@mks.com.pl
Piotr W
> Ale jak widać system InvestBanku ma dużo słabszy
> punkt w innym miejscu: klucz prywatny i hasło można stosunkowo łatwo
> przechwycić.
> Paweł Kierski
no dobrze
przechwycić po łączach w trakcie przyznawania ?
czy też już u petenta,
zakładam że klucz jest na nośniku wyjmowalnym
całość (także komp) zbezpieczona przed dostępem osób trzecich
łącze do i-netu przez kochaną TePSę?
--
Piotr W
ts...@poczta.onet.pl
Robert Wicik
> przechwycić po łączach w trakcie przyznawania ?
> czy też już u petenta,
> zakładam że klucz jest na nośniku wyjmowalnym
> całość (także komp) zbezpieczona przed dostępem osób trzecich
> łącze do i-netu przez kochaną TePSę?
Na tym się nie znam.
Ale najlepiej jak klucz się sam broni np. w karcie, z której nie można
(przynajmniej teoretycznie) go wyczytać.
Pozdrawiam
Robert Wicik
Wojtek Frabinski
wrote:
>
>no dobrze
>przechwycić po łączach w trakcie przyznawania ?
>czy też już u petenta,
na komputerze klienta
>zakładam że klucz jest na nośniku wyjmowalnym
>całość (także komp) zbezpieczona przed dostępem osób trzecich
>łącze do i-netu przez kochaną TePSę?
Jesli komp jest zabezpieczony przed dzialaniem osob trzecich zarowno
bezposrednio jak i przez siec to ok. Ale ile kompow tak na prawde
zabezpieczonych ?
U przecietnego usera zainstalowanie trojana to nie problem.
Pawel Kierski
> Użytkownik Pawel Kierski <pkie...@mks.com.pl> w wiadomości do grup
> dyskusyjnych napisał:age2d6$uvq$1...@news.polbox.pl...
> > Ale jak widać system InvestBanku ma dużo słabszy
> > punkt w innym miejscu: klucz prywatny i hasło można stosunkowo łatwo
> > przechwycić.
> > Paweł Kierski
>
> no dobrze
> przechwycić po łączach w trakcie przyznawania ?
Jeśli jest tak przesyłany - można.
> czy też już u petenta,
> zakładam że klucz jest na nośniku wyjmowalnym
... który raz na jakiś czas musi się znaleźć w kompie...
> całość (także komp) zbezpieczona przed dostępem osób trzecich
OK.
> łącze do i-netu przez kochaną TePSę?
Dynamiczny IP trochę utrudni pracę trojanowi. Ale wystarczy
napisać takiego, który wychwytuje pojawienie się pliku klucza
w systemie plików (włożenie nośnika), zapisuje go sobie i zaczyna
logować naciśnięcia klawiszy. Potem to wszystko mailem (po wykryciu
aktywnego połącznia) na darmowe konto i już...
A dobrze zabezpieczona karta/czytnik po prostu nie da szany.
Paweł Kierski
pkie...@mks.com.pl
Piotr W
> > przechwycić po łączach w trakcie przyznawania ?
> Jeśli jest tak przesyłany - można.
niestety :-(((((
> > czy też już u petenta,
> > zakładam że klucz jest na nośniku wyjmowalnym
> ... który raz na jakiś czas musi się znaleźć w kompie...
to jest oczywiste
> > łącze do i-netu przez kochaną TePSę?
> Dynamiczny IP trochę utrudni pracę trojanowi. Ale wystarczy
> napisać takiego, który wychwytuje pojawienie się pliku klucza
> w systemie plików (włożenie nośnika), zapisuje go sobie i zaczyna
> logować naciśnięcia klawiszy. Potem to wszystko mailem (po wykryciu
> aktywnego połącznia) na darmowe konto i już...
zrozumiałe
> A dobrze zabezpieczona karta/czytnik po prostu nie da szany.
> Paweł Kierski
Jednym słowem :
wypada czekać na "prawdziwy podpis elektroniczny"
PS
Pytałem jako autor tematu o InvestBank
Czy któryś z działających już e-banków korzysta z dokładnie
takiej formy podpisu jak proponuje IB?
---
Piotr W
ts...@poczta.onet.pl
Wojtek Frabinski
wrote:
>Pytałem jako autor tematu o InvestBank
>Czy któryś z działających już e-banków korzysta z dokładnie
>takiej formy podpisu jak proponuje IB?
>
Z tym, ze tutaj haslo logowania moze byc dlugie, alfanumeryczne i przy
logowaniu podaje sie tylko czesc losowo wybranych znakow z calego
hasla. Wiec tutaj jednorazowo przychwycone logowanie raczej nie
wystarczy.
W wypadku IB trzeba tez pamietac, ze za pomoca tego samego numeru
klienta i hasla, ale juz bez jakiegolokwek klucza te same opracje
mozna wykonac przez WAP ! Mam nadzieje ze ten kanal mozna
przynajmniej skutecznie zablokowac, musze sprawdzic jaka jest
procedura aktywacji.
Jednak na razie, dopoki nie ma porzadnie zrealizowanego (i
zastosowanego w bankowosci internetowej) podpisu na karcie
kryptografciznej, osobiscie wole zabezpieczenia oparte na TANach lub
tokenach (mimo zagrozen opisanych dokladnie przez Vizvardego).
PS, a i tak na szarym koncu bezpeiczenstwa lezy sobie i chichutko
chlipie Citi ;-) a zaraz po nim LGnet.
blad
> wypada czekać na "prawdziwy podpis elektroniczny"
> PS
> Pytałem jako autor tematu o InvestBank
> Czy któryś z działających już e-banków korzysta z dokładnie
> takiej formy podpisu jak proponuje IB?
Fortis Bank w systemie planet, BPH-PBK w sezamie i chyba ING-BSK z tym ze tylko
Fortis stosuje sie do procedur zwiazanych z podpisem elektronicznym, a inni
uzywaja jedynie klucza do podpisu
*** blad ***
blad
> Jednak na razie, dopoki nie ma porzadnie zrealizowanego (i
> zastosowanego w bankowosci internetowej) podpisu na karcie
> kryptografciznej, osobiscie wole zabezpieczenia oparte na TANach lub
> tokenach (mimo zagrozen opisanych dokladnie przez Vizvardego).
W tym rankingu ostatniego KomputerSwiata, z ktorego jak zwykle wszyscy sie
wysmiewali zauwazylem jedna pozytywna rzecz - po raz pierwszy w rankingach
wiecej cenione byly systemy z podpisem elektronicznym niz te z tokenem, czy
TANani
> PS, a i tak na szarym koncu bezpeiczenstwa lezy sobie i chichutko
> chlipie Citi ;-) a zaraz po nim LGnet.
co nie przeszkadzalo citi chwalic sie, ze ma "produkt roku" (nie pamietam
ktorego)
*** blad ***
Piotr W
napisał:3d2a...@news.vogel.pl...
> > PS, a i tak na szarym koncu bezpeiczenstwa lezy sobie i chichutko
> > chlipie Citi ;-) a zaraz po nim LGnet.
> co nie przeszkadzalo citi chwalic sie, ze ma "produkt roku" (nie pamietam
> ktorego)
> *** blad ***
reklama dźwignią bankowości ( było handlu )
--
Piotr W
ts...@poczta.onet.pl
--
Piotr W
ts...@poczta.onet.pl
Piotr W
Użytkownik Wojtek Frabinski <wojt...@alpha.net.pl> w wiadomości do grup
dyskusyjnych napisał:pc8liu0isv728agt7...@4ax.com...
> On Tue, 9 Jul 2002 10:32:55 +0200, "Piotr W" <ts...@poczta.onet.pl>
> wrote:
> >Czy któryś z działających już e-banków korzysta z dokładnie
> >takiej formy podpisu jak proponuje IB?
> >
> Podobnie jest w ING BSK i w BPHPBK.
> klienta i hasla, ale juz bez jakiegolokwek klucza te same opracje
> mozna wykonac przez WAP ! Mam nadzieje ze ten kanal mozna
> przynajmniej skutecznie zablokowac, musze sprawdzic jaka jest
> procedura aktywacji.
GSM WAP i GSM SMS są blokowane skutecznie w czasie rejestracji
Dosłownie wykreślasz te kanały z listy (myślę że są wykreślane skutecznie)
> Jednak na razie, dopoki nie ma porzadnie zrealizowanego (i
> zastosowanego w bankowosci internetowej) podpisu na karcie
> kryptografciznej, osobiscie wole zabezpieczenia oparte na TANach lub
> tokenach (mimo zagrozen opisanych dokladnie przez Vizvardego).
Zgadzam się w 101%-tach
Używam takie jedno konto z tokenem
>
> PS, a i tak na szarym koncu bezpeiczenstwa lezy sobie i chichutko
> chlipie Citi ;-) a zaraz po nim LGnet.
> Wojtek Frabinski ICQ 50443653
Co ?
Aż tak tragicznie stoją z zabezpieczeniami ?
--
Piotr W
ts...@poczta.onet.pl
Marcin F
Piotr W wrote:
> > PS, a i tak na szarym koncu bezpeiczenstwa lezy sobie i chichutko
> > chlipie Citi ;-) a zaraz po nim LGnet.
> > Wojtek Frabinski ICQ 50443653
>
> Co ?
> Aż tak tragicznie stoją z zabezpieczeniami ?
>
Nie wiem jak dokladnie Citi ale Lg ma stale hasla logowania i akceptacji
transakcji. Ani jedno nie jest nawet maskowane (tak jak haslo logowania
w BPHPBK). Jedyne co poprawia bezpieczenstwo to mozliwosc ustanowienia
limitu dziennego obciazenia rachunku dla danego kanalu dostepu (zdjecie
limitu wymaga potwierdzenia dyspozycji przez oddzwonienie do klienta,
przynajmiej na razie bo z tego co wiem planuja zrobic zarzadzanie
limitami na stronie transakcyjnej).
Vizvary II Istvan
"Robert Wicik" <RWi...@poczta.onet.pl> wrote in message
news:agdt5i$55t$1...@news.onet.pl...
> Użytkownik "Vizvary II Istvan" <vi...@poczta.onet.pl> napisał w wiadomości
> news:agcmgm$2ls$1...@news2.tpi.pl...
> > na konto klienta) nie wiadomo czy dokonal to cwany klient i sie wypiera
> > transakcji, jego znajomy (tesciowa ?) - czy tez dokonal to jakis
pracownik
> > banku podszywajac sie pod tozsamosc klienta. Ten aspekt sprawy z
> oczywistych
> > //...//
> Właśnie w skrócie wyjasniłeś różnice między zabezpieczeniami-kryptografią
> symetryczną i asymetryczną.
> W symetrycznej dwie strony mają ten sam klucz, w asymetrycznje tylko jedna
> :-).
Sama kryptografia asymetryczna jeszcze nie powoduje, że zaistnieją warunki
rozdziału odpowiedzialnosci. Dlatego pisze o PRAWIDLOWO zrealizowanych
systemach.
To jest podstawowy warunek niezaprzeczalnosci wiec w efekcie warunek
rozszerzenia oferty lub zawieranie umowy na odleglosc (bez obecnosci w
oddziale).
> > Już podpisany dokument jest pewny. Kradziez klucza tez można wykluczyć
> (gdy
> > jest w karcie kryptograficznej). Inne ataki nie sa jeszcze znane, ale
> > teoretycznie sa mozliwe (wyłudzenie podpisu)
> //...//
> A tu podstawowy problem - podpisał Kowalski, czy ktoś kto akurat był w
> posiadaniu kluczy Kowalskiego, dlatego trzeba chronić klucze. Kopia
zapasowa
> kluczy może się jeszcze znajdować w instytucji je generującej na wypadek
np.
> odtworzenia w przypadku zagubienia ...
Zasada jest taka, że kluczy do szyfrowania tworzy sie w miare mozliwosci
kopie (by w razie zagubienia mozna bylo odszyfrowac dokument). Kluczy
sluzace do podpisu nie backapuje się. Generuje sam klient i zwykle sam go
nawet nie zna. Zagubione klucze podpisujace zwykle się uniewaznia.
Vizvary
Vizvary II Istvan
> Jednak na razie, dopoki nie ma porzadnie zrealizowanego (i
> zastosowanego w bankowosci internetowej) podpisu na karcie
> kryptografciznej, osobiscie wole zabezpieczenia oparte na TANach lub
> tokenach (mimo zagrozen opisanych dokladnie przez Vizvardego).
To nie jest kwestia woli klienta. Po prostu jesli sie wymaga
niezaprzeczalnosc transakcji ze strony klienta, to nie ma innej drogi niz
taki czy inny sposob realizacji podpisu cyfrowego.
Rozum - to nie jest kwestia ZABEZPIECZENIA, tylko dokładny rozdział
odpowiedzialnosci, niezaprzeczalnosc transakcji i podpisanie umow na
odległosc. Zupelnie inne funkcje, niz zapewnienie poufnosci pomiedzy
stronami, ktore sobie w założeniach ufaja, bo posluguja sie umowionymi i
znanymi obu stronom sygnałami (hasla jedno i wielorazowe lub wskazanie
topkena).
I zeby nie bylo nieporozumienia - w zaden sposob nie proponuje zastapic
tokeny czy tany karta (chyba, że bedzie to jedna dodatkowa funkcja jakiejs
karty, wiec nijako "przy okazji"). Tam gdzie tokeny lub TANy wystarczaly,
tam podejrzewam ze wystarczaja jeszcze długo.
Vizvary
Vizvary II Istvan
> > posiadaniu kluczy Kowalskiego, dlatego trzeba chronić klucze.
> Albo dodatkowo zabezpieczać urządzenia/procedury PIN-em lub
> identyfikacją biometryczną.
Kilka lat temu mialem taki ulubiony (chociaz makabryczny) przyklad na
zastosowanie identyfikacji biometrycznej czy do podpisu czy do odblokowania
urzadzenia podpisujacego - delikwent po wypadku jeszcze ostatnim wysilkiem
zdazylby przelac swoje oszczednosci na rzecz personelu karetki. Od roku wole
tym przykladem sie nie poslugiwac (szczegolnie ze pisze to z Lodzi) ale
zwroc uwage, że podpis cyfrowy powinno byc WYRAZEM WOLI, wiec cos, co
pozbawiony swiadomosci klient nie jest w stanie dokonac. Wiec cos co wie.
oki co pozostanie PIN kod lub (na przyklad) hasla jednorazowe.
> > Kopia zapasowa
> > kluczy może się jeszcze znajdować w instytucji je generującej na wypadek
np.
> > odtworzenia w przypadku zagubienia ...
>
> To chyba nawet w ustawie zostało przewidziane.
Tak? Gdzie?
Vizvary
Ardi
Ardi
Piotr W
Użytkownik Ardi <ar...@go2.pl> w wiadomości do grup dyskusyjnych
napisał:agfkps$jbb$1...@korweta.task.gda.pl...
> A po co wykreślać SMS ? Przecież to kanał pasywny (mBank).
> Ardi
>
>
--
Piotr W
ts...@poczta.onet.pl
Maciek Pasternacki
> Co do tokenow, list hasel jedno i wielorazowych : wszelkie tego typu
> narzedzia sa oparte na zasadach takich, że bank jest w posiadaniu tych
> samych informacji (sluzacych do autoryzacji) co uzytkownik. W efekcie
> rozmywa sie odpowiedzialnosc - w razie udanego ataku na bank (czy tez raczej
> na konto klienta) nie wiadomo czy dokonal to cwany klient i sie wypiera
> transakcji, jego znajomy (tesciowa ?) - czy tez dokonal to jakis pracownik
> banku podszywajac sie pod tozsamosc klienta. Ten aspekt sprawy z oczywistych
> wzgledow nie jest to zbytnio naglosniony przez bankow .
Nieprawda. To znaczy, bank (o ile nie są skrajnymi kretynami ani
niczym w tym duchu) nie posiada odszyfrowanej listy moich haseł
jednorazowych, tylko (w prostszym przypadku) jednokierunkowe funkcje
skrótu każdego z tych haseł. W ciekawszej implementacji haseł
jednorazowych, każde kolejne hasło jest jednokierunkową funkcją skrótu
poprzedniego, a bank (czy cokolwiek innego dokonującego autoryzacji)
posiada tylko wartość jednokierunkowej funkcji skrótu ostatniego
hasła. Ja podaję ostatnie hasło z listy, bank sprawdza, czy wartość
funkcji skrótu jest taka sama, jeżeli tak, zapamiętuje podane przeze
mnie hasło (już użyte, czyli tym samym odtajnione) jako wartość
funkcji skrótu hasła kolejnego. Nie wiem, jak wyglądają algorytmy
tokenów, tutaj już jest większe prawdopodobieństwo, że bank posiada
dokładnie tę samą tajemnicę (chyba, że wymyślili coś równie sprytnego,
jak powyżej); token działa głównie na zasadzie ,,security by
obscurity'', a jak wszyscy (mam nadzieję) wiedzą, ,,security by
obscurity is no security''.
Jednokierunkowa funkcja skrótu to jest taka funkcja, której
odwrotności nie można obliczyć (a konkretniej, złożoność obliczeniowa
odwrotności takiej funkcji jest większa niż metoda brute force --
wyliczanie wartości funkcji kolejno dla wszystkich możliwych danych
wejściowych). Funkcjami takimi są np. algorytm MD5, SHA1 czy uniksowy
crypt().
> W przypadku prawidlowo zrealizowanego systemu opartego o podpis cyfrowy
> roznica jest taka, ze
> 1. bank nigdy nie byl i nie jest w posiadaniu tej "tajemnicy" co klientowu
> sluzy do autoryzacji (Bank jest w posiadaniu tylko danych służacych do
> weryfikacji podpisu, ale nie danych służacych do ich sporzadzania)
> 2. bank do kazdej transakcji posiada autoryzowany przez klienta dokument.
> Dokument którego autentyczność można bez kłopotów sprawdzić.
> W razie udanego ataku na bank(na konto klienta) sprawa jest jasna
> - jest dokument : "atak" dokonał klient, niech szuka winowajce u siebie (w
> firmie)
> - nie ma dokumentu : przepraszamy klienta, "zle zaksiegowana operacja",
> idzie w straty, dochodzenie jest wewnetrzne.
>
> Bynajmniej nie wynika z tego, że klient jest bardziej bezpieczny. To znaczy
> jest całkowicie bezpieczny od manipulacji ze strony pracownikow banku. Bank
> też jest bezpieczny - nawet cien podejrzenia nie może paść na pracownikow
> banku - oni fizycznie nie sa w stanie podrobic podpisu klienta. Nawet
> wszyscy najbardziej uprawnieni informatycy bankowi na kupie.
Tutaj już racja. W przypadku haseł jednorazowych itp. bank nie jest w
stanie udowodnić, że nie przechowywali haseł w postaci odszyfrowanej
(przez pewien okres czasu bank był w posiadaniu postaci odszyfrowanej
i mógł jej nie wykasować). W przypadku podpisu nie ma możliwości jego
podrobienia.
Zainteresowanym polecam cegiełkę ,,Kryptografia dla praktyków'' pana
Bruce'a Schneiera.
--japh
--
__ Maciek Pasternacki <mac...@japhy.fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { ...lecz i ten dzień przeżyjemy, może nawet znów nam kiedyś
,|{-}|}| }\/ będzie miło na tej ziemi, co umiera pod podeszwą... }
\/ |____/ ( J. Podsiadło ) -><-
Maciek Pasternacki
> To jak wygląda tak głośny ostatnio podpis elektroniczny ?
> Jeżeli dobrze trybie to przecież to to samo ?
W podpisie elektronicznym masz do czynienia z tzw. kluczem prywatnym i
publicznym. Klucz prywatny masz tylko ty, klucz publiczny zna cały
świat. Jednego klucza nie da się (w sensownym czasie) otrzymać z
drugiego. Dane zaszefrowane kluczem publicznym da się odszyfrować
tylko odpowiednim kluczem prywatnym (szyfrowanie) i na odwrót
(podpis). W przypadku podpisu szyfruje się nie całą wiadomość, ale
wartość jednokierunkowej funkcji skrótu tej wiadomości. W oryginalnym
algorytmie nie ma żadnych haseł.
Hasło do klucza polega na tym, że plik z kluczem prywatnym masz
dodatkowo zaszyfrowany ,,na hasło''. Dopiero po podaniu hasła możesz
(czy ty, czy ten pan, który przegrał plik z Twoim kluczem na
dyskietkę, kiedy ,,coś sprawdzał w sieci'') odczytać swój klucz
prywatny i zaszyfrować nim coś (tzn. podpisać) bądź odszyfrować
(odczytać wiadomość przeznaczoną tylko dla ciebie).
W przypadku podpisu elektronicznego hasło, ani żadna inna wrażliwa
wiadomość, nie jest przesyłana przez sieć przy każdej transakcji (ani
w postaci czystej, ani w zaszyfrowanej), bo autoryzacja nie opiera się
na znajomości wspólnego sekretu (hasła), tylko na posiadaniu
odpowiednich połówek sekretu (klucza publicznego i prywatnego).
Jak w poście niżej, odsyłam do ,,Kryptografii dla praktyków'' Bruce'a
Schneiera.
> mamy tu do czynienia z zahasłowanym kluczem elektronicznym
> trojan przechwyci hasło do klucza a co z samym kluczem ?
> Znajduje się on tylko na "moim" nośniku , który był wysyłany do mnie tylko 1
> raz.
> Przecież w trakcie podpisywania elektronicznego nie jest wysyłany cały klucz
> a jedynie jego sciśle określony ciąg przez niego generowany
> na dany moment , połączenie . . . etc.
Trojan nie przechwyci hasła z sieci (to robią sniffery), bo ono nie
jest przesyłane. Trojan jest programem uruchomionym na twoim
komputerze. On przechwyci hasło po drodze między klawiaturą a
programem (przeglądarką czy czym tam innym). A plik z kluczem po
prostu odczyta z dysku. Ani jedno, ani drugie nie stanowi problemu, o
ile twoj komputer nie jest dośc mocno pozabezpieczany.
--japhy
--
__ Maciek Pasternacki <mac...@japhy.fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { ...Boże Ciało. Pół rynku, albo trzy czwarte rynku,
,|{-}|}| }\/ oblepione wiernymi. Czemuś jestem wierny,
\/ |____/ więc czuję się u siebie... } ( M. Świetlicki ) -><-
Piotr W
dyskusyjnych napisał:87eled8...@lizard.localdomain...
> W podpisie elektronicznym masz do czynienia z tzw. kluczem prywatnym i
> publicznym. Klucz prywatny masz tylko ty, klucz publiczny zna cały
tego nigdy nie można być pewnym ;-)
> W przypadku podpisu elektronicznego hasło, ani żadna inna wrażliwa
> wiadomość, nie jest przesyłana przez sieć przy każdej transakcji (ani
> w postaci czystej, ani w zaszyfrowanej), bo autoryzacja nie opiera się
> na znajomości wspólnego sekretu (hasła), tylko na posiadaniu
> odpowiednich połówek sekretu (klucza publicznego i prywatnego).
mam jednak wątpliwości czy przesyłanie klucza prywatnego
w trakcie jego nadania przez i-net nie umożliwia jego przechwycenie
( mimo że przekaz szyfrowany SSL )
> Trojan nie przechwyci hasła z sieci (to robią sniffery)
> --japhy
> __ Maciek Pasternacki <mac...@japhy.fnord.org>
http://japhy.fnord.org/ ]
trojany , sniffery . . .
czy dobry antywiral , i bezwzględny brak dostępu osób trzecich
są w stanie zabezpieczyc skutecznie komp
No . . . prawie
--
Piotr W
ts...@poczta.onet.pl
Wojtek Frabinski
wrote:
>
>trojany , sniffery . . .
>czy dobry antywiral , i bezwzględny brak dostępu osób trzecich
>są w stanie zabezpieczyc skutecznie komp
>No . . . prawie
I jeszcze firewall, no i ostrozne dawanie uprawnien programom, kotre o
nie prosza
Marcin F
Wojtek Frabinski wrote:
> >trojany , sniffery . . .
> >czy dobry antywiral , i bezwzględny brak dostępu osób trzecich
> >są w stanie zabezpieczyc skutecznie komp
> >No . . . prawie
>
> I jeszcze firewall, no i ostrozne dawanie uprawnien programom, kotre o
> nie prosza
i to nie gwarantuje 100% bezpieczenstwa, jesli ktos sie uprze to
podrzuci trojana ktory bardzo skutecznie podszyje sie pod jakies
uslugi systemowe
blad
> mam jednak wątpliwości czy przesyłanie klucza prywatnego
> w trakcie jego nadania przez i-net nie umożliwia jego przechwycenie
> ( mimo że przekaz szyfrowany SSL )
nikt ci nie "nadaje" klucza prywatnego i nie przesyla go przez siec.
klucz ten jest generowany przez przegladarke, inne oprogramowanie zainstalowane
lokalnie lub procesor krryptograficzny na karcie chipowej. W tym ostatnim
przypadku zostaje on na karcie i nigdy jej nie opuszcza bo nawet ty sam jako
wlasciciel nie musisz go znac ;-))
*** blad ***
Vizvary II Istvan
"Maciek Pasternacki" <ja...@hell.org.pl> wrote in message
news:87k7o58...@lizard.localdomain...
> Nieprawda. To znaczy, bank (o ile nie są skrajnymi kretynami ani
> niczym w tym duchu) nie posiada odszyfrowanej listy moich haseł
> jednorazowych, tylko (w prostszym przypadku) jednokierunkowe funkcje
> skrótu każdego z tych haseł.
Hmmmm. Ja bym ostrozniej operowal takimi pojeciami jak "nieprawda". Wezmy
dla przykładu BSK Online czy jak sie teraz nazywa. Ja podaje czesc hasla (5
wytypowanych przez system znakow). Znasz taka funkcje hashujaca, ktora
potrafi z czesci tekstu robic jednakowy skrot? Czy raczej jest to dowod, ze
haslo jest w postaci czystej przechowane ?
>W ciekawszej implementacji haseł [...]
Niezaleznie od tego w jaki sposob jest, czy jest czy nie jest implementowane
i co jest implementowane ....
Poki klient nie autoryzuje kazdej tranzakcji dokumentem niepodrabialnym ale
tez niezaprzeczalnym a bank sie nie zobowiazuje kazdej transakcji klienta
takim czyms dokumentowac, tak dlugo w pewnym sensie mamy do czynienia
bankowoscia "na slowo honoru". Co wcale nie wyklucza pozytecznosci (i
stosowania z pewnymi ograniczeniami co do dopuszczalnych operacji.) bo w ten
sposob konstruowane systemy zapewniają dużą mobilność uzytkownika. Wiekszą ,
niż systemy oparte o podpis cyfrowy. Jakie operacje dopuszczac i z jakimi
ograniczeniami, to zalezy od kalkulacji ryzyka.
Vizvary
Krzysztof Halasa
> Nieprawda.
Jednak prawda.
> To znaczy, bank (o ile nie są skrajnymi kretynami ani
> niczym w tym duchu) nie posiada odszyfrowanej listy moich haseł
> jednorazowych, tylko (w prostszym przypadku) jednokierunkowe funkcje
> skrótu każdego z tych haseł.
1. Skad ta informacja?
2. Taki mechanizm, by sensownie dzialac, potrzebuje argumentu o znacznej
dlugosci. Przy kilku cyfrach takiego hasla jednorazowego, nie ma
najmniejszego znaczenia czy bank przechowuje skrot, czy cale haslo
- i tak zlamanie tego trwa mikrosekunde.
Dokladnie tak samo jest oczywiscie z tokenami, tyle ze tam bank musi
posiadac kompletne dane o pamieci tokena, gdyz musi z nich na biezaco
liczyc jego wskazania.
> W ciekawszej implementacji haseł
> jednorazowych, każde kolejne hasło jest jednokierunkową funkcją skrótu
> poprzedniego, a bank (czy cokolwiek innego dokonującego autoryzacji)
> posiada tylko wartość jednokierunkowej funkcji skrótu ostatniego
> hasła. Ja podaję ostatnie hasło z listy, bank sprawdza, czy wartość
> funkcji skrótu jest taka sama, jeżeli tak, zapamiętuje podane przeze
> mnie hasło (już użyte, czyli tym samym odtajnione) jako wartość
> funkcji skrótu hasła kolejnego.
Niczego takiego sie nie stosuje. Gdyby tak bylo, bank moglby wygenerowac
kazde haslo (ktore jest skrotem poprzedniego). S/Key dziala dokladnie
odwrotnie - stare haslo jest funkcja nowego, po prostu hasla podaje sie
w odwrotnej kolejnosci do ich generowania.
Nie slyszalem, by jakis bank uzywal tego mechanizmu. Co oczywiscie nie
ma zadnego znaczenia, gdyz nie jest on z zalozenia bezpieczny
kryptograficznie przy niewielkich rozmiarach kluczy.
> Nie wiem, jak wyglądają algorytmy
> tokenów, tutaj już jest większe prawdopodobieństwo, że bank posiada
> dokładnie tę samą tajemnicę (chyba, że wymyślili coś równie sprytnego,
> jak powyżej); token działa głównie na zasadzie ,,security by
> obscurity'', a jak wszyscy (mam nadzieję) wiedzą, ,,security by
> obscurity is no security''.
Nie, token dziala na zasadzie jawnego algorytmu i shared secret (seed).
Przynajmniej od jakiegos czasu tokeny SecurID tak dzialaja, wczesniej
algorytm takze byl niby tajny (na tyle, na ile tajny przed adminem
serwera autoryzacyjnego moze byc jakis kod).
> Jednokierunkowa funkcja skrótu to jest taka funkcja, której
> odwrotności nie można obliczyć (a konkretniej, złożoność obliczeniowa
> odwrotności takiej funkcji jest większa niż metoda brute force --
> wyliczanie wartości funkcji kolejno dla wszystkich możliwych danych
> wejściowych). Funkcjami takimi są np. algorytm MD5, SHA1 czy uniksowy
> crypt().
To teraz porownaj np. SHA1 czy nawet MD5 (ktory jest podatny na ataki
polegajace na dopasowywaniu tresci do pozadanego wyniku) z tym, co
wklepujesz w okienko logowania / potwierdzenia przelewu itp.
> Zainteresowanym polecam cegiełkę ,,Kryptografia dla praktyków'' pana
> Bruce'a Schneiera.
Ja ze swej strony polecam standardowo Handbook of Applied Cryptography
(mimo ze nie jest to najnowsza ksiazka), potem mozna czytac inne rzeczy.
--
Krzysztof Halasa
Network Administrator
Robert Wicik
news:m3n0sy1...@defiant.pm.waw.pl...
> Ja ze swej strony polecam standardowo Handbook of Applied Cryptography
> (mimo ze nie jest to najnowsza ksiazka), potem mozna czytac inne rzeczy.
No, no, to jest chyba najlepsza cegła z tej dziedziny, ale pokazuje głównie
stronę teoretyczną kryptografii.
Pozdrawiam
Robert Wicik
Maciek Pasternacki
> "Maciek Pasternacki" <ja...@hell.org.pl> wrote in message
> news:87k7o58...@lizard.localdomain...
>
>> Nieprawda. To znaczy, bank (o ile nie są skrajnymi kretynami ani
>> niczym w tym duchu) nie posiada odszyfrowanej listy moich haseł
>> jednorazowych, tylko (w prostszym przypadku) jednokierunkowe funkcje
>> skrótu każdego z tych haseł.
>
> Hmmmm. Ja bym ostrozniej operowal takimi pojeciami jak "nieprawda". Wezmy
> dla przykładu BSK Online czy jak sie teraz nazywa. Ja podaje czesc hasla (5
> wytypowanych przez system znakow). Znasz taka funkcje hashujaca, ktora
> potrafi z czesci tekstu robic jednakowy skrot? Czy raczej jest to dowod, ze
> haslo jest w postaci czystej przechowane ?
>
A taki system: generując karteczkę z hasłami, system losuje dajmy na
to 2000 kombinacji znaków z karteczki, zapisuje w pliku kombinację
(numery znaków) i hash kombinacji, po czym zapomina pierwotną kartkę?
Przy każdym logowaniu losuje jedną z ustalonych wcześniej kombinacji,
sprawdza ją i skreśla z listy. Jak zostanie mniej niż połowa, każe
wygenerować nową karteczkę.
>>W ciekawszej implementacji haseł [...]
>
> Niezaleznie od tego w jaki sposob jest, czy jest czy nie jest implementowane
> i co jest implementowane ....
> Poki klient nie autoryzuje kazdej tranzakcji dokumentem niepodrabialnym ale
> tez niezaprzeczalnym a bank sie nie zobowiazuje kazdej transakcji klienta
> takim czyms dokumentowac, tak dlugo w pewnym sensie mamy do czynienia
> bankowoscia "na slowo honoru". Co wcale nie wyklucza pozytecznosci (i
> stosowania z pewnymi ograniczeniami co do dopuszczalnych operacji.) bo w ten
> sposob konstruowane systemy zapewniają dużą mobilność uzytkownika. Wiekszą ,
> niż systemy oparte o podpis cyfrowy. Jakie operacje dopuszczac i z jakimi
> ograniczeniami, to zalezy od kalkulacji ryzyka.
Tu się zgodzę. Niezależnie od implementacji, hasła jednorazowe (czy
dowolne inne hasła tudzież cokolwiek nie opartego na kluczach
asymetrycznych) nie będzie stuprocentowo niezaprzeczalne. Tym
bardziej, że nigdy nie mam pewności, że bank nie skopiował sobie
gdzieś czystej wersji haseł.
--japh
--
__ Maciek Pasternacki <mac...@japhy.fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { ...więc chwytam kraty rozgrzane do białości, twarz moją widzę,
,|{-}|}| }\/ twarz przekleństwa, a obok sąsiad patrzy z ciekawością,
\/ |____/ jak płonie na nim kaftan bezpieczeństwa... } ( J. Kaczmarski ) -><-
Maciek Pasternacki
>> To znaczy, bank (o ile nie są skrajnymi kretynami ani
>> niczym w tym duchu) nie posiada odszyfrowanej listy moich haseł
>> jednorazowych, tylko (w prostszym przypadku) jednokierunkowe funkcje
>> skrótu każdego z tych haseł.
>
> 1. Skad ta informacja?
Znajomość otwartych systemów haseł jednorazowych (OPIE, S/KEY, OTPW),
podstawowa znajomość zagadnień bezpieczeństwa informatycznego i
odrobina zdrowego rozsądku. Chyba, że przeceniam nasze banki...
> 2. Taki mechanizm, by sensownie dzialac, potrzebuje argumentu o znacznej
> dlugosci. Przy kilku cyfrach takiego hasla jednorazowego, nie ma
> najmniejszego znaczenia czy bank przechowuje skrot, czy cale haslo
> - i tak zlamanie tego trwa mikrosekunde.
...tak, chyba przeceniam. Byłem święcie przekonany, że jak hasło jest
jednorazowe i czytane z karteczki, to można wymagać od ludzi
przepisania co najmniej siedmiu znaków, liter (małych i dużych) i
cyfr. Co byłoby i tak niezbyt złożonym hasłem...
> Dokladnie tak samo jest oczywiscie z tokenami, tyle ze tam bank musi
> posiadac kompletne dane o pamieci tokena, gdyz musi z nich na biezaco
> liczyc jego wskazania.
Chyba, że wymyślili coś sprytnego. W co nie wierzę. (hm... token
oparty w jakiś sposób na algorytmie w duchu S/KEY?)
> Niczego takiego sie nie stosuje. Gdyby tak bylo, bank moglby wygenerowac
> kazde haslo (ktore jest skrotem poprzedniego). S/Key dziala dokladnie
> odwrotnie - stare haslo jest funkcja nowego, po prostu hasla podaje sie
> w odwrotnej kolejnosci do ich generowania.
Albo mi się coś pochrzaniło przy przepisywaniu, albo Ty odczytałeś nie
w tę stronę; w każdym razie, miałem na myśli właśnie S/KEY.
> Nie slyszalem, by jakis bank uzywal tego mechanizmu. Co oczywiscie nie
> ma zadnego znaczenia, gdyz nie jest on z zalozenia bezpieczny
> kryptograficznie przy niewielkich rozmiarach kluczy.
Ja po prostu chyba jakiś naiwny jestem i zakładam, że klucze mają
jakiś ludzki rozmiar.
> To teraz porownaj np. SHA1 czy nawet MD5 (ktory jest podatny na ataki
> polegajace na dopasowywaniu tresci do pozadanego wyniku) z tym, co
> wklepujesz w okienko logowania / potwierdzenia przelewu itp.
Możesz rozwinąć? Chodzi Ci o to, że to, co mi wypluwa np. md5sum
,,wygląda inaczej''? Przecież hasz czegokolwiek jest liczbą, a to, co
wypluwa md5sum albo jest zapisane w /etc/shadow jest jakąś
reprezentacją alfanumeryczną tej liczby. Co komu szkodzi hashować tym
samym algorytmem, używając innej reprezentacji liczb? Chyba, że źle
zrozumiałem...
--japh
--
__ Maciek Pasternacki <mac...@japhy.fnord.org> [ http://japhy.fnord.org/ ]
Maciek Pasternacki
> Użytkownik Maciek Pasternacki <ja...@hell.org.pl> w wiadomości do grup
> dyskusyjnych napisał:87eled8...@lizard.localdomain...
>> W podpisie elektronicznym masz do czynienia z tzw. kluczem prywatnym i
>> publicznym. Klucz prywatny masz tylko ty, klucz publiczny zna cały
>> swiat
>
> tego nigdy nie można być pewnym ;-)
Tego pierwszego, czy teog drugiego?
>> W przypadku podpisu elektronicznego hasło, ani żadna inna wrażliwa
>> wiadomość, nie jest przesyłana przez sieć przy każdej transakcji (ani
>> w postaci czystej, ani w zaszyfrowanej), bo autoryzacja nie opiera się
>> na znajomości wspólnego sekretu (hasła), tylko na posiadaniu
>> odpowiednich połówek sekretu (klucza publicznego i prywatnego).
>
> mam jednak wątpliwości czy przesyłanie klucza prywatnego
> w trakcie jego nadania przez i-net nie umożliwia jego przechwycenie
> ( mimo że przekaz szyfrowany SSL )
Nie wiem, kto generuje parę kluczy (Ty, czy bank - sensowniej byłoby,
gdybyś Ty sobie generował i wysyłał do banku tylko klucz publiczny),
ale jeden z kluczy zawsze musi być przesłany i tu jest właśnie
najwrażliwszy punkt. W wersji, w której bank generuje parę kluczy,
ktoś może podsłuchać po drodze klucz prywatny; w wersji, w której Ty
wysyłasz klucz publiczny do banku, ktoś może go po drodze podmienić.
SSL jest podatny na ataki typu MITM (Man In The Middle). Polega to,
wdużym skrócie, na tym, że atakujący siedzi gdzieć po drodze między
Tobą a bankiem i przedstawia się Tobie jako bank, a bankowi jako Ty.
Jako że autoryzacja w SSL opiera się na kluczach asymetrycznych, u
Ciebie, o ile masz włączone odpowiednie ustawienia, pokaże się okno,
że klucz banku się zmienił lub że nie jest certyfikowany -- napastnik
nie dysponuje kluczem prywatnym banku (chyba, że łączysz się z bankiem
po raz pierwszy, wtedy - sorry, Winnetou). Ogromna większość ludzi w
takiej sytuacji klika ,,OK'' i łączy się dalej... Wniosek: trzeba
przy sprawdzać fingerprint klucza banku (widać go gdzieś w ,,opcjach
zabezpieczeń'', o ile pamiętam) i nie klikać ,,OK'' na wszystkich
okienkach. Prawidłowy fingerprint klucza powinien być udostępniony na
stronie banku... tylko, z drugiej strony, jeżeli ktoś może przedstawić
Ci się jako bank, nie stanowi dla niego problemu podstawienie nieco
zmienionej strony (ze swoim fingerprintem). Problem prędzej czy
później sprowadza się do bezpiecznego przekazania klucza. Z
fingerprintem klucza SSL-owego jest o tyle łatwiej, że (teoretycznie)
powinieneś móc zapytać pracownika banku, albo bank mógłby go drukować
na ulotkach, reklamach itp... jak to u nas wygląda w praktyce -
wiadomo... :(
> trojany , sniffery . . .
> czy dobry antywiral , i bezwzględny brak dostępu osób trzecich
> są w stanie zabezpieczyc skutecznie komp
> No . . . prawie
Dobry antywir, dobry (i dobrze skonfigurowany) firewall, dobra
przeglądarka i klient maila (czytaj: jak chcesz mieć bezpiecznie,
zapomnij o Explorerze i Outlooku). Plus, w ramach dodatkowej paranoi,
szyfrowanie we własnym zakresie co wrażliwszych plików. A najlepiej
to nie korzystać z windowsów, tylko postawić (dobrze skonfigurowanego)
Linuksa/BSD/dowolnego innego Uniksa.
Pozdrawiam,
--japhy
--
__ Maciek Pasternacki <mac...@japhy.fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { ...so I talked about conscience, and I talked about pain,
,|{-}|}| }\/ and he looked out of window, and it started to rain, and
\/ |____/ I thought, maybe - I've already gone crazy... } ( Fish ) -><-
Vizvary II Istvan
> > Hmmmm. Ja bym ostrozniej operowal takimi pojeciami jak "nieprawda".
Wezmy
> > dla przykładu BSK Online czy jak sie teraz nazywa. Ja podaje czesc hasla
(5
> > wytypowanych przez system znakow). Znasz taka funkcje hashujaca, ktora
> > potrafi z czesci tekstu robic jednakowy skrot? Czy raczej jest to dowod,
ze
> > haslo jest w postaci czystej przechowane ?
> >
>
> A taki system: generując karteczkę z hasłami, system losuje dajmy na
> to 2000 kombinacji znaków z karteczki, zapisuje w pliku kombinację
> (numery znaków) i hash kombinacji, po czym zapomina pierwotną kartkę?
> Przy każdym logowaniu losuje jedną z ustalonych wcześniej kombinacji,
> sprawdza ją i skreśla z listy. Jak zostanie mniej niż połowa, każe
> wygenerować nową karteczkę.
Nie bardzo rozumie, ale poki bank i klient sobie ufaja (i wszystkim swoim
pracownikom jak tez dowolnemu ich zespolowi) bezwzglednie, wydaje się, że
bedzie to niewatpliwie bardzo bezpieczne. (Ale czy niezaprzeczalne i
wystarczajaco wiarygodne np. dla sadu w razie sporu?)
Vizvary
Vizvary II Istvan
> Krzysztof Halasa <k...@defiant.pm.waw.pl> writes:
> >> To znaczy, bank (o ile nie są skrajnymi kretynami ani
> >> niczym w tym duchu) nie posiada odszyfrowanej listy moich haseł
> >> jednorazowych, tylko (w prostszym przypadku) jednokierunkowe funkcje
> >> skrótu każdego z tych haseł.
> >
> > 1. Skad ta informacja?
>
> Znajomość otwartych systemów haseł jednorazowych (OPIE, S/KEY, OTPW),
> podstawowa znajomość zagadnień bezpieczeństwa informatycznego i
> odrobina zdrowego rozsądku. Chyba, że przeceniam nasze banki...
Ponownie Ci zwracam uwage na przyadek BS Online - do identyfikacji podaje
się CZESC hasla. Funkcja skrotu wykluczona. Haslo MUSI byc w banku w postaci
jawnej. Inna sprawa, że owe haslo upowaznia do sprawdzenia stanu konta itd.
Do wszelkich operacji stosuja podpisane cyfrowo dokumenty.
> Chyba, że wymyślili coś sprytnego. W co nie wierzę. (hm... token
> oparty w jakiś sposób na algorytmie w duchu S/KEY?)
Roznie z tym bywa. Ja się krecilem wokol zespolu ktory wdrazal pierwsze
tokeny w Polsce (w innej sprawie). Z tego co pamietam i wiem, kierownictwo
banku zazadal tokeny z kryptografii asymetryczna. Producent tokenu
zapewnial, ze dostarczane tokeny beda takie. Mi sie smiac chcialo i
tlumaczylem ze wykluczone, by moglo takie cos miec zasilanie bateryjkowe i
to dzialajace bez wymiany baterii przez dwa lata (znajac pobor mocy kart z
kryptografia asymetryczna). Czas naglil. Okazalo sie, że tokeny zawieraja
pojedynczy DES i to bodajze DES okrojony ze wzgledu na ograniczenia
eksportowe...
Vizvary
Vizvary II Istvan
> w której Ty
> wysyłasz klucz publiczny do banku, ktoś może go po drodze podmienić.
I co z nim robi ? A tak na prawde klucz publiczny wysyla sie w postaci
standardowego zadania certyfikatu w postaci podpisanej kluczem prywatnym.
Mozna jeszcze szyfrowac kluczem publicznym serwera certyfikatow.
> SSL jest podatny na ataki typu MITM (Man In The Middle).
[...]
>Polega to, [...] jak to u nas wygląda w praktyce - wiadomo... :(
SSL przyjelo sie traktowac jako narzedzie zapewniajace bezpieczenstwo. Dla
mnie jest ono kiepskim narzedziem nadającym sie w ograniczonym zakreesie do
zapewnienia prywatności (szyfrowanie).
> > trojany , sniffery . . .
> > czy dobry antywiral , i bezwzględny brak dostępu osób trzecich
> > są w stanie zabezpieczyc skutecznie komp
> > No . . . prawie
>
> Dobry antywir, dobry (i dobrze skonfigurowany) firewall, dobra
> przeglądarka i klient maila (czytaj: jak chcesz mieć bezpiecznie,
> zapomnij o Explorerze i Outlooku). Plus, w ramach dodatkowej paranoi,
> szyfrowanie we własnym zakresie co wrażliwszych plików. A najlepiej
> to nie korzystać z windowsów, tylko postawić (dobrze skonfigurowanego)
> Linuksa/BSD/dowolnego innego Uniksa.
>
> Pozdrawiam,
> --japhy
Musze Cie rozczarowac. Zupelnie co innego jest stabilny serwer internetowy,
a co innego jest stacja robocza.
Prosty przyklad - ochrona przed administratorem. Czy glowny ksiegowy
korporacji moze byc pewny, ze rano zastaje TEN SAM system operacyjny, ktory
wczoraj wylaczyl ? A moze ktos mu w nocy "przekompilowal jadro"? To samo
dotyczy wiekszosc oprogramowania OpenSource. Sprawa bynajmniej nie jest
jednoznaczna.
Podobnie wyglada sprawa bezpieczenstwa komunikacji.
Wez pod uwage nastepujaca rzecz.
W 1997 wspolne przedsiewziecie MS Sun i IBM (PCSC Workgroup) opracowalo
zasady wlaczenia kryptografii asymetrycznej (i obsluge kart
kryptograficznych) w systemy operacyjne.
MS konsekentnie realizuje, tak, że dzis szyfrowanie i podpis cyfrowy
dokumentow elektronicznych to dwie linii kodu w IE. Dotyczy to rowniez
szyfrowanie i podpis przez karty kryptograficzne. Jest to zawarte w cenie
systemu operacyjnego i przegladarki.
Sun i IBM po roku sie wylamaly, utworzyly konkurencyjny OpenCard Framework i
w zeszlym roku zakonczyly prace - niczym (PO PROSTU!) .
Efekt jest taki, że wspomniane problemy z SSL dotycza wspomniany przez
Ciebie Linux/BSD/Unix.
Jesli zas dotyczy Windows, to TYLKO dlatego, że ze wzgledu na wrazliwosc
uzytkownikow innych przegladarek i systemow operacyjnych niz od MS- nikomu
do glowy nie przyjdzie wykorzystac to, co juz jest gotowe w IE. Zreszta
zauwaz ile firm na tym zarobi (od TP S.A poczawszy)!
Vizvary
Piotr W
> "Piotr W" <ts...@poczta.onet.pl> writes:
>
> >> W podpisie elektronicznym masz do czynienia z tzw. kluczem prywatnym i
> >> publicznym. Klucz prywatny masz tylko ty, klucz publiczny zna cały
> >> swiat
> > tego nigdy nie można być pewnym ;-)
> Tego pierwszego, czy teog drugiego?
pierwszego ... niestety :-(
--
Piotr W
ts...@poczta.onet.pl
Krzysztof Halasa
> Znajomość otwartych systemów haseł jednorazowych (OPIE, S/KEY, OTPW),
> podstawowa znajomość zagadnień bezpieczeństwa informatycznego i
> odrobina zdrowego rozsądku. Chyba, że przeceniam nasze banki...
Nie, to nawet nie o to chodzi. Tego nie da sie tak zrobic "dla mas".
> > 2. Taki mechanizm, by sensownie dzialac, potrzebuje argumentu o znacznej
> > dlugosci. Przy kilku cyfrach takiego hasla jednorazowego, nie ma
> > najmniejszego znaczenia czy bank przechowuje skrot, czy cale haslo
> > - i tak zlamanie tego trwa mikrosekunde.
>
> ...tak, chyba przeceniam. Byłem święcie przekonany, że jak hasło jest
> jednorazowe i czytane z karteczki, to można wymagać od ludzi
> przepisania co najmniej siedmiu znaków, liter (małych i dużych) i
> cyfr. Co byłoby i tak niezbyt złożonym hasłem...
Wlasnie. Dla osoby, ktora wlamala sie do domu z wlaczonym komputerem
i strona z np. mBanku roznica miedzy takimi haslami i 5-znakowymi
bedzie niezauwazalna (bo albo wlamywacz znajdzie kartke z haslami,
albo jej nie znajdzie i najwyzej zasili zaklad energetyczny).
Dla komputera, ktory mialby to polamac, roznica bedzie oczywiscie
wielokrotna - ale i tak zajmie to tylko chwile.
> Chyba, że wymyślili coś sprytnego. W co nie wierzę. (hm... token
> oparty w jakiś sposób na algorytmie w duchu S/KEY?)
Teoretycznie moglaby byc taka mozliwosc, ale:
- 1. wciaz problem dlugosci klucza
- 2. user musialby sam "obsiewac" taki token (ten sam problem co przy
kryptografii asymetrycznej).
No i ile normalne tokeny maja nieograniczony czas zycia (przynajmniej
nie jest z zalozenia ograniczony), a poza tym zabezpieczaja usera przed
"skopiowaniem wskazan".
> Ja po prostu chyba jakiś naiwny jestem i zakładam, że klucze mają
> jakiś ludzki rozmiar.
Tzn. ile? Ludzie maja sklonnosc do uzywania slabych kluczy (entropia
w wymyslanych przez nich haslach to cos w stylu np. 2 bitow / znak).
Hasla generowane losowo przez komputer sa oczywiscie lepsze, ale
trudniejsze do zapamietania/zapisania, i naprawde nie moga byc
specjalnie dlugie, jesli maja dzialac (postaw sie w sytuacji helpdesku).
> > To teraz porownaj np. SHA1 czy nawet MD5 (ktory jest podatny na ataki
> > polegajace na dopasowywaniu tresci do pozadanego wyniku) z tym, co
> > wklepujesz w okienko logowania / potwierdzenia przelewu itp.
>
> Możesz rozwinąć? Chodzi Ci o to, że to, co mi wypluwa np. md5sum
> ,,wygląda inaczej''? Przecież hasz czegokolwiek jest liczbą, a to, co
> wypluwa md5sum albo jest zapisane w /etc/shadow jest jakąś
> reprezentacją alfanumeryczną tej liczby. Co komu szkodzi hashować tym
> samym algorytmem, używając innej reprezentacji liczb? Chyba, że źle
> zrozumiałem...
Tak przypuszczam. Taki hash MD5 zapisany w postaci dziesietnej mialby
tylko ok. 128/10*3 = czterdziesci cyfr. Przy SHA1 tylko drobne 50 cyferek.
No coz, w jakims sensie to tez wyglada inaczej :-)
Krzysztof Halasa
> Roznie z tym bywa. Ja się krecilem wokol zespolu ktory wdrazal pierwsze
> tokeny w Polsce (w innej sprawie). Z tego co pamietam i wiem, kierownictwo
> banku zazadal tokeny z kryptografii asymetryczna. Producent tokenu
> zapewnial, ze dostarczane tokeny beda takie. Mi sie smiac chcialo i
> tlumaczylem ze wykluczone, by moglo takie cos miec zasilanie bateryjkowe i
> to dzialajace bez wymiany baterii przez dwa lata (znajac pobor mocy kart z
> kryptografia asymetryczna). Czas naglil. Okazalo sie, że tokeny zawieraja
> pojedynczy DES i to bodajze DES okrojony ze wzgledu na ograniczenia
> eksportowe...
To akurat bylo to, czego nalezalo sie spodziewac.
Ale moc nie powinna tu byc jakims wyznacznikiem - w koncu mozna zrobic
tak, ze token bedzie pracowal tylko wtedy, gdy jest cos do zrobienia.
Zreszta sa takie tokeny, nie wyswietlaja normalnie nic, dopiero po
nacisnieciu klawisza. Naturalnie jakis tam RTC pracuje caly czas,
ale to nie problem dla baterii litowej.
Krzysztof Halasa
> SSL jest podatny na ataki typu MITM (Man In The Middle). Polega to,
> wdużym skrócie, na tym, że atakujący siedzi gdzieć po drodze między
> Tobą a bankiem i przedstawia się Tobie jako bank, a bankowi jako Ty.
> Jako że autoryzacja w SSL opiera się na kluczach asymetrycznych, u
> Ciebie, o ile masz włączone odpowiednie ustawienia, pokaże się okno,
> że klucz banku się zmienił lub że nie jest certyfikowany -- napastnik
> nie dysponuje kluczem prywatnym banku (chyba, że łączysz się z bankiem
> po raz pierwszy, wtedy - sorry, Winnetou).
To nie tak. Normalnie userowi ostrzezenie pokaze sie wtedy, jesli
serwer nie ma certyfikatu wydanego przez jakikolwiek CA wpisany
w konfiguracji przegladarki (albo zaszyty w tajnym miejscu w kodzie,
kto to moze wiedziec). Oczywiscie ostrzezenie bedzie takze wtedy,
jesli certyfikat nie bedzie odpowiedni z jakiegokolwiek powodu.
> Ogromna większość ludzi w
> takiej sytuacji klika ,,OK'' i łączy się dalej... Wniosek: trzeba
> przy sprawdzać fingerprint klucza banku (widać go gdzieś w ,,opcjach
> zabezpieczeń'', o ile pamiętam) i nie klikać ,,OK'' na wszystkich
> okienkach. Prawidłowy fingerprint klucza powinien być udostępniony na
> stronie banku... tylko, z drugiej strony, jeżeli ktoś może przedstawić
> Ci się jako bank, nie stanowi dla niego problemu podstawienie nieco
> zmienionej strony (ze swoim fingerprintem). Problem prędzej czy
> później sprowadza się do bezpiecznego przekazania klucza.
W takim scenariuszu system certyfikatow jest zbedny, wystarczylyby
same klucze (dystrybucja kluczy publicznych). Takie cos sie sprawdza,
ale raczej w innych okolicznosciach.
Vizvary II Istvan
"Krzysztof Halasa" <k...@defiant.pm.waw.pl> wrote in message
news:m3znwr8...@defiant.pm.waw.pl...
> Ale moc nie powinna tu byc jakims wyznacznikiem - w koncu mozna zrobic
> tak, ze token bedzie pracowal tylko wtedy, gdy jest cos do zrobienia.
Wowczas kooprocesor kryptograficzny pobieral okolo 50 mA w czasie obliczen
(teraz okolo 10 mA) i liczyl (RSA 1024 bit) okolo 3 sekund. (teraz
300-700-1000 ms). To jest bardzo duzo dla urzadzenia bateryjnego. Na tyle
duzo, ze czas pracy sie podaje nie w latach, tylko w ilosci operacji. I to
bedzie niewiele operacji.
Vizvary
Krzysztof Halasa
> Wowczas kooprocesor kryptograficzny pobieral okolo 50 mA w czasie obliczen
> (teraz okolo 10 mA) i liczyl (RSA 1024 bit) okolo 3 sekund. (teraz
> 300-700-1000 ms). To jest bardzo duzo dla urzadzenia bateryjnego. Na tyle
> duzo, ze czas pracy sie podaje nie w latach, tylko w ilosci operacji. I to
> bedzie niewiele operacji.
Ale na tyle wiele, zeby wystarczylo na dlugo. Czy potrzebujesz czegos
wiecej?
No chyba ze to mialo sluzyc do wielu operacji dziennie.
Maciek Pasternacki
> Ponownie Ci zwracam uwage na przyadek BS Online - do identyfikacji podaje
> się CZESC hasla. Funkcja skrotu wykluczona. Haslo MUSI byc w banku w postaci
> jawnej. Inna sprawa, że owe haslo upowaznia do sprawdzenia stanu konta itd.
> Do wszelkich operacji stosuja podpisane cyfrowo dokumenty.
Hasło *nie* musi być w całości w postaci jawnej. Patrz mój poprzedni
post <871ya9t...@lizard.localdomain>.
Inna sprawa, że to jest tak czy inaczej kwestia zaufania. Ale do
wprowadzenia w .pl porządnych podpisów cyfrowych, to się raczej nie
zmieni...
--japh
--
__ Maciek Pasternacki <mac...@japhy.fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { ...nazwy serwerów poczty wychodzącej i przychodzącej
,|{-}|}| }\/ są jak grupa krwi. Trzeba zawsze mieć to gdzieś zapisane
\/ |____/ i zawsze przy sobie. } ( J. L. Wiśniewski ) -><-
Maciek Pasternacki
> "Maciek Pasternacki" <ja...@hell.org.pl> wrote in message
> news:877kk1t...@lizard.localdomain...
>> w której Ty
>> wysyłasz klucz publiczny do banku, ktoś może go po drodze podmienić.
>
> I co z nim robi ? A tak na prawde klucz publiczny wysyla sie w postaci
> standardowego zadania certyfikatu w postaci podpisanej kluczem prywatnym.
> Mozna jeszcze szyfrowac kluczem publicznym serwera certyfikatow.
Zachowa dla siebie. A bankowi przedstawi swój klucz publiczny
(podpisany swoim kluczem prywatnym) jako Twój.
>> SSL jest podatny na ataki typu MITM (Man In The Middle).
> [...]
>>Polega to, [...] jak to u nas wygląda w praktyce - wiadomo... :(
>
> SSL przyjelo sie traktowac jako narzedzie zapewniajace bezpieczenstwo. Dla
> mnie jest ono kiepskim narzedziem nadającym sie w ograniczonym zakreesie do
> zapewnienia prywatności (szyfrowanie).
SSL jest całkiem niezłym narzędziem zapewniejącym bezpieczeństwo
informacji podczas przesyłania (zabezpieczenie zarówno przed atakami
aktywnymi, jak i pasywnymi). O ile tylko używa się tego świadomie,
wiedząc co się robi i nie klikając ,,Tak'' w każdym oknie, które się
pokaże. Problem tkwi w tym, że większość ludzi wychodzi z założenia,
że jak przy tym ,,http'' w okienku jest jeszcze ,,s'', to znaczy, że
jest bezpiecznie -- taki magiczny warunek wystarczający
,,bezpieczeństwa'' dla kogoś, kto nie potrafiłby zdefiniować, na czym
to bezpieczeństwo powinno polegać.
>> Dobry antywir, dobry (i dobrze skonfigurowany) firewall, dobra
>> przeglądarka i klient maila (czytaj: jak chcesz mieć bezpiecznie,
>> zapomnij o Explorerze i Outlooku). Plus, w ramach dodatkowej paranoi,
>> szyfrowanie we własnym zakresie co wrażliwszych plików. A najlepiej
>> to nie korzystać z windowsów, tylko postawić (dobrze skonfigurowanego)
>> Linuksa/BSD/dowolnego innego Uniksa.
>
> Musze Cie rozczarowac. Zupelnie co innego jest stabilny serwer internetowy,
> a co innego jest stacja robocza.
Ja mam stację roboczą na Linuksie. Wiem, co jest w przeglądarce
internetowej, czytniku maila itd. W razie potrzeby mogę zmienić, co
mi się żywnie podoba. Wiem, że wysypanie się jednego programu nie
położy mi całego systemu -- ani jednorazowo (zwis), ani permanentnie
(uszkodzenie ważnych plików). Temu systemowi mogę zaufać, bo *widzę*,
co ma w środku i mogę go dostosować do swoich potrzeb, nawet
najbardziej paranoicznych.
> Prosty przyklad - ochrona przed administratorem. Czy glowny ksiegowy
> korporacji moze byc pewny, ze rano zastaje TEN SAM system operacyjny, ktory
> wczoraj wylaczyl ? A moze ktos mu w nocy "przekompilowal jadro"? To samo
> dotyczy wiekszosc oprogramowania OpenSource. Sprawa bynajmniej nie jest
> jednoznaczna.
A czy mając Windowsa w jakiejkolwiek sieci ma pewność, że mu się nie
przypałętał robak-trojan, wpięty w przeglądarkę i wysyłający zawartość
wszystkich formularzy z polem ,,Hasło'' do Mossadu / CIA / Al Kaidy /
/ konkurencji?
> Podobnie wyglada sprawa bezpieczenstwa komunikacji.
Wybacz, ale najbliższym routerem brzegowym też ktoś musi
administrować. A sniffera dużo łatwiej ukryć w Windowsie niż w
U*ksie.
> Wez pod uwage nastepujaca rzecz.
> W 1997 wspolne przedsiewziecie MS Sun i IBM (PCSC Workgroup) opracowalo
> zasady wlaczenia kryptografii asymetrycznej (i obsluge kart
> kryptograficznych) w systemy operacyjne.
> MS konsekentnie realizuje, tak, że dzis szyfrowanie i podpis cyfrowy
> dokumentow elektronicznych to dwie linii kodu w IE. Dotyczy to rowniez
Jakiego kodu? W źródłach IE? Kodu JavaScript / VBScript / cokolwiek
w dokumencie HTML?
> szyfrowanie i podpis przez karty kryptograficzne. Jest to zawarte w cenie
> systemu operacyjnego i przegladarki.
Wysyłanie do Microsoftu informacji o tym, jakie strony oglądam, też.
Bez możliwości zablokowania, jaką miałbym w OpenSource, nawet jakby
komuś przyszło do głowy zbierać takie statystyki bez możliwości
wyłączenia tego w konfiguracji. W co nie wierzę.
> Efekt jest taki, że wspomniane problemy z SSL dotycza wspomniany przez
> Ciebie Linux/BSD/Unix.
Co ma SSL do podpisów cyfrowych kartą kryptograficzną? Poza tym:
podatność na ataki MITM są cechą *protokołu*, a nie którejś jego
konkretnej implementacji.
> Jesli zas dotyczy Windows, to TYLKO dlatego, że ze wzgledu na wrazliwosc
> uzytkownikow innych przegladarek i systemow operacyjnych niz od MS- nikomu
> do glowy nie przyjdzie wykorzystac to, co juz jest gotowe w IE. Zreszta
Mam rozumieć, że wszyscy programiści według Ciebie albo mają płacić
haracz Microsoftowi za ich rozwiązania i zamykać kod źródłowy (bo to
przecież zastrzeżone algorytmy), albo dać sobie spokój z
programowaniem kryptografii? Wybacz, ale o ile rozumiem, sugerujesz
oddanie kontroli nad podpisami cyfrowymi jednej firmie prywatnej. Nie
bałbyś się?
> zauwaz ile firm na tym zarobi (od TP S.A poczawszy)!
Na tym -- czyli czym i w jaki sposób?
--japh
--
__ Maciek Pasternacki <mac...@japhy.fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { ...człowiek myślący jest solą w oku.
,|{-}|}| }\/ Kretyn to kretyn. Dajcie mu spokój... }
\/ |____/ ( J. Kofta ) -><-
Maciek Pasternacki
> Maciek Pasternacki <ja...@hell.org.pl> writes:
>
>> Znajomość otwartych systemów haseł jednorazowych (OPIE, S/KEY, OTPW),
>> podstawowa znajomość zagadnień bezpieczeństwa informatycznego i
>> odrobina zdrowego rozsądku. Chyba, że przeceniam nasze banki...
>
> Nie, to nawet nie o to chodzi. Tego nie da sie tak zrobic "dla mas".
Dlaczego?
>> > 2. Taki mechanizm, by sensownie dzialac, potrzebuje argumentu o znacznej
>> > dlugosci. Przy kilku cyfrach takiego hasla jednorazowego, nie ma
>> > najmniejszego znaczenia czy bank przechowuje skrot, czy cale haslo
>> > - i tak zlamanie tego trwa mikrosekunde.
>>
>> ...tak, chyba przeceniam. Byłem święcie przekonany, że jak hasło jest
>> jednorazowe i czytane z karteczki, to można wymagać od ludzi
>> przepisania co najmniej siedmiu znaków, liter (małych i dużych) i
>> cyfr. Co byłoby i tak niezbyt złożonym hasłem...
>
> Wlasnie. Dla osoby, ktora wlamala sie do domu z wlaczonym komputerem
> i strona z np. mBanku roznica miedzy takimi haslami i 5-znakowymi
> bedzie niezauwazalna (bo albo wlamywacz znajdzie kartke z haslami,
> albo jej nie znajdzie i najwyzej zasili zaklad energetyczny).
> Dla komputera, ktory mialby to polamac, roznica bedzie oczywiscie
> wielokrotna - ale i tak zajmie to tylko chwile.
Mówiąc o łamaniu haseł chyba nie mamy na myśli włamywacza znajdującego
kartkę z hasłami, bo to jest oczywiste, że wtedy długość hasła nie ma
znaczenia. Dlatego do jednorazów powinien być jakiś stały pin czy
prefix password jak w OTPW. Dla programu łamiącego... hm... weźmy
pięciocyfrową liczbę. Mamy ln 10/ln 2 = 3,322 bita na cyfrę, razy
pięć to będzie 16,6 bitów na hasło. Przy siedmiu znakach
litery/cyfry, mamy ln (26*2+10 = 62)/ln 2=5,954 bitów na znak, razy
siedem to jest 41,68 bitów na hasło. Rzeczywiście, wciąż mało jak na
dzisiejszą moc obliczeniową. Chociaż, jak na jednorazy w systemie
OTPW, gdzie szansę trafienia możesz mieć jak jeden do kilkuset tysięcy
(wspomniany wyżej system z wybieraniem iluś cyfr z długiej tabeli może
być jakimś słabszym wariantem OTPW, co zresztą wcześniej opisałem).
>> Chyba, że wymyślili coś sprytnego. W co nie wierzę. (hm... token
>> oparty w jakiś sposób na algorytmie w duchu S/KEY?)
>
> Teoretycznie moglaby byc taka mozliwosc, ale:
To nie była jakakolwiek sugestia z mojej strony, raczej taka dość
losowa myśl.
>> Ja po prostu chyba jakiś naiwny jestem i zakładam, że klucze mają
>> jakiś ludzki rozmiar.
>
> Tzn. ile? Ludzie maja sklonnosc do uzywania slabych kluczy (entropia
> w wymyslanych przez nich haslach to cos w stylu np. 2 bitow / znak).
> Hasla generowane losowo przez komputer sa oczywiscie lepsze, ale
> trudniejsze do zapamietania/zapisania, i naprawde nie moga byc
> specjalnie dlugie, jesli maja dzialac (postaw sie w sytuacji helpdesku).
Jak są jednorazowe (ze zdrapką), to nawet nie trzeba
,,wygwiazdkowywać'' pola do wpisywania hasła. W hasłach
jednorazowych, paradoksalnie można osiągnąć większą entropię
pojedynczego hasła niż w hasłach ,,zwykłych''.
>> Możesz rozwinąć? Chodzi Ci o to, że to, co mi wypluwa np. md5sum
>> ,,wygląda inaczej''? Przecież hasz czegokolwiek jest liczbą, a to, co
>> wypluwa md5sum albo jest zapisane w /etc/shadow jest jakąś
>> reprezentacją alfanumeryczną tej liczby. Co komu szkodzi hashować tym
>> samym algorytmem, używając innej reprezentacji liczb? Chyba, że źle
>> zrozumiałem...
>
> Tak przypuszczam. Taki hash MD5 zapisany w postaci dziesietnej mialby
> tylko ok. 128/10*3 = czterdziesci cyfr. Przy SHA1 tylko drobne 50 cyferek.
A kto mi (a właściwie bankowi) zabroni wygenerować 64-, 48-, a nawet
32-bitowy skrót SHA1 albo MD5? Że zamiast 128 bitów entropii będą 64?
Do jednorazów wystarczy. Powtarzam, nie widziałem rozwiązań haseł
jednorazowych stosowanych przez banki, byłem przekonany, że nie
stosują rozwiązań, które bym obśmiał, jakby ktoś mi sugerował
zabezpieczenie tym konta pocztowego, a co dopiero dorobku całego
życia... ;)
Pozdrawiam,
--Washington Irving
--
__ Maciek Pasternacki <mac...@japhy.fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { ...For I was born with a habit, from a sign,
,|{-}|}| }\/ the habit of a windswept thumb,
\/ |____/ and a sign of the rain... } ( Fish ) -><-
Vizvary II Istvan
> "Vizvary II Istvan" <vi...@poczta.onet.pl> writes:
>
> > Ponownie Ci zwracam uwage na przyadek BS Online - do identyfikacji
podaje
> > się CZESC hasla. Funkcja skrotu wykluczona. Haslo MUSI byc w banku w
postaci
> > jawnej. Inna sprawa, że owe haslo upowaznia do sprawdzenia stanu konta
itd.
> > Do wszelkich operacji stosuja podpisane cyfrowo dokumenty.
>
> Hasło *nie* musi być w całości w postaci jawnej. Patrz mój poprzedni
> post <871ya9t...@lizard.localdomain>.
To wobec tego powtarzam ci, że gdy sie podaje losową czesc hasła, to funkcje
jednokierunkowe odpadają. Oczywiście możesz przechować wiele wyników funkcji
dla dowoklnie wybranych kombinacji 5 znakowej z 10 znakowego hasła.W to z
kolei ja nie wierze.
Chociaż kto to wie ...
Vizvary II Istvan
> > I co z nim robi ? A tak na prawde klucz publiczny wysyla sie w postaci
> > standardowego zadania certyfikatu w postaci podpisanej kluczem
prywatnym.
> > Mozna jeszcze szyfrowac kluczem publicznym serwera certyfikatow.
>
> Zachowa dla siebie. A bankowi przedstawi swój klucz publiczny
> (podpisany swoim kluczem prywatnym) jako Twój.
A może dlatego banki nie powinne certyfikowac kluczy klientów ?
Chociaż i tak caly atak kuleje.
Potencjalny intruz od samego początku musiałby kontrolować i to w czasie
rzeczywistym korespondencje elektroniczną klienta z centrum certyfikacji.
Nie jest to łatwe, a nawet jesli sie uda, to atak padnie w momencie
osobistej wizyty klienta w celu kontroli tozsamości. Trzeba by wybudować
lipny oddział banku lub lipny punk rejestracji CA.
Według mnie PKI i certyfikacja kluczy ma kilka słabych punktów (wynikają one
z tak a nie inaczej przyjetych komromisów pomiedzy wygoda a bezpieczenstwem,
mozna inaczej, ja bym preferował generowanie zadania off line) ale nie jest
tak prosto oszukac jak sugerujesz.
Niebezpieczenstwo lezy zupelnie gdzie indziej.
zas dalej .... wybacz od tego jest grupa pl.comp.os.advocacy by podyskutowac
sobie w kregu ekspertów (przepraszam za wyrazenie) nad wyzszoscia Linuxa nad
Windowsami i odwrotnie.
Ja po prostu twierdze, że jesli system operacyjny nie rozwiązał sprawę
sprzętowego wspomagania kryptografii, tylko odpuszcza sprawe aplikacjom, to
po prostu jest mało ambitny. Dobrze robi programistom. Czy klientom
też...nie wiem.
> Wybacz, ale o ile rozumiem, sugerujesz
> oddanie kontroli nad podpisami cyfrowymi jednej firmie prywatnej. Nie
> bałbyś się?
SUNowi bym się bal.
AOLowi ? sprzedałbym szybciej komputer.
MS - tu bym się zastanawiał. Przynajmniej pozwala klucze trzymac na kartach
i nie narzuca własnej kryptografii. Zreszta żaden system nie narzuca.
> > zauwaz ile firm na tym zarobi (od TP S.A poczawszy)!
>
> Na tym -- czyli czym i w jaki sposób?
O to chodzi, że jak sam zauważyłesz SSL jako zabezpieczenie (szczególnie
jesli każdy może zmienić wygląd swojej przegladarki) to iluzja. Obrazek
kłodki, napis https i wiara, że to działa.
Jesli zakładamy , że użytkownik potrafi sie podpisać, to również może
szyfrować dane. SAME DANE i bezpieczniej niż robi to SSL. Tak do banku jak
do klienta.
A tak to obrazki i cała reszta idzie szyfrowany, złotówki leca, bo zegar
tyka. Chociaż może i to nie jest taka istotna sprawa...
Vizvary
Krzysztof Halasa
> >> Znajomość otwartych systemów haseł jednorazowych (OPIE, S/KEY, OTPW),
> >> podstawowa znajomość zagadnień bezpieczeństwa informatycznego i
> >> odrobina zdrowego rozsądku. Chyba, że przeceniam nasze banki...
> >
> > Nie, to nawet nie o to chodzi. Tego nie da sie tak zrobic "dla mas".
>
> Dlaczego?
Poniewaz masy wola 5-cyfrowe hasla jednorazowe itp. Poniewaz masy
nie sa w stanie wklepac np. do telefonu 128-bitowego hasha MD5.
Poniewaz tak naprawde w tej chwili to nie wystarczy, by zabezpieczyc
sie przed dzialaniem banku na szkode klienta. Poniewaz to i tak byloby
rozwiazanie przejsciowe - wszyscy czekaja na podpis elektroniczny,
i sie z pewnoscia doczekaja.
> Mówiąc o łamaniu haseł chyba nie mamy na myśli włamywacza znajdującego
> kartkę z hasłami, bo to jest oczywiste, że wtedy długość hasła nie ma
> znaczenia. Dlatego do jednorazów powinien być jakiś stały pin czy
> prefix password jak w OTPW. Dla programu łamiącego... hm... weźmy
> pięciocyfrową liczbę. Mamy ln 10/ln 2 = 3,322 bita na cyfrę, razy
> pięć to będzie 16,6 bitów na hasło. Przy siedmiu znakach
> litery/cyfry, mamy ln (26*2+10 = 62)/ln 2=5,954 bitów na znak, razy
> siedem to jest 41,68 bitów na hasło. Rzeczywiście, wciąż mało jak na
> dzisiejszą moc obliczeniową. Chociaż, jak na jednorazy w systemie
> OTPW, gdzie szansę trafienia możesz mieć jak jeden do kilkuset tysięcy
> (wspomniany wyżej system z wybieraniem iluś cyfr z długiej tabeli może
> być jakimś słabszym wariantem OTPW, co zresztą wcześniej opisałem).
Ale co przez to zyskujesz? Nic. Zabezpieczyc sie przed bankiem nie jestes
w stanie, bo to bank generuje Ci hasla i przesyla poczta. Nic nie stoi
na przeszkodzie, by zaradny specjalista robil druga kopie "na wszelki
wypadek".
> > Tak przypuszczam. Taki hash MD5 zapisany w postaci dziesietnej mialby
> > tylko ok. 128/10*3 = czterdziesci cyfr. Przy SHA1 tylko drobne 50 cyferek.
>
> A kto mi (a właściwie bankowi) zabroni wygenerować 64-, 48-, a nawet
> 32-bitowy skrót SHA1 albo MD5? Że zamiast 128 bitów entropii będą 64?
> Do jednorazów wystarczy. Powtarzam, nie widziałem rozwiązań haseł
> jednorazowych stosowanych przez banki, byłem przekonany, że nie
> stosują rozwiązań, które bym obśmiał, jakby ktoś mi sugerował
> zabezpieczenie tym konta pocztowego, a co dopiero dorobku całego
> życia... ;)
Wbrew pozorom, roznica pomiedzy stosowanymi przez banki np. 5-cyfrowymi
haslami jednorazowymi a np. 32 czy 64-bitowymi skrotami nie jest wcale
taka duza - ani jedno, ani drugie nie zabezpiecza uzytkownika przed
dzialaniem banku na jego szkode, oraz jedno i drugie dosc dobrze
zabezpiecza uzytkownika przed dzialaniem osob trzecich.
Krzysztof Halasa
> > Wybacz, ale o ile rozumiem, sugerujesz
> > oddanie kontroli nad podpisami cyfrowymi jednej firmie prywatnej. Nie
> > bałbyś się?
>
> SUNowi bym się bal.
> AOLowi ? sprzedałbym szybciej komputer.
> MS - tu bym się zastanawiał. Przynajmniej pozwala klucze trzymac na kartach
> i nie narzuca własnej kryptografii. Zreszta żaden system nie narzuca.
Dziwne rozumowanie.
Szczerze mowiac, moze to i paranoidalne, ale ja bym nie zaufal do konca
zadnej firmie ani urzedowi, obojetnie czy bylo to prywatne czy panstwowe,
krajowe czy zagraniczne.
Dlaczego? Poniewaz w kazdej firmie zatrudniajacej wiecej niz 1 osobe
zawsze jest mozliwosc, ze osoba nieuprawniona uzyska dostep np. do
klucza prywatnego CA, albo przynajmniej bedzie w stanie podpisac nim
swoje rzeczy, i nikt tego nie zauwazy.
Wszystko jest tylko kwestia ceny i stopnia waznosci np. certyfikatu.
Natomiast zupelnie inaczej to wyglada, jesli certyfikaty maja byc
uzywane do konkretnych zastosowan.
W banku w ogole nie widze problemu, wystarczy dostarczyc bankowi
klucz publiczny (czy to bedzie podpisany przez siebie certyfikat,
czy cos innego, to juz bez znaczenia). Np. wystarczy, by karta wzorow
podpisow miala miejsce na wydrukowanie na niej klucza - bank moze sobie
zeskanowac i jest papierowy dokument. Nie widze powodu, by do takich
celow uzywac certyfikatow wystawianych przez kogos innego niz obie
zainteresowane strony (bank i klient).
> O to chodzi, że jak sam zauważyłesz SSL jako zabezpieczenie (szczególnie
> jesli każdy może zmienić wygląd swojej przegladarki) to iluzja. Obrazek
> kłodki, napis https i wiara, że to działa.
Bo _to_ dziala. Kwestia tylko tego, czym jest _to_.
> Jesli zakładamy , że użytkownik potrafi sie podpisać, to również może
> szyfrować dane. SAME DANE i bezpieczniej niż robi to SSL. Tak do banku jak
> do klienta.
Dlaczego? Taki uzytkownik rownie dobrze moze wykorzystac SSL, to nie
strona techniczna (sam protokol) jest slaba strona.
Vizvary II Istvan
> "Vizvary II Istvan" <vi...@poczta.onet.pl> writes:
>
> > > Wybacz, ale o ile rozumiem, sugerujesz
> > > oddanie kontroli nad podpisami cyfrowymi jednej firmie prywatnej. Nie
> > > bałbyś się?
> >
> > SUNowi bym się bal.
> > AOLowi ? sprzedałbym szybciej komputer.
> > MS - tu bym się zastanawiał. Przynajmniej pozwala klucze trzymac na
kartach
> > i nie narzuca własnej kryptografii. Zreszta żaden system nie narzuca.
>
> Dziwne rozumowanie.
Mogę to uzasadnic i to z której strony bym nie podszedł do tematu to samo mi
wychodzi.
> Szczerze mowiac, moze to i paranoidalne, ale ja bym nie zaufal do konca
> zadnej firmie ani urzedowi, obojetnie czy bylo to prywatne czy panstwowe,
> krajowe czy zagraniczne.
Generalnie się zgadza, tylko rzeczywiście zaczyna być to paranoia. Według
mnie dlatego, że wobec równiania podpisu cyfrowego z podpisem odrecznym
przez ustawodawca doszlismy do takiego stanu, jakbysmy w matematyce
dodatkowo zrobili jeszcze jedno założenie że na przykład 2=3. Ja cały czas
się obawiam, że do tego to prowadzi, że znakomitą metodę, którą od ponad
dziesięciu lat mozna by z powodzeniem stosować do powaznych rzeczy bez
żadnej regulacji prawnej (tak jak się dzieje w ZUS lub w Skandynawii) -
zagłaskamy na smierć. Mogę się mylić.
[...]
> Natomiast zupelnie inaczej to wyglada, jesli certyfikaty maja byc
> uzywane do konkretnych zastosowan.
No właśnie. Ja kilka razy o tym pisałem przy okazji tego mojego konta w BS,
z którego bym zrezygnował, gdyby podpis do czego innego (niż dostep do
konta ) upowazniał (a BS nie pozwolił klucze chronić chociazby za pomocą
karty).
> W banku w ogole nie widze problemu, wystarczy dostarczyc bankowi
> klucz publiczny (czy to bedzie podpisany przez siebie certyfikat,
> czy cos innego, to juz bez znaczenia). Np. wystarczy, by karta wzorow
> podpisow miala miejsce na wydrukowanie na niej klucza - bank moze sobie
> zeskanowac i jest papierowy dokument. Nie widze powodu, by do takich
> celow uzywac certyfikatow wystawianych przez kogos innego niz obie
> zainteresowane strony (bank i klient).
> > Jesli zakładamy , że użytkownik potrafi sie podpisać, to również może
> > szyfrować dane. SAME DANE i bezpieczniej niż robi to SSL. Tak do banku
jak
> > do klienta.
>
> Dlaczego? Taki uzytkownik rownie dobrze moze wykorzystac SSL, to nie
> strona techniczna (sam protokol) jest slaba strona.
Ja z tym SSL em tylko na to chciałem zwrócić uwagę, że jeśli uzywamy
przegladarkę, do którego ma administrator (sieciowy lub inny, lokalny(?):-))
kod żródłowy i może w każdej chwili przekompilować (a może to robić) to
wmawianie ludziom, że obrazek kłodki o czymkolwiek świadczy, jest
nieporozumieniem. Tu chodzi po prostu o pewien aspekt oprogramowania open
source i że (nie)bezpieczenstwo róznie może się pojawiać (zależy kto kogo
się obawia. Wiem. Administratorów należy po prostu tak opłacać, by żadna
pokusa nie była atrakcyjna :-)
Z kolei gdy dane są szyfrowane do mnie (moim kluczem publicznym) to obrazki
i ogloszenia moga byc nieszyfrowane. Obrazek może być, może też nie być, nie
ma znaczenia.
Pojawiają się inne zagrożenia, to prawda (2=3).
Vizvary Istvan
Krzysztof Halasa
> Ja z tym SSL em tylko na to chciałem zwrócić uwagę, że jeśli uzywamy
> przegladarkę, do którego ma administrator (sieciowy lub inny, lokalny(?):-))
> kod żródłowy i może w każdej chwili przekompilować (a może to robić) to
> wmawianie ludziom, że obrazek kłodki o czymkolwiek świadczy, jest
> nieporozumieniem.
To oczywiste, ale to nie problem protokolu SSL.
Zreszta nie ma znaczenia, czy administrator ma kod zrodlowy przegladarki,
ani czy w ogole jest jeszcze jakis administrator. Istnieje masa sposobow,
by podrzucic uzytkownikowi cos, co mu odpowiednio "ustawi" przegladarke.
Wszystkie te dzialania oczywiscie najlepiej dzialaja w polaczeniu
z nieswiadomym uzytkownikiem - takim, ktory widzi klodke i wierzy.
> Wiem. Administratorów należy po prostu tak opłacać, by żadna
> pokusa nie była atrakcyjna :-)
A to zawsze :-)
Maciek Pasternacki
> Wowczas kooprocesor kryptograficzny pobieral okolo 50 mA w czasie obliczen
> (teraz okolo 10 mA) i liczyl (RSA 1024 bit) okolo 3 sekund. (teraz
> 300-700-1000 ms). To jest bardzo duzo dla urzadzenia bateryjnego. Na tyle
> duzo, ze czas pracy sie podaje nie w latach, tylko w ilosci operacji. I to
> bedzie niewiele operacji.
A kto powiedział, że token musi być pancernie zamknięty i posiadać
tylko okienko na wyświetlacz i ewentualnie guziczek? Zawsze można
wprowadzić ładowanie. A żeby nie tracić kasy na ładowarki, dać
przejściówkę do złącza baterii 9V (bo samo złącze byłoby
niepraktyczne; chociaż, z jakąś zaślepką?) -- i ładować albo z
baterii, albo z dowolnego zasilacza z takim wyjściem.
Pozdrawiam,
--japh
--
__ Maciek Pasternacki <mac...@japhy.fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { ...Read some Kerouac and it put me on the tracks
,|{-}|}| }\/ to burn a little brighter now... }
\/ |____/ ( Fish ) -><-
Maciek Pasternacki
>> Hasło *nie* musi być w całości w postaci jawnej. Patrz mój poprzedni
>> post <871ya9t...@lizard.localdomain>.
>
> To wobec tego powtarzam ci, że gdy sie podaje losową czesc hasła, to funkcje
> jednokierunkowe odpadają. Oczywiście możesz przechować wiele wyników funkcji
> dla dowoklnie wybranych kombinacji 5 znakowej z 10 znakowego hasła.W to z
> kolei ja nie wierze.
> Chociaż kto to wie ...
Nie dla dowolnej. Dla kilkuset ustalonych z góry (przy generowaniu).
Tylko to i tak kwestia zaufania (kto mi zagwarantuje, że system
informatyczny działa w tai, a nie inny sposób?).
--dżaf.
--
__ Maciek Pasternacki <mac...@japhy.fnord.org> [ http://japhy.fnord.org/ ]
`| _ |_\ / { ...Can't you understand that the way things were planned
,|{-}|}| }\/ it never worked out, so I just went crazy... }
Maciek Pasternacki
> Chociaż i tak caly atak kuleje.
> Potencjalny intruz od samego początku musiałby kontrolować i to w czasie
> rzeczywistym korespondencje elektroniczną klienta z centrum certyfikacji.
> Nie jest to łatwe, a nawet jesli sie uda, to atak padnie w momencie
> osobistej wizyty klienta w celu kontroli tozsamości. Trzeba by wybudować
> lipny oddział banku lub lipny punk rejestracji CA.
Mówiłem tu o bezpieczeństwie od strony czysto informatycznej. MITM
może wymaga sporych środków ze strony atakującego (możliwość
filtrowania połączeń na jednym z routerów po drodze albo IP
spoofing/hijacking), ale nie jest niemożliwe.
> zas dalej .... wybacz od tego jest grupa pl.comp.os.advocacy by podyskutowac
> sobie w kregu ekspertów (przepraszam za wyrazenie) nad wyzszoscia Linuxa nad
> Windowsami i odwrotnie.
Nie ja zacząłem. :p
> Ja po prostu twierdze, że jesli system operacyjny nie rozwiązał sprawę
> sprzętowego wspomagania kryptografii, tylko odpuszcza sprawe aplikacjom, to
> po prostu jest mało ambitny. Dobrze robi programistom. Czy klientom
> też...nie wiem.
Grr... czy fakt, że do sprzętowej kryptografii *jeszcze* nie ma
sterowników pod Linuksa (w co mi się nie chce wierzyć) znaczy, że
system jest gorszy? Kto Ci broni te sterowniki napisać? To jest
najwyżej kwestia czasu.
>> Wybacz, ale o ile rozumiem, sugerujesz
>> oddanie kontroli nad podpisami cyfrowymi jednej firmie prywatnej. Nie
>> bałbyś się?
>
> SUNowi bym się bal.
> AOLowi ? sprzedałbym szybciej komputer.
> MS - tu bym się zastanawiał. Przynajmniej pozwala klucze trzymac na kartach
> i nie narzuca własnej kryptografii. Zreszta żaden system nie narzuca.
Akurat MS jest znany jako firma, która nie narzuca własnych
rozwiązań. No comment. I EOT z mojej strony.
>> > zauwaz ile firm na tym zarobi (od TP S.A poczawszy)!
>>
>> Na tym -- czyli czym i w jaki sposób?
>
> O to chodzi, że jak sam zauważyłesz SSL jako zabezpieczenie (szczególnie
> jesli każdy może zmienić wygląd swojej przegladarki) to iluzja. Obrazek
> kłodki, napis https i wiara, że to działa.
Ale to działa. To znaczy, protokół od strony technicznej działa,
tylko trzeba stosować go z pewną świadomością tego, co się dzieje w środku.
> Jesli zakładamy , że użytkownik potrafi sie podpisać, to również może
> szyfrować dane. SAME DANE i bezpieczniej niż robi to SSL. Tak do banku jak
> do klienta.
Tu się zgodzę. Ale SSL nie jest fikcją polegającą na dodaniu przez
przeglądarkę literki ,,s'' do ,,http'' i kłódki w pasku stanu, bo jej
się tak uwidziało. SSL też daje silną kryptografię.
> A tak to obrazki i cała reszta idzie szyfrowany, złotówki leca, bo zegar
> tyka. Chociaż może i to nie jest taka istotna sprawa...
Hihi... akurat razem z włączeniem szyfrowania można AFAIK włączyć
dodatkową kompresję... jedno, co się traci, to cykle procesora,
których większość użytkowników posiada spory nadmiar.
Ale EOT.
--dżaf.
--
__ Maciek Pasternacki <mac...@japhy.fnord.org> [ http://japhy.fnord.org/ ]
Vizvary II Istvan
> "Vizvary II Istvan" <vi...@poczta.onet.pl> writes:
>
> > Chociaż i tak caly atak kuleje.
> > Potencjalny intruz od samego początku musiałby kontrolować i to w
czasie
> > rzeczywistym korespondencje elektroniczną klienta z centrum
certyfikacji.
> > Nie jest to łatwe, a nawet jesli sie uda, to atak padnie w momencie
> > osobistej wizyty klienta w celu kontroli tozsamości. Trzeba by
wybudować
> > lipny oddział banku lub lipny punk rejestracji CA.
>
> Mówiłem tu o bezpieczeństwie od strony czysto informatycznej. MITM
> może wymaga sporych środków ze strony atakującego (możliwość
> filtrowania połączeń na jednym z routerów po drodze albo IP
> spoofing/hijacking), ale nie jest niemożliwe.
Nie jest to dosłownie ŻADNE zagrożenie (albo bardzo łatwe do
wyeliminowania) w procesie generowania ządania certyfikatu.
Nie jest też to ŻADNA odpowiedz na moje argumenty, że zapomniałes w
opisie ataku uwzględnić takiego "drobiazgu" jak obecność gościa w
punkcie rejestracji.
Proponuję grupę pl.comp.security.
> > zas dalej .... wybacz od tego jest grupa pl.comp.os.advocacy by
podyskutowac
> > sobie w kregu ekspertów (przepraszam za wyrazenie) nad wyzszoscia
Linuxa nad
> > Windowsami i odwrotnie.
>
> Nie ja zacząłem. :p
Hmmm. To nie wiesz od czego się zaczęło, a sprawa jest zasadnicza.
Ty zacząłes proponując uzywac Linuxa jako panaceum na sprawy wiązane z
bezpieczeństwem po stronie klienta.
Ja z kolei twierdze, że postawienie Linuxa, nawet najlepiej
skonfigurowanego, za firewallem nie zapobiega opisanym przez Ciebie
atakom (MITM).
Za to uwzględnienie Linuxa jako stacji roboczej klienta w bankowości
elektronicznej DZIS (!) albo powoduje olbrzymy wzrost kosztow
opracowania i dystrybucji aplikacji, albo eliminuje sprzętowego
wspomagania kryptografii. Więc w efekcie własnie umożliwia opisany przez
Ciebie atak.
Sprawa jest na prawde skomplikowana i zasadnicza, ale mi tak na prawdę
chodzi tylko o nieprawdziwość twierdzenia jakoby postawienie Linuxa lub
Unixa w domu załatwi sprawę i nic więcej.
Vizvary
Vizvary II Istvan
> "Vizvary II Istvan" <vi...@poczta.onet.pl> writes:
>
> > Wowczas kooprocesor kryptograficzny pobieral okolo 50 mA w czasie
obliczen
> > (teraz okolo 10 mA) i liczyl (RSA 1024 bit) okolo 3 sekund. (teraz
> > 300-700-1000 ms). To jest bardzo duzo dla urzadzenia bateryjnego. Na
tyle
> > duzo, ze czas pracy sie podaje nie w latach, tylko w ilosci
operacji. I to
> > bedzie niewiele operacji.
>
> A kto powiedział, że token musi być pancernie zamknięty i posiadać
> tylko okienko na wyświetlacz i ewentualnie guziczek? Zawsze można
> wprowadzić ładowanie. A żeby nie tracić kasy na ładowarki, dać
> przejściówkę do złącza baterii 9V (bo samo złącze byłoby
> niepraktyczne; chociaż, z jakąś zaślepką?) -- i ładować albo z
> baterii, albo z dowolnego zasilacza z takim wyjściem.
Tyle, że ja nie pisałem o tym co MOŻNABY, bo mozna i przewodem 5
milimetrowym podłaczyć do wózka akumulatorowego.
Ja pisałem o konkretnym tokenie, który wówczas widziałem. Albo i nie
widziałem, ale o nim usłyszałem. Już nie pamietam.
Zreszta moje założenia okazały się nieprawdziwe (jak kol. Halasa wykazał
wcale nie tak mało bedzie tych operacji) co nie zmienia faktu, że
wniosek wyciagnałem słuszny z tych błędnych przesłanek - token działał w
oparciu o pojedynczy DES.
Vizvary