W dniu wtorek, 22 stycznia 2013 10:32:08 UTC+1 użytkownik Stachu 'Dozzie' K. napisał:
> >> Mój drogi, każdy głupi jest tak mądry, żeby opracować kryptosystem,
> >> którego sam nie umie złamać. Tylko że to za mało dla obrony przed
> >> prawdziwym adwersarzem. Nie wiem co chciałeś pokazać w tym akapicie.
> > Jest odporny na wszystkie ataki jakich zazyczyl sobie klient, jestem
> > odpowiedzialny za to i nie mam z tego tytulu problemow.
>
> "Jest odporny". Kto to oceniał? Ty? Klient? Mądra głowa, kosztująca
> pięciokrotność budżetu? Społeczność kryptologów na podstawie publikacji
> naukowej?
Nie rozumiem dlaczego tak sie interesujesz systemem stworzonym
przez kogos kto nie ma przygotowania kryptograficznego. Zdaje sie
ze Ty jestes ekspertem od kryptografii i zaczales cos o mozliwosciach
zastosowania MD5 w kryptografii pod warunkiem ze sie wie gdzie
mozna zastosowac. Mysle ze inni podobne jak i ja chetniej posluchaja
eksperta.

> Nadal nie widać dowodu czy uzasadnienia, że kryptosystem (to był
> w ogóle kryptosystem? bo IMO nie było to jasno powiedziane) został
> przygotowany prawidłowo.
Szczegolow publicznie nie zaprezentuje. W moim odczuciu dowod skutecznosci
jest poprawny. A czy sie nie myle.... coz, zawsze jest taka mozliwosc Ogolnie
dowod polega na tym, ze uzyskamy w wyniku ataku wszystkie ciagi i kazdy
ciag jest rownie dobry.

Abstrahujac od tematu, kiedys rozmaiwalem z kims kto podobnie argumentowal
jak Ty. Byl po studiach kierunkowych i sam wykladal na uczelniach. Opowiadal
jakie hasla zlamal, jakie ataki przeprowadzil, itd. Gdy poprosilem go o
odszyfrowanie wiadomosci zaszyfrowanej prostym algorytmem i krotkim haslem to
nie dal rady. Wiedzial ze wiadomosc jest kopia jednej wiadomosci na usenecie,
mial tylko powiedziec ktora to. Algorytm opracowalem jeszcze w szkole sredniej
kierujac sie tylko i wylacznie intuicja.

Pozdrawiam

do góry

W dniu wtorek, 22 stycznia 2013 10:45:14 UTC+1 użytkownik Maciej Sobczak napisał:
> Bogusław podał scenariusz, gdzie admini/programiści naśmiewają się z haseł i
> to jest powód, żeby te hasła kodować. OK, nie przyszło mi to do głowy.

Alez to byl zart. Chodzi oto, ze jak ktos w Twoim serwisie uzyje tego
samego hasla co w banku, to mozesz mu sie zalogowac na konto. A jak poda
to samo haslo co mailowe, to mozesz zmienic haslo w prawie wszystkich
serwisach, lacznie z moneybookers...

Pozdrawiam

do góry

W dniu wtorek, 22 stycznia 2013 10:55:54 UTC+1 użytkownik Maciej Sobczak napisał:
> Intuicja podpowiada mi, że w kontekście bezpieczeństwa informacji szczególne
> traktowanie jednego tylko elementu, np. hashowanie haseł, jest albo a)
> niewystarczające albo b) niepotrzebne.
Zalezy od wymogow. Dobre zahashowanie hasel przydaje sie gdy kopia bazy
lezy gdzies poza komputerem.

W przypadku ochrony przed administratorem to nie rozwiazuje w pelni
problemu. Program w koncu dostaje haslo w niezaszyfrowanej postaci.
Admin zawsze moze podpiac kod ktory zrzuci gdzies hasla w golej postaci.
W przyadku obrony przed takim adminem, ten prosty zabieg jest wlasnie
niewystarczajacy. On jedynie troche utrudnia.

