eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingkodowanie haseł › Re: kodowanie haseł
  • Data: 2013-01-22 16:38:09
    Temat: Re: kodowanie haseł
    Od: Michoo <m...@v...pl> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    On 22.01.2013 16:07, bartekltg wrote:
    > W dniu 2013-01-22 15:45, Michoo pisze:
    >> On 22.01.2013 13:11, bartekltg wrote:
    >>> W dniu 2013-01-22 02:53, M.M. pisze:
    >>>> Określenia "posolić" używa się normalnie, czy tak sobie napisałeś?
    >>>> Ja dodaje losowe znaki w kilku miejscach oryginalnego ciągu, potem
    >>>> jakiś standardowy klucz sha, albo md5, albo nawet jakiś własny. Gdzieś
    >>>> czytałem że md5 został rozpracowany - nie wiem znaczy słowo
    >>>> "rozpracowany",
    >>>> ale tak czy inaczej do hashowania w poważnej kryptografii lepiej nie
    >>>> używać.
    >>>
    >>> Zwróć uwagę na to, o czym prawie kulturalnie mówił Stachu
    >>> wczoraj a daniel rzucił linka. Jeśli poza bazą danych o hasłach
    >>> (hash i 'sól')wycieknie też metoda kodowania (a czemu ma nie
    >>> wyciec, skoro baza wyciekła, o ile wręcz nie jest jawna) to
    >>> jesteśmy podatni na atak przez ręczne md5 wszystkich możliwych
    >>> haseł. Jeśli nie są one zbyt długie, jest to robialne.
    >>>
    >>> Sól daje to, że operację trzeba powtórzyć dla każdego użytkownika,
    >>> zamiast za jednym zamachem mieć odkodowanych wszystkich,
    >>> ale to niewielka pociecha, gdy np Ty jesteś celem;)
    >>
    >> Ale z tego co rozumiem on dodawał losowe znaki (nie wiem po co w "kilku
    >> miejscach").
    >
    > Tak jak i w pisywanej metodzie. One siedzą pod nazwą 'salt'.
    > Tylko były zapisywane.
    >
    >
    >> XOR hasła z losowym dwubajtowym (nie zapisywanym) ciągiem jest znaną
    >> metodą na:
    >
    > Nie zapisywanym?
    Koniecznie.

    >
    >> - proste zwiększenie złożoności łamania hasła przy zachowaniu
    >> istniejącej infrastruktury (średnio 32k razy, w praktyce więcej, bo
    >> wynik jest z przedziału 0-255 a nie alfanum)
    >> - uniemożliwienie użycia "złamanego" hasła (po znalezieniu odwzorowania
    >> hash - String nadal ma się ~64k możliwości do zbadania)
    >
    >
    > Nie wiem, nie znam się, więc powiedz mi, jak chcesz użyć losowej
    > wartości nie zapisując jej? Jak wtedy chcesz zweryfikować
    > osobę z hasłem.
    >
    > hash = fhash( hasło OXR rand() )
    >
    > Robimy to przy zakładaniu konta. Zapisujemy hash.
    >
    >
    > Przychodzi teraz użytkownik, chce się zalogować,
    > podaje [haslo]. Jak chcesz je porównać z hashem?
    >
    // rand jest z przedziału <0,2^16-2>
    bool passOk=false;
    for(uint16_t i=0;i<-1;i++){
    hash = fhash( hasło OXR i )?
    if(hash==db.hash){
    passOk = true;
    break;//*
    }
    }


    Jak już pisałem - to jest do użycia gdy masz już jakąś infrastrukturę,
    której nie chcesz zmieniać. Jak sam robisz "funkcję sprawdzającą" to
    wywołanie md5 w pętli było jednym z ładniejszych rozwiązań.

    > A jeśli zapisujesz, to ta losowa liczba może wyciec razem z hashem
    > i wracamy do problemu opisanego iterację wyżej.

    Tak, dlatego nie zapisujesz.


    * uwaga - w teorii powoduje podatność na time-based attacks w przypadku
    MiTM, rozwiązaniem jest trzymanie losowo permutowanej tablicy i XOR z
    tab[i] zamiast z i. Imo to już przkombinowanie, bo atakujący musiałby
    mieć bazę haszy i jednocześnie monitorować ruch. To równie dobrze by
    mógł rootkit podrzucić.


    --
    Pozdrawiam
    Michoo

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: