Bezpieczne przechowywanie klucza Opcje

[Cliassi]

Witam, czy macie jakieś pomysły gdzie można trzymać klucz do odszyfrowania danych w bazie ? tak aby nie był w formie jawnej w skrypcie bo to prawie bez sensu

[Sephirus]

Robiłem kiedyś coś takiego gdzie klucz musiał być podawany przy logowaniu - w formie wrzucania pliku z kluczem - klucz ten po odebraniu był przez pewien algorytm dzielony na dwie części z czego jedna zapisywana była w sesji (strona serwera) a druga w cookie (strona klienta) - w ten sposób ani z serwera ani z kompa użytkownika nie dało się tego klucza odzyskać bez dostępu do obu sprzętów Przy odwoływaniu się do zaszyfrowanych danych klucz był składany w skrypcie i używany (na bieżąco - nigdzie cały nie zapisywany).

Ot taki przykład

EDIT - Źle napisałem - to miało dziury potem to zmieniliśmy tak, że na serwerze na stałe była połówka klucza a druga połówka jako plik była wrzucana przy logowaniu i przechowywana w sesji - jakoś tak - mam nadzieję, że Cię nakieruje na jakiś pomysł. Grunt aby cały klucz nie był zapisywany ani na serwerze ani na kompie użytkownika.

Ten post edytował Sephirus 20.09.2012, 08:30:24

[vermis]

A do czego chesz to wykorzystać? Bo w zasadzie w komunikacji bierze udział klient i serwer, więc możesz zapisać klucz tylko na kliencie, serwerze lub kliencie i serwerze. Nalepsze jest 3 rozwiązanie na zasadzie klucza publicznego i prywatnego, ale w tym wypadku klient musi znać klucz publiczny. Do odszyfrowania niezbędne są oba klucze.

[Cliassi]

Chodzi o to że podczas włamania klucz nie był w formie jawnej w skrypcie. Pomysł z połówkami klucza nie jest głupi. Ale w jakim formacie to zapisywałeś(plik) txt ?

I to rozwiązanie jest dobre gdy chcemy odczytać dane a co jak chciałbym rejestrować userow i ich mail zaszyfrować ? wtedy klucz gdzie najlepiej miec ?

[CuteOne]

Hmmm dziwne podejście.. zamiast myśleć jak zapobiec włamaniu myślisz jak zabezpieczyć dane gdy do niego dojdzie. Zauważ, że nikt tego nie robi po co szyfrować email, login czy adres? Lepiej spożytkuj czas na czytaniu o zabezpieczeniach serwisu - lepiej na tym wyjdziesz

[Cliassi]

no ale zawsze lepiej miec zabezpieczony i system i klucz prawda ?

Ten post edytował Cliassi 20.09.2012, 20:39:08

[r4xz]

no ale zawsze lepiej miec zabezpieczony i system i klucz prawda ?

a portfel wkładasz do sejfu i wtedy z nim chodzisz czy tylko uważasz, aby nikt Ci go nie ukradł?
tak jak CuteOne powiedział, nie ma sensu zabezpieczać wszystkiego (tzn. szyfrować wszystkie dane)

[redeemer]

Podzielam zdanie @r4xz oraz @CuteOne. Jak ktoś Ci się włamie na serwer to będzie mógł zrobić wszystko co będzie chciał. Zresztą, nawet nie napisałeś jakie dane chcesz szyfrować w bazie.

[Cliassi]

adresy email

[CuteOne]

Widzisz nawet w bankach dane klientów czy numery kart kredytowych nie są w żaden sposób szyfrowane, dlaczego? Bo zapewnili pewien poziom bezpieczeństwa swoim danym tak, że jakiś małoletni haxior się do niech nie wbije. Tobie radze to samo tym bardziej, że w grę wchodzą tylko adresy email

[wNogachSpisz]

Hmmm dziwne podejście.. zamiast myśleć jak zapobiec włamaniu myślisz jak zabezpieczyć dane gdy do niego dojdzie.

Nie jest dziwne, tylko normalne, gdybyś miał choć minimalne pojęcie o bezpieczeństwie wiedziałbyś to.

[Crozin]

@CuteOne: Skąd wiesz co banki szyfrują, a czego nie?
@redeemer: @r4xy: @CuteOne: Dlaczego krytykujecie pomysł dodatkowego zabezpieczenia? A właściwie próby minimalizacji potencjalnych strat?

@Cliassi: Wszystko zależy od tego co potrzebujesz utajnić. Jeżeli są to jakieś prywatne dane użytkownika, możesz posłużyć się jego [dodatkowym] hasłem, jednak wtedy tracisz możliwość jakiejkolwiek analizy danych przez system, poza okresem gdzie użytkownik podał owe hasło. Adresy email jednak na 99% muszą być dostępne cały czas w Twojej aplikacji, więc to rozwiązanie odpada.