Pozdrawiam

do góry

W dniu 2013-01-22 02:53, M.M. pisze:
> W dniu poniedziałek, 21 stycznia 2013 10:21:35 UTC+1 użytkownik yamma napisał:
>> No i jeszcze pasowałoby przedtem posolić, żeby z takich samych haseł nie
>> wyszły identyczne "hasze". Ja zazwyczaj solę GUIDem, który jest
>> identyfikatorem rekordu ale np. Microsoft w ASP.NETowym Membershipie tworzy
>> dodatkowe pole z losowo wygenerowanym ciągiem znaków.
>
> Określenia "posolić" używa się normalnie, czy tak sobie napisałeś?
> Ja dodaje losowe znaki w kilku miejscach oryginalnego ciągu, potem
> jakiś standardowy klucz sha, albo md5, albo nawet jakiś własny. Gdzieś
> czytałem że md5 został rozpracowany - nie wiem znaczy słowo "rozpracowany",
> ale tak czy inaczej do hashowania w poważnej kryptografii lepiej nie używać.

Zwróć uwagę na to, o czym prawie kulturalnie mówił Stachu
wczoraj a daniel rzucił linka. Jeśli poza bazą danych o hasłach
(hash i 'sól')wycieknie też metoda kodowania (a czemu ma nie
wyciec, skoro baza wyciekła, o ile wręcz nie jest jawna) to
jesteśmy podatni na atak przez ręczne md5 wszystkich możliwych
haseł. Jeśli nie są one zbyt długie, jest to robialne.

Sól daje to, że operację trzeba powtórzyć dla każdego użytkownika,
zamiast za jednym zamachem mieć odkodowanych wszystkich,
ale to niewielka pociecha, gdy np Ty jesteś celem;)


Różnica między
http://en.wikipedia.org/wiki/Cryptographic_hash_func
tion
a
http://en.wikipedia.org/wiki/Key_derivation_function


I to, na co koledzy zwrócili uwagę:
Modern password-based key derivation functions, such as PBKDF2
(specified in RFC 2898), use a cryptographic hash, such as MD5
or SHA1, more salt (e.g. 64 bits and greater) and a high iteration
count (often 1000 or more). NIST requires at least 128 bits of
random salt and a NIST-approved cryptographic function, such as
the SHA series or AES (MD5 is not approved).[5] There have been
proposals to use algorithms that require large amounts of computer
memory and other computing resources to make custom hardware
attacks more difficult to mount.


pzdr
bartekltg

do góry

W dniu wtorek, 22 stycznia 2013 13:11:54 UTC+1 użytkownik bartekltg napisał:
>
> > Określenia "posolić" używa się normalnie, czy tak sobie napisałeś?
> > Ja dodaje losowe znaki w kilku miejscach oryginalnego ciągu, potem
> > jakiś standardowy klucz sha, albo md5, albo nawet jakiś własny. Gdzieś
> > czytałem że md5 został rozpracowany - nie wiem znaczy słowo "rozpracowany",
> > ale tak czy inaczej do hashowania w poważnej kryptografii lepiej nie używać.
>
> Zwróć uwagę na to, o czym prawie kulturalnie mówił Stachu
> wczoraj a daniel rzucił linka. Jeśli poza bazą danych o hasłach
> (hash i 'sól')wycieknie też metoda kodowania (a czemu ma nie
> wyciec, skoro baza wyciekła, o ile wręcz nie jest jawna) to
> jesteśmy podatni na atak przez ręczne md5 wszystkich możliwych
> haseł. Jeśli nie są one zbyt długie, jest to robialne.

