Pierwsza zasada bezpieczeństwa aplikacji: każda maszyna, na którą atakujący uzyskuje nieograniczony fizyczny lub elektroniczny dostęp, należy teraz do twojego atakującego, niezależnie od tego, gdzie faktycznie jest lub za co zapłaciłeś.
Druga zasada bezpieczeństwa aplikacji: każde oprogramowanie, które wykracza poza fizyczne granice, w którym atakujący nie może przeniknąć, należy teraz do atakującego, niezależnie od tego, ile czasu spędziłeś na jego kodowaniu.
Trzecia zasada: wszelkie informacje, które opuszczają te same fizyczne granice, których atakujący nie może przeniknąć, należą teraz do atakującego, bez względu na to, jak cenne są dla Ciebie.
Podstawy bezpieczeństwa technologii informatycznych opierają się na tych trzech podstawowych zasadach; jedynym naprawdę bezpiecznym komputerem jest ten zamknięty w sejfie, w klatce Farradaya, w stalowej klatce. Są komputery, które spędzają większość swojego życia serwisowego właśnie w tym stanie; raz w roku (lub krócej) generują klucze prywatne dla zaufanych głównych urzędów certyfikacji (przed wieloma świadkami z kamerami rejestrującymi każdy centymetr pokoju, w którym się znajdują).
Obecnie większość komputerów nie jest używana w tego typu środowiskach; są fizycznie poza domem, podłączone do Internetu za pośrednictwem bezprzewodowego kanału radiowego. Krótko mówiąc, są wrażliwe, podobnie jak ich oprogramowanie. Dlatego nie można im ufać. Istnieją pewne rzeczy, które komputery i ich oprogramowanie muszą wiedzieć lub robić, aby były użyteczne, ale należy zadbać o to, aby nigdy nie wiedziały lub nie robiły wystarczająco dużo, aby spowodować szkody (przynajmniej nie trwałe uszkodzenie poza granicami tego pojedynczego komputera ).
Już to wszystko wiedzieliście; dlatego próbujesz chronić kod swojej aplikacji. Ale na tym polega pierwszy problem; narzędzia zaciemniające mogą sprawić, że kod będzie bałaganem dla człowieka, który będzie próbował go przekopać, ale program wciąż musi działać; oznacza to, że faktyczny przepływ aplikacji i dane, z których korzysta, nie mają wpływu na zaciemnianie. Biorąc pod uwagę niewielką wytrwałość, atakujący może po prostu zaciemnić kod, a nie jest to nawet konieczne w niektórych przypadkach, w których to, na co patrzy, nie może być niczym innym, jak tym, czego szuka.
Zamiast tego powinieneś starać się upewnić, że atakujący nie może nic zrobić z twoim kodem, bez względu na to, jak łatwo jest mu uzyskać wyraźną kopię. Oznacza to, że nie ma zakodowanych na stałe tajemnic, ponieważ te sekrety nie są tajne, gdy tylko kod opuści budynek, w którym został opracowany.
Te kluczowe wartości, które zapisałeś na stałe, powinny zostać całkowicie usunięte z kodu źródłowego aplikacji. Zamiast tego powinni być w jednym z trzech miejsc; pamięć ulotna na urządzeniu, która jest trudniejsza (ale nadal nie niemożliwa) dla atakującego w celu uzyskania kopii offline; na stałe w klastrze serwerów, do którego kontrolujesz dostęp żelazną pięścią; lub w drugim magazynie danych niezwiązanym z urządzeniem lub serwerami, takim jak karta fizyczna lub w pamięci użytkownika (co oznacza, że ostatecznie znajdzie się w pamięci ulotnej, ale nie musi długo).
Rozważ następujący schemat. Użytkownik wprowadza dane uwierzytelniające aplikacji z pamięci do urządzenia. Musisz niestety ufać, że urządzenie użytkownika nie jest już zagrożone przez keyloggera lub trojana; najlepsze, co możesz zrobić w tym zakresie, to wdrożyć zabezpieczenia wieloskładnikowe, zapamiętując trudne do sfałszowania informacje identyfikujące o urządzeniach, z których korzystał użytkownik (MAC / IP, IMEI itp.), i zapewniając co najmniej jeden dodatkowy kanał przez którą próbę logowania na nieznanym urządzeniu można zweryfikować.
Poświadczenia, po ich wprowadzeniu, są zaciemniane przez oprogramowanie klienckie (przy użyciu bezpiecznego skrótu), a poświadczenia zwykłego tekstu są odrzucane; spełniły swój cel. Zaciemnione dane uwierzytelniające są przesyłane bezpiecznym kanałem do serwera uwierzytelnionego za pomocą certyfikatu, który ponownie je szyfruje w celu wygenerowania danych służących do weryfikacji ważności logowania. W ten sposób klient nigdy nie wie, co jest faktycznie porównywane z wartością bazy danych, serwer aplikacji nigdy nie zna poświadczeń w postaci zwykłego tekstu za tym, co otrzymuje do sprawdzania poprawności, serwer danych nigdy nie wie, w jaki sposób są tworzone dane przechowywane do sprawdzania poprawności, a mężczyzna środek widzi tylko bełkot, nawet jeśli bezpieczny kanał zostałby naruszony.
Po weryfikacji serwer przesyła z powrotem token kanałem. Token jest użyteczny tylko w bezpiecznej sesji, składa się z losowego szumu lub zaszyfrowanej (a zatem weryfikowalnej) kopii identyfikatorów sesji, a aplikacja kliencka musi wysłać ten token w tym samym kanale do serwera w ramach dowolnego żądania zrobić coś. Aplikacja kliencka zrobi to wiele razy, ponieważ nie może zrobić nic, co wiązałoby się z pieniędzmi, poufnymi danymi lub czymkolwiek innym, co samo w sobie mogłoby być szkodliwe; zamiast tego musi poprosić serwer o wykonanie tego zadania. Aplikacja kliencka nigdy nie zapisuje żadnych poufnych informacji w trwałej pamięci na samym urządzeniu, przynajmniej nie w postaci zwykłego tekstu; klient może poprosić serwer za pośrednictwem bezpiecznego kanału o klucz symetryczny do szyfrowania dowolnych danych lokalnych, które serwer zapamięta; w późniejszej sesji klient może poprosić serwer o ten sam klucz do odszyfrowania danych do użycia w pamięci ulotnej. Te dane też nie będą jedyną kopią; wszystko, co klient przechowuje, również powinno zostać przesłane w jakiejś formie na serwer.
Oczywiście powoduje to, że twoja aplikacja jest silnie uzależniona od dostępu do Internetu; urządzenie klienckie nie może wykonywać żadnej ze swoich podstawowych funkcji bez odpowiedniego połączenia i uwierzytelnienia przez serwer. Tak naprawdę nie różni się od Facebooka.
Komputer, którego chce atakujący, to Twój serwer, ponieważ to nie aplikacja / urządzenie klienckie może zarabiać na nim pieniądze lub powodować ból innych osób. W porządku; zyskujesz znacznie więcej za swoje pieniądze wydając pieniądze i starając się zabezpieczyć serwer, niż próbując zabezpieczyć wszystkich klientów. Serwer może znajdować się za wszelkiego rodzaju zaporami ogniowymi i innymi zabezpieczeniami elektronicznymi, a dodatkowo może być fizycznie zabezpieczony za stalą, betonem, kartą dostępu / pinami i 24-godzinnym monitoringiem wideo. Twój atakujący musiałby być naprawdę bardzo wyrafinowany, aby uzyskać jakikolwiek dostęp do serwera bezpośrednio, i powinieneś (powinnaś) o tym natychmiast wiedzieć.
Najlepsze, co może zrobić atakujący, to ukraść telefon użytkownika i dane uwierzytelniające oraz zalogować się na serwerze z ograniczonymi prawami klienta. Jeśli tak się stanie, podobnie jak utrata karty kredytowej, należy pouczyć legalnego użytkownika, aby zadzwonił pod numer 800 (najlepiej łatwy do zapamiętania, a nie na odwrocie karty, którą mieliby w torebce, portfelu lub teczce) skradzione obok urządzenia mobilnego) z dowolnego telefonu, do którego mają dostęp, co łączy je bezpośrednio z obsługą klienta. Podają, że ich telefon został skradziony, podają podstawowy unikatowy identyfikator, a konto jest zablokowane, wszelkie transakcje, które atakujący mógł przetworzyć, są wycofywane, a atakujący wraca do punktu wyjścia.