Aplikacje internetowe

Bełdziowe spojrzenie na aplikacje internetowe

Dynamiczne logowanie

Każde, nawet najbardziej skomplikowane hasło może zostać złamane. Jedyną niewiadomą w tym procesie jest czas potrzebny do wygenerowania wszystkich możliwych kombinacji znaków. Powodem takiego stanu rzeczy jest statyczność hasła. Mianowicie podczas ataku brute force każdy wygenerowany ciąg znaków porównywany jest zawsze z tym samym hasłem znajdującym się w bazie. Gdyby zapewnić zmienność hasła przy każdym logowaniu sprawdzanie każdej kombinacji przestałoby mieć sens. Poniżej kilka przykładów pokazujących jak można stworzyć dynamiczne logowanie.

Logowanie na podstawie czasu

Najbardziej zmiennym, a zarazem najbardziej logicznym elementem, który może zostać wykorzystany jest czas. Przyjmijmy, że logujący się użytkownik na początku swojego hasła musi podać aktualną minutę z czasu, który wyświetla mu się na stronie (oczywiście może to być czas systemowy, bądź też ten z zegarka na ręce ;-)). Uznajmy, że dodana minuta pełni rolę pseudo sumy kontrolnej. Co dzięki temu zyskujemy? Co minutę musimy podać inne hasło, a dodatkowo zwiększamy jego trudność poprzez dodanie do niego cyfr.

<?php

    if( !$_POST )
    {
        echo '<p>Aktualny czas: ' . date( 'H:i' ) . '</p>';
    ?>
        <form action="" method="post">
            <p>
                Login: <input name="login" />
            </p>
            <p>
                Haslo: <input type="password" name="passwd" />
            </p>
            <p>
                <input type="submit" />
            </p>
        </form>
    <?php
    }
    else
    {
        $login  = 'admin';
        $passwd = 'admin';

        if( $login != $_POST['login'] )
            die( 'Podany login jest niepoprawny.' );

        $min = date( 'i' );

        /*
            Dodatkowe sprawdzenie czy przekazana minuta nie jest
            wieksza o 1 od aktualnej ma na celu zalogowanie uzytkownika,
            ktory wysle formularz pod koniec biezacej minuty.
         */
        $nextMin = $min + 1;

        if( strlen( $nextMin ) == 1 )
            $nextMin = 0 . $nextMin;

        if( $min . $passwd != $_POST['passwd'] &&
            $nextMin . $passwd != $_POST['passwd'] )
            die( 'Podane haslo jest niepoprawne' );

        echo 'Zalogowales sie pomyslnie.';
    }

?>

Zmiana hasła po każdym logowaniu

Oczywiście nie wymagamy tego od użytkownika, tylko przeprowadzamy ten proces automatycznie. Jak? Po poprawnym zalogowaniu się przez użytkownika generujemy nową sól oraz hash hasła. Dzięki takiemu działaniu mamy podwójne zabezpieczenie. Po pierwsze do złamania hasha napastnik musi znać sól użytą podczas jego generowania. Po drugie po każdym zalogowaniu użytkownika napastnik musi ponownie przeprowadzić proces łamania hash’a.

Token

Najlepszym rozwiązaniem mającym zapewnić bezpieczeństwo logowania jest skorzystanie z tokenów. Możemy się z nimi spotkać podczas wykonywania przelewów w mBanku (hasła sms’owe) bądź też podczas sprawdzania historii połączeń na stronie Play.

Zasada działania tokenów polega na wygenerowaniu losowego ciągu znaków oraz przesłaniu ich do użytkownika – hasło nie powinno być wysyłane drogą internetową, powinno do tego wykorzystywać się specjalne urządzenie, bądź po prostu telefon komórkowy. Dzięki nim zyskujemy teoretycznie pełne bezpieczeństwo procesu logowania.


Tagi: ,
Kategoria: Bezpieczeństwo, Logowanie


