Widzialem kilka aplikacji e-commerce, ktore bazuja na plikach *.txt i zastanawiam sie nad bezpieczenstwem takich danych.

Co myslicie o tym by tworzac takie aplikacje trzymac dane klienta, produktow, kategorii, zamowien nie w bazie danych tylko w plikach.

Jesli uwazacie, ze to mozliwe i akceptowalne to jakie macie propozycje na to by te dane byly przechowywane bezpiecznie?

Trzymac dane poza "public_html".
Hasla w md5 -> to wiadomo
Można tez z kozystac z klas bazy danych na plikach txt i trzymac odpowniedno zabezpieczona baze np przed "public_html" (np utworszys sobie kolo niego katalog baza i tam trzymac dane) albo jakis .htaccess

Moja rada jest następująca:

O ile to możliwe wszystkie tego typu aplikacje trzymaj w bazie o ile to możliwe i je hashuj tak jak napisał

Jeśli już korzystasz z plików txt jako bazy danych to staraj się trzymać tego typu dane poza www (chodzi o to by pliki były dostępne tylko wyłącznie dla serwera)

Jeśli chodzi o bezpieczeństwo to według swojego uznania. Ja przyjąłem taką taktykę że porównóję zawsze jakie user wysle do mnie dane typu przeglądarka, co akceptuje przeglądarka i jego ip (to zapobiegnie że jak ktoś dał komuś linka pełnego z id sesji a on będzie zalogowany to nie zobaczy prywatnych informacji, a prawdopodobieństwo że ktoś ma dokładnie takie same dane przeglądarki, co akceptuje jest moim zdaniem malutkie)

Jeśli chodzi o logowania to przyjąć taktykę że tylko jedna osoba może być w tym momencie na taki login zalogowana, i jak ktoś będzie próbował szperać to dawać mu ban-a na 1 godzinę.

To tyle jeśli chodzi o moje porady. Myślę, że one ci się przydadzą a ja natomiast przyjąłem powyżej wymienioną taktykę co do zabezpieczeń i jak na razie nie zdarzyło mi się aby tego typu prze ze mnie napisane skrypty miały jakie kolwiek problemy.

Wydaje mi sie, ze myslicie, ze zastanawiam sie nad tym by takie cos zrobic ... otoz nie.

Po prostu zastanawiam sie nad ta kwestia ...

Hwao napisal:
" Trzymac dane poza "public_html". "

no tak to dobry pomysl ... tyle, ze do takich plikow i tak latwiej dotrzec niz do bazy danych ... bo wystarczy dopasc login i haslo do ftp. oczywiscie wtedy haslo do bazy danych tez dopadnie ale to juz inna sprawa ... bo nie kazdy koniecznie moze umiec sie z ta baza polaczyc. w sumie to wielkie gdybanie ale jakos nie mam przekonania do tego ... z reguly uwazalem pliki za lepsze do trzymania danych w stylu: artykuly, dlugie newsy itd i tak robie ... ale trzymanie danych kontaktowych klienta, ktore nie powinny byc dostepne ot tak... co na to jakies prawo o ochronie danych osobowych?

Gdzies czytalem, ze dane osobowe klientow powinny byc trzymanie zaszyfrowanie lub dostepne za dodatkowym haslem (baza danych?)... ale tego juz za dobrze nie pamietam

No ja myślę. że tutaj to już kwestja jakie robisz loginy i hasła. Jedno jest pewne, że jak długie unikatowe hasło (kombinacja minimum ok 9 znaków z liczbami) to ciezko jest znależć odpowiednie hasło.

Jeśli chodzi o dane klienta to niestety ale zielonego pojęcia nie mam jak na to prawo reaguje i jakie są wymogi. Ja przynajmniej uważam że poza html public jest ciezko wyciągnąć takie dane.

Może dobrze by było trzymac baze na 2 koncie czyli innym niz strona wtedy znalezienie bezy jest duzo trudniejsze?

a moze wszystko "szyfrowac" np. base_64 (chocby dane klienta i teleadresowe) dla potencjalnego hackera-lammera-amatora to moze byc lekka przeszkoda, ktora moze zniecheci do dalszych dzialan? (a takich wiekszosc lubiacych sie bawic i mieszac z bezpieczenstwem danych/aplikacji)

