[GWT] Autoryzacja na podstawie konfiguracji bazy danych
Jacek
Mam nastepujacy problem. W mojej aplikacji GWT sa serwisy pobierajace
dane z bazy. Autoryzacja userow do poszczegolnych czynnosci ma sie
opierac na uprawnieniach danego usera do bazy - czyli jak wyskoczy
wyjatek o braku uprawnien to mam sie martwiďż˝ :)
Podejscie dosc wygodne ale budzi 1 watpliwosc :
W formularzu logowania musze podac login i haslo w plaintext - przekazac
do serwisu ktory zwroci datasource badz nie. I zastanawiam sie na ile
jest to bezpieczne rozwiazanie...
--
Jacek
nullpointer
1. Zanwestuj w SSL
2. Je�li Ci� nie sta�, albo z jakich� powod�w nie mo�esz, submituj
formularz javascriptem, a przedtem hashuj (w JS) pole z has�em przy
pomocy MD5 + ziarno
3. Je�li to aplikacja intranetowa (a nie dla szerszej publisi) poczytaj
o Single Sign On
--
npe
Witold Szczerba
> 2. Jeśli Cię nie stać, albo z jakichś powodów nie możesz, submituj
> formularz javascriptem, a przedtem hashuj (w JS) pole z hasłem przy
> pomocy MD5 + ziarno
Tak się zastanawiam - co ma dać (z punktu widzenia bezpieczeństwa)
taka operacja, żeby skrypt przerobił hasło na MD5 przed wysłaniem?
Jeśli to ma być zabezpieczenie przed podsłuchaniem hasła - to nic taki
zabieg nie da. Osobnik przechwyci MD5, a twój serwis i tak będzie
autoryzował na bazie pary [login+MD5(hasło)], więc to ten MD5 będzie
de-fakto hasłem.
nullpointer
> Tak si� zastanawiam - co ma da� (z punktu widzenia bezpiecze�stwa)
> taka operacja, �eby skrypt przerobi� has�o na MD5 przed wys�aniem?
> Je�li to ma by� zabezpieczenie przed pods�uchaniem has�a - to nic taki
> zabieg nie da. Osobnik przechwyci MD5, a tw�j serwis i tak b�dzie
> autoryzowa� na bazie pary [login+MD5(has�o)], wi�c to ten MD5 b�dzie
> de-fakto has�em.
Ano, tak to w�a�nie bywa, jak si� co� gdzie� us�yszy, nie przemy�li i
powtarza.
Oczywi�cie masz racj� a ja gadam g�upoty ;-)
--
npe
Marcin Biegan
Wystarczy wys�a� klientowi jak�� losow� warto��, niech j� najpierw doklei do
has�a i ju� b�dzie (w miar�) ok.
--
MB
Witold Szczerba
> Wystarczy wysłać klientowi jakąś losową wartość, niech ją najpierw doklei do
> hasła i już będzie (w miarę) ok.
>
> --
> MB
Nie rozumiem, możesz wyjaśnić? Kod JavaScript jest wszystkim znany,
więc i "włamywacz" go może go uruchomić. Serwis ma wg powyższej zasady
zawsze najpierw wysłać "coś" klientowi, który podaje hasło, które
następnie JavaScript modyfikuje i odsyła serwerowi jako _niby_
autoryzacja klienta.
To ja się pytam co to za zabezpieczenie, skoro wystarczy podsłuchać
konwersację i można się logować? No chyba, że zakładamy, że nikt nie
podsłuchuje, tylko wtedy po co w ogóle kombinować?
Marcin Biegan
>> Wystarczy wys�a� klientowi jak�� losow� warto��, niech j� najpierw doklei do
>> has�a i ju� b�dzie (w miar�) ok.
>
> wi�c i "w�amywacz" go mo�e go uruchomi�. Serwis ma wg powy�szej zasady
> zawsze najpierw wys�a� "co�" klientowi, kt�ry podaje has�o, kt�re
> nast�pnie JavaScript modyfikuje i odsy�a serwerowi jako _niby_
> autoryzacja klienta.
> To ja si� pytam co to za zabezpieczenie, skoro wystarczy pods�ucha�
> konwersacj� i mo�na si� logowa�? No chyba, �e zak�adamy, �e nikt nie
> pods�uchuje, tylko wtedy po co w og�le kombinowa�?
"Osobnik przechwyci MD5, a tw�j serwis i tak b�dzie
autoryzowa� na bazie pary [login+MD5(has�o)], wi�c to ten MD5 b�dzie
de-fakto has�em."
Teraz wysy�asz login+MD5(has�o+jednorazowy_token), przechwycenie tego nic nie
da, bo hash zadzia�a tylko raz - przy ka�dym logowaniu co innego jest
przekazywane do serwera i wcze�niejsze hashe nie s� ju� aktualne. Oczywi�cie
nie eliminuje to wi�kszo�ci problem�w (pods�uchiwanie po zalogowaniu dalej w
sumie pozwala na wszystko, mo�na szybko si� zalogowa� i dosta� do serwera przed
legalnym userem, itp).
--
MB
Jacek
> "Osobnik przechwyci MD5, a tw�j serwis i tak b�dzie
> autoryzowa� na bazie pary [login+MD5(has�o)], wi�c to ten MD5 b�dzie
> de-fakto has�em."
>
> Teraz wysy�asz login+MD5(has�o+jednorazowy_token), przechwycenie tego
> nic nie da, bo hash zadzia�a tylko raz - przy ka�dym logowaniu co innego
> jest przekazywane do serwera i wcze�niejsze hashe nie s� ju� aktualne.
> Oczywi�cie nie eliminuje to wi�kszo�ci problem�w (pods�uchiwanie po
> zalogowaniu dalej w sumie pozwala na wszystko, mo�na szybko si�
> zalogowaďż˝ i dostaďż˝ do serwera przed legalnym userem, itp).
Nie kumasz chyba jak dziala GWT - cala aplikacje masz na dysku -
potencjalnie atakujacy moze zrobic eval() na kazdym kawalku kodu JS.
Widze ze SSL jest jedyna sensowna opcja w tym przypadku.
--
Jacek
Marcin Biegan
No i co z tego? Niby w kt�rym miejscu "potencjalnie atakuj�cy" mia�by
skorzysta� ze znajomo�ci kodu w tym przypadku? A co do ssl to masz racj�.
--
MB
Witold Szczerba
> Teraz wysyłasz login+MD5(hasło+jednorazowy_token), przechwycenie tego nic nie
> da, bo hash zadziała tylko raz - przy każdym logowaniu co innego jest
> przekazywane do serwera i wcześniejsze hashe nie są już aktualne.
Przechwytujesz:
hasło+jednorazowy_token,
odrzucasz ten jednorazowy_token, pobierasz sobie nowy z serwera,
doklejasz i masz:
hasło+nowy_jednorazowy_token
i logujesz się.
Witold Szczerba
OK, teraz widzę, że to było MD5(hasło+jednorazowy_token), ale w tym
wypadku serwer musiałby znać hasło, żeby sobie taką samą kombinację
wygenerować do sprawdzenia, czy hasło było poprawne, a jak wiadomo
nikt poza właścicielem nie powinien znać hasła. W takim razie powinno
być:
MD5(MD5(hasło) + jednorazowy_token)
Problem jest tylko taki, że serwer musiałby pamiętać wszystkie
wykorzystane tokeny, coś jak hasła jednorazowe. Na dodatek i tak
średnio to by wszystko działało, bo po zalogowaniu klient musi dostać
jakiś ID sesji - bez SSL można to przechwycić i zamiast się logować,
wystarczyłoby się podłączyć pod sesję użytkownika... Masa babrania a i
tak niewiele to ma wspólnego z bezpieczeństwem :)