W dniu 14.11.2014 o 16:19, M.M. pisze:
> 3) Można sól trzymać na osobnym serwerze i ograniczyć ilość odpytań do
> np. 100 na godzinę. Gdy jest maksymalnie 50 logowań na godzinę w
> ostatnim miesiącu, to 100 na godzinę powinno wystarczyć. W momencie
> gdy się włamią na główny serwer i zaczną odpytywać serwer dodatkowy,
> to im nie poda więcej niż te 100 na godzinę.


Słuchaj, w PKW chyba szukają informatyków.

(Bo skąd mogliśmy wiedzieć, że zagłosuje więcej niż 10% społeczeństwa?)

do góry

On Monday, November 17, 2014 8:32:36 AM UTC+1, Krzychu wrote:
> W dniu 14.11.2014 o 16:19, M.M. pisze:
> > 3) Można sól trzymać na osobnym serwerze i ograniczyć ilość odpytań do
> > np. 100 na godzinę. Gdy jest maksymalnie 50 logowań na godzinę w
> > ostatnim miesiącu, to 100 na godzinę powinno wystarczyć. W momencie
> > gdy się włamią na główny serwer i zaczną odpytywać serwer dodatkowy,
> > to im nie poda więcej niż te 100 na godzinę.
>
>
> Słuchaj, w PKW chyba szukają informatyków.
>
> (Bo skąd mogliśmy wiedzieć, że zagłosuje więcej niż 10% społeczeństwa?)
Zawsze można jakoś oszacować.

do góry

On Fri, 14 Nov 2014 10:38:25 -0800, firr wrote:

>> >> Eee... Co? O_O
>> > Misiu, kiedy masz zamiar poczytać o zabezpieczeniach? Bo wcześniej
>> > dyskusja z tobą na ten temat nie ma najmniejszego sensu.
>>
>> Misiu, jakich znowu zabezpieczeniach? Widać z daleka żeś ty dyletant w
>> tej dziedzinie. Rozdzielać sól od hasza hasła tylko po to, żeby móc
>> zrobić limit na częstość logowań?
>>
> wydaje ci sie grupowiczu-z-jawnymi-brakami-w-inteligencji ze piszesz z
> misiem? (do mnie od czasu do czasu internetowe buractwo mowi per
> chlopie, bez zenady chwalac sie swoim poziomem ;o walnac tak nagle
> misiem to jest coś ponizej krytyki (no coż moze jestem zbyt krytyczny
> ale zaiste... ;o (
> "bliss is blisfull like fir is peacefull", (fir))

A już mi się tak dobrze czytało wątek... Misiu firrku ty, jakiś ty
poważny dzisiaj, no no no...

--
Edek

do góry

On Wed, 12 Nov 2014 02:30:46 +0000, Piotr wrote:

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

Dokładnie. Ludzia i ludzie: kryptografia opiera się na dwóch rzeczach
jak już matematycy coś wysmażą.
1. Mechaniźmie, jak asymetryczne, symetryczne, one way hash, paru
innych. One określają co z czego można mieć (albo nie można).
Matematyczne słabości oczywiście zmieniają sposób patrzenia na to
co można a co nie.
2. Pytaniu, co kto wie, skąd i od kiedy. Na przykład przy
logowaniu zakłada się, że dana osoba zna hasło, nikt inny nie zna.

W hashu z solą:

- user zna hasło
- system zna sól i hash(sól+hasło)
- atakujący z zewnątrz nie zna ani soli ani hasła
- atakujący, który przejął serwer zna i sól i hash, chce znać hasło

To ostatnie jest ciekawe: wykradając /etc/shadow - mając dostęp
do serwera czy tylko wykradając plik - można odpowiednio włamać
się do innych serwerów lub do tego serwera też, o ile odpowiednio
user używa tego samego hasła gdzie indziej lub też na tym serwerze.

I tylko dlatego się soli. Stała sól ma pewien sens, w końcu
o ile nie jest znana atakującemu ma przewagę nad solą przyklejoną
do hasha, która staje się znana wraz z hashem. Ale ma wymienione
wady, da się wygenerować hashe no i gratis znać hasła identycznych
hashy (z identycznego hasła przy identycznej soli powstaje identyczny
hash).

Nie wydaje mi się żeby to wyliczenie Bartka dotyczące czasu używania
tablic było sensowne: można wyliczone hashe ułożyć w b-tree i zrobić
lookup log(n) po hashu z hasła usera. Nie da się?

Nie wymyślać tylko solić jak PB przykazał ;)

--
Edek

do góry

W dniu sobota, 29 listopada 2014 20:58:19 UTC+1 użytkownik Edek napisał:
> On Wed, 12 Nov 2014 02:30:46 +0000, Piotr wrote:
>
> > 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.
>
> Dokładnie. Ludzia i ludzie: kryptografia opiera się na dwóch rzeczach
> jak już matematycy coś wysmażą.
> 1. Mechaniźmie, jak asymetryczne, symetryczne, one way hash, paru
> innych. One określają co z czego można mieć (albo nie można).
> Matematyczne słabości oczywiście zmieniają sposób patrzenia na to
> co można a co nie.
> 2. Pytaniu, co kto wie, skąd i od kiedy. Na przykład przy
> logowaniu zakłada się, że dana osoba zna hasło, nikt inny nie zna.
>
> W hashu z solą:
>
> - user zna hasło
> - system zna sól i hash(sól+hasło)
> - atakujący z zewnątrz nie zna ani soli ani hasła
> - atakujący, który przejął serwer zna i sól i hash, chce znać hasło
>
> To ostatnie jest ciekawe: wykradając /etc/shadow - mając dostęp
> do serwera czy tylko wykradając plik - można odpowiednio włamać
> się do innych serwerów lub do tego serwera też, o ile odpowiednio
> user używa tego samego hasła gdzie indziej lub też na tym serwerze.
>
> I tylko dlatego się soli. Stała sól ma pewien sens, w końcu
> o ile nie jest znana atakującemu ma przewagę nad solą przyklejoną
> do hasha, która staje się znana wraz z hashem. Ale ma wymienione
> wady, da się wygenerować hashe no i gratis znać hasła identycznych
> hashy (z identycznego hasła przy identycznej soli powstaje identyczny
> hash).
>
> Nie wydaje mi się żeby to wyliczenie Bartka dotyczące czasu używania
> tablic było sensowne: można wyliczone hashe ułożyć w b-tree i zrobić
> lookup log(n) po hashu z hasła usera. Nie da się?

Nie, nie da się. To do cholery nie problem przeszukiwania! ;-)
Nie da się bo nie masz takiej pojemnośći, by
wszystkie hashe (z malutkiego przykladu) trzymać.
Dlatego korzysta się z tablic tęczowych, to tradeof pomiędzy
objętością bazy danych a potrzebną mocą.
Myślisz o np 10^11 łańcuchach hashy, każdy mający 10^9
elementów. Na dysku trzymasz tylko pierwszy i ostatni
element łancucha (coś rzędu wspomnianego terabajta).

Jeśli teraz dostajesz zadanie, rozbij hash X, liczysz
łańcuch od niego, i dla każdego elementu łancucha
sprawdzamy, czy nie jest elementem końcowym któregoś
z danych na dysku.

I tu niespodzianka, Ty proponujesz robić to w log[n]
odczytach z dysku, a ja zaproponowałem robić to
_jednym_ odczytem z dysku;p Bardzo optymistyczne
oszacowanie;-)

pzdr
bartekltg

do góry

On Saturday, November 29, 2014 8:58:19 PM UTC+1, Edek wrote:

> I tylko dlatego się soli. Stała sól ma pewien sens, w końcu
> o ile nie jest znana atakującemu ma przewagę nad solą przyklejoną
> do hasha, która staje się znana wraz z hashem. Ale ma wymienione
> wady, da się wygenerować hashe no i gratis znać hasła identycznych
> hashy (z identycznego hasła przy identycznej soli powstaje identyczny
> hash).

A trzecia możliwość od macochy... Czemu nie używać zarówno stałej soli i losowej?
Dlaczego musi być albo stała, albo losowa? Jak ktoś wpisze
5cio znakowe hasło, to dasz cost na całą dobę obliczeń i logowanie
będzie trwało dobę? Stała sól o dużym rozmiarze ma zajebisty sens gdy
tablice haseł wyciekną, a kody nie wyciekną.

Jakbyś spojrzał w kody moich programów, to byś właśnie zauważył wszędzie
stałą sól. Mam niemal identyczny kod, jak owe kwiatki, z których w tym
wątku się nabijacie. Ja się nie nabijam, bo nie wiem jak ta sól jest
używana. W frameworkach w jakich pracowałem albo chociaż przeglądałem
kod, też była stała sól, i kod też wyglądał w tamtym przykładzie. Nie
nabijam się, bo nie sprawdzałem jak ta sól jest używana. Może być
jest używana całkiem mądrze.


> Nie wydaje mi się żeby to wyliczenie Bartka dotyczące czasu używania
> tablic było sensowne: można wyliczone hashe ułożyć w b-tree i zrobić
> lookup log(n) po hashu z hasła usera. Nie da się?


> Nie wymyślać tylko solić jak PB przykazał ;)
A PB przykazał albo używać stałej, albo losowej?

Zdrowia

do góry

On Sat, 29 Nov 2014 15:50:59 -0800, bartekltg wrote:

>> Nie wydaje mi się żeby to wyliczenie Bartka dotyczące czasu używania
>> tablic było sensowne: można wyliczone hashe ułożyć w b-tree i zrobić
>> lookup log(n) po hashu z hasła usera. Nie da się?
>
> Nie, nie da się. To do cholery nie problem przeszukiwania! ;-)
> Nie da się bo nie masz takiej pojemnośći, by wszystkie hashe (z
> malutkiego przykladu) trzymać.
> Dlatego korzysta się z tablic tęczowych, to tradeof pomiędzy objętością
> bazy danych a potrzebną mocą.
> Myślisz o np 10^11 łańcuchach hashy, każdy mający 10^9 elementów. Na
> dysku trzymasz tylko pierwszy i ostatni element łancucha (coś rzędu
> wspomnianego terabajta).
>
> Jeśli teraz dostajesz zadanie, rozbij hash X, liczysz łańcuch od niego,
> i dla każdego elementu łancucha sprawdzamy, czy nie jest elementem
> końcowym któregoś z danych na dysku.
>
> I tu niespodzianka, Ty proponujesz robić to w log[n] odczytach z dysku,
> a ja zaproponowałem robić to _jednym_ odczytem z dysku;p Bardzo
> optymistyczne oszacowanie;-)

A ok, doczytam.

do góry

On Tue, 02 Dec 2014 09:42:45 -0800, M.M. wrote:

> On Saturday, November 29, 2014 8:58:19 PM UTC+1, Edek wrote:
>
>> I tylko dlatego się soli. Stała sól ma pewien sens, w końcu o ile nie
>> jest znana atakującemu ma przewagę nad solą przyklejoną do hasha, która
>> staje się znana wraz z hashem. Ale ma wymienione wady, da się
>> wygenerować hashe no i gratis znać hasła identycznych hashy (z
>> identycznego hasła przy identycznej soli powstaje identyczny hash).
>
> A trzecia możliwość od macochy... Czemu nie używać zarówno stałej soli
> i losowej? Dlaczego musi być albo stała, albo losowa? Jak ktoś wpisze
> 5cio znakowe hasło, to dasz cost na całą dobę obliczeń i logowanie
> będzie trwało dobę? Stała sól o dużym rozmiarze ma zajebisty sens gdy
> tablice haseł wyciekną, a kody nie wyciekną.

Logowanie nie będzie trwało dobę, sól jest znana - doklejasz i liczysz
hash w tym samym czasie co zawsze.

