On 11.11.2014 23:24, M.M. wrote:
> On Tuesday, November 11, 2014 9:45:43 PM UTC+1, bartekltg wrote:
>>> Natomiast jesli wyciekna, to do najbardziej wyrafinowanych
>>> algorytmow mozna zrobic operacje odwrotna. Na pewno zdarzaja sie
>>
>> Nieprawda. Bezpieczeństwo tego typu metod nie opiera się na tym,
>> że nie wiemy, jak ktoś coś hashuje, tylko na tym, że funkcja,
>> która hashuje jest trudna do odwrócenia.
> No tak, zakladamy ze nie istnieje (albo chociaz nie jest znany)
> szybki algorytm odwracana i trzeba lamac burtforcem. Zakladamy

Czy istnieje prawdziwy hash, jest chyba pytaniem otwartym;-)
Ale są przyzwoicie, z punktu widzenia ludzi, nieodwracalne funkcje.

> ze user wpisal krotkie haslo skladajace sie z 3 znakow. Pytanie
> brzmi, czy istnieje algorytm osolenia, ktory uniemozliwi odkodowanie
> tego hasla metoda burforce, nawet gdy lamacz wie, w jaki sposob
> zostalo osolone?


3 znaki alfanumeryczne to jakieś 40^3 = 64000 możliwości.
Skoro znam metodę i 'sól', robię sobie w ciągu 5 minut/doby
tablicę wszystkich możliwości.


> Moim zdaniem przez losowe osolenie, mozna co
> najwyzej uniemozliwic lamanie calej bazy na raz, czyli lamacz musi
> kazde haslo po kolei. Czy myle sie?

Przecież dokładnie to Ci napiałem w pierwszym poście

>>Zapisanie tego na sztywno spowoduje co prawda, że uniwersalna tablica
>>będzie mało przydatna, ale koszt odwrócenia jednego hasha
>>jest w praktyce taki sam, jak odwrócenia wszystkich.




>> Zobaczy ile jest gotowców:-) Kryptograficzne programy open source
>> też istnieją ;-) Jeśli "przeciwnik" nie wie, co dokładnie robimy,
>> to dodatkowy plus (z drugiej strony, jeśli nie jesteś NSA czy choćby
>> ABW, to Twoją tajną metodę przetestowało znacznie mniej osób, skąd
>> wiesz, czy nie ma tam jakiejś brzydkiej matematycznej dziury;).
> Mysle podobnie.
>
>
>>> Osobiscie nie doklejam na koncu hasel losowych ciagow. Zamiast tego w
>>> losowy ciag wstawiam w losoych miejscach znaki hasla.
>>
>> To z grubsza to samo.
> W sumie racja. Funkcja skrotu to funkcja skrotu. Albo jest znana atakujacemu,
> albo nie. Albo jest znany szybki algorytm odwracania, albo trzeba burtforcem.
> Na ciag zaburzajacy mozna spojrzec jak na element funkcji skrotu.

Wg mnie nie da się na to tak spojrzeć. Jak drugi raz przyjdę
i dam to samo hasło, dostanę inną liczbę solącą.

Raczej jak na podzielenie się hasłem. Połowę hasła zna urzytkownik,
połowę hasła znamy my. To, że otrzymany hash jest funkcją obu
polepsza jego własności.


A, jeszcze jedno. Czasem wyciekają tablice hashy. I wtedy widzimy, że
najpopulrniejszym hashem jest 5689345794856. Dzięki temu mamy
listę osób z hasłem dupo.8 ;-) Od biedy sprawdzam, kto ma identyczne
hasło jak ja.
Po posoleniu hashe powinne być równomiernie rozłożone, do tego nie
da się sprawdzić, kto ma identyczne.


>
>
>> Wczytałem się tylko na tyle, by sprawdzić, że tej tablicy gdzieś
>> używa (a nuż był to tylko dowcip na cześć xkcd dowcip), głębiej
>> nie czytałem.
> Ja tez nie wczytywalem sie. Jesli kazdy uzytkownik moze wpisac
> te liczby sam przed kompilacja i jesli mozna sensownie bronic
> przed wyciekiem tych liczb, to nie jest az taki bubel. Z kolei
> jesli sposob osolenia wycieknie, to solac losowo, zyskujemy niewiele:
> mozemy tylko ograniczyc lamanie od jednego hasla jednoczesnie.

Jakie znowu odsolania!?


pzdr
bartekltg

do góry

On Wednesday, November 12, 2014 12:31:11 AM UTC+1, bartekltg wrote:

