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