bo jak trafimy na hackera-pro-advanced to i tak raczej sie przed nim nie obronimy nawet baza ... tyle, ze taki gosc musialby miec jakis konkretny cel ku temu (tak zakladam)

Wg mnie to tylko marmowanie zasobow- za kazdym odwierzeniem odkodowywanie to raczej nie to- a base_64 to raczej nie najlepiej koduje i jak ktos sie juz dobierze Ci do bazy danych to napewno bedziedzial jak jest zakodowana ( chocby po likkach ktorymi wysietlasz). Chyba najlepiej jest trzymac dane na innym koncie w takim razie i tam jakos je jeszcze dodtakowo zabezpieczyc

No nie przesadzaj ... wyobraz sobie plik users.txt
imie|nazwisko|haslo|email|ulica|kod|miasto|
i wszystkie te dane kodujesz w base64 (oprocz hasla, ktore robisz w np. md5).

Jak czesto musisz zerkac do tych danych po stronie klienckiej?
-> rzadko

Jak czesto musisz zerkac do tych danych po stronie admina?
-> czesto ... ale znow generujesz mniej ruchu po stronie administracyjnej...

a czemu nie trzymać danych w pliku php??
Przykłąd z sbase:
[php:1:1888580810]
<?php if( strstr( $_SERVER['PHP_SELF'], "users_structure.php" ) ) { exit("Brak dostepu"); } ?>
id;int;11;1;;
login;varchar;250;0;;
password;varchar;32;0;;
bazy;varchar;250;0;*;
[/php:1:1888580810]

Może i można, ale moim zdaniem prowadzenie dużego sklepu internetowego na plikach txt jest poranionym pomysłem.

hm, z drugiej strony po co kodowac baze... Ja bym dal mozliwosc wyboru, albo kodowac niektore pola, albo nie...
po co kodowac baze dla np: newsow ? jesli i tak ma byc dostepna dla wszystkich
a jesli chodzi o wazne dane, np: konta, to tez niektore pola bym kodowal... jesli na stornie uzytkownik ma dostep do np: imienia i nazwiska innych osob, to tych pol bym nie kodowal, a jesli np: hasla - md5, telefony - kodujemy, adres - kodujemy... podpowieedz do odzyskania hasla - kodujemy... wszystkie wazne dane kodujemy, a reszte olewamy bo i tak ludzie maja dostep do nich. Troche to skomplikuje stworzenie takiej bazy danych, ale cos napewno nam to da - troche szybsze wyciaganie danych.

Tylko, że jeżeli ty możesz to odkodować to ktoś inny mając te zakodowane dane też może je odkodować

hm no tak. ale np:


i plik z baza danych

wiec hasla nie masz ... hm... tzn masz ;] bo swoje ;p Ale jesli wymyslisz swoj algorytm unikalny, to troche zajmie to odkodowanie tych danych... a jesli sie da warunki z php na poczatek pliku takie jak przedstawil Bora, to nie dostaniesz sie do pliku z baza...

a jesli mowicie o loginie i hasle do ftpa, to chyba zawsze dobierzesz sie wtedy do danych ? wiec powinnismy sie skupic nad zabezpieczeniem plikow przed dostepem do nich, a nie przed sciagnieciem ich z konta ftp...

No tak, tylko trzeba wymyślić swój algorytm... Poza tym myślałem, że mówimy o base_64

To nie jest już kodowanie

To jest plik definiujący pola w bazie. Jeżeli chodzi o rekiordy to są one poprostu zapisywane :

Niedługo zostanie wypuszczona kolejna wersja.
Narazie jest zrobiona obsługa SELECT'a wraz z podstawową składnią mysql (LIMIT, WHERE).
[php:1:fc7cfa51c1]<?php
include_once('sbase.php');
sbase_connect('localhost', 'Bora', 'pass');
sbase_select_db('baza');
$query = sbase_query("SELECT id FROM small WHERE record = '3cc73' LIMIT 400,2");
while ($result = sbase_fetch_assoc($query)){
var_dump($result);
}
?>[/php:1:fc7cfa51c1]
Wracając do tematu. Chodziło o to że przechowując dane w plikach php i sprawdzając jak pli został wywołany można go bardzo dobrze zabezpieczyć.