> > Moim zdaniem przez losowe osolenie, mozna co
> > najwyzej uniemozliwic lamanie calej bazy na raz, czyli lamacz musi
> > kazde haslo po kolei. Czy myle sie?
>
> Przecież dokładnie to Ci napiałem w pierwszym poście
Zgadzam sie ze wszystkim co mi napisales w pierwszym poscie. Niezgadzam sie
tylko z tym, ze uzycie tego samego zaburzenia do wszystkich hasel jest duzo
gorszym rozwiazaniem niz za kazdym razem losowego.


> Wg mnie nie da się na to tak spojrzeć. Jak drugi raz przyjdę
> i dam to samo hasło, dostanę inną liczbę solącą.
Wg mnie nie duza roznica. Raz na wyjsciu mamy wynik funkcji skrotu
jako takiej. Drugi raz mamy wynik funkcji srkotu dla zaburzonego
hasla i owe zaburzenie. Z kolei z punktu widzenia algorytmu
brute-force nie ma zadnej istotnej roznicy.


> Raczej jak na podzielenie się hasłem. Połowę hasła zna urzytkownik,
> połowę hasła znamy my. To, że otrzymany hash jest funkcją obu
> polepsza jego własności.
Polepsza, ale nieznacznie i to polepszenie jest to wazne w rzadkich sytuacjach.


> A, jeszcze jedno. Czasem wyciekają tablice hashy. I wtedy widzimy, że
> najpopulrniejszym hashem jest 5689345794856. Dzięki temu mamy
> listę osób z hasłem dupo.8 ;-) Od biedy sprawdzam, kto ma identyczne
> hasło jak ja.
Jest masa innych zagrozen - czego dowodem jest wyciekanie tablicy hashy.
Jesli wyciekly, to oznacza, ze administrator byl nieuczciwy, albo sa
zle zabezpieczenia w systemach operacyjnych, albo haker zlamal czlowieka
przy pomocy socjotechniki, itd.


Masz racje w tych sytuacjach gdy wszystkie inne slabe punkty zostaly
zabezpieczone, a wyciekly zarowno zakodowane hasla jak i metoda kodowania.
W takich sytuacjach dzieki losowym zaburzeniom troche zyskujemy na czasie.
Ludzie kochaja krotkie hasla, powiedzmy ze w 90% i tak zwykly brut-force
sobie poradzi. W dluzszych haslach ile moga te tablice teczowe przyspieszac?
Obojetnie ile przyspiesza, to trzeba pamietac, ze to jest wazne tylko wtedy,
gdy nie ma innych slabych punktow, a wycieka i tablica hashy i algorytm
kodowania.

Pozdrawiam

do góry

Dnia 12.11.2014 M.M. <m...@g...com> napisał/a:
> On Wednesday, November 12, 2014 12:31:11 AM UTC+1, bartekltg wrote:
>
>> > Moim zdaniem przez losowe osolenie, mozna co
>> > najwyzej uniemozliwic lamanie calej bazy na raz, czyli lamacz musi
>> > kazde haslo po kolei. Czy myle sie?
>>
>> Przecież dokładnie to Ci napiałem w pierwszym poście
> Zgadzam sie ze wszystkim co mi napisales w pierwszym poscie. Niezgadzam sie
> tylko z tym, ze uzycie tego samego zaburzenia do wszystkich hasel jest duzo
> gorszym rozwiazaniem niz za kazdym razem losowego.

Jesli masz dostep do zaszyfrowanych hasel, to jest duzo gorszym. Przy
wspolnym zasoleniu po pierwsze trywialne jest sprawdzenie kto ma takie samo
haslo jak Ty, a po drugie zlozonosc zlamania jest znacznie mniej
korzystana. Wezmy dla przykladu haslo 8-bajtowe (64-bit) i sol 8-bajtowe,
jesli kazdy ma losowa sol, to masz 2^128 mozliwosci do sprawdzenia dla
brute-force. Jesli masz wspolna "sol", to masz tylko 2^64+2^64=2^65
mozliwosci a to duzo, duzo mniej. Zapytasz czemu 2^64+2^64? Chociazby mozna
podejsc do tego w ten sposob, ze lamiesz najpierw "sol" (swoje haslo znasz,
i wynik dzialania hasha na tym hasle tez znasz, wiec crackujesz tylko bity
"osolenia" a wiec 2^64 wariantow), jak juz znasz konfiguracje bitow soli,
to potem lamiesz czyjes haslo wiedzac, jaka jest konfiguracja bitow "soli"
czyli pozostaje Ci tez "tylko: 2^64 wariantow do sprawdzenia. Roznica jest
jak widzisz kolosalna.

