2011-10-26 17 views
6

Potrzebuję sposobu przechowywania zaszyfrowanych danych w taki sposób, że nadal mogę uruchamiać zapytania. Czy to w ogóle jest możliwe?Jak przechowywać "zaszyfrowane dane" w MySQL?

Przynajmniej potrzebuję algorytmu szyfrowania, który zawsze zwraca ten sam ciąg dla tego samego wejścia, więc mogę znaleźć wszystkich użytkowników o nazwie "John", szyfrując ten ciąg i szukając zaszyfrowanego wyniku w DB. W PHP mcrypt zawsze zwraca różne ciągi (wiem, że to celowo, aby poprawić bezpieczeństwo).

Wszelkie pomysły?

+1

Aby przechowywać zaszyfrowane dane w mysql, trzeba by je odszyfrować (zakładając, że zrobiono to przy użyciu mysql, a nie php), aby przeprowadzić wyszukiwanie słów kluczowych. Byłoby to szalenie powolne, ponieważ nawet indeksy nie byłyby w stanie ci pomóc. –

+0

Mam pomysł na pytanie, dlaczego chcesz przechowywać zaszyfrowane dane? –

+0

Ponieważ jest to dane, które powinny być czytelne tylko dla osób, które zostały autoryzowane w aplikacji internetowej (nie w DB). Wiele osób pracuje z tym DB i ma dostęp do odczytu. – HappyDeveloper

Odpowiedz

8

Zależy od tego, jak przechowujesz nazwę "John". Jeśli jest to jedyna rzecz w danej dziedzinie, można zrobić coś jak

SELECT ... 
FROM sometable 
WHERE cryptedfirstname = AES_ENCRYPT('John', $key) 

jeśli „John” jest częścią większego łańcucha („John Doe” lub „Król Jan, Władcą Wszechświata”), a następnie Będziesz musiał odszyfrować pełne pole i dopasować do tego, że umieszczam klucz deszyfrujący w zapytaniu. Zły pomysł na system produkcyjny, ale to tylko przykład.

nie będzie w stanie zrobić coś takiego:

... 
WHERE INSTR(cryptedFULLname, AES_ENCRYPT('John', $key)) 

ze względu na to, jak AES i większość innych Userful/godnej pracy systemów kryptograficznych.

+0

Dzięki, bardzo przydatne. Jakiś idiota-1-ciebie, najwyraźniej nie rozumiał problemu. +1 – HappyDeveloper

+0

Żadnych biggies. Puchary przelatują tu grubo i szybko. I szczerze mówiąc, -1 nie robi tak wielkiej różnicy w tym momencie ... –

+1

Oddanie głosu nie było ode mnie, ale mogło być od kogoś, kto rozumie, że dobre bezpieczeństwo wymaga trybu szyfrowania z nieprzewidywalnym IV. Wszystkie przykłady tutaj nie mają tego. – erickson

2

Wygląda na to, że rozumiesz to, ale należy podkreślić, że algorytm szyfrowania, który zawsze wytwarza ten sam tekst szyfrowania dla danego zwykłego tekstu, jest uszkodzony. Prowadzi do wszelkiego rodzaju ataków.

Na przykład osoba atakująca mająca dostęp do bazy danych i aplikacja może wybrać wartość "Jan" dla pola i spowodować, że aplikacja zapisze dane w bazie danych. Następnie może przyjrzeć się tekstowi szyfrowania dla swojego rekordu i zidentyfikować wszystkie inne rekordy zawierające ten tekst szyfrowania. Nie musi uzyskać klucza do tego.

Wyjątek stanowi szyfrowanie dużych, "nieprzewidywalnych" unikatowych numerów, na przykład identyfikatorów sesji lub identyfikatorów UUID. W takim przypadku, ponieważ zwykłe teksty nie powtarzają się, a prawidłowy tekst jawny nie może być przewidziany przez atakującego, nierozróżnialność szyfrogramów nie jest wymagana.

Dowolny symetryczny szyfr używany w trybie ECB będzie generował spójny tekst zaszyfrowany z czystego tekstu, podobnie jak przy użyciu trybów, które pobierają wektor inicjujący, jeśli zawsze używasz tego samego IV. Po prostu nie jest to dobry pomysł.

+0

Dobrze wiedzieć, dzięki. Cóż, ktoś inny w firmie będzie musiał sobie z tym poradzić = p, nie zaprojektowałem systemu. +1 – HappyDeveloper

Powiązane problemy