9 komentarzy

  1. phjr napisał(a):

    Według mnie dodawanie minuty na początku nic nie daje. Taka informacje musi być podana publicznie na stronie, czyli włamywacz też ją będzie miał. W bazie musi być hash samego hasła… a jest komplikacja z powodu możliwej różnicy we wskazaniach zegarków (+/- minuta itd).

    "Po drugie po każdym zalogowaniu użytkownika napastnik musi ponownie przeprowadzić proces łamania hash'a." – nieprawda. Hasło się nie zmieniło, czyli może kontynuować atak używając starych znanych sobie wartości salta (soli) i hasha. Też myślę, że nie jest to żadne utrudnienie, ale może czegoś nie dostrzegam…

  2. Michał "Bełdzio" Ławicki napisał(a):

    1. Nie musi być podana publicznie. Wystarczy, że o konieczności dodania minuty będą wiedziały tylko konkretne osoby tzn. sposób ten nie jest przeznaczony dla logowania dostępnego dla każdego, a raczej dla wybranych osoób np. administracji serwisu.

    2. Co do róznicy w minucie to w przykładowym kodzie jest rozwiązanie tego problemu.

    3. Sęk w tym, że za każdym razem generujemy nową wartośc soli, a następstwem wygenerowania nowej soli jest nowe hasło. Jeśli mamy hasło "admin" i sól 1234 to hasło = "admin1234", po zalogowaniu wygeneruje się nowa sól np. 678 i hasło będzie wtedy "admin678" :)

  3. dr_bonzo napisał(a):

    // zakladam ze w bazie trzymamy: sol | md5( sol + haslo )

    Ale zmiana soli nic nie poprawia bezpieczenstwa, jak chacker leci po haslach bruteforcem.

    Bo i tak kiedys wpisze "admin" i to po polaczeniu z sola da nam

    $sol . "admin"

    i wpusci usera.

    Zmiana soli sie przyda na wypadek, gdyby chaker mial dostep do hashy hasel, wtedy musi atakowac hasha z niezna, nowa2 sola.

    Nie? :)

  4. Michał "Bełdzio" Ławicki napisał(a):

    Hmmm tak patrze na tą notkę i widzę, że przydałoby się napisać do czego dany sposób może być pomocny. W pierwszym punkcie chodziło o zabezpieczenie się przed brute force, w drugim zaś o obrone w przypadku, gdy ktoś w jakiś magiczny sposób dorwie się do hashy. Miało być pięknie, a wyszło jak zawsze ;-)

  5. Kokoss napisał(a):

    Dobry sposób na proste strony, jednak dla zaawansowanych serwisów potrzeba czegoś więcej. Artykuł ciekawy.

  6. Firemark napisał(a):

    Sądzę, że te metody są zbędne [Czas może być określony za pomocy algorytmu, co to za problem]
    Jak chcemy na upartego dynamicznego logowania to najlepiej by użytkownik miał listę 30 haseł, które każde z nich mogło być użyte tylko raz. Po skończeniu się listy, użytkownik by dostawał nowe.
    Choć i tak to nie broni przed brute-force.

  7. Powyższa metoda to tylko przykład, że w prosty sposób można sprawić, aby proces logowania był mniej „standardowy”, a co za tym idzie trudniejszy do złamania. Co do brute-force to bez względu na to w jaki sposób użytkownik się loguje powinniśmy wziąć pod uwagę ograniczenie ilości błędnych logować, ale to już nie jest tematem powyższej notki :)

  8. Moim zdaniem już lepiej wrzucić re-Captcha’ę Wówczas żaden algorytm (przynajmniej o takim nie słyszałem) tego nie złamie, a wątpie czy przy brute force chciałoby się komukolwiek za każdym razem przepisywyać kod z obrazka. Choć to trochę bardziej uciążliwe dla userów – no ale coś za coś :)

  9. Jak najbardziej można, tyle że w tym poście skupialiśmy się na rozwiązaniach „wewnętrznych”. Jeśli chodzi o serwisy typu reCaptcha istnieją dedykowane serwisy wspierające ich „łamanie”.

Dodaj komentarz