Komentarze do: Dynamiczne logowanie

Autor: Michał Ławicki

Michał Ławicki — Mon, 11 Jul 2011 10:35:02 +0000

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

Autor: tr!ckle

tr!ckle — Mon, 11 Jul 2011 10:32:10 +0000

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ś :)

Autor: Michał Ławicki

Michał Ławicki — Thu, 01 Apr 2010 22:37:55 +0000

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 :)

Autor: Firemark

Firemark — Thu, 01 Apr 2010 22:21:42 +0000

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.

Autor: Kokoss

Kokoss — Sat, 05 Apr 2008 09:54:38 +0000

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

Autor: Michał "Bełdzio" Ławicki

Michał "Bełdzio" Ławicki — Fri, 04 Apr 2008 23:35:26 +0000

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 ;-)

Autor: dr_bonzo

dr_bonzo — Fri, 04 Apr 2008 22:44:18 +0000

// 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? :)

Autor: Michał "Bełdzio" Ławicki

Michał "Bełdzio" Ławicki — Fri, 04 Apr 2008 22:21:38 +0000

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" :)

Autor: phjr

phjr — Fri, 04 Apr 2008 22:14:03 +0000

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…