Bora - ja to wiem, tylko ze w jednym polu w moim przykladzie w definicji podalem ;koduj; , a w innych bylo to ;; i akurat to pole w moim przykladzie wygladalo, oznacza to, ze to pole ma byc kodowane.

Masz racje
Pisząc ten projekt można bez problemu dorzucić kodowanie pól.
ps:
Jak wam sie podoba pokazany przykład??

bora juz od dawna zapisuje dane w plikach php ... (te wazne np. loginy i hasla) ... jednak to nie jest rozwiazanie ... ja mowie nie o gosciach, ktorzy wlamuja sie przez www ale przez np ftp a wtedy pliki php odczytasz bez problemu ... jak i caly kod

To z takimi gośćmi już gorzej.
Jedynie pozostaje kodować dane w plikach własnym algorytmem przy czym algorytm ten trzymać np na innym koncie albo zabezpieczony np przez zend coś tam (gdzieś było na forum), albo trzymac pliki na inym serwie. W tym przypadku nawet jak stosujesz baze mysql jak ktoś sie wbije na ftp to pozna całą baze. Przed tym nigdy się wystarczająco zabezpieczysz.

wlasnie, bo majac pliki z bazami danych mysql tez masz problem, bo gosc moze je spokojnie odczytac, wiec w ramach bezpieczenstwa, bedziesz wszystkie dane kodowal i dekodowal nawet w mysql ? absurd... to o czym ty mowisz, to juz chyba bezpieczenstwo serwera ? admin musi zadbac o to, zeby serwer byl tak zabezpieczony, zeby zaden uzytkownik nie mogl dostac sie do kont innych uzytkownikow, a uzytkownik musi pilnowac swojego hasla...

Znajdź sobie na necie klasę RC4 i szyfruj każde pole kodując jeszcze urlencode(), żeby nic się nie wysypało (kodowanie znaków, raz mi się przytrafiło).

no tak ale sam admin moze robic problem (nie slyszeliscie o roznego typu aferach - sabotaze/ukradzione dane )
patrz -> serwery wirutalne

oczywiscie juz przesadzam specjalnie ... ale po to by rozwinac dyskusje troszke odnosnie bezpieczenstwa samych danych... nie zawsze niebezpieczenstwo danych czycha tylko po stronie http

ace - nie przesadzaj i czytaj uwaznie co piszemy ... kodowanie zapewne byloby warte ale odnosnie danych klientow i zamowien bo to sa najwazniejsze i teoretycznie "super tajne" dane firm/instytucji/organizacji.
dane produktow/grup/slownikow nie wymagaja moim zdaniem specjalnego kodowania

byc moze warto zastosowac jakichs wlasny szyfrator i deszyfrator do takich danych nawet w bazie danych (tych najwazniejszych) i jesli jest mozliwosc to zakodowac go jeszcze zend encoderem lub turk mmcache.

wiecie ja od pewnego czasu mysle, ze w sumie admini moga sobie wszystko (glownie serwery wirtualne, serwery fizyczne a takich jest mnostwo patrz: kei.pl, home.pl itd itp). ty produkujesz aplikacje n-miesiecy/n-lat ... i nikt nie bedzie mial dostepu do niej oprocz ciebie i admina (roota) ?

treewod - czytam, i nie przesadzam... tak czy inaczej jesli ktos dostanie dostep do twojego ftp'a to ma twoje dane - jesli chodzi o pliki, z baza troche trudniej jest, bo trzeba miec konto ktore da nam dostep do jej plikow. I uwazam ze powinnismy skupic sie raczej na sposobem kodowania danych. Tak jak juz powiedzialem, kodowanie niektorych pol w bazie, zeby nie spowalniac niepotrzebnie skryptu, najlepiej wlasnym koderem, lecz nadal jest ten problem, ze jesli gosc wbije sie na twojego ftp'a to ma i twoje dane i skrypt ktory te dane dekoduje. Wiec chyba najlepszym rozwiazaniem jest trzymanie danych w innym miejscu. Sadze, ze nie da sie zabezpieczyc tych danych.

