[php] Ukrywanie hasla

0

Wiem, ze zapewne ten temat byl juz poruszany na forum, ale mam pytanie: jak w php ukryc hasla, czy jakiekolwiek inne dane? Bo np. jesli zapisze je w jakims pliku, to i tak kazdy moze znalezc nazwe tego pliku w zrodlowce i go pozniej odczytac. Jesli uzyje mysql, to musze podac uzytkownika i haslo, wiec kazdy je moze widziec i sie pozniej wlamac. Szukam tego od wczoraj, ale nic co mnie interesuje jescze nie znalazlem.

0

Co do pierwszego to skorzystaj z jakiegoś hashowania (md5) i po prostu porównuj hashe.

0

A jesli chodzi o dostep do zrodel, to do zrodel php ma dostep tylko ten co ma dostep do ftp. Co do hasel do mysql'a to wrzuc taki plik z haslem do jakiegos katalogu i daj prawa typu 700, albo po prostu wrzuc do katalogu nadrzednego w stosunku do public_html i po klopocie. Skrypt sobie plik przeczyta (bo wykonuje sie z prawami wlasciciela zazwyczaj) i nikt wiecej.

pozdrawiam
johny

0
johny_bravo napisał(a)

A jesli chodzi o dostep do zrodel, to do zrodel php ma dostep tylko ten co ma dostep do ftp. Co do hasel do mysql'a to wrzuc taki plik z haslem do jakiegos katalogu i daj prawa typu 700, albo po prostu wrzuc do katalogu nadrzednego w stosunku do public_html i po klopocie. Skrypt sobie plik przeczyta (bo wykonuje sie z prawami wlasciciela zazwyczaj) i nikt wiecej.

pozdrawiam
johny

Nie zawsze masz dostęp powyżej public_html. ja to robie inaczej:

  • Tworze katalog conf
  • do niego wrzucam wszystkie pliki konfiguracyjne
  • w tym katalogu conf tworzę plik .htaccess o zawartości:
Order Deny,Allow
Deny from All
Allow from localhost

Dostęp do katalogu skrypt będzie miał (jak pisał johny_bravo skrypt jest wykonywany lokalnie) i poprzez ftp'ka będzie dostęp a po wpisaniu adresu http://www.example.com/conf/ będzie piękny błąd 403, tak samo jeśli wpiszesz nazwę jakiegokolwiek plik z katalogu conf. Proste i skuteczne...

0

Fakt, nie zawsze jest dostep powyzej. Ale mam takie 'gdybajace' pytanie: czy w przypadku allow from localhost jest mozliwe, ze ktos majacy konto na tym samym serwerze dostanie sie do takiego katalogu? Pytam, bo tez by mi sie taki sposob przydal, a wolalbym dla pewnosci wiedziec :)

pozdrawiam
johny

0

Allow from localhost jest zbędne, to są regułki dla serwera http i jego klientów, php korzysta z plików normalnie poprzez system plików i je*** go to czy w/g regułek jakiegoś innego programu może to sobie robić czy nie, nie jego działka - czy ty chcąc się pobawić w piaskownicy idziesz spytać o pozwolenie sąsiada ?

tak, osoba mająca konto na tym samym koncie może uzyskać dostęp, wszystko zależy od wiedzy administratora i ustawień serwera, jednak dopisanie w .htaccess "allow from localhost" to ułatwia

0

Dzięki wszystkim za odpowiedzi, naprawdę dzięki. Nie spodziewałem się, że ktokolwiek odpowie, myślałem, że powiecie, że to już było. Dzieki, bardzo pomocne.

0

inna sprawa, ze mozna dodawac hasla do pliku o rozszerzeniu .php i w pierwszej linii dawac <? exit; ?>. Nastpena linia bedzie na dane.

0
maniek_2 napisał(a)

...

I dokładnie takie wyjście polecam - tylko nie w zamian, ale oprócz - rozwiązanie uniwersalne nie uzależnione od serwera (w sensie dla każdego ze skonfigurowanym php), oczywiście dla danych które masz zapisane plain, jak już coś jest w zmiennej to można zostawić dane a na górze np ew jeszcze dopisać
if(!defined('costam zdefiniowane w skrypcie ktory moze z tego skorzystac')) Die();
co jest w większości przypadków zamiennikiem
if(FILE != $_SERVER['PATH_TRANSLATED']) Die();
co by akurat u mnie nie działało a trzebaby tak:
if(realpath(FILE) != $_SERVER['PATH_TRANSLATED']) Die();

tym bardziej że ukryty np plik .htaccess może się czasem przypadkowo zagubić przy np przenosinach

0
Adamo napisał(a)

tak, osoba mająca konto na tym samym koncie może uzyskać dostęp, wszystko zależy od wiedzy administratora i ustawień serwera, jednak dopisanie w .htaccess "allow from localhost" to ułatwia

jeśli może uzyskać dostęp to admin jest dupa (bez obrazy) i dał ciała przy konfiguracji systemu. User nie powinien mieć prawa wyjścia poza własny katalog (jeśli mowa o FTP, jeśli o SSH to nie powinien mieć prawa dostępu do katalogów innych userów) w /home/<user_name>, przynajmniej taka jest podstawowa polityka bezpieczeństwa.

Adamo napisał(a)

Allow from localhost jest zbędne, to są regułki dla serwera http i jego klientów, php korzysta z plików normalnie poprzez system plików i je*** go to czy w/g regułek jakiegoś innego programu może to sobie robić czy nie, nie jego działka - czy ty chcąc się pobawić w piaskownicy idziesz spytać o pozwolenie sąsiada ?

A co będzie jak się apache skaszani (czy inny serwer) i zamiast poprzez php wykonywać skrypty będzie je po prostu wyświetlał. Miałem taki przypadek na komercyjnym serwerze, że wprowadzili jakąs poprawkę i admin coś źle wpisał (admin też człowiek i się myli...) i skrypty php nie były interpretowane tylko wyświetlane. Co prawda awaria zostałą usunięta po chwili ale jednak...

Dlatego IMHO dostęp do plików konfiguracyjnych powinien być tylko i wyłącznie lokalnie. A jeśli coś trzeba zmienić to albo poprzez skrypty jeśli się da, a jeśli nie (widocznie poważniejsza interwencja) to via FTP lub SSH. Ale to tylko moje zdanie i moj sposób, który się sprawdza dla moich potrzeb...

==========================================
Dopisane

Adamo napisał(a)

[...]if(FILE != $_SERVER['PATH_TRANSLATED']) Die();
co by akurat u mnie nie działało a trzebaby tak:
if(realpath(FILE) != $_SERVER['PATH_TRANSLATED']) Die();

tym bardziej że ukryty np plik .htaccess może się czasem przypadkowo zagubić przy np przenosinach</quote>
No fakt może "się zagubić" ale co za problem stworzyć go od nowa. Zgodze się także z tym

if(!defined('costam zdefiniowane w skrypcie ktory moze z tego skorzystac')) Die();

bo to dopełnie bezpieczeństwo ale co będzie w sytuacji wspomnianej wyżej gdy php nie jest interpretowane ? Wtedy ten .htaccess jest dodatkowym zabezpieczeniem...

0
angel2953 napisał(a)

A co będzie jak się apache skaszani (czy inny serwer) i zamiast poprzez php wykonywać skrypty będzie je po prostu wyświetlał. Miałem taki przypadek na komercyjnym serwerze, że wprowadzili jakąs poprawkę i admin coś źle wpisał (admin też człowiek i się myli...) i skrypty php nie były interpretowane tylko wyświetlane. Co prawda awaria zostałą usunięta po chwili ale jednak...

no tak, dlatego jeszcze warto wyczić jak to jest z grupami porobione na serwie i właściwe chmody ustawić, jak się apache skaszani to już w ogóle nic nie będzie brało pod uwagę tych regułek w .htaccess
jeśli skrypty php się wyświetlają normalnie podczas awarii to admin dopiero jest dupa - powinien się wyświetlić błąd 5xx typu Internal Server Error
ja miałem konto na serwerze gdzie niby nie mogę się dostać do plików innych userów w żaden sposób ale wystarczyło zrobić dowiązanie symboliczne do cudzego foldera żeby php miał full dostęp :|

dlatego:

  1. odpowiednia konfiguracja serwera (zazwyczaj niezależne od nas)
  2. plik .htaccess
  3. pliki w formacie *.php
  4. odpowiednie chmody
0

Ad.3. Pliki w formacie php i z długimi tagami, tzn. <?php zamiast <? - coraz częściej odchodzi się od wsparcia dla tych drugich, a te pierwsze działają od zawsze i na zawsze (tzn. taki jest standard w PHP).

jeśli skrypty php się wyświetlają normalnie podczas awarii to admin dopiero jest dupa - powinien się wyświetlić błąd 5xx typu Internal Server Error
Ale to nie musi być BŁĄD w konfiguracji. Przykładowo wyłączenie krótkich tagów dla PHP spowoduje, że 80% skryptów się wyświetli, zamiast wykonać, podczas gdy z formalnego punktu widzenia wszystko jest OK (te 80% to strzeliłem, łażąc po różnych miejscach widuję ogromną przewagę w popularności short-tagów).

0
Adam.Pilorz napisał(a)

Przykładowo wyłączenie krótkich tagów dla PHP spowoduje, że 80% skryptów się wyświetli, zamiast wykonać, podczas gdy z formalnego punktu widzenia wszystko jest OK (te 80% to strzeliłem, łażąc po różnych miejscach widuję ogromną przewagę w popularności short-tagów).

no to jest błąd praktycznie tego co pisze skrypty ale mówię o całkowitej awarii php
btw jak widzę w jakimś skrypcie <? to automatycznie przeprawiam na <?php i nie dlatego że odchodzi wsparcie czy bla bla bla tylko mnie to po prostu wkurza ;P

0

Bo to jest wkurzające. Zwłaszcza gdy tworzysz dokumenty XML i PHP chce sparsować <?xml version="1.0"?> ;)

0

Co do błędu, że można będzie zobaczyc zawartość pliku z hasłem php. Takie hasło powinno sie hashować dodatkowo. Inna sprawa, że w takim przypadku mozna obejrzeć całe źródła php strony, więc nie sądze aby to było możliwe (można podpatrzeć hasła do logowania się do bazy, dziury w kodzie, które póxniej mozna wykorzystać jak serwer czy php powstanie).

0

Nie mozesz hashowac dodatkowo, bo przeciez potrzebujesz go w formie niezakodowanej

0

A po co? Jeżeli wchodzisz na hasło to wpisując w formularz, skrypt hashuje go i dalej porównuje z hashem w pliku. Odzyskiwanie haseł to po prostu nadanie nowego (z losowych ciagów niepowtarzalnych), który później gdzieś tam (jak system na to pozwala) mozna zmienić.

0

Mi chodzi o haslo do bazy np. jest jakie jest i musi byc wpisane w formie oryginalnej, a nie haszowane...

0

Ktos predzej napisal, zeby nadac prawa do pliku 700. Otoz mam pewien plik, ktory zostaje otwierany przez skrypt php. Wszystko dziala, gdy mam na 666, ale po zmianie na 700 wyskakuje:

Warning: fopen(licznik.tt) [function.fopen]: failed to open stream: Permission denied
. Plik znajduje sie w tym samym katalogu, co strona zawierajaca skrypt php. W czym moze byc problem?

0

Prawdopodobnie wlascicielem pliku jest ktos inny niz ten, z czyimi prawami uruchamiany jest plik php. Sprobuj stworzyc ten plik przez php i wtedy zmieniac jego zawartosc, to powinno byc w porzadku.

0
johny_bravo napisał(a)

Mi chodzi o haslo do bazy np. jest jakie jest i musi byc wpisane w formie oryginalnej, a nie haszowane...

W takim razie nie zorumiałeś co napisałem. Chodziło mi o hashowanie haseł w pliku o którym jest mowa. O hasłach do bazy to wspomniałem dodatkowo, że jeżeli po awarii mozna zobaczyć źródła takiego pliku to równocześnie mozna zobaczyć źródła całego stworzonego systemu, gdzie mogą wystepować połączenia do bazy. Nigdzie nie wspomnaiłem, że hashuje hasła do bazy.

0

No chyba, że autor przechowuje hasła tak do bazy? No to nie hashujemy.

0

A ja mam taki sposób, że do pliku php z hasłami wpisuję po prostu w pierwszej linii:

<? exit(); ?>

W ten sposób zawsze wyświetli się pusta strona.

0

Ta sama kwestia, co była wcześniej - nie zawsze, tylko jak działa PHP. Mało tego, tylko wtedy, gdy ma dozwolone krótkie tagi.

0
<?php exit(); ?>

Działanie to samo... a krótkie tagi są teraz na każdym darmowym hostingu i domyślnie skonfigurowanym php.ini

0

Ale nie mniej jednak - gdy php przestanie dzialać, a źle zabezpieczony serwer wyśle kod skryptu o użytkownika, to to "zabezpieczenie" się na nic nie zda.

To samo Adam próbuje powiedzieć.

0

No fakt, przeciwko temu nie mam argumentów... a najprostszy sposób na zabezpieczenie danych to zaszyfrowanie ich własnym algorytmem...

1 użytkowników online, w tym zalogowanych: 0, gości: 1