Hashing nie zadziała, ponieważ, jak wspomina skjaidev, jest to jeden ze sposobów.
Jeśli masz uzasadnioną obawę, że plik lub baza danych zostanie skradziona (*), szyfrowanie jest drogą do zrobienia. Ale tak jak wspomniałeś, twoja aplikacja będzie potrzebować klucza odszyfrowywania, więc pytanie, gdzie go przechowywać. Oczywiście przechowywanie go w tym samym miejscu, co dane, nie zwiększa bezpieczeństwa. Proszę wziąć pod uwagę:
- Gdy dane znajdują się w bazie danych, jest (najprawdopodobniej) mniej bezpieczny niż w pliku płaskim. Dzieje się tak dlatego, że istnieją techniki wstrzyknięcia bazy danych, które umożliwiają odczytanie bazy danych, ale nie plików. W tym przypadku umieszczenie klucza deszyfrującego w systemie plików (w kodzie) ma sens: dane z samej bazy danych są w tym przypadku bezużyteczne.
- Nawet jeśli dane są w pliku płaskim, umieszczenie klucza odszyfrowywania w pliku może zmniejszyć ryzyko. Wiele systemów zostaje "zhakowanych", gdy haker uzyskuje dostęp do systemu, który nie powinien nawet zawierać tych danych, które zawierały stare kopie danych lub w inny sposób (niekoniecznie) nie zawierają kodu z deszyfrowaniem klawisz.
Najlepiej mieć klucz odszyfrowywania nie w systemie plików, ale tylko w pamięci komputera. Dobry haker z dostępem do roota lub fizycznym dostępem może nadal do niego docierać, ale twierdzę, że w 99% przypadków, gdy hakerzy uzyskają dostęp do systemów plików, nie będą oni w stanie odczytać również pamięci (w Sprawy kradną kopie zapasowe, kradną fizyczną maszynę (wyłączając ją w procesie), uzyskują dostęp na poziomie użytkownika itp.). Jest to w zasadzie podejście oparte na keychain. Problem polega na tym, jak uzyskać klucz odszyfrowywania w pamięci i istnieje tylko jedno rozwiązanie, które znam: wpisz je (lub inne hasło, które odszyfrowuje klucz odszyfrowywania) przy każdym uruchomieniu aplikacji. To, czy jest to dopuszczalne, zależy od częstotliwości restartowania aplikacji.
Jest jeszcze jedna metoda. Jeśli potrzebujesz dostępu do skrzynki tylko wtedy, gdy Twoi użytkownicy są rzeczywiście zalogowani do Twojej aplikacji, możesz rozważyć szyfrowanie tokena za pomocą unikalnej właściwości użytkownika (lub instancji hasło używane przez użytkownika do logowania się do witryny lub losowy ciąg znaków ustawić w ciasteczku przy pierwszej wizycie). W takim przypadku możesz również rozważyć przechowywanie całego tokena dostępu zaszyfrowanego w cookie (a nie na twoim serwerze).
Bez względu na wybraną metodę, tak naprawdę nigdy nie ochroni, jak wspominasz. Jeśli twoja aplikacja może dostać się do odszyfrowanych tokenów (które może, w przeciwnym razie twoja aplikacja nie musiałaby ich przechowywać w pierwszej kolejności), może się też zdarzyć jakiś haker z nieograniczonymi uprawnieniami. Dobrą cechą tokenów dostępu jest to, że prawdopodobnie można je łatwo odwołać, więc jeśli zostaną skradzione, to prawdopodobnie nie koniec świata; a haker wie, że można je łatwo odwołać, więc nie będą interesujące jako cel.
(*) Uwaga: zawsze można założyć, że rzeczy zostaną ukradzione w ten czy inny sposób. Mogę sobie jednak wyobrazić, że jeśli założysz małą witrynę dla 20 znajomych na swoim domowym komputerze, mniej troszczysz się o swoje skradzione hasła, niż kiedy budujesz następny instagram. To zawsze kompromis między bezpieczeństwem a ilością pracy. Jak już wspomniano, posiadanie żetonów w postaci płaskiego pliku zamiast bazy danych (w przypadku prawidłowego postępowania) powinno zmniejszyć prawdopodobieństwo, że zostaną skradzione.
Szarpanie jest zwykle jednym ze sposobów. Czy twoja platforma ma miejsce na breloczki? – jman
Należy zauważyć, że SQLite używa również pliku do bazy danych, a pobranie z niego danych jest trywialne. Nie doda więc żadnych zabezpieczeń do plików płaskich. –