Trzymanie zaszyfrowanych danych binarnie/tekstowo w bazie danych (gdzie dane są [de]szyfrowane bezpośrednio przez aplikację) poza nielicznymi przypadkami nie ma sensu/uniemożliwia działanie systemu - przykładowo chęć sprawdzenia czy podany adres email nie jest przypadkiem w użyciu wymaga dostępu do wszystkich emaili w bazie.
Jednak nic nie stoi na przeszkodzie by szyfrować całą bazę danych/tabelę (Przykładowe rozwiązanie dla baz Oracle) albo w ogóle cały dysk/system plików. Czy to Cię uchroni przed kimś kto uzyskał pełen dostęp do serwera, na poziomie systemu operacyjnego? Raczej nie. Czy uchroni Cię to przed kimś kto uzyskał możliwość ingerowania w kod aplikacji? Raczej nie. Ale uchroni Cię to w wypadku, gdy ktoś uzyskał dostęp do plików bazy danych na dysku, albo niepełnego dostępu do systemu.

Oczywiście, jest to zabezpieczenie, które szansę na przydanie się będzie miało niezwykle rzadko. Ale zawsze jest to jakieś dodatkowe zabezpieczenie, chroniące w pewnych sytuacjach dane Twoich klientów.

[CuteOne]

wNogachSpisz: Nigdy nie potrafiłem "strawić" Twoich nic nie wnoszących wywodów.. nawiasem mówiąc o mojej wiedzy wiesz tyle co ja o kolorze Twoich skarpetek.

Crozin:
- mój ojciec zajmuje się administracją serwera jednego z polskich banków (sporo się w życiu nasłuchałem wręcz nierealnych opowieści niczym z polmozbytu)
- co do mojej krytyki takiego rozwiązania podałem konkretny argument - lepiej poświęcić czas na zabezpieczenie aplikacji/serwera przed włamaniem niż zabezpieczać same dane, które jak już sam napisałeś wcale nie będą bezpieczniejsze.

IMO dziwne pytanie zadałeś - w końcu żyjemy w wolnym kraju i z tego co wiem krytyka nie jest zabroniona Autor tematu chyba też w nim mieszka i sam jako wolny człowiek zdecyduje czy posłucha mnie czy użytkownika XYZ. Ot taki mały wywód

[Sephirus]

Wszyscy naraz i każdy z osoba macie rację - i nie macie zarazem.

@CuteOne To że twój ojciec pracuje w przy adm. w jakimś polskim banku wcale nie oznacza, że jest w nim wszystko tak jak należy - nieraz spotykałem się bardzo poważnymi firmami (jak się na nie patrzyło z zewnątrz) a w środku mimo przymusu spełniania wielu norm i tak był niezły bu***l Więc dla mnie - to żaden argument. Głupi przykład - jeden z dużych polskich serwisów mający rzeszą klientów trzymał hasła w jawnej formie w bazie - i co z tego że mieli super technologię 1000 pracowników itd... dane wyciekły.

Co do samego tematu - czy warto w ogóle szyfrować/zabezpieczać same dane? Wg niektórych pewnie nie - hashowanie haseł też jest jakieś bez sensu widać

Są firmy, w których same zabezpieczenia przed włamem i atakiem są niewystarczające - różne polityki prowadzą do tego, że niektórzy mogą mieć omyłkowo jakiś dostęp (czy to admini czy jacyś programiści) do danych z serwerów produkcyjnych. Wycieków jest pełno. Jeśli dane zabezpieczy się odpowiednim kluczem nieznanym dla tych ludzi - to naprawdę bardzo im to uprzykrzy jakieś próby kradnięcia informacji i danych. Ze swojego doświadczenia spotkałem się z szyfrowaniem danych właśnie w celu "ataku" ludzi z wewnątrz a nie z zewnątrz.

Podsumowując lepiej mieć dwa zabezpieczenia niż jedno.

Ciekawe rozwiązanie przedstawił też @Crozin aby szyfrować całość - aczkolwiek jest do przemyślenia IMHO.

[wNogachSpisz]

Hmmm dziwne podejście.. zamiast myśleć jak zapobiec włamaniu myślisz jak zabezpieczyć dane gdy do niego dojdzie. Zauważ, że nikt tego nie robi

lepiej poświęcić czas na zabezpieczenie aplikacji/serwera przed włamaniem niż zabezpieczać same dane, które jak już sam napisałeś wcale nie będą bezpieczniejsze.

Najpierw napisałeś że to dziwne podejście i nikt się nie zabepieczna przed minimalizacją szkód keidy już dojdzie do włamania, a za chwile napisałeś, że lepiej poświęcić czas na poprawę zabepieczeń chroniących przed włamaniem.