do góry

Dnia 12.11.2014 M.M. <m...@g...com> napisał/a:
> On Wednesday, November 12, 2014 12:31:11 AM UTC+1, bartekltg wrote:
>
>> > Moim zdaniem przez losowe osolenie, mozna co
>> > najwyzej uniemozliwic lamanie calej bazy na raz, czyli lamacz musi
>> > kazde haslo po kolei. Czy myle sie?
>>
>> Przecież dokładnie to Ci napiałem w pierwszym poście
> Zgadzam sie ze wszystkim co mi napisales w pierwszym poscie. Niezgadzam sie
> tylko z tym, ze uzycie tego samego zaburzenia do wszystkich hasel jest duzo
> gorszym rozwiazaniem niz za kazdym razem losowego.

Jesli masz dostep do zaszyfrowanych hasel, to jest duzo gorszym. Przy
wspolnym zasoleniu po pierwsze trywialne jest sprawdzenie kto ma takie samo
haslo jak Ty, a po drugie trzeba znacznie mniejszej mocy (ilosci obliczen)
aby haslo zlamac. Wezmy dla przykladu haslo 8-bajtowe (64-bit) i sol 8-bajtowe,
jesli kazdy ma losowa sol, to masz 2^128 mozliwosci do sprawdzenia dla
brute-force. Jesli masz wspolna "sol", to masz tylko 2^64+2^64=2^65
mozliwosci a to duzo, duzo mniej. Zapytasz czemu 2^64+2^64? Chociazby mozna
podejsc do tego w ten sposob, ze lamiesz najpierw "sol" (swoje haslo znasz,
i wynik dzialania hasha na tym hasle tez znasz, wiec crackujesz tylko bity
"osolenia" a wiec 2^64 wariantow), jak juz znasz konfiguracje bitow soli,
to potem lamiesz czyjes haslo wiedzac, jaka jest konfiguracja bitow "soli"
czyli pozostaje Ci tez "tylko: 2^64 wariantow do sprawdzenia. Roznica jest
jak widzisz kolosalna.

do góry

On Wednesday, November 12, 2014 3:28:56 AM UTC+1, Piotr wrote:
> Jesli masz dostep do zaszyfrowanych hasel, to jest duzo gorszym.
Moim zdaniem trzeba miec takze dostep do sposobu zaburzania, ale
jesli sie myle, to chetnie zmienie zdanie.


> Przy wspolnym zasoleniu po pierwsze trywialne jest sprawdzenie kto ma
> takie samo haslo jak Ty,
Zgadzam sie. Mozna znalezc latwo pary wspolnych hasel, nawet gdy
nie mamy dostepu do sposobu zaburzania. Jest to niepodwazalna wada.


> a po drugie zlozonosc zlamania jest znacznie mniej
> korzystana. Wezmy dla przykladu haslo 8-bajtowe (64-bit) i sol 8-bajtowe,
Ok.


> jesli kazdy ma losowa sol, to masz 2^128 mozliwosci do sprawdzenia dla
> brute-force.
Niezgadzam sie. Jesli wyciekl algorytm zaburzania, to jest tylko 2^64.
Jesli nie wyciekl, to w ogole nie wiadomo jak sie zabrac za lamanie.


> Jesli masz wspolna "sol", to masz tylko 2^64+2^64=2^65
Jesli nie jest znany sposob zaburzania, to na moje w ogole nie ma
mozliwosci odzyskania hasel. Jesli jest znany, to 2^64.


> mozliwosci a to duzo, duzo mniej. Zapytasz czemu 2^64+2^64? Chociazby mozna
> podejsc do tego w ten sposob, ze lamiesz najpierw "sol" (swoje haslo znasz,
> i wynik dzialania hasha na tym hasle tez znasz, wiec crackujesz tylko bity
> "osolenia" a wiec 2^64 wariantow),
Nie wiesz jak byla uzyta funkcja hash i w jaki sposob haslo bylo zaburzone.
Zeby miec 2^64 wariantow, to trzeba wiedziec jak jest hashowane i jak osolone.


> jak juz znasz konfiguracje bitow soli,
> to potem lamiesz czyjes haslo wiedzac, jaka jest konfiguracja bitow "soli"
> czyli pozostaje Ci tez "tylko: 2^64 wariantow do sprawdzenia. Roznica jest
> jak widzisz kolosalna.
Roznice moze widze, ale kolosalnych nie.


Pozdrawiam

do góry

Dnia 12.11.2014 M.M. <m...@g...com> napisał/a:
> On Wednesday, November 12, 2014 3:28:56 AM UTC+1, Piotr wrote:
>> Jesli masz dostep do zaszyfrowanych hasel, to jest duzo gorszym.
> Moim zdaniem trzeba miec takze dostep do sposobu zaburzania, ale
> jesli sie myle, to chetnie zmienie zdanie.

Zakladamy opensource, czyli algorytm jest znany (ale nie znamy kluczy).

(...)
>> jesli kazdy ma losowa sol, to masz 2^128 mozliwosci do sprawdzenia dla
>> brute-force.
> Niezgadzam sie. Jesli wyciekl algorytm zaburzania, to jest tylko 2^64.
> Jesli nie wyciekl, to w ogole nie wiadomo jak sie zabrac za lamanie.

Jakiego "zaburzania"? Algorytm znamy, nie znamy klucza, funkcja hash
przyjmuje dwa argumenty, jeden z nich to haslo, drugi z nich to
klucz (czy jak to wolisz "zasolenie"), czyli generalnie masz 128 bitow
informacji na wejsciu (oczywiscie zakladamy, ze funkcja hasha jest
roznowartosciowa :D).

>> Jesli masz wspolna "sol", to masz tylko 2^64+2^64=2^65
> Jesli nie jest znany sposob zaburzania, to na moje w ogole nie ma
> mozliwosci odzyskania hasel. Jesli jest znany, to 2^64.

No bo nie ma, nie chodzi o "odzyskiwanie" hasel (odczytywanie ich w postaci
jawnej) tylko o mozliwosc sprawdzenia, czy user podal wlasciwe haslo.


>> mozliwosci a to duzo, duzo mniej. Zapytasz czemu 2^64+2^64? Chociazby mozna
>> podejsc do tego w ten sposob, ze lamiesz najpierw "sol" (swoje haslo znasz,
>> i wynik dzialania hasha na tym hasle tez znasz, wiec crackujesz tylko bity
>> "osolenia" a wiec 2^64 wariantow),
> Nie wiesz jak byla uzyta funkcja hash i w jaki sposob haslo bylo zaburzone.
> Zeby miec 2^64 wariantow, to trzeba wiedziec jak jest hashowane i jak osolone.

Nie wiem do tej pory co rozumiesz pod pojeciem "zaburzone". Wezmy jak
najbardziej trywialny przypadek, funkcja hasha robi konkatenacje
16-bitowego hasla z wygenerowanymi losowo 16 bitami klucza (soli) i dla tak
powstalego 32-bitowego ciagu liczy md5 i zapisuje to jako zakodowane haslo.
Jesli dla kazdego hasla masz inny klucz (sol), to w kazdym przypadku masz
2^32 mozliwych wariantow, a jesli masz wspolny klucz (sol), to najpierw
lamiesz klucz (sol) poprzez ustawienie znanego hasla (i wtedy masz 2^16
wariantow do sprawdzenia), a jak juz znajdziesz klucz, to potem "obce"
haslo to tez 2^16 wariantow, czyli 2*2^16 na zlamanie pierwszego "obcego"
hasla (kazde kolejne to tylko 2^16).

do góry

W dniu 2014-11-10 20:03, Wojciech Muła pisze:
> On Monday, November 10, 2014 5:53:59 PM UTC+1, JDX wrote:
>>> Hmm. Przywodzi na mysl kod zrodlowy popularnego ostatnio serwera NGINX.
>>> Mozna znalezc tam takie kwiatki, jak
>>>
>>> if ((c[0] == 'S'|| c[0] == 's')
>>> && (c[1] == 'T'|| c[1] == 't')
>>> && (c[2] == 'A'|| c[2] == 'a')
>>> && (c[3] == 'R'|| c[3] == 'r')
>>> && (c[4] == 'T'|| c[4] == 't')
>>> && (c[5] == 'T'|| c[5] == 't')
>>> && (c[6] == 'L'|| c[6] == 'l')
>>> && (c[7] == 'S'|| c[7] == 's'))
>>>
>>> autentyk.
>>> https://github.com/nginx/nginx/blob/master/src/mail/
ngx_mail_parse.c
>
> Tu jest sprytne porównanie case insensitive. :)
>
>> Ale to w sam raz może być optymalizacja ze względu na wydajność (nie
>> wiem czy słuszna). Kiedyś, studiując jakąś implementację LZ77, natknąłem
>> się na wyszukiwanie ciągu znaków w słowniku AFAIR w taki sposób (p i s
>> to wskaźniki na tablicę char-ów):
>>
>> *p++ != *s++ || *p++ != *s++ || *p++ != *s++ || *p++ != *s++ ||
>> *p++ != *s++ || *p++ != *s++ || *p++ != *s++ || *p++ != *s++ ||
>> *p++ != *s++ || *p++ != *s++ || *p++ != *s++ || *p++ != *s++ ||
>> *p++ != *s++ || *p++ != *s++ || *p++ != *s++ || *p++ != *s++
>>
>> i dopiero tutaj była pętla w przypadku dłuższych trafień.
>
> Możliwe, że w starszych kompilatorach to coś dawało, bo to
> jedynie ręcznie rozwinięta pętla
>
> int i=0;
> while (*p == *s&& i< 16) {
> p++; s++; i++
> }
>
> GCC 4.9 sobie z tym oryginalnym kodem w ogóle nie poradził,
> w sensie, że nie zrobił żadnej spektakularnej optymalizacji. :)
>
> Zdecydowanie lepiej byłoby porównywać w porcjach równych
> rozmiarom rejestru maszynowego (32 lub 64 bity) bo to się
> przekłada na pojedyncze instrukcje, a dopiero po
> niedopasowaniu porównywać poszczególne bajty.

