On Wednesday, November 12, 2014 11:26:08 AM UTC+1, Stachu 'Dozzie' K. wrote:
> 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.
Nie wiem jakie przyspieszenie mozna uzyskac dzieki teczowym tabicom, ale
chyba nie az tak duze, aby mozna bylo nazwac je zupelnie innym atakiem?
Pozdrawiam

do góry

W dniu 11.11.2014 o 23:24, M.M. pisze:
> czy istnieje algorytm osolenia, ktory uniemozliwi odkodowanie
> tego hasla metoda burforce, nawet gdy lamacz wie, w jaki sposob
> zostalo osolone?


Nie ma takiego algorytmu, decyzja o dodaniu soli oraz wybranie czy jest
losowa dla każdego rekordu, czy wspólna dla wszystkich wpływa tylko na
czasochłonność operacji.

3 metody hashowania:

1. hash(hasło)
atakujący generuje jedną tabelę skrótow dla słownika i może hurtem
dopasować wszystkie hashe do danych z tabeli.

w przypadku popularnych funkcji, skrót można 'złamać' wklejając go w
google
<https://www.google.com/search?q=8ce3de21e18ae819c7d
472bae25a9156>, może
też pobrać gotową tablicę hashy.


2. hash(stała sól+hasło)
atakujący nie może pobrać gotowej tablicy hashy, musi ją wytworzyć
samodzielnie. Musi wiedzieć, jakiej soli użyto - jeśl tego nie wie, jest
na lodzie i jedyne na co może liczyć, to kolizje funkcji hashującej -
widziałem hasła hashowane funkcją ADLER32, znalezienie kolizji zajmowało
sekundy.

jeśli atakujący zna sól, to może wytworzyć samodzielnie tablicę i
porównać dla wszystkich hashy naraz.

3. hash(zmienna sół+hasło)
atakujący nie może pobrać gotowej tablicy hashy, nie może też jej
wytworzyć dla wszystkich hashy naraz. Musi znać metodę solenia, sól i
dla każdego hasła osobno musi wytwarzać osobną tablicę. To najbardziej
czasochłonny z tych trzech wariantów, ergo najbardziej bezpieczny.

Mimo wszystko, nie ma metody która uniemożliwi całkowicie odkodowanie
hasła metodą bruteforce.

do góry

On 12.11.2014 10:47, Krzychu wrote:
> 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.

Jasne.


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

Obawiam się, że tego nie robi, w koncu w kodzie napisali, że to
bardzo dobre bardzo losowe liczby. ;-)

A na serio, jeśli gdzieś w opisie nie ma wyraźnie napisanego:
w tej linijce i tym pliku podmień to a to, cieżko oczekiwać
od każdego użytkownika przeczytania całego kodu.

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

Przychodzi mi do głowy tylko to, że też jest krótki.

pzdr
bartekltg

do góry

On 2014-11-12, M.M. <m...@g...com> wrote:
> On Wednesday, November 12, 2014 11:26:08 AM UTC+1, Stachu 'Dozzie' K. wrote:
>> 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.
> Nie wiem jakie przyspieszenie mozna uzyskac dzieki teczowym tabicom, ale
> chyba nie az tak duze, aby mozna bylo nazwac je zupelnie innym atakiem?

Owszem, aż tak duże. Poczytaj sobie na czym polegają i w jakich
warunkach są skuteczne.

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu 12.11.2014 o 13:11, bartekltg pisze:
> A na serio, jeśli gdzieś w opisie nie ma wyraźnie napisanego:
> w tej linijce i tym pliku podmień to a to, cieżko oczekiwać
> od każdego użytkownika przeczytania całego kodu.

To jest fakt, ja w swoim oprogramowaniu podkreśliłem to wyraźnie w
README, a i tak większość instalacji używa domyślnej.

do góry

Dnia 12.11.2014 Krzychu <k...@w...pl.invalid> napisał/a:
> 2. hash(stała sól+hasło)
> atakujący nie może pobrać gotowej tablicy hashy, musi ją wytworzyć
> samodzielnie. Musi wiedzieć, jakiej soli użyto - jeśl tego nie wie, jest
> na lodzie i jedyne na co może liczyć, to kolizje funkcji hashującej -
> widziałem hasła hashowane funkcją ADLER32, znalezienie kolizji zajmowało
> sekundy.

Nie tylko kolizje, jesli atakujacy jest "z systemu", to zna swoje haslo w
postaci jawnej, a wiec moze zaatakowac metoda bruteforce w celu znalezienia
"soli" - oczywiscie to specyficzny przypadek (na przyklad zwykly user
atakuje haslo roota) ale to pokazuje jak "slabe" jest uzywanie tej samej
soli dla wszystkich hasel.

do góry

On 2014-11-12, Krzychu <k...@w...pl.invalid> wrote:
> W dniu 12.11.2014 o 13:11, bartekltg pisze:
>> A na serio, jeśli gdzieś w opisie nie ma wyraźnie napisanego:
>> w tej linijce i tym pliku podmień to a to, cieżko oczekiwać
>> od każdego użytkownika przeczytania całego kodu.
>
> To jest fakt, ja w swoim oprogramowaniu podkreśliłem to wyraźnie w
> README, a i tak większość instalacji używa domyślnej.

W kodzie? Bardzo mądra strategia. A jak sobie wyobrażasz instalację
z binarnych pakietów? `apt-get install'? Oczywiście każdy będzie
rekompilować twój soft?

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu 12.11.2014 o 15:41, Stachu 'Dozzie' K. pisze:
> W kodzie? Bardzo mądra strategia. A jak sobie wyobrażasz instalację
> z binarnych pakietów? `apt-get install'? Oczywiście każdy będzie
> rekompilować twój soft?
>

Mój soft to kod serwera wieloosobowej gry komputerowej, dostarczany w
postaci kodu źródłowego (Lua), niekompilowany, interpretowany w czasie
wykonywania. Oprócz salta trzeba też zmienić wiele parametrów
bezpośrednio w kodzie, chociażby dane autoryzacyjne do serwera SQL albo
chociażby nazwę samego serwera. Nie przeszkadza mi, że nowicjusze mogą
sobie z tym nie poradzić.

To dość specyficzne oprogramowanie, raczej nigdy nie trafi do żadnego
apta :-).

do góry

On 2014-11-12, Krzychu <k...@w...pl.invalid> wrote:
> W dniu 12.11.2014 o 15:41, Stachu 'Dozzie' K. pisze:
>> W kodzie? Bardzo mądra strategia. A jak sobie wyobrażasz instalację
>> z binarnych pakietów? `apt-get install'? Oczywiście każdy będzie
>> rekompilować twój soft?
>>
>
> Mój soft to kod serwera wieloosobowej gry komputerowej, dostarczany w
> postaci kodu źródłowego (Lua), niekompilowany, interpretowany w czasie
> wykonywania. Oprócz salta trzeba też zmienić wiele parametrów
> bezpośrednio w kodzie, chociażby dane autoryzacyjne do serwera SQL albo
> chociażby nazwę samego serwera. Nie przeszkadza mi, że nowicjusze mogą
> sobie z tym nie poradzić.

Ach. Czyli ty pewnie z tych, co to uważają hardcode'owany konfig za
właściwy i co to nawet nie potrafią załadować pliku INI?

> To dość specyficzne oprogramowanie, raczej nigdy nie trafi do żadnego
> apta :-).

Nie? Jesteś pewny, że masz użytkowników zbyt głupich na postawienie
własnego repozytorium? I oni sobie radzą z poprawieniem wartości
w kodzie? O_o

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu 12.11.2014 o 17:06, Stachu 'Dozzie' K. pisze:
> Nie? Jesteś pewny, że masz użytkowników zbyt głupich na postawienie
> własnego repozytorium? I oni sobie radzą z poprawieniem wartości
> w kodzie? O_o

Wręcz przeciwnie - nie chcę aby z tego oprogramowania korzystały osoby
które nie wiedzą nic o programowaniu i chcą sobie postawić tylko serwer
do grania. Niech korzystają tylko osoby które wiedzą jak ten kod
modyfikować.

To gra dla dzieci - średnia wieku gracza powiedzmy 14 lat. Serwerów jest
kilka tysięcy, polskich kilkaset.

Straciłem zainteresowanie rozwijaniem tego projektu więc zrobiłem to co
mogłem zrobić na zakończenie - udostępniłem kod na licencji GPL i BSD
(do wyboru). Nie jest idealny, na pewno ma setki błędów i niedociągnięć,
a to czy typowa osoba chcąca skorzystać z tego oprogramowania będzie
potrafiła zmienić konfigurację hardkodowaną w kodzie źródłowym już mnie
nie obchodzi - mają README w którym jest wskazane w której linii co
trzeba zmienić.

Jeśli nowicjusz sobie nie poradzi to tym lepiej - chciałem zastymulować
społeczność graczy, a nie spowodować wysyp kiepskich serwerów. Nie
czerpię żadnych korzyści z wypuszczenia tego kodu, oprócz przyjemności z
obserwowania rozwijania się dwóch albo trzech dobrych forków.

do góry