[PHP-MySQL] a właściwie ogólnie - hasła w aplikacjach klient-serwer

	B O A R D
	» Board » Zadaj pytanie » Archiwum » Szukaj » Stylizacja

M E N U

» Nowości

» Archiwum

» Recenzje / Testy

» Board

» Rejestracja

Szukaj @ TwojePC

	OBECNI NA TPC
	» Lukas12p 23:36 » ReeX 23:35 » Flo 23:34 » Kool@ 23:24 » Shark20 23:21 » dugi 23:20 » rulezDC 23:13 » Qjanusz 23:13 » Wojtekar 22:48 » Wedrowiec 22:42 » Conan Bar 22:41 » DYD 22:39 » Pawiano 22:38 » Wedelek 22:29 » rbxxxx 22:25 » stefan_nu 22:22 » Curro 22:20 » Holyboy 22:17 » fiskomp 22:10 » DJopek 22:10 Dzisiaj przeczytano 41139 postów, wczoraj 25974 Szybkie ładowanie jest: włączone.

ccc

A R C H I W A L N A W I A D O M O Ś Ć

[PHP-MySQL] a właściwie ogólnie - hasła w aplikacjach klient-serwer , bwana 30/09/08 15:32
Sprawa niby oczywista - w aplikacji klient-serwer (powiedzmy jest to strona www) trzeba utrzymać konta użytkowników z, wiadomo, hasłami. Zakładam, że serwer jest bezpieczny, klient też, a połączenie jest "publiczne" czyli nieszyfrowane i, w skrócie, wychodzące poza DMZ. Oznacza to, że hasło w postaci niezakodowanej z klienta do serwera nie powinno być wysyłane. W zakodowanej też nie, na dobrą sprawę, bo spreparowanie ramki http z wstawionym (uprzednio przechwyconym) zakodowanym hasłem nie będzie raczej trudne dla hakiera.

Załóżmy, że po stronie serwera mam zapamiętany login i hasło, przy czym hasło jest zakodowane jakąś funkcją skrótu (md5, sha, ...). Teraz - jeżeli przez publiczną sieć wysłany zostanie z klienta formularz z loginem i hasłem (hasło zakodowane albo nie, nie ma znaczenia) to po przechwyceniu go, potencjalny haker ma albo hasło (z którego hash jest porównywany z tym co zapisane po stronie serwera), albo hash hasła, jeśli na kliencie wykonany został hash przed wysłaniem. Tak czy siak, choć hakier hasła nawet nie pozna (pozna tylko jego hash) to i tak nadal będzie mógł się w sposób nieautoryzowany zalogować.

Jakie są praktyki unikania tego rodzaju ryzyka? Myślałem o dodaniu jakiegoś tokena do hasła, znanego i klientowi i serwerowi i zmiennego w czasie - na przykład daty i godziny, przy czym serwer powinien uwzględnić strefę czasową klienta, rzecz jasna. Ale to nadal może okazać się trudne i niewystarczające z kilku powodów:

- konieczność wykonania hasha po stronie klienta (czyli przez przeglądarkę lub osobny problem)
- pozostająca możliwość zalogowania się na to samo zatokenowane hasło (powiedzmy, token jest z dokładnością do 10 sekund) jeżeli przechwycimy czyjś formularz (jeśli nawet serwer nie pozwoli na ponowne zalogowanie z tym samym tokenem co poprzednio, to przecież formularz można przechwycić i do tego nie dopuścić do jego dotarcia do celu).

No to jak to zrobić z sensem i bezpiecznie?

"you don't need your smile when I cut
your throat"

errata - osobny problem -> osobny program , bwana 30/09/08 15:34
i oczywiście przy założeniu, że nie używamy https (napisałem wprawdzie, że łącze jest "publiczne", ale może warto napisać wprost, że bez https:))
"you don't need your smile when I cut
your throat"
one time pad , Grocal 30/09/08 15:46
Jedynym racjonalnym rozwiazaniem sa hasla jednorazowe. Dla hasel stalych lub rotowanych czasowo (wymuszanie zmiany hasla) lepiej stosowac bezpieczne protokoly jak wspomniany przez Ciebie SSL (https).