A ja obawiam się że w tym wcześniejszym jest niejednoznaczność, masz
postinkrementacje, które mogą być różnie wykonane....


--
Kaczus
http://kaczus.ppa.pl

do góry

On Wednesday, November 12, 2014 8:37:37 AM UTC+1, Tomasz Kaczanowski wrote:
> >> *p++ != *s++ || *p++ != *s++ || *p++ != *s++ || *p++ != *s++ ||
> >> *p++ != *s++ || *p++ != *s++ || *p++ != *s++ || *p++ != *s++ ||
> >> *p++ != *s++ || *p++ != *s++ || *p++ != *s++ || *p++ != *s++ ||
> >> *p++ != *s++ || *p++ != *s++ || *p++ != *s++ || *p++ != *s++

> A ja obawiam się że w tym wcześniejszym jest niejednoznaczność, masz
> postinkrementacje, które mogą być różnie wykonane....

Myślę, że jest ok, bo operator || to sequence point
(http://en.wikipedia.org/wiki/Sequence_point).

Oczywiście takiego kodu bym nie przepuścił na code review. :)

w.

do góry

W dniu 09.11.2014 o 15:51, bartekltg pisze:
> Ciekawy kwiatek
>
> https://github.com/haiwen/ccnet/issues/35
> https://github.com/haiwen/ccnet/blob/master/net/serv
er/user-mgr.c#L612
>
> /* -------- EmailUser Management -------- */
> /* truly random sequece read from /dev/urandom. */
> static unsigned char salt[8] = { 0xdb, 0x91, 0x45, 0xc3, 0x06, 0xc7,
> 0xcc, 0x26 };
>
> I ta tabelka użyta jest przynajmniej w funkcji hash_password_salted.

Nie jest to wcale takie złe. Co prawda gorsze od funkcji skrótu z losową
solą, ale lepsze od funkcji skrótu bez soli.

Atakujący nie posłuży się już ogólnodostępnymi rainbowtables, będzie
musiał wytworzyć własne. A jeśli nie ma dostępu do kodu źródłowego (bo
każda osoba wdrażająca ten kod może sól zmienić na własną) to nawet i
tego nie zrobi.

Ja używam w swoich aplikacjach stałej soli + loginu jako sól. Szukałem
informacji na temat używania loginu jako soli - czy są jakieś
przeciwskazania - ale niestety nic nie znalazłem.

do góry

On 2014-11-11, M.M. <m...@g...com> wrote:
>> >> > Osobiscie nie doklejam na koncu hasel losowych ciagow. Zamiast tego w
>> >> > losowy ciag wstawiam w losoych miejscach znaki hasla.
>> >>
>> >> To z grubsza to samo.
>> > W sumie racja. Funkcja skrotu to funkcja skrotu. Albo jest znana atakujacemu,
>> > albo nie. Albo jest znany szybki algorytm odwracania, albo trzeba burtforcem.
>> > Na ciag zaburzajacy mozna spojrzec jak na element funkcji skrotu.
>>
>> Nie. Sól jest po to, żeby podnieść koszt przygotowania wstępnie
>> przeliczonych danych o kilka rzędów wielkości. To nie ma nic wspólnego
>> z funkcją skrótu jako taką.
> Piszesz ze nie, a podajesz takie same uzasadnienie jak moje. Nie rozumiem.

Ty piszesz o brute force. Przeliczenie haszy zawczasu to zupełnie inny
atak.

--
Secunia non olet.
Stanislaw Klekot

do góry