przyklad :
1) hakier wchodzi na ftp'a sciaga dane, nie ma baz danych w plikach, nie ma odwolan do mysql, wiec szuka w kodzie. Jesli sie zna, to nic to nie da ze pliki sa w innym miejscu, bo moze napisac prosty skrypcik ktory otworzy tamten plik z baza ktory jest w innym miejscu i skopiuje go do swojego katalogu na tym koncie ftp' a potem to juz tylko kopiowanie na twardziela. I ma wszystko - skrypt dekodujacy te dane, te dane - wyszarczy napisac funkcje ktora zdekoduje baze i ma juz baze w 100%... nie liczac elementow zakodowanych w md5()...

sadze ze po pierwsze trzeba stworzyc takie haslo, zeby nie bylo zbyt banalne do odszyfrowania, unikalne. Wiele ludzi uzywa 1 hasla do kilku kont/uslug... co jest bledem. To sa podstawy, ktore w znacznym juz stopniu zabezpiecza twoje konto...

a i 2 sprawa... Na forum byla poruszana kwestia plikow textowych vs mysql. Poszukaj. W skrocie, do duzych projektow pliki txt nie nadaja sie, bo sa zbyt wolne.

pozdrawiam

Ace napisal:
" to ma i twoje dane i skrypt ktory te dane dekoduje."

No ale zapomniales, ze taki dekoder twojego autorstwa mozesz jeszcze zakodowac turck mmcache, zend encoder itp. i nie dosc, ze daje to lepsze efekty (szybkosc) to jeszcze nie jest widoczne dla kogos kto ma dostep do twojego ftp'a

"Na forum byla poruszana kwestia plikow textowych vs mysql."
Jakbys poszukal dobrze, to bys znalazl moj temat sprzed roku na temat porownania plikow i mysql

moze nawet o nim mowie

ja powiem, ze wole ogolnie pliki choc wlasnie do e-commerce mam mieszane uczucia z ich zastosowaniem ...

np. www.forum.ox.pl dziala i posiada juz ponad 1000 tematow a smiga na plikach (baza plikowa zajmuje 4MB - to nie tak malo ...). oczywiscie pliki ograniczaja i nie wyobrazalbym sobie jakiegos skomplikowanego algorytmu sortowania itd (babelkowe, wstawianie, przestawienie, quick sort itd) ale jednak mysle, ze po dluzszej dyskusji i rozmowie moge dojsc do wniosku iz spokojnie PROSTY sklep www mozna zrobic pod warunkiem:

- kodowania danych kontaktowych do pliku np. wlasnym algorytmem
- wlasny algorytm bylby zakodowany innym popularnym koderem np. zend encoder czy turck mmcache (nie mam zadnego zaufania do administratorow i to wlasnie od nich balbym sie "ukradniecia" kodu)
- przechowywania danych w pliku php lub poza kontem ( z tym czasem gorzej) lub poza public_html

plusy by byly takie iz:

+ nie zliczalby sie transfer (ograniczenia transferu np. na miesiac dla konta) poniewaz nie byloby zapytan miedzy baza danych a serwerem www a trzeba pamietac, ze na wielu serwerach taka opcja istnieje - liczy sie optymalizacja
+ system backup'u bylby troche prostrzy (sprawa wzgledna)
+ wymagania aplikacji bylyby generalnie mniejsze (bez sql'a)

no minusy to coz:

- niestety ograniczenia w sortowaniu, operacjach na np. produktach
- wieksza koncentracja na bezpieczenstwie np. kodowanie (sprawa wzgledna - to moze uczyc dobrych nawykow mnie pliki nauczyly paru dobrych nawykow, ktorych nie nauczylbym sie na bazach danych, ktore naprawde rozpieszczaja)
- mniejsze mozliwosc rozbudowy (tez sprawa wzgledna)
- turck, zend czy inne dekodery bylyby wymagane :/ jesli zalezy nam na bezpieczenstwie danych kontaktowych

Nie jestem pewien, ale chyba jak zmienisz hasło (np. w cPanelu) do swojego konta to wątpie, żeby admin je znał...

czyli root bez mozliwosci zagladania do kont userow? wierzyc sie nie chce