Pierwsza zasada jaka sie czlowiek uczy na kryptografii - nie ma systemow nie do przejscia :)
Na pewno, na razie, w ogóle...
Naprawdę, naprzeciwko, stąd...
Ortografia nie gryzie!
1. jeśli chodzi o hasła jednorazowe, to zachodzi konieczność ich dystrybucji innym kanałem , bwana 30/09/08 16:07
  (tak jak np. zdrapki Inteligo - dostaje się je pocztą). Rozwiązanie ze sprzętowym tokenem też wymaga dystrybucji, ale jednokrotnej co jest pewnie mniej kłopotliwe. Ale też w zasadzie bez szyfrowanego połączenia może zostać złamane w opisany wyżej sposób, tzn. przejęcie formularza logowania, ubicie go, skorzystanie z jego kopii we własnej sesji (we własnej przeglądarce www). Hmmm, zastanawiam się, czy na to w ogóle jest sposób (tj. na uchronienie się przed tym w sytuacji, gdy transmisja nie jest szyfrowana)?
  "you don't need your smile when I cut
  your throat"
  1. i znów errata - dystrybucji -> dystrybuowania , bwana 30/09/08 16:09
    ;-)
    "you don't need your smile when I cut
    your throat"
Problem nie ma rozwiazania , pachura 30/09/08 17:08
Zawsze musisz zalozyc istnienie bezpiecznego kanalu (hasla jednorazowe, tokeny, instytucja przechowujaca certyfikaty SSL). Niewazne jak bys kodowal po stronie klienta, man-in-the-middle moze zawsze wszystko przechwycic i dzialac jak proxy miedzy Toba a serwerem... co z tego ze do tokena dokleisz przehaszowany czas, skoro operacja haszowania bedzie musiala byc przeprowadzana w JavaScripcie, w zwiazku z czym algorytm bedzie powszechnie dostepny?

A w praktyce to https:// i tyle.
ekhm , john565 30/09/08 17:14
wszytko bez https jest do złamania prędzej czy później, ale co bym ja zrobił
- wraz z formularzem logowania wysyłał bym dwuczłonowy string, niech on będzie nazwany swego rodzaju hashem

ten hash zawierałby dwie nierozdzielone niczym części jedna część sterująca kodowanie, 2 część będą to śmieci w których zostanie umieszczone jakoś javascriptowo hasło według części sterującej kodowaniem, dodatkowo kilka wersji skryptów ktore będa kodowały hasło przed wysłaniem, dołaczanych do formularza logowania losowo i inaczej interpretujących instrukcje z pierwszej części hasha

Oczywiście w tej pierwszej części będzie musiał zawierać identyfikacjie skryptu losowo przydzielonego do formularza, ale tu po stornie serwera mozna co jakiś czas wrzucac skrypty pod inne numery

troche zkręciłem, ale czy coś takiego by cie satysfakcjonowało? bo wsumie wysyłany w te i spowrotem jest tylko ten specyficzny hash i java script, ale jakby go zobfuskowac?
f*ck
1. No ale... , pachura 30/09/08 17:20
  ...ma to znikomy sens skoro potencjalny haker ma dostep do zrodla(zrodel) Twojej strony, tzn. widzi jak na dloni wszystkie te javascriptowe obfuscatory. Chroni to co najwyzej przed jakimis genericowymi snifferami ktore wylapuja pakiety/ramki z "password=blabla" w srodku, ale jesli ktos zdecyduje zaatakowac konkretnie Twoja strone, nie ma to sensu.
  1. niekoniecznie , john565 30/09/08 18:47
    mozna zrobić masę kombinacji i znacznie utrudnić wszelkie przechwytywanie, wszystko zalezy od wyobraźni programisty
    f*ck
najlepiej , recydywista 30/09/08 17:24
w ogóle nie wysyłać hasła, patrz Kerberos http://en.wikipedia.org/wiki/Kerberos_(protocol)
Computers are useless. They can only
give you
answers.
1. To samo , pachura 30/09/08 17:41
  Podatny na man-in-the-middle attacks, wymaga istnienia Key Distribution Center.
  1. nie do końca ;) , recydywista 30/09/08 18:11
    http://books.google.com/...;pg=PA108&lpg=PA108
    Ale fakt, jest trochę użerania się z infrastrukturą dla kerberosa. W nagrodę dostajesz naprawdę solidne zabezpieczenie.
    Computers are useless. They can only
    give you
    answers.
no to może , Magnus 30/09/08 18:32
połowiczne rozwiązanie typu podaj 1 5 8 litere hasła. Za kazdym razem inną losową.
Plus tego taki że haker nie bedzie mial całego hasła (przynajmniej od razu bo podłuchując kilka logowań pewnie będzie się dało skompletowa całe) a każde kolejne logowanie będzie wymagało podania innego zestawu znaków.

Jes to raczej utrudnienie niż rozwiązanie ale zawsze coś.
Albo znajdz algorytm w JavaScript co po stronie klienta Ci... , Kilgor-Admin 30/09/08 18:58
... zakoduje haslo do md5 czy sha1 i przesylaj hash tylko przy logowaniu.
Pozdr. Kilgor
Admin Board'a
1. haxor wyciagnie hasha i będzie rządził , john565 30/09/08 19:52
  123
  f*ck