Te podstawy to raczej znam. Nie wiedziałem tylko ze to nazywa
sie "sól". Ja zastosowałem rozwiązanie w którym właśnie atak przez
sprawdzenie wszystkich funkcji hash nic nie da, nawet jak wycieknie
baza z haslami, metoda hashowania i sposób dodawania szumu do haseł.
Nawet nic nie pomoże jak nieuczciwy pracownik firmy podsłucha całą
transmisję, albo napisze skrypt i uruchomi go jako root na serwerze.
Oczywiście są inne sposoby na rozwalenie tego systemu, ale
wiadomo co trzeba zrobić aby nie dopuścić do tego. Obejście zabezpieczeń
jest tak trudne, że jest osoba która bierze odpowiedzialność finansową i
jednocześnie śpi spokojnie. Istnieje też prostszy sposób obejścia
zabezpieczeń, ale z kolei za ten sposób mój klient przed swoimi klientami
nie musi ponosić odpowiedzialności.

Pozdrawiam

do góry

On 2013-01-22, M.M. <m...@g...com> wrote:
> W dniu wtorek, 22 stycznia 2013 10:32:08 UTC+1 użytkownik Stachu 'Dozzie' K.
napisał:
>> >> Mój drogi, każdy głupi jest tak mądry, żeby opracować kryptosystem,
>> >> którego sam nie umie złamać. Tylko że to za mało dla obrony przed
>> >> prawdziwym adwersarzem. Nie wiem co chciałeś pokazać w tym akapicie.
>> > Jest odporny na wszystkie ataki jakich zazyczyl sobie klient, jestem
>> > odpowiedzialny za to i nie mam z tego tytulu problemow.
>>
>> "Jest odporny". Kto to oceniał? Ty? Klient? Mądra głowa, kosztująca
>> pięciokrotność budżetu? Społeczność kryptologów na podstawie publikacji
>> naukowej?
> Nie rozumiem dlaczego tak sie interesujesz systemem stworzonym
> przez kogos kto nie ma przygotowania kryptograficznego.

Dlatego, że ten ktoś wyciąga przykład tego systemu jako dowód swojej
biegłości (?) w kryptografii czy bezpieczeństwie komputerowym w ogóle.
Chcę zatem się dowiedzieć, na ile ten dowód jest wiarygodny, tzn. na ile
rzeczony system został oceniony przez ludzi, o których wiadomo, że są
kompetentni.

>> Nadal nie widać dowodu czy uzasadnienia, że kryptosystem (to był
>> w ogóle kryptosystem? bo IMO nie było to jasno powiedziane) został
>> przygotowany prawidłowo.
> Szczegolow publicznie nie zaprezentuje. W moim odczuciu dowod skutecznosci
> jest poprawny.

Twoje odczucie jest nieistotne, bo jesteś autorem systemu. Jak pisałem,
nawet idiota jest w stanie stworzyć system, którego nie będzie umiał sam
złamać. To obrona przed atakami zawodowców jest miarą skuteczności.

A o szczegóły, proszę zauważyć, na razie nie prosiłem. Prosiłem jedynie
o podanie a) jakiego rodzaju relacja łączyła autora systemu (ciebie)
z oceniającym bezpieczeństwo tego systemu i b) jakie kompetencje miał
oceniający, o ile to była inna osoba.

> Abstrahujac od tematu, kiedys rozmaiwalem z kims kto podobnie argumentowal
> jak Ty. Byl po studiach kierunkowych i sam wykladal na uczelniach. Opowiadal
> jakie hasla zlamal, jakie ataki przeprowadzil, itd. Gdy poprosilem go o
> odszyfrowanie wiadomosci zaszyfrowanej prostym algorytmem i krotkim haslem to
> nie dal rady. Wiedzial ze wiadomosc jest kopia jednej wiadomosci na usenecie,
> mial tylko powiedziec ktora to. Algorytm opracowalem jeszcze w szkole sredniej
> kierujac sie tylko i wylacznie intuicja.