Ten koszt o którym pewnie mówisz to hash(hash(hash(...(hash(string)))).
Taki trick pozwala na zwiększenie kosztowności potrzebnych obliczeń
a dodatkowo trzeba wiedzieć ile razy liczyć hash z hasha z hasha -
trzeba znać tę liczbę. Używa się raczej do szyfrowania plików
niż haseł, ale też można. O ile nie masz na myśli gigantycznej soli...

Stała + losowa - ma sens, o ile ta stała nie jest znana, czyli w praktyce
łatwa do zdobycia. Jakoś sens zaszycia stałej w binarce przy
podstawowej umiejętności deasemblowania jaką każdy cracker posiada
mnie mało przekonuje. Czyli jak mówisz, sprowadza się do sytuacji
gdy kody nie wyciekną co zakłada closed-source przy okazji jeżeli
nie one-time builds - zbudowanie builda dla każdego z inną stałą.

> Jakbyś spojrzał w kody moich programów, to byś właśnie zauważył
> wszędzie stałą sól. Mam niemal identyczny kod, jak owe kwiatki, z
> których w tym wątku się nabijacie. Ja się nie nabijam, bo nie wiem jak
> ta sól jest używana. W frameworkach w jakich pracowałem albo chociaż
> przeglądałem kod, też była stała sól, i kod też wyglądał w tamtym
> przykładzie. Nie nabijam się, bo nie sprawdzałem jak ta sól jest
> używana. Może być jest używana całkiem mądrze.

Pytanie jak się ją stosuje. Oba zastosowania mają sens tylko też inne
właściwości. W kryptografii różne elementy różnie się stosuje, nie ma
jednej złotej reguły na wszystko, jak właściwości pasują do celu
to się ich używa. Dlatego trzeba rozumieć co się robi i dlaczego,
kopiowanie rozwiązań jest dla misiów o małym rozumku.

>> Nie wymyślać tylko solić jak PB przykazał
> A PB przykazał albo używać stałej, albo losowej?

Do haseł: doklejonej do hasha zmiennej o ile rozwiązanie jest znane.
Zawsze można stworzyć jakieś security by obscurity albo olać -
o ile zna się konsekwencje. Ja na mojej prywatnej apce na mojej
prywatnej bazce używam hasło plaintext - DO NOT TRY THIS AT HOME.
OBLICZENIA OKAZANE W POŚCIE NALEŻY POWTÓRZYĆ NA WŁASNYM ZASTOSOWANIU
ALBO ZASIĘGNĄĆ OPINII LEKARZA LUB FARMACEUTY.

do góry

On Wednesday, December 3, 2014 9:13:41 PM UTC+1, Edek wrote:

> Logowanie nie będzie trwało dobę, sól jest znana - doklejasz i liczysz
> hash w tym samym czasie co zawsze.
Podstawą jest regulowanie tego czasu. Gdy policzy się raz hash(string), to
hasła o długości 5 znaków od razu rozkodują. Składające się z 8 znaków na
mocnym sprzęcie też da rady. Można łamać z milion na sekundę w brutforce.

> Ten koszt o którym pewnie mówisz to hash(hash(hash(...(hash(string)))).
O kiedy dostałem funkcję biblioteczną, to szkoda mi czasu na sprawdzanie
co to naprawdę robi.


> Taki trick pozwala na zwiększenie kosztowności potrzebnych obliczeń
> a dodatkowo trzeba wiedzieć ile razy liczyć hash z hasha z hasha -
> trzeba znać tę liczbę.
Nie wiem jak jest w bibliotekach których Wy używacie, ja przywykłem, że
ta liczba jest tak samo doklejana do hasła, jak losowa sól.


> Używa się raczej do szyfrowania plików niż haseł, ale też można.
Ale czego używa się do szyfrowania plików? Na pewno zwiększa się
koszt przy szyfrowaniu haseł. A pliki to chyba zupełnie inna inszość...
bo hasha nie da się rozszyfrować. Zwykły sha czy md5 to można użyć
jako coś lepszego od crc do plików, ale do szyfrowania? Sorry, nie
widzę związku.


> O ile nie masz na myśli gigantycznej soli...
Mam na myśli, może nie gigantyczny, ale duży koszt. Zresztą stała sól
też może być duża, bo czemu nie?


> Stała + losowa - ma sens, o ile ta stała nie jest znana.
Jak masz dużą stałą sól i duży koszt (np. 3 sekund na jednym
rdzeniu) to nawet po wycieku trudno wygenerować tablice tęczowe.
Na jednym kompie dla 5 znakowych haseł (powiedzmy znak pochodzi z
80elementowego zbioru), generowanie może trwać 100 lat.


> czyli w praktyce łatwa do zdobycia.
Gdy się udostępnia kod (obojętnie czy binarny czy źródłowy) to
jedyną gwarancję daje świadomość użytkownika, aby nie używał
hasła takiego samego jak do banku. Zresztą o czym rozmawiamy,
jeśli na kompie da się zainstalować spyware...


> Jakoś sens zaszycia stałej w binarce przy
> podstawowej umiejętności deasemblowania jaką każdy cracker posiada
> mnie mało przekonuje.
W ogóle nie przekonuje. Chodzi o sytuacje, gdy trudno jest wykraść
cokolwiek.


> Czyli jak mówisz, sprowadza się do sytuacji
> gdy kody nie wyciekną co zakłada closed-source przy okazji jeżeli
> nie one-time builds - zbudowanie builda dla każdego z inną stałą.
Ściśle, sprowadza się do sytuacji colsed-salt ;-)


> Pytanie jak się ją stosuje. Oba zastosowania mają sens tylko też inne
> właściwości. W kryptografii różne elementy różnie się stosuje, nie ma
> jednej złotej reguły na wszystko, jak właściwości pasują do celu
> to się ich używa. Dlatego trzeba rozumieć co się robi i dlaczego,
> kopiowanie rozwiązań jest dla misiów o małym rozumku.
Nie zgodzę się. Jeden i drugi sposób solenia ma swoje zalety. Połączenie
stałej soli z losową nie powoduje utraty zalet ani jednego sposobu,
ani drugiego. Dlatego zawsze należy połączyć oba sposoby i
zawsze należy ustawić duży koszt.


> Do haseł: doklejonej do hasha zmiennej o ile rozwiązanie jest znane.
> Zawsze można stworzyć jakieś security by obscurity albo olać -
> o ile zna się konsekwencje. Ja na mojej prywatnej apce na mojej
> prywatnej bazce używam hasło plaintext - DO NOT TRY THIS AT HOME.
Ja mam do tego celu bibliotekę. Generuję sól i wywołuję jedną, może
dwie funkcje. Nieważne czy aplikacja będzie dla studenta czy poważnej
firmy.

Zdrowia

do góry

On Thursday, December 4, 2014 12:35:06 PM UTC+1, M.M. wrote:
> > Jakoś sens zaszycia stałej w binarce przy
> > podstawowej umiejętności deasemblowania jaką każdy cracker posiada
> > mnie mało przekonuje.
> W ogóle nie przekonuje. Chodzi o sytuacje, gdy trudno jest wykraść
> cokolwiek.
Przykładowo na jednym kompie może być baza haseł. Hasła są osolone
losową solą. Na drugim kompie może być program ze stałą solą lub bez
stałej soli. Co się dzieje, gdy ukradną komputer z bazą haseł? Bez
stałej soli, zaczynają łamać burteforcem. Ze stałą solą łamanie w
ogóle nie jest możliwe. Gdy ukradną komputer ze stałą solą, to w
ogóle nie ma czego łamać. Trudniej wykraść dwa komputery niż jeden?
Trudniej! Dlatego jak gdzieś w programie w źródłach widać stałą sól,
to warto jeszcze sprawdzić jak ona jest używana, wtedy można
krytykować.

Pozdrawiam

do góry