![]() |
![]() |
![]()
Post
#1
|
|
![]() Grupa: Zarejestrowani Postów: 813 Pomógł: 34 Dołączył: 18.03.2007 Skąd: o stamtąd Ostrzeżenie: (0%) ![]() ![]() |
Witam
Potrzebuje zrobić system autoryzacji. Chciałem się was zapytać jakie są najlepsze sposoby, jak najlepiej się zabezpieczyć przed możliwymi włamami, gdzie i jak przetrzymywać dane ze taki i taki user jest zalogowany? Interesują mnie tylko najlepsze/najbezpieczniejsze rozwiązania. Liczę na waszą kreatywność. Pozdrawiam Chmura EDIT Dotychczas korzystałem z link dziś nie wydaje mi się to najlepszym rozwiązaniem... Ten post edytował b_chmura 11.09.2007, 19:15:40 |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 295 Pomógł: 9 Dołączył: 8.02.2006 Ostrzeżenie: (0%) ![]() ![]() |
hmm na co powinno się zwrócić uwagę:
1. hashowanie hasła 2. ograniczyć ilość wpisywanych znaków 3. zabezpieczyć przed wprowadzeniem niebezpiecznych znaków 4. korzystać z troszkę mniej standardowych nazwa tabel i pól jak pojedyńcze słowa "user", "login" czy "password" |
|
|
![]()
Post
#3
|
|
Grupa: Zarejestrowani Postów: 27 Pomógł: 0 Dołączył: 31.07.2006 Skąd: Czeladź Ostrzeżenie: (0%) ![]() ![]() |
co do przechowywania danych, to przetrzymuje je w sesji, login i haslo,
i przy kazdym odswiezeniu strony / przejsciu na inna sie loguje / sprawdza czy uzytkownik ma uprawnienia, nigdy np nie trzymam informacji ze uzytkownik sie zologowal, i tylko to pozniej po kazdym odswiezeniu sprawdzam -------------------- Projektowanie stron internetowych
|
|
|
![]()
Post
#4
|
|
![]() Grupa: Zarejestrowani Postów: 338 Pomógł: 2 Dołączył: 4.03.2006 Skąd: Łódź Ostrzeżenie: (0%) ![]() ![]() |
|
|
|
![]()
Post
#5
|
|
![]() Grupa: Zarejestrowani Postów: 2 262 Pomógł: 21 Dołączył: 3.05.2004 Skąd: Sopot, Krakow, W-wa Ostrzeżenie: (0%) ![]() ![]() |
Przechowywanie hasla to czysta glupota bo kto go potrzebuje ? Tak naprawde jedyna rzecza ktora powinna byc w sesji to id uzytkownika oraz te dane ktorych sie czesto uzywa np do wypisania - np. login,email czy nazwa ekranowa tak nie pobierac ich za kazdym zadanie z bazy danych.
-------------------- Javascript, Coffeescript, Node.js, Mongo, CouchDb, chmury, workery & inne bajery - zycie jest zbyt krotkie aby miec nudna prace :)
|
|
|
![]()
Post
#6
|
|
![]() Grupa: Zarejestrowani Postów: 418 Pomógł: 8 Dołączył: 16.11.2006 Ostrzeżenie: (0%) ![]() ![]() |
Ja bym jednak za każdym wejściem na stronę sprawdzał użytkownika. Np. jedna zmienna sesji to będzie login/email/id czy coś podobnego (unikalnego sie rozumie), a druga to zahashowana konkatenacja loginu i hasła (albo czegokolwiek innego, byle nie tego samego, co trzymamy w pierwszej zmiennej).
-------------------- |
|
|
![]()
Post
#7
|
|
![]() Grupa: Zarejestrowani Postów: 813 Pomógł: 34 Dołączył: 18.03.2007 Skąd: o stamtąd Ostrzeżenie: (0%) ![]() ![]() |
a jest taka możliwość żeby ktoś się podszył pod jakąś sesje?
żeby ktoś odczytał co sie znajduje w sesji? |
|
|
![]()
Post
#8
|
|
![]() Grupa: Zarejestrowani Postów: 418 Pomógł: 8 Dołączył: 16.11.2006 Ostrzeżenie: (0%) ![]() ![]() |
No właśnie można, aczkolwiek nie jest to takie proste (ogólnie sesje są po to, żeby nikt niepowołany tam się nie wpieprzał, ale wiadomo - dla chcącego nic trudnego
![]() -------------------- |
|
|
![]()
Post
#9
|
|
![]() Grupa: Zarejestrowani Postów: 813 Pomógł: 34 Dołączył: 18.03.2007 Skąd: o stamtąd Ostrzeżenie: (0%) ![]() ![]() |
tak mi się wydawało dlatego czekam na dalsze sugestie jak bezpiecznie się zalogować i przechowywać dane o użytkowniku by tylko po poprawnym zalogowaniu ukazały mu sie odpowiednie dane.
a może by tak napisać własny hash? |
|
|
![]()
Post
#10
|
|
![]() Grupa: Zarejestrowani Postów: 418 Pomógł: 8 Dołączył: 16.11.2006 Ostrzeżenie: (0%) ![]() ![]() |
Własny hash? Przecież masz md5. Hasha nie odczytasz - to jest tak jakby "szyfrowanie w jedną stronę".
-------------------- |
|
|
![]()
Post
#11
|
|
![]() Grupa: Zarejestrowani Postów: 813 Pomógł: 34 Dołączył: 18.03.2007 Skąd: o stamtąd Ostrzeżenie: (0%) ![]() ![]() |
szczerze sie przyznam ze nie znam dokładnej definicji "hash'a" ale chodziło mi o własne zakodowanie danych wraz z funkcją odpowiedzialną za odkodowanie..
np zamiana liter na cyfry i wykonanie jakiegoś działania matematycznego |
|
|
![]()
Post
#12
|
|
![]() Grupa: Zarejestrowani Postów: 418 Pomógł: 8 Dołączył: 16.11.2006 Ostrzeżenie: (0%) ![]() ![]() |
Rozumiem o co Ci chodzi, ale weź pod uwagę to, że twój szyfr ktoś może odszyfrować. Funkcji hashującej odszyfrować się nie da. A jak sprawdzać? Za każdym wywołaniem strony bierzesz dane z sesji (załóżmy, że w zmiennych sesji masz login i md5(login.hasło) - zhashowana konkatenacja, że się tak wyrażę...
![]() -------------------- |
|
|
![]()
Post
#13
|
|
![]() Grupa: Zarejestrowani Postów: 813 Pomógł: 34 Dołączył: 18.03.2007 Skąd: o stamtąd Ostrzeżenie: (0%) ![]() ![]() |
to nie zabije bazy? jak jej przyjdzie hashowac wszytkie loginy i hasła... może od razu przy rejestracji zastosować tą kombinacje?
|
|
|
![]()
Post
#14
|
|
Grupa: Zarejestrowani Postów: 411 Pomógł: 35 Dołączył: 27.06.2004 Skąd: Kraków Ostrzeżenie: (0%) ![]() ![]() |
O przepraszam, mając hash masz spore szanse odzyskania hasła. Poczytajcie o tęczowych tablicach. W internecie są też strony typu http://md5.rednoize.com/ które zawierają 50 000 000 najpopularniejszych haseł i hashy. Więc to nie jest takie trudne. Najlepszą obroną jest solenie hashowanych stringów.
Ale to była taka mała dygresja. Wracając do tematu. Najlepsze są rozwiązania najprostsze. Przy rejestracji zapisujesz w bazie: id, login, hash hasła. Prz próbie zalogowania robisz: SELECT * FROM user WHERE `login`='$login' AND `pass`=MD5('$pass'); Jeśli to zapytanie zwróci ilość rekordów różną od 1 to znaczy, że coś jest nie tak: nie ma usera, złe hasło etc. Jeśli wszystko jest OK, apisujemy do sesji np id i login. Nie ma sensu niczego więcej, chyba że jest to dla Ciebie wygodne. Teraz, żeby sprawdzić czy user jest zalogowany sprawdzamy czy te dane istnieją w sesji. Aby wylogować usera usuwamy jest z sesji. Najsłabszym ogniwem tego rozwiązania jest zapytanie do bazy, mamy tu dane które pochodzą od użytkownika. Dlatego najaważniejsz rzeczą jest taka konfiguracja serwera i fitlrowanie zapytań, aby uniemożliwić SQL injection. To wszystko, nie ma sposobu, żeby oszukać taki system jeśli jest dobrze zaprojektowany. Istnieją jeszcze dwa niebezpieczeństwa, jednemu możesz zapobiec, drugiemu możesz tylko próbować: 1) Zła konfiguracja serwera, która pozwoliłaby w jakiś sposób uzyskać atakującemu do katalogu z sesjami (czy do bazy z sesjami, jeśli masz własny mechanizm obsługi sesji) Ale szczerze wątpie żeby istniał tak lamowaty admin serwera ![]() 2) Zdobycie przez atakującego identyfikatora sesji ofiary. To już poważniejszy problem, bo atakujący może działać na koncie ofiary. Musisz tak przygotować swój serwis, aby nie dało się dokonać Code Insertion. (konkretnie chodzi o wstrzyknięcie javascriptu lub innego języka skryptowego który pozwala na dostęp do ciasteczek) Ale to już jest temat rzeka, bo nawet największe serwisy sobie z tym nie zawsze radzą. Pozdrawiam! -------------------- |
|
|
![]()
Post
#15
|
|
![]() Grupa: Zarejestrowani Postów: 418 Pomógł: 8 Dołączył: 16.11.2006 Ostrzeżenie: (0%) ![]() ![]() |
legorek => No tak, ja mówiłem o teorii, czyli o funkcji hashującej jako funkcji z dążącym do 0 prawdopodobieństwem kolizji. Zawsze można zamiast md5 wybrać coś "lepszego".
b_chmura => Z podanych przez legorka "zagrożeń" naprawdę ciężko wyeliminować to drugie. Cytat Ale to już jest temat rzeka, bo nawet największe serwisy sobie z tym nie zawsze radzą. Prawda... ![]() -------------------- |
|
|
![]()
Post
#16
|
|
![]() Grupa: Zarejestrowani Postów: 338 Pomógł: 2 Dołączył: 4.03.2006 Skąd: Łódź Ostrzeżenie: (0%) ![]() ![]() |
No właśnie można, aczkolwiek nie jest to takie proste (ogólnie sesje są po to, żeby nikt niepowołany tam się nie wpieprzał, ale wiadomo - dla chcącego nic trudnego ![]() Moja sesja: id = 5, login = prph, haslo = *****; Kradniesz moja sesje. Twoja sesja to: id = 5, login = prph, haslo = *****; Wiec, czy sprawdzisz, czy w sesji jest ustawione "zalogowany", czy sprawdzisz haslo to wyjdzie na to samo. No pomijam, ze baza dostaje w tylek na dzien dobry. |
|
|
![]()
Post
#17
|
|
![]() Grupa: Zarejestrowani Postów: 418 Pomógł: 8 Dołączył: 16.11.2006 Ostrzeżenie: (0%) ![]() ![]() |
W tym przypadku wszystko jedno, chodzi o to, żebyś nie mógł sobie sam wpisać (jakkolwiek byś to zrobił) zmiennych sesji. Jak jest tylko zmienna "zalogowany" to żaden problem, a tak musisz znać dane konta (login, hasło, etc.).
Zresztą ja spotykałem się głównie z takimi rozwiązaniami, chociażby osCommerce, i tak to zawsze kazało mi robić szefostwo z pracy, że tak się na autorytety powołam... ![]() A co do tego, że "baza dostaje w tyłek" - nie dostaje aż tak bardzo. Ten jeden SELECT przy wczytywaniu strony wielkiej krzywdy nie robi. -------------------- |
|
|
![]()
Post
#18
|
|
Grupa: Zarejestrowani Postów: 27 Pomógł: 0 Dołączył: 31.07.2006 Skąd: Czeladź Ostrzeżenie: (0%) ![]() ![]() |
A wiec dlaczego za kazdym razem sprawdzam czy dana osoba jest w bazie danych, przy kazdym odswiezeniu:
jesli osoba sie zaloguje, i dane ze zalogowany bedzie przechowywac w sesji, to taka osoba moze byc zalogowana nawet przez rok jesli bedzie sobie strone odswiezal, i np jesli np admin zablokuje uzytkownika, lub zmieni mu jakies dane ktore sa przechowywane w sesji, to i tak nic nie da , jesli czlowiek jest zalogowany. Dlatego zawsze sprawdzam czy dane login-haslo zgadza sie z tym w bazie, i danych uzytkownika nie przechowuje w sesji tylko w normalnej zmiennej, i aktualizuje za kazdym odswiezeniem -------------------- Projektowanie stron internetowych
|
|
|
![]()
Post
#19
|
|
![]() Grupa: Zarejestrowani Postów: 793 Pomógł: 32 Dołączył: 23.11.2006 Skąd: Warszawa Ostrzeżenie: (0%) ![]() ![]() |
Sesja ma dwa czasy życia, jeden pomiędzy odświeżeniami drugi od założenia. Więc sesja może się przeterminować np. po dniu nie ważne że ciągle odświeżasz.
Przypadek kiedy użytkownik wyleciał a ma aktywną sesje jest na tyle rzadki, że nie warto męczyć systemu ciągłym sprawdzaniem. Ale to wszystko już zależy od systemu który wymaga autoryzacji... bo można sprawdzać uprawnienia do danej akcji za każdym razem itp. itd. -------------------- Algorytmy w PHP, czy ktoś o tym słyszał?
Dlaczego tak mało kobiet programuje? ponieważ nie zajmują się głupotami. |
|
|
![]()
Post
#20
|
|
![]() Grupa: Zarejestrowani Postów: 418 Pomógł: 8 Dołączył: 16.11.2006 Ostrzeżenie: (0%) ![]() ![]() |
No cóż, temat rzeka, jak widać... W gruncie rzeczy proponuję używanie PEAR::Auth. Sprawdzone, rozwijane i projektowane przez tęższe umysły niż niżej podpisany...
-------------------- |
|
|
![]() ![]() |
![]() |
Wersja Lo-Fi | Aktualny czas: 25.07.2025 - 09:51 |