On Thursday, November 13, 2014 12:35:19 AM UTC+1, bartekltg wrote:
> Trzeba podejść do sprawy paranoicznie. Za zol uzywamuy liczby
> wygenerowanej dla hasła użytkownika i liczby zapisanej w kodzie.
> ;-)
Zgadzam się że trzeba podejść paranoicznie.

>
>
> > Może ja zacznę tę listę, a Ty
> > ją skorygujesz i rozbudujesz - jeśli mogę prosić.
> >
> > 1) Nie można ustalić kto ma takie same hasła na podstawie listy
> > loginów i zakodowanych haseł.
> > 2) Nie można łamać wszystkich haseł na raz.
> >
> > Co jeszcze? Co dalej?
>
> A nie wystarczy?
Czy wystarczy czy nie, to temat rzeka. Żeby sensownie rozmawiać, to
byśmy musieli mieć rozkład prawdopodobieństwa poszczególnych ataków i
straty gdy atak się powiódł. Nie mam takich danych. Może niech każdy
sam sobie odpowie czy to wystarczy czy nie. Dla mnie osobiście to mało :)


Mnie zaciekawił ten wątek, a że nie jestem specjalistą od
zabezpieczeń, to staram się ustalić precyzyjną i kompletną
listę zalet.


> Raz unikamy ataku statystyką i słownikiem,
Słownikiem chyba nie unikniemy dzięki różnym solom.


> którego koszt jest praktycznie darmowy, za drugim zwiększamy
> koszt obliczeniowy ataku *liczba użytkowników, czyli potencjalnie
> miliony razy.
Tak, to jest zaleta różnych soli.


Pozdrawiam

do góry

On Thursday, November 13, 2014 1:00:18 AM UTC+1, bartekltg wrote:
> Wydaje mi się, że autor miał na myśli to, że przygotowanie takiej
> tablicy dla porządnej kryptograficznej funkcji skrótu trochę trwa,
> zakłada więc, że taką tablicę przygotowujemy raz i potem tylko
> chcemy używać. Użycie _jakiejś_ odpowiednio długiej soli uniemożliwia
> atakującemu zbudowanie tablicy dekodującej na zapas. Może ją zacząć
> budować dopiero, gdy sol wycieknie.
>
> Tele na temat 'co autor miał na myśli'. Klikam na dłuższą wersję:
Właśnie to jest bardzo istotne czy należy autora rozumieć dosłownie, czy
może chodzi o to, że stała sól nie utrudnia ataku tablicami tęczowymi.


> The salt value is not secret and may be generated at random and
> stored with the password hash. A large salt value prevents
> precomputation attacks, including rainbow tables, by ensuring that
> each user's password is hashed uniquely. This means that two users
> with the same password will have different password hashes (assuming
> different salts are used). In order to succeed, an attacker needs to
> precompute tables for each possible salt value. The salt must be large
> enough, otherwise an attacker can make a table for each salt value.
>
> Tu już zalecają różne sole. Przemykają nieco nad uzasadnieniem,
Szkoda że nie uzasadniają.

> liczba_haseł_w_bazie/liczba_potencajlnych_haseł
Tak, co do tego nie straciłem pewności w trakcie rozmowy. Natomiast
straciłem pewność czy tylko(!) rożna sól uniemożliwia atak tęczowymi
tablicami.


> na trafienie w jakis hash. Zamiast po prostu
> 1/liczba_potencajlnych_haseł
> jak będzie przy różnych solach.
Tak, to jest jasne. W przypadku takiej samej soli dla wszystkich hasel, mozemy
wrzucic zakodowane hasla do hash-table i sprawdzac tak jakby równolegle
dla wszystkich haseł na raz. Wiadomo, dostęp do dużej hash-table jest z
10-50 razy wolniejszy niż do jednego hasła, ale w przypadku miliona
użytkowników to nadal duże przyspieszenie.


Pozdrawiam

do góry

On 2014-11-12, M.M. <m...@g...com> wrote:
> On Wednesday, November 12, 2014 11:24:20 PM UTC+1, Stachu 'Dozzie' K. wrote:
>> Widziałeś kiedyś zawartość /etc/shadow? Czym jest twoim zdaniem ciąg po
>> drugim dolarze w "$1$...$........"? Sól nie musi być nieznana, wystarczy
>> że będzie inna dla każdego hasła.
> Wystarczy do czego? Jak wygląda kompletna lista konkretnych zalet względem
> soli takiej samej dla każdego hasła?

Misiu, kiedy masz zamiar poczytać o ataku z użyciem precomputed hashes
(na przykład rainbow tables) i roli soli w haśle? Bo wcześniej dyskusja
z tobą na ten temat nie ma najmniejszego sensu.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2014-11-13, M.M. <m...@g...com> wrote:
> On Thursday, November 13, 2014 1:00:18 AM UTC+1, bartekltg wrote:
>> Wydaje mi się, że autor miał na myśli to, że przygotowanie takiej
>> tablicy dla porządnej kryptograficznej funkcji skrótu trochę trwa,
>> zakłada więc, że taką tablicę przygotowujemy raz i potem tylko
>> chcemy używać. Użycie _jakiejś_ odpowiednio długiej soli uniemożliwia
>> atakującemu zbudowanie tablicy dekodującej na zapas. Może ją zacząć
>> budować dopiero, gdy sol wycieknie.
>>
>> Tele na temat 'co autor miał na myśli'. Klikam na dłuższą wersję:
> Właśnie to jest bardzo istotne czy należy autora rozumieć dosłownie, czy
> może chodzi o to, że stała sól nie utrudnia ataku tablicami tęczowymi.

A weź ty sobie policz, ile razy musisz dla tej samej skuteczności
zawczasu przeliczonych tablic zwiększyć rozmiar tych tablic. Załóż
sobie, że sól ma raptem 48 bitów. A potem powiedz nam tu na grupie, ilu
terabajtowe pendrive'y wyrzucałeś, bo kupiłeś większy.

>> liczba_haseł_w_bazie/liczba_potencajlnych_haseł
> Tak, co do tego nie straciłem pewności w trakcie rozmowy. Natomiast
> straciłem pewność czy tylko(!) rożna sól uniemożliwia atak tęczowymi
> tablicami.

No jak masz zawsze taką samą, to oczywiście nie możesz używać tych
samych tablic do dwóch różnych haseł, prawda? Bo dla drugiego użycia
tej samej soli dostajesz inny skrót. Chyba że coś w tym rozumowaniu się
nie zgadza.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 13.11.2014 03:06, Stachu 'Dozzie' K. wrote:
> On 2014-11-13, M.M. <m...@g...com> wrote:
>> On Thursday, November 13, 2014 1:00:18 AM UTC+1, bartekltg wrote:
>>> Wydaje mi się, że autor miał na myśli to, że przygotowanie takiej
>>> tablicy dla porządnej kryptograficznej funkcji skrótu trochę trwa,
>>> zakłada więc, że taką tablicę przygotowujemy raz i potem tylko
>>> chcemy używać. Użycie _jakiejś_ odpowiednio długiej soli uniemożliwia
>>> atakującemu zbudowanie tablicy dekodującej na zapas. Może ją zacząć
>>> budować dopiero, gdy sol wycieknie.
>>>
>>> Tele na temat 'co autor miał na myśli'. Klikam na dłuższą wersję:
>> Właśnie to jest bardzo istotne czy należy autora rozumieć dosłownie, czy
>> może chodzi o to, że stała sól nie utrudnia ataku tablicami tęczowymi.
>
> A weź ty sobie policz, ile razy musisz dla tej samej skuteczności
> zawczasu przeliczonych tablic zwiększyć rozmiar tych tablic. Załóż
> sobie, że sól ma raptem 48 bitów. A potem powiedz nam tu na grupie, ilu
> terabajtowe pendrive'y wyrzucałeś, bo kupiłeś większy.

Zakładając z sufitu, że proste hasła ma entropię na 20 bitów *)
(i potrafimy je dobrze odwzorować) wychodzi 3*10^20 kluczy,
Na wejście i wyjście ciągu z tablicy rzućmy po 10 = 20 bajtów.
To daje 6*10^9 TB / długość łańcucha.

Lekko licząc łańcuch musi mieć długość rzędu 10^9,
tyle też zapytań rzucimy naszej kilku TB macierzy dysków.

Normalny dysk będzie miał coś rzędu 10^5 IOPS, jakieś potwory
na PCIe dobijają do 10^6. Chyba nie ma co liczyć na to, że
przypadkiem zapytamy się o ten sam obszar w krótkim odstępie.
Zakłądam też, że w ram trzymamy strukturę, pozwalającą nam trafić
we właściwy obszar dysku średnio w 1.trochę odczytów.
Mamy więc 1000s < 20 minut. Mamy nieco zapasu.

Tylko dwa problemy. Założyłem bardzo małą liczbę bitów na hasło,
oraz umiejętność zbudowania dobrej funkcji hash-> (ludzkie haslo, sol )
(to nie jest funkcja dekodująca! jedynie genertor karminy 'losowym'
ciągiem). Pewnie trzeba by dorzucić wspołczynnik Ignaca typy 2 czy 10.

Jeszcze gorszym problemem jest to, że gdzieś trzeba te 10^20 hashy
policzyć. Hmm, już wiem po co sa bitcoiny! ;-)


nieźródło *) http://xkcd.com/936/ ;-)

pzdr
bartekltg

do góry

On Thursday, November 13, 2014 3:06:42 AM UTC+1, Stachu 'Dozzie' K. wrote:
> A weź ty sobie policz, ile razy musisz dla tej samej skuteczności
> zawczasu przeliczonych tablic zwiększyć rozmiar tych tablic. Załóż
> sobie, że sól ma raptem 48 bitów. A potem powiedz nam tu na grupie, ilu
> terabajtowe pendrive'y wyrzucałeś, bo kupiłeś większy.

