Witam!
Jestem w trakcie pisania sklepu. Jedną z funkcji sklepu ma byc taka ze bedzie mógł ktos sie zalogowac(wpisujac login oraz haslo), dzieki czemu bedzie on traktowany jako stały klient i sklep bedzie pokazywal nizsze ceny. Chcialem sie Was zapytac czy w miere mam dobry pomysł na rozwiazanie problemu dotyczacego przesylania loginu oraz hasla:

Hasło oraz login chce przesylac za pomoca sesji.
Produkty oraz ich ilosci w koszyku tez w sesji.
A teraz wlasnie ten głowny problem:
Mysle ze przesylanie loginu oraz hasla w sesji nie jest bezpieczne.
Czytalem ze sa tekie programy (chyba snifery czy cos takiego),
ktora potrafia podejrzec naglowki strony.

Czy jest jakies sensowne rozwiazanie tago problemu nie uzywajac SSL?

Myslalem rozwiazac to w taki sposob aby przesylac zakodowany login oraz haslo w md5.
W bazie danych klientow bylby zapisany login,
haslo oraz login i haslo w md5.
Skrypt przy wyswietlaniu produktow odczytalby z sesji login i haslo zakodowane w md5 i sprawdzalby w bazie.
Ale przeciez moglby ktos podejrzec zaszyfrowane haslo a to wystarczyloby do pokazania niższych cen(bo skrypt by porownywal tylko zaszyfrowany login oraz haslo).
Myslalem tez aby za kazdym logowaniem do loginu i hasla dodawany byl ciag znakow, bylby to identyfikator sesji. Taka postac: md5($login.$haslo.$idsesji); Wtedy jak ktos by podejrzal to jakby chcial uzyc tych danych to otrzymalby inny idsesji i juz skrypt by go odrzucil.

Moze macie jakies inne pomysly, z góry dziękuje za pomoc!

Hasło zawsze dobrze jest trzymac w md5 a login nie koniecznie jak chcesz potem cos odszukac to 2 zmienna tez kodujesz w md5 i porownujesz tak jest najlepiej

php posiada wiele algorytmow szyfrujacych np MD5

http://www.php.net/manual/pl/function.md5.php

Jejku...

1) Wrzucanie hasła do sesji jest ZŁE. Po co?

2) Bez SSL nie da rady. Żadne kombinacje tego nie zmienią. Sam protokół SSL jest nie do złamania, cokolwiek być sam nie wymyślił - jest łatwe do złamania.

3) Hasło wypada, co ja piszę, należy trzymać w bazie zakodowane MD5 (lub SHA1, lub podobnym).

4) Przesyłanie hasła zakodowanego MD5 jest głupie. Nic to ci nie daje, poza spowolnieniem działania. Hakerowi na jedno wychodzi czy przechwyci plain text, czy MD5.

Witam
Zamiescilem to pytanie tez na inny forum.
Dostalem m.in. take odpowiedz:

Przecież między serwerem a userem przesyłany jest tylko identyfikator sesji. To nie są cookies, w których są wszystkie dane. Tu cookies jest wykorzystywane tylko (ew) do przesyłania identyfikatora. Hasło - owszem - w sesji miej zakodowane - ale to i tak nic nie zmienia - nikt kto nie ma dostepu do serwera nie pozna danych z sesji.

czy to prawda?