OK. Czy znał algorytm szyfrowania? Ile miał czasu na przygotowania
i prace? Jak dobrą miał motywację, żeby w ogóle się zajmować twoim
algorytmem? I czy zostały znalezione inne słabości twojego algorytmu? Bo
bezpieczeństwo to nie tylko niemożność odszyfrowania wiadomości przy
nieznanym kluczu.

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu 2013-01-22 14:08, M.M. pisze:
> W dniu wtorek, 22 stycznia 2013 13:11:54 UTC+1 użytkownik bartekltg napisał:
>>
>>> Określenia "posolić" używa się normalnie, czy tak sobie napisałeś?
>>> Ja dodaje losowe znaki w kilku miejscach oryginalnego ciągu, potem
>>> jakiś standardowy klucz sha, albo md5, albo nawet jakiś własny. Gdzieś
>>> czytałem że md5 został rozpracowany - nie wiem znaczy słowo "rozpracowany",
>>> ale tak czy inaczej do hashowania w poważnej kryptografii lepiej nie używać.
>>
>> Zwróć uwagę na to, o czym prawie kulturalnie mówił Stachu
>> wczoraj a daniel rzucił linka. Jeśli poza bazą danych o hasłach
>> (hash i 'sól')wycieknie też metoda kodowania (a czemu ma nie
>> wyciec, skoro baza wyciekła, o ile wręcz nie jest jawna) to
>> jesteśmy podatni na atak przez ręczne md5 wszystkich możliwych
>> haseł. Jeśli nie są one zbyt długie, jest to robialne.
>
> Te podstawy to raczej znam. Nie wiedziałem tylko ze to nazywa
> sie "sól". Ja zastosowałem rozwiązanie w którym właśnie atak przez
> sprawdzenie wszystkich funkcji hash nic nie da, nawet jak wycieknie
> baza z haslami, metoda hashowania i sposób dodawania szumu do haseł.

Dlaczego nic nie da.

hash = H (haslo, salt).

Znam H, znam salt (wszytkie liczby losowe dodane w procedurze),
znam hash.

Jeśli H liczy się _szybko_, to podstawiam rozsądne hasła
(niezbyt długie alfanumeryczne + pare znaczków jak "_")
i po niedługim czasie mam dopasowanie.


Pytanie było o ten typ ataku. Jak sobie z nim poradzileś
inaczej niż skomplikowaną (wymagającą długich obliczeń) H?


> jednocześnie śpi spokojnie. Istnieje też prostszy sposób obejścia
> zabezpieczeń, ale z kolei za ten sposób mój klient przed swoimi klientami
> nie musi ponosić odpowiedzialności.

Brzmi to jak spora fuszerka:(

pzdr
bartekltg

do góry

W dniu wtorek, 22 stycznia 2013 14:24:55 UTC+1 użytkownik Stachu 'Dozzie' K. napisał:
>
>
> Dlatego, że ten ktoś wyciąga przykład tego systemu jako dowód swojej
> biegłości (?) w kryptografii czy bezpieczeństwie komputerowym w ogóle.
> Chcę zatem się dowiedzieć, na ile ten dowód jest wiarygodny, tzn. na ile
> rzeczony system został oceniony przez ludzi, o których wiadomo, że są
> kompetentni.
W zabezpieczeniach duże znaczenie, a może najważniejsze, ma ekonomia.
W razie problemów z powodu nie wykonania obowiązków ponoszą odpowiedzialność
finansową osoby którym te obowiązki powierzono. W razie jak nie zadziała
system wypełniania obowiązków, odpowiedzialność finansową ponoszę ja.
Ja się na to zgodziłem, osoby które otrzymały obowiązki się zgodziły,
odbiorca projektu na to się zgodził. Czyli od strony ekonomicznej dowód
jest w 100% wiarygodny i wszyscy są zadowoleni. Co jeszcze ważne, system może
administrować firma zewnętrzna, która nie musi ponosić odpowiedzialności
za to że ich pracownik, który ma fizyczny dostęp do komputera, okaże się
nieuczciwy i np. zabierze twardy dysk do domu.

Co do oceny przez specjalistów od zabezpieczeń to takiej w ogóle nie było,
gdyż po wycenie ( z tego co pamiętam w cenie była też odpowiedzialność
finansowa ) wszelkie oferty były absolutnie nie do przyjęcia, jak już
pisałem, ceny przewyższały cały projekt wielokrotnie.

Generalnie to dowód skuteczności nie jest zbytnio zawiły, jest wręcz
prosty, dlatego bez szczegółowej wiedzy z dziedziny, uznałem go za
poprawny. Niemniej zawsze jest taka możliwość, że mogę się mylić - no
ale to oczywiste, taka możliwość wchodzi zawsze w grę.


> Twoje odczucie jest nieistotne, bo jesteś autorem systemu. Jak pisałem,
> nawet idiota jest w stanie stworzyć system, którego nie będzie umiał sam
> złamać. To obrona przed atakami zawodowców jest miarą skuteczności.
Zrozumiałem.
Zawodowiec prawdopodobnie (na pewno) przeprowadziłby tańszy atak (znowu
ekonomia) niż atak na te elementy systemu za które wziąłem odpowiedzialność.
Piszesz że moje odczucie jest nieistotne, tak czy inaczej, moje odczucie
właśnie jest takie, że co innego jest wąskim gardłem i w razie ataku co
innego zostanie rozwalone. Może jakaś dziura w systemie operacyjnym, może
błąd w jakimś programie nie pisanym przeze mnie, może jakaś dziura w bazie
danych, może pracownik-samobójca...

> A o szczegóły, proszę zauważyć, na razie nie prosiłem. Prosiłem jedynie
> o podanie a) jakiego rodzaju relacja łączyła autora systemu (ciebie)
> z oceniającym bezpieczeństwo tego systemu i b) jakie kompetencje miał
> oceniający, o ile to była inna osoba.
Nie było innych osób. Zrobiliśmy to tak, że możemy wziąć odpowiedzialność.
Możemy wyznaczyć założenia przy których system jest bezpieczny i zakres
czynności aby te założenia były spełnione. Jak system padnie - ja becaluję.


> > Abstrahujac od tematu, kiedys rozmaiwalem z kims kto podobnie argumentowal
> > jak Ty. Byl po studiach kierunkowych i sam wykladal na uczelniach. Opowiadal
> > jakie hasla zlamal, jakie ataki przeprowadzil, itd. Gdy poprosilem go o
> > odszyfrowanie wiadomosci zaszyfrowanej prostym algorytmem i krotkim haslem to
> > nie dal rady. Wiedzial ze wiadomosc jest kopia jednej wiadomosci na usenecie,
> > mial tylko powiedziec ktora to. Algorytm opracowalem jeszcze w szkole sredniej
> > kierujac sie tylko i wylacznie intuicja.


> OK. Czy znał algorytm szyfrowania? Ile miał czasu na przygotowania
> i prace? Jak dobrą miał motywację, żeby w ogóle się zajmować twoim
> algorytmem? I czy zostały znalezione inne słabości twojego algorytmu? Bo
> bezpieczeństwo to nie tylko niemożność odszyfrowania wiadomości przy
> nieznanym kluczu.

Nie wiem co on znał, a co nie znał. Nakreśliłem mu algorytm, a on w
zachwycie powiedział, że to się łamie jakimś tam sposobem. Tłumaczę mu,
że to jest niemożliwe, bo otrzyma wszystkie ciągi i każdy będzie równie
dobry. On na to ze bzdury gadam, bo już nie takie rzeczy łamał. No to
mu zaniosłem do złamania i nie doczekałem się rozwiązania do dziś.
Pozdrawiam

do góry

On 2013-01-22, M.M. <m...@g...com> wrote:
> W dniu wtorek, 22 stycznia 2013 14:24:55 UTC+1 użytkownik Stachu 'Dozzie' K.
napisał:
>>
>>
>> Dlatego, że ten ktoś wyciąga przykład tego systemu jako dowód swojej
>> biegłości (?) w kryptografii czy bezpieczeństwie komputerowym w ogóle.
>> Chcę zatem się dowiedzieć, na ile ten dowód jest wiarygodny, tzn. na ile
>> rzeczony system został oceniony przez ludzi, o których wiadomo, że są
>> kompetentni.
> W zabezpieczeniach duże znaczenie, a może najważniejsze, ma ekonomia.

Nie, mój drogi. W opracowywaniu zabezpieczeń ma znaczenie koszt
wytworzenia tego zabezpieczenia. Ekonomia ma znaczenie dopiero
w zarządzaniu ryzykiem. Mylisz dwa światy.

> W razie problemów z powodu nie wykonania obowiązków ponoszą odpowiedzialność
> finansową osoby którym te obowiązki powierzono. W razie jak nie zadziała
> system wypełniania obowiązków, odpowiedzialność finansową ponoszę ja.
> Ja się na to zgodziłem, osoby które otrzymały obowiązki się zgodziły,
> odbiorca projektu na to się zgodził. Czyli od strony ekonomicznej dowód
> jest w 100% wiarygodny i wszyscy są zadowoleni.

Mylisz dwie rzeczy. Jedną jest czy dowód jest wiarygodny, a drugą jest
adekwatność zabezpieczenia (tu: domorosłego, najwyraźniej
nieposiadającego sensownej analizy bezpieczeństwa) do ryzyka.

> Co jeszcze ważne, system może
> administrować firma zewnętrzna,

Firma może "zarządzać ten system"? Czy "tym systemem"? Polska język
trudna język.

> która nie musi ponosić odpowiedzialności
> za to że ich pracownik, który ma fizyczny dostęp do komputera, okaże się
> nieuczciwy i np. zabierze twardy dysk do domu.
>
> Co do oceny przez specjalistów od zabezpieczeń to takiej w ogóle nie było,
> gdyż po wycenie ( z tego co pamiętam w cenie była też odpowiedzialność
> finansowa ) wszelkie oferty były absolutnie nie do przyjęcia, jak już
> pisałem, ceny przewyższały cały projekt wielokrotnie.

No własnie. Brak kiepskiej analizy bezpieczeństwa jest ryzykiem. Ryzyko
twojego fuckupu zostało pewnie wliczone, ale to nie znaczy, że system
jest bezpieczny. Po prostu stwierdzono, że nie musi być bezpieczny (i to
jest w porządku; nie wszystko musi być ogrodzone zasiekami i polem
minowym).

> Generalnie to dowód skuteczności nie jest zbytnio zawiły, jest wręcz
> prosty, dlatego bez szczegółowej wiedzy z dziedziny, uznałem go za
> poprawny.

Częsty błąd laików. To, że dowód jest prosty jeszcze nie znaczy, że
obejmuje wszystkie potrzebne przypadki i możliwe ataki.

>> Twoje odczucie jest nieistotne, bo jesteś autorem systemu. Jak pisałem,
>> nawet idiota jest w stanie stworzyć system, którego nie będzie umiał sam
>> złamać. To obrona przed atakami zawodowców jest miarą skuteczności.
> Zrozumiałem.
> Zawodowiec prawdopodobnie (na pewno) przeprowadziłby tańszy atak (znowu
> ekonomia) niż atak na te elementy systemu za które wziąłem odpowiedzialność.

A skąd ten pomysł? Może zawodowiec będzie miał możliwość przeprowadzenia
ataku tylko w tym jednym miejscu?

> Piszesz że moje odczucie jest nieistotne, tak czy inaczej, moje odczucie
> właśnie jest takie, że co innego jest wąskim gardłem i w razie ataku co
> innego zostanie rozwalone.

Już pisałem: twoje odczucie jako autora jest nieistotne. Ty jesteś
przekonany o tym, że obsłużyłeś wszystkie możliwe (albo choćby sensowne)
scenariusze, bo inaczej włączyłbyś to, czego brakuje, do systemu.
Sytuacja taka sama jak z testowaniem softu: autor kodu nie powinien tego
robić sam.

>> A o szczegóły, proszę zauważyć, na razie nie prosiłem. Prosiłem jedynie
>> o podanie a) jakiego rodzaju relacja łączyła autora systemu (ciebie)
>> z oceniającym bezpieczeństwo tego systemu i b) jakie kompetencje miał
>> oceniający, o ile to była inna osoba.
> Nie było innych osób.

Właśnie. Dlatego twoją analizę bezpieczeństwa można o kant dupy rozbić
(jesteś autorem i nie masz przygotowania z bezpieczeństwa).

Zaznaczam, że to nie dyskwalifikuje samego produktu. To jedynie
dyskwalifikuje analizę.

>> OK. Czy znał algorytm szyfrowania? Ile miał czasu na przygotowania
>> i prace? Jak dobrą miał motywację, żeby w ogóle się zajmować twoim
>> algorytmem? I czy zostały znalezione inne słabości twojego algorytmu? Bo
>> bezpieczeństwo to nie tylko niemożność odszyfrowania wiadomości przy
>> nieznanym kluczu.
>
> Nie wiem co on znał, a co nie znał. Nakreśliłem mu algorytm, a on w
> zachwycie powiedział, że to się łamie jakimś tam sposobem. Tłumaczę mu,
> że to jest niemożliwe, bo otrzyma wszystkie ciągi i każdy będzie równie
> dobry. On na to ze bzdury gadam, bo już nie takie rzeczy łamał. No to
> mu zaniosłem do złamania i nie doczekałem się rozwiązania do dziś.

Aha. Czyli w sumie żaden argument, ot, taka anegdota do opowiadania
w towarzystwie. Gościu może po prostu nie miał motywacji (pieniądze?
sława? nauczenie się czegoś nowego? dobra łamigłówka? chęć popisania
się?), żeby się tym w ogóle zająć, może był za głupi, a może algorytm
rzeczywiście taki wypasiony.

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu wtorek, 22 stycznia 2013 14:44:16 UTC+1 użytkownik bartekltg napisał:
>
> Dlaczego nic nie da.
> hash = H (haslo, salt).
> Znam H, znam salt (wszytkie liczby losowe dodane w procedurze),
> znam hash.
> Jeśli H liczy się _szybko_, to podstawiam rozsądne hasła
> (niezbyt długie alfanumeryczne + pare znaczków jak "_")
> i po niedługim czasie mam dopasowanie.
Jest znacznie gorzej. Nieuczciwy administrator ma gotowe hasła w
formacie tekstowym i nie musi niczego dekodować, niczego obliczać
ani nie musi mieć wiedzy kryptograficznej. Jak zauważył Maciej Sobczak
takie klucze są niepotrzebne/niewystarczające. Musiałem poradzić sobie
zupełnie inaczej.


> Pytanie było o ten typ ataku. Jak sobie z nim poradzileś
> inaczej niż skomplikowaną (wymagającą długich obliczeń) H?
Nie mogę napisać jak, musiałem poradzić sobie inaczej.


> > jednocześnie śpi spokojnie. Istnieje też prostszy sposób obejścia
> > zabezpieczeń, ale z kolei za ten sposób mój klient przed swoimi klientami
> > nie musi ponosić odpowiedzialności.
> Brzmi to jak spora fuszerka:(
A nie jest fuszerką. Po prostu zanim dane dotrą do komputerów klienta, to
on za ich bezpieczeństwo nie odpowiada. Wszelka logika z kolei podpowiada,
że jakby ktoś chciał przeprowadzić atak, to właśnie by atakował na etapie
wcześniejszym, bo tam łatwiej i taniej.

Pozdrawiam

do góry