Żeby nie było, zmieniam lekko temat:

Nie umiem policzyć tego o czym piszesz. Jak wygląda dowód, że tablicy nie
da się przekonwertować w szybkim czasie bez zwiększania ich rozmiaru?
Mamy tablice dla haseł od 1 do N bitów. Nagle dodajemy do hasła znaną
sól o długości K bitów, K+N=M. Po dodaniu soli ilość haseł w żaden cudowny
sposób nie zwiększyła się. Nie mamy ilości haseł suma_1^M(2^i), tylko
nadal suma_1^N(2^i). Jeśli ilość haseł jest taka sama, to teoretycznie
mogą wystarczyć tablice o takich samych rozmiarach. Jedna trudność w
konwersji tychże tablic. Jest znany taki dowód, czy go nie ma? Jeśli
nie ma takiego dowodu, to ja nie umiem policzyć.


> No jak masz zawsze taką samą, to oczywiście nie możesz używać tych
> samych tablic do dwóch różnych haseł, prawda? Bo dla drugiego użycia
> tej samej soli dostajesz inny skrót. Chyba że coś w tym rozumowaniu się
> nie zgadza.
Nic nie rozumiem.


Pozdrawiam

do góry

On 13.11.2014 03:54, M.M. wrote:
> On Thursday, November 13, 2014 3:06:42 AM UTC+1, Stachu 'Dozzie' K. wrote:
>> A weź ty sobie policz, ile razy musisz dla tej samej skuteczności
>> zawczasu przeliczonych tablic zwiększyć rozmiar tych tablic. Załóż
>> sobie, że sól ma raptem 48 bitów. A potem powiedz nam tu na grupie, ilu
>> terabajtowe pendrive'y wyrzucałeś, bo kupiłeś większy.
>
> Żeby nie było, zmieniam lekko temat:
>
> Nie umiem policzyć tego o czym piszesz. Jak wygląda dowód, że tablicy nie
> da się przekonwertować w szybkim czasie bez zwiększania ich rozmiaru?
> Mamy tablice dla haseł od 1 do N bitów. Nagle dodajemy do hasła znaną
> sól o długości K bitów, K+N=M. Po dodaniu soli ilość haseł w żaden cudowny
> sposób nie zwiększyła się.

Stachu piał o przypadku, gdy przygotowujesz się na dowolną możliwą sól.
Ty teraz piszesz o tym, że dopiero gdy masz sol, zapuszczasz botnet, by
tablicę spreparował.


pzdr
bartekltg

do góry

On Thursday, November 13, 2014 4:33:45 AM UTC+1, bartekltg wrote:
> On 13.11.2014 03:54, M.M. wrote:
> > On Thursday, November 13, 2014 3:06:42 AM UTC+1, Stachu 'Dozzie' K. wrote:
> >> A weź ty sobie policz, ile razy musisz dla tej samej skuteczności
> >> zawczasu przeliczonych tablic zwiększyć rozmiar tych tablic. Załóż
> >> sobie, że sól ma raptem 48 bitów. A potem powiedz nam tu na grupie, ilu
> >> terabajtowe pendrive'y wyrzucałeś, bo kupiłeś większy.
> >
> > Żeby nie było, zmieniam lekko temat:
> >
> > Nie umiem policzyć tego o czym piszesz. Jak wygląda dowód, że tablicy nie
> > da się przekonwertować w szybkim czasie bez zwiększania ich rozmiaru?
> > Mamy tablice dla haseł od 1 do N bitów. Nagle dodajemy do hasła znaną
> > sól o długości K bitów, K+N=M. Po dodaniu soli ilość haseł w żaden cudowny
> > sposób nie zwiększyła się.
>
> Stachu piał o przypadku, gdy przygotowujesz się na dowolną możliwą sól.
> Ty teraz piszesz o tym, że dopiero gdy masz sol, zapuszczasz botnet, by
> tablicę spreparował.

Nie o tym pisałem. Zastanawiam się, czy istnieje możliwość wykorzystania
tablic do haseł nieosolonych, gdy zostały osolone.

Pozdrawiam

do góry

On 12/11/2014 20:26, Borneq wrote:
> W dniu 2014-11-12 o 19:59, Piotr pisze:
>> Przy losowych "solach" mozesz userowi udostepnic program hashujacy (moze
>> byc nawet zrodlowka czy program napisany w jezyku skryptowym - nie musisz
>
> Ale losowa sól musi być taka sama przy tworzeniu każdego hasha jak i
> przy sprawdzaniu. Jeśli nie jest zaszyta w kodzie programu, powinna być
> w pliku konfiguracyjnym i nie zmieniana?

Normalnie jest trzymana razem z hasłem.

do góry

>
> Misiu, kiedy masz zamiar poczytać o ataku z użyciem precomputed hashes
> (na przykład rainbow tables) i roli soli w haśle? Bo wcześniej dyskusja
> z tobą na ten temat nie ma najmniejszego sensu.
>
z takimi tekstami to nie tutaj jawny ćwoku

do góry