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").

XOR hasła z losowym dwubajtowym (nie zapisywanym) ciągiem jest znaną
metodą na:
- 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)

(Zamiast XOR można użyć też doklejenie, ale nie powoduje to drugiego
bonusu.)

--
Pozdrawiam
Michoo

do góry

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.


> 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.

> 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.


> 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ł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.


> 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ł.


Pozdrawiam

do góry

On 22.01.2013 10:55, Maciej Sobczak wrote:
> W dniu poniedziałek, 21 stycznia 2013 23:46:29 UTC+1 użytkownik Stachu 'Dozzie' K.
napisał:
>
>> Ano po to, Maćku, żeby utrata bazy haseł użytkowników z jednej
>> aplikacji czy serwisie nie prowadziła (zbyt łatwo) do kompromitacji kont
>> tych samych ludzi w innych serwisach.
>
> Rozumiem.
>
> Co prawda założenie, że baza haseł zostanie utracona, powoduje u
> mnie
> dyskomfort. Mówimy o systemie, który my sami tworzymy (bo tylko wtedy
> mamy wybór, jak przechować hasła) a skoro my sami go tworzymy, to jak
> możemy zakładać, że utracimy bazę? Rozumiem, że jest to część
> zarządzania ryzykiem i minimalizujemy straty w przypadku katastrofy,
> przed którą nie zapewniliśmy 100% ochrony.

Jeżeli masz serwis w sieci to niestety musisz założyć, że prędzej czy
później możesz wpaść na 0day w jakimś frameworku. Wtedy warto
minimalizować zniszczenia.

>
> Natomiast nadal pozostaje pytanie o pozostałą zawartość bazy. Czy
> jeżeli rozwiążemy *jakoś* (temat otwarty) problem tej pozostałej części,
> to czy nadal jest sens przejmować się hasłami, skoro rozwiązanie dla
> całej bazy może objąć również hasła?

Jedno z rozwiązań na klientów typu "dlaczego mamy wam zaufać w
bezpieczeństwie danych?" (w lekkim uproszczeniu):
- klucz generowany z hasła usera
- dane w bazie szyfrowane kluczem
- hasło przesyłane clear-textem po SSLu, generowany klucz, jak się nim
zdeszyfruje "access granted" to znaczy, że jest prawidłowe ;)

Zostaje jedna kwestia - klient musi podpisać, że "W przypadku zagubienia
hasła nie istnieje możliwość odzyskania danych. Zabezpieczenie to
zostaje włączone na życzenie Klienta i Klient w pełni zdaje sobie sprawę
z konsekwencji zagubienia hasła."

"... Ale serio - to jest maksymalnie bezpieczne więc jak zgubicie hasło
to jesteście udupieni i my nic nie damy rady zrobić... Poważnie...Przy
długim haśle kilkadziesiąt tysięcy i nawet kilka miesięcy..." Nagle
bezpieczeństwo przestaje być tak "kluczową" kwestią ;)

--
Pozdrawiam
Michoo

do góry

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?

> - 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?

hash = fhash( hasło OXR rand )?
tylko przecież nie zapisaliśmy 'rand'. Więc jak?

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


pzdr
bartekltg

do góry

W dniu 2013-01-22 15:41, M.M. pisze:
> 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

Ale my nie o tym przecież.

Zrozumiałeś, na zcym polega opisywany atak?
Jesteś pewien, że Twó algorytm jest odporny
na tego bruteforce?

pzdr
bartekltg

do góry

> Dla naprostowania, bo identyfikator -- jak to on zwykle -- popieprzył
> terminologię:

Ty i tak masz już na pieńku, ale broń się, jak Twoim zdaniem powinienem
sformułować to zdanie?

do góry

W dniu 2013-01-22 15:57, M.M. pisze:
> 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.

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żą.

Ale to dyskusja o słowniku:)


>> 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.
Mamy dwie liczby pierwsze p,q, publikujemy ich iloczyn i jeszcze
jedną liczbę e(p,q). Ktoś tym koduje, my odczytujemy za pomocą p i q.

I bardzo prosty dowód bezpieczeństwa: potrzeba mieć p i q, a p*q
ciężko rozdzielić, jesteśmy wiec bezpieczni. A e jest bez znaczenie...

Tylko, czy na pewno to e nigdy pomaga w rozłożeniu p*q? :)


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

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;)


pzdr
bartekltg

do góry

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

> 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() )

rand = rand();
hash = fhash1( fhash2( haslo , rand ) , rand )

fhash1 jest funkcja odwracalną, fhash2 nie jest. Czyli
losowa wartość jest zapisana wewnątrz hasha. hash jest
za każdym razem inny nawet dla tego samego hasła. Jest
to dobre, do póki nie wycieknie kod metody fhash1, no i
jeśli admin nie może podpiąć swojego skryptu który odczyta
hasła zanim program je zaszyfruje.

Pozdrawiam

do góry

W dniu 2013-01-22 16:23, M.M. pisze:
> W dniu wtorek, 22 stycznia 2013 16:07:59 UTC+1 użytkownik bartekltg napisał:
>
>> 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() )
>
> rand = rand();
> hash = fhash1( fhash2( haslo , rand ) , rand )
>
> fhash1 jest funkcja odwracalną, fhash2 nie jest. Czyli
> losowa wartość jest zapisana wewnątrz hasha. hash jest
> za każdym razem inny nawet dla tego samego hasła. Jest

No to jak porównujesz zapisany w bazie hash z hasłem
wpisanym przez użytkownika?



> to dobre, do póki nie wycieknie kod metody fhash1, no i
> jeśli admin nie może podpiąć swojego skryptu który odczyta
> hasła zanim program je zaszyfruje.

Jeśli kod nie wycieka, to głupie
sha-8_4096( hasło XOR [tajne_ciąg_bitów] )
jest skuteczne. Ale cały czas w tej odnodze (za sugestią
Stacha i Daniela) zakładamy, że wycieka.

pzdr
bartekltg

do góry

W dniu wtorek, 22 stycznia 2013 16:10:27 UTC+1 użytkownik bartekltg napisał:
> Ale my nie o tym przecież.
Ja bym chciał żeby rozmowa miała wartość praktyczną. W
praktyce właśnie często widzę hasła skrupulatnie szyfrowane, a
do komputera ma dostęp ktoś, kto może zainstalować swój
skrypt...


> Zrozumiałeś, na zcym polega opisywany atak?
> Jesteś pewien, że Twó algorytm jest odporny
> na tego bruteforce?
Powiem tak: idziesz do komputera, wykręcasz z niego
twardy dysk. Masz bazę danych i algorytm szyfrowania.
Wszyscy użyli tych samych haseł co do kont bankowych.
Uruchamiasz algorytm szyfrowania dla wszystkich ciągów
bruteforcem. Wyselekcjonowałeś ciągi które dają te
same hashe. Używasz ciągów w kontach bankowych. Okazuje
się prawdopodobieństwo że będą pasowały do kont bankowych
jest takie samo, jakbyś użył haseł losowych. Czyli w
100% odporny nie jest, może przez przypadek pasować :)

Pozdrawiam

do góry