On 22.01.2013 16:07, bartekltg wrote:
> W dniu 2013-01-22 15:45, Michoo pisze:
>> On 22.01.2013 13:11, bartekltg wrote:
>>> W dniu 2013-01-22 02:53, M.M. pisze:
>>>> 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;)
>>
>> Ale z tego co rozumiem on dodawał losowe znaki (nie wiem po co w "kilku
>> miejscach").
>
> Tak jak i w pisywanej metodzie. One siedzą pod nazwą 'salt'.
> Tylko były zapisywane.
>
>
>> XOR hasła z losowym dwubajtowym (nie zapisywanym) ciągiem jest znaną
>> metodą na:
>
> Nie zapisywanym?
Koniecznie.

>
>> - proste zwiększenie złożoności łamania hasła przy zachowaniu
>> istniejącej infrastruktury (średnio 32k razy, w praktyce więcej, bo
>> wynik jest z przedziału 0-255 a nie alfanum)
>> - uniemożliwienie użycia "złamanego" hasła (po znalezieniu odwzorowania
>> hash - String nadal ma się ~64k możliwości do zbadania)
>
>
> Nie wiem, nie znam się, więc powiedz mi, jak chcesz użyć losowej
> wartości nie zapisując jej? Jak wtedy chcesz zweryfikować
> osobę z hasłem.
>
> hash = fhash( hasło OXR rand() )
>
> Robimy to przy zakładaniu konta. Zapisujemy hash.
>
>
> Przychodzi teraz użytkownik, chce się zalogować,
> podaje [haslo]. Jak chcesz je porównać z hashem?
>
// rand jest z przedziału <0,2^16-2>
bool passOk=false;
for(uint16_t i=0;i<-1;i++){
hash = fhash( hasło OXR i )?
if(hash==db.hash){
passOk = true;
break;//*
}
}


Jak już pisałem - to jest do użycia gdy masz już jakąś infrastrukturę,
której nie chcesz zmieniać. Jak sam robisz "funkcję sprawdzającą" to
wywołanie md5 w pętli było jednym z ładniejszych rozwiązań.

> A jeśli zapisujesz, to ta losowa liczba może wyciec razem z hashem
> i wracamy do problemu opisanego iterację wyżej.

Tak, dlatego nie zapisujesz.


* uwaga - w teorii powoduje podatność na time-based attacks w przypadku
MiTM, rozwiązaniem jest trzymanie losowo permutowanej tablicy i XOR z
tab[i] zamiast z i. Imo to już przkombinowanie, bo atakujący musiałby
mieć bazę haszy i jednocześnie monitorować ruch. To równie dobrze by
mógł rootkit podrzucić.


--
Pozdrawiam
Michoo

do góry

W dniu wtorek, 22 stycznia 2013 16:29:06 UTC+1 użytkownik bartekltg napisał:
>
> No to jak porównujesz zapisany w bazie hash z hasłem
> wpisanym przez użytkownika?
Wyciagam klucz z bazy, odwracam i mam oryginalnego randa.
Haslo hasuje soląc randem i sprawdzam czy w bazie jest
taki sam klucz.

Pozdrawiam

do góry

W dniu wtorek, 22 stycznia 2013 16:38:09 UTC+1 użytkownik Michoo napisał:

> Tak, dlatego nie zapisujesz.
Tak moze wyciec Ci algorytm i masz taki sam efekt jakby
wyciekł seciurity_salt. Byś musiał jeszcze algorytmu
nie zapisywać :)

Pozdrawiam

do góry

W dniu wtorek, 22 stycznia 2013 16:20:53 UTC+1 użytkownik bartekltg napisał:
> Ubezpieczenie auta od kradzieży powoduje, że jest ono
> zabezpieczone przed kradzieżą? To zabezpiecza przed
> poniesieniem (większości) strat związanych z kradzieżą,
> nie przed samą kradzieżą.

Dla mnie tak, pozbylbym sie grata w zamian za odszkodowanie :D

Jesli kupuję jakiś sprzęt i mam gwarancję na ileś lat, to
czuję się bezpiecznie. Przypuszczam że ktoś się starał zrobić
to solidnie. Oczywiście nie oznacza to, że czasami urządzenia
nie pasują się przed upływem gwarancji. No cóż, czasami się mylimy,
być może i ja mylnie oceniłem bezpieczeństwo.

Pozdrawiam

do góry

On 2013-01-22, M.M. <m...@g...com> wrote:
> W dniu wtorek, 22 stycznia 2013 15:34:28 UTC+1 użytkownik Stachu 'Dozzie' K.
napisał:
>>
>> 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).
> Jest bezpieczny chociazby z powodu odpowiedzialnosci finansowej za
> niego.

Nie, mój drogi. Prawny dupochron nie wpływa bezpośrednio na
bezpieczeństwo systemu, służy jedynie ukierunkowaniu konsekwencji. Znowu
mieszasz dwa różne światy.

>> Częsty błąd laików. To, że dowód jest prosty jeszcze nie znaczy, że
>> obejmuje wszystkie potrzebne przypadki i możliwe ataki.
> Ale właśnie prostota polega na tym, że możliwych przypadków jest mało.

Przypadków przewidzianych. Skąd wiadomo że obsłużyłeś wszystkie
przypadki, w tym te nieoczywiste? Jako laik możesz sobie nie zdawać
sprawy ze wszystkich metod wyciekania danych. Specjalistom się rzadko
udaje wszystko przewidzieć, a ty uważasz, że tobie akurat jednemu się
udało?

>> A skąd ten pomysł? Może zawodowiec będzie miał możliwość przeprowadzenia
>> ataku tylko w tym jednym miejscu?
> To system nadal jest bezpieczny, bo wtedy ja pokrywam koszty za straty.

Nie. To nie jest system bezpieczny, tylko ubezpieczony prawnie.
Analogicznie, jeśli *ubezpieczysz* samochód od kradzieży, to jeszcze nie
znaczy, że jest *zabezpieczony*. Nie znaczy jeszcze, że możesz nie
zamykać drzwi.

>> 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.
> W czym problem? Wielokrotnie, a w przypadku prostego softu niemal zawsze,
> udawało mi się obsłużyć wszystkie przypadki.

W tym, że wtedy pisałeś soft, a nie tworzyłeś kryptosystemy.
Z kryptosystemów najprawdopodobniej jesteś dupa (nie masz przeszkolenia,
a w samorodny talent w tym przypadku nie wierzę) i nie ma podstaw
sądzić, że udało ci się wszystko przewidzieć.

>> 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ę.
> Jedno z drugim nie może współistnieć. Albo analiza dobra i dobry produkt, albo
> w analizie coś pomiąłem i produkt do dupy.

Ty to stwierdziłeś. Ja jedynie dyskwalifikuję twoją analizę (z dwóch
ważnych powodów podanych wyżej).

>> 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.
> Argumentował że jego doświadczenie/wykształcenie jest spore, a
> sposób łamania banalny - potem nie złamał.

Nadal: może nie miał motywacji, żeby w ogóle myśleć o tej sprawie? Tak
przedstawiona historia jest jedynie anegdotą i nie ma żadnej wartości
jako argument za twoimi zdolnościami kryptograficznymi.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2013-01-22, bartekltg <b...@g...com> wrote:
>>> 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.
>> W czym problem? Wielokrotnie, a w przypadku prostego softu niemal zawsze,
>> udawało mi się obsłużyć wszystkie przypadki.
>
> Bardzo prosty przypadek. Kodowanie RSA.
[cut]

Szyfrowanie. Jeśli wchodzisz na grunt kryptografii, używaj własciwej
terminologii.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2013-01-21, Stachu 'Dozzie' K. <d...@g...eat.some.screws.spammer.invalid> wrote:
> Dla naprostowania, bo identyfikator -- jak to on zwykle -- popieprzył
> terminologię:
> * funkcja może być jednokierunkowa, inaczej nieodwracalna, a nie

Sam popieprzyłeś. Funkcje jednokierunkowe jak najbardziej są odwracalne,
"inszyniesze".

pozdrawiam,
PK

do góry

On 2013-01-22, PK <P...@n...com> wrote:
> On 2013-01-21, Stachu 'Dozzie' K. <d...@g...eat.some.screws.spammer.invalid>
wrote:
>> Dla naprostowania, bo identyfikator -- jak to on zwykle -- popieprzył
>> terminologię:
>> * funkcja może być jednokierunkowa, inaczej nieodwracalna, a nie
>
> Sam popieprzyłeś. Funkcje jednokierunkowe jak najbardziej są odwracalne,
> "inszyniesze".

I co dostajesz? Przeciwobraz? No popacz, a nie oryginalną wartość? Też
mi odwrotność funkcji. Bo wiesz co to jest funkcja odwrotna? Czy może
mam ci przytoczyć definicję?

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu wtorek, 22 stycznia 2013 17:27:29 UTC+1 użytkownik Stachu 'Dozzie' K. napisał:
> Nie, m�j drogi. Prawny dupochron nie wp�ywa bezpo�rednio na
> bezpiecze�stwo systemu, s�u�y jedynie ukierunkowaniu konsekwencji. Znowu
> mieszasz dwa r�ne �wiaty.
Jak mi ukradna samochod, to moge kupic nowy za odszkodowanie, czyli
pomimo kradziezy mam samochod nadal. To na pewno nie wyplywa bezposrednio
na bezpieczenstwo?


> Przypadk�w przewidzianych. Sk�d wiadomo �e obs�u�y�e� wszystkie
> przypadki, w tym te nieoczywiste? Jako laik mo�esz sobie nie zdawa�
> sprawy ze wszystkich metod wyciekania danych. Specjalistom siďż˝ rzadko
> udaje wszystko przewidzie�, a ty uwa�asz, �e tobie akurat jednemu si�
> uda�o?
Nie musialem przewidziec wszystkich przypadkow. Za bezpieczenstwo systemow
operacyjnych, siei i innego badziewia instalowanego na komputerach
odpowiada ktos inny, a wlasciwie to nawet nie wiem czy odpowiada. Wzialem
odpowiedzialnosc tylko za swoja robote. A pewnie ze ktos moze sie
wlamac przez byle ftp jak zle skonfiguruja, moze sie przyjrzec jak co
dziala i rozwalic moj system. Nigdy nie twierdzilem ze przewidzialem
wszystkie przypadki, albo ze chociaz probowalem przewidziec wszystkie.


> Nie. To nie jest system bezpieczny, tylko ubezpieczony prawnie.
> Analogicznie, je�li *ubezpieczysz* samoch�d od kradzie�y, to jeszcze nie
> znaczy, �e jest *zabezpieczony*. Nie znaczy jeszcze, �e mo�esz nie
> zamykaďż˝ drzwi.
Nie twierdze ze moge drzwi zostawiac otwarte. Jest wrecz przeciwnie, system
dziala, jesli jest spelniony dlugi szereg zalozen.


Pozdrawiam

do góry

W dniu wtorek, 22 stycznia 2013 16:20:53 UTC+1 użytkownik bartekltg napisał:

> Kiedyś na wydziale informatyki spotkałem gościa, co właśnie
> kończył zdobywać papier potwierdzający wykształcenie i święcie
> wierzył,że jak będzie liczył na GPU to pokona algorytm na
> procesorze o lepszej złożoności, niezależnie od wielkości danych;)

W sumie to ciekawe, miałem podobną rozmowę i to niezbyt dawno,
może ze 3 miesiące temu. Facet dawno po studiach, pracuje w
zawodzie, z tego co wiem, nieźle zarabia, itd. Rozmawiamy o
łamaniu hasła burteforcem. Mówi że ma CUDE i na tym to można
wszystko policzyć. Zastanowiłem się, myślę że może źle
coś oszacowałem i mówię, no to ewentualnie można zwiększyć
rozmiar hasła o jedno albo dwa znaki i już nie policzysz.
On na to: na CUDA? wiesz ile to ma procesorów?

Nie wiem ile to ma procesorów, ale najwyraźniej w jego
wersji ilość procesorów rośnie wraz z ilością danych i
to rośnie wykładniczo:D

Pozdrawiam

do góry