bezpieczne hasla w plikach konfiguracyjnych Opcje

[art]

Witam!

Administrator pewnego serwera zwrocil mi uwage iż w moim skrypcie haslo sluzace do polaczenia z bazą danych mySQL znajdujące się w pliku config.inc.php nie jest zaszyfrowane i ze taka sytuacja jest niedopuszczalna...

tak więc mam plik config.inc.php a w nim przykładowo:

[PHP] pobierz, plaintext 
<?php
// server bazy danych z ktorym ma sie łączyć skrypt
// (najczęsciej localhost)
$db_hostname='localhost';
 
// nazwa bazy danych
$db_name='nazwabazy';
 
// login do bazy danych
$db_username='login';
 
// haslo do bazy danych
$db_password='haslo123';
?>
[PHP] pobierz, plaintext 

Podobno zamiast 'haslo123' powinienem w to miejsce wstawic to haslo w formie zakodowanej tak aby osoba przegladajaca pliki na serwerze (np. admin lub 'włamywacz') tego hasla nie zobaczyli...

pierwszy raz sie z czyms takim spotykam i szczerze mowiać zgłupiałem... czy ktoś wie czy wogole coś takiego da sie zrobic ? jesli tak to w jaki sposob?

[w3b]

ja bym Ci radzil zrobic cos takiego

1. Tworzysz sobie plik conf.db, a w nim:

Kod

SetEnv USER "your user login"
SetEnv PASS "you password"

2. Ustawiasz chmod 600 conf.db
3. W pliku php includujesz ten pliczek np,;

[PHP] pobierz, plaintext 
<?php
include('includes/conf.db')
?>
[PHP] pobierz, plaintext 

4.i teraz robisz cos takiego:

[PHP] pobierz, plaintext 
<?php
$login = $_SERVER['USER'];
$pass = $_SERVER['PASS'];
?>
[PHP] pobierz, plaintext 

i tez masz bezpiecznie

Pozdrawiam

[kszychu]

3. W pliku php includujesz ten pliczek np,;

i pupa zbita, bo apache nie ma prawa do odczytu tego pliku.
@art: nie jest to może najbezpieczniejsze, ale inaczej się nie da. Oczywiście możesz napisać funkcje kodującą i dekodującą i używać kodowanego hasła, ale jak ktoś obejrzy zawartość pliku konfiguracyjnego, to obejrzy też inne pliki i znajdzie funkcję dekodującą.
Zahaszować hasła niestety nie można.

[w3b]

Racja z rozpedu sie pomylilem zeby odwolac sie do $_SERVER['USER'], nalezy includowac ten plik w httpd.conf , zwracam honor

[art]

@art: nie jest to może najbezpieczniejsze, ale inaczej się nie da. Oczywiście możesz napisać funkcje kodującą i dekodującą i używać kodowanego hasła, ale jak ktoś obejrzy zawartość pliku konfiguracyjnego, to obejrzy też inne pliki i znajdzie funkcję dekodującą.
Zahaszować hasła niestety nie można.

Dzieki serdeczne... pisanie wlasnej fuknkcji do kodowania/dekodowania faktycznie sensu nie ma... ja ogolnie nie rozumie czemu administrator sie czepil z tego ci widzialem wiekszosc skryptow php przechowuje w ten sposb (w takim config.inc.php jak moj) haslo bez zadnego dodatkowego kodowania...

poradzil mi wygenerowanie hasla w md5 no ale przeciez nie ma funkcji dekodujacej md5 (bo musialbym za kazdym razem zakodowane haslo przed zadaniem zapytania bazie dekodować)

i tak sie zastanawiam czy jestem jakis głupi czy moze ktoś tu głupka ze mnie chce zrobic ...

czy takie przechowywanie hasla do bazy w pliku config.inc.php jest az tak niebezpieczne zeby robic wielki szum w tej sprawie?

[kszychu]

poradzil mi wygenerowanie hasla w md5 no ale przeciez nie ma funkcji dekodujacej md5 (bo musialbym za kazdym razem zakodowane haslo przed zadaniem zapytania bazie dekodować)

i tak sie zastanawiam czy jestem jakis głupi czy moze ktoś tu głupka ze mnie chce zrobic ...

W tym przypadku to drugie, niestety. md5 jest algorytmem haszującym a nie kodującym i nie ma możliwości odtworzenia pierwotnego tekstu potraktowanego md5. I uprzedzam, proszę mnie nie łapać za słówka i nie pisać o kolizjach, nie mają one tutaj zastosowania.

czy takie przechowywanie hasla do bazy w pliku config.inc.php jest az tak niebezpieczne zeby robic wielki szum w tej sprawie?

Ważne jest, by hasła były w pliku config.inc.php a nie w config.inc.innerozszerzenie. W tym pierwszym przypadku nawet jawne wywołanie tego pliku w przeglądarce skończy się zwróceniem przez apache pustej strony, w drugim zostałby zwrócony cały kod php.

[art]

No cóż dziekuje serdecznie za wyczerpujace wyjaśnienia, jako że nigdy nie zakładam z góry że wszystko wiem najlepiej, przed przystapieniem do polemiki z wspomnianym administratorem wolałem się upewnić co do słuszności moich przekonań w tym temacie ...