Powiem tylko jedno osoba, która to pisała jest ********,a nawet można zaryzykować stwierdzenie ********...
od It`s_me: (****** - są moje)
Lepiej nie ryzykować gdyż może sie to dla Ciebie źle skończyć. Przekazuję Tobie upomnienie. Proszę sobie zaoszczedzić tego typu nazewnictwo. Jeżeli chcesz przekazać swoje uwagi to w formie argumentów a nie epitetów.
Zalecam zapoznanie się lub przypomnienie sobie regulaminu

Cytat

1) Wrzucanie hasła do sesji jest ZŁE. Po co?

Zgadzam się ale gdy jest dobry haker to Ci nic nie pomoże [ ].

Cytat

2) Bez SSL nie da rady. Żadne kombinacje tego nie zmienią. Sam protokół SSL jest nie do złamania, cokolwiek być sam nie wymyślił - jest łatwe do złamania.

Wszysko jest do złamania. Widziałem tylko jeden bezwrunkowo bezpieczny algorytm, który generuje jako klucz dowlony ciąg znaków.
[Używali go na lini Rosja - Ameryka (Czerwona linia)]

Cytat

3) Hasło wypada, co ja piszę, należy trzymać w bazie zakodowane MD5 (lub SHA1, lub podobnym).

Tak należy to robic, i najlepiej kodowaniem tylko w jedną stronę. Ale jak mówiłem jeśli piszesz skrypt dla IBM lub jakieś wiekszej firmy to wymyśl coś lepszego . [b]Dla chcącego nic trudnego!
Żadna metoda nie jest 100% bezpieczna. My możemy zapewnić tylko aby nikt nie dostał sie przez nią do serwa . Ale dużo zależy od administratora. Dobrzy programiści [ja do nich nie nalaże (narazie :F)] mają własne sposoby.



Ale jeśli jest to mało doświadczony haker to go zaszachuje .
Najlepiej to jak najwięcej zabezpieczeń, które nie spóźniają aplikacji o wiecej niz ułamki sekund.
Chyba że bezpieczeństwo jest najważniejsze to wtedy sprawa się ma inaczej.

Jeśli się gdzieś pomysliłem jak chodzi o treść merytoryczną to prosze aby doświadczony użytkownik forum mnie solidnie sktytykował [tak abym wiecej nie rozpowiadał plotek]

Aha i należy wystrzegać sie dziur w aplikacji, bo one są wbrew pozorą najważniejsze.

Masz zamiar przechowywać numery kard kredytowych i inne ważne informacje. Jeśli tak to radze dużo spędzić czasu nad bezpieczeństwem.

Dziekuje za przeczytanie i pozdro

Ludzie..... Co tu się dzieje!!!!
Tak jak powiedział hawk: "Jejku... "

Dalczego na posty odpowiadają osoby, które nie mają pojęcia o temacie?

Sesja nie służy do przesyłania, tylko przechowywania pewnych informacji. Jest to mechanizm ogólnie powiedziawszy bezpieczny (tj. na tyle, na ile bezpieczne sa pliki na serwerze.
Dlatego prawdą jest stwierdenie 'tych ludzi z innego forum'

Problem tkwi jednak w przesyłaniu danych pomiędzy użytkownikiem, a serwerem. Własnie ten moment jest narażony na przechwycenie, i dlatego właśnie w wielu systemach z ssl korzysta się tylko 1 - właśnie do wysłania formularza logowania.

Nie prawdę jest też, że nie ma systemów kodowania nie do złamania. Są. Jest tylko jeden problem. Ich użyteczność.
Zasada jest jedna - dane koduje się tak, by przy aktualnym poziomie techniki było je trudno (niemożliwe) złamać. Jest to kompromis pomiędzy wygodą a bezpieczeństwem.
Nic jednak nie stoi na przeszkodzie by napisać algorytm używający zamiast np. 512 albo 1024 bitowych kluczy, klucza o długości 1 MB, albo nawet klucza o tej samej długości co przesyłana dana.
Jeśli będzie on wystarczająco losowy, o informacja tak zakodowania będzie nie możliwa do złamania.
Tylko niech ktoś wymyśli jakiś bezpieczny sposób przesyłania i przechowywania takich kluczy...


A co do przesyłania danych przepuszczonych przez MD5 w przeglądarce - nie ma to żadnego sensu.
Jeśli serwer będzie 'myślał' że własnie tak wygląda hasło, to taki haker po prostu podszyje się pod przeglądarkę, i wyśle taki pakiet, z dokładnie takimi danymi. Więc - nie ma dla niego znacznia, czy będzie to 6 literowe hasło, czy 32 znakowy hash.

ps ja nie napisalem ze haslo ma byc zaszyfrowane i przeslane. ja napisalem ze jest cos takiego jak md5 a moim zdaniem SLL to b dobre rozwiązanie

W zasadze to mam do dydpozycji ssl na serwerze tylko jak wpisze link w postaci https:// to pojawia sie komunikat przegladarki ze moj certyfikat nie jest zaufany, a to głupio wygląda.
W tym sklepie (taki internetowy sklep komputerowy) nie bedą przechowywane numer kart kredytowych.
Beda przechowywane w bazie danych informacje takie jak: profil uzytkownika(m.in. haslo do logowania), jego poprzednie zakupy i dane do wyslania paczki, klient bedzie placil listonoszwi przy odbieraniu paczki z zakupami. Klient po zalogowaniu bedzie mial troche nizsze ceny i dlatego chce w miare bepiecznie przesylac login i haslo.

Co mogłby jeszcze sprawdzac serwer aby zapezpieczyc sie przed tym?
Moze ma ktos jeszcze jakiś pomysł. Z góry dzieki za pomoc!

Dobrze, ze DeyV cos napisal od siebie, bo niektorzy probuja byc madrzejsi sami od siebie
Tak jak napisal - najwiekszy zgrzyt jest w momencie komunikacji user<->server<->user. Wlasnie dlatego polaczenia te sa szyfrowane (wtedy dane nie ida plain-textem).

Jesli masz problem z certyfikatem, to wez powiedz klientowi zeby juz takowy wykupil. Wtedy w testach bedziesz mial do dyspozycji pelne srodowisko.