Wojciech Dworakowski

• Cześć!

Witam wszystkich bardzo serdecznie. Ja nazywam się Kacper Szurek a to kolejny odcinek podcastu „Szurkogadanie”, w którym opowiadam o bezpieczeństwie w prosty i zrozumiały sposób.

Dzisiaj moim gościem jest Wojciech Dworakowski – prezes firmy Securing i osoba, która w Polsce może być znana z organizacji OWASP.

Wojtku, dziękuje Ci, że zgodziłeś się wziąć udział w tym nagraniu.

• To może na początku – kim jesteś i czym się zajmujesz?

Cześć Kacper. Dziękuję za zaproszenie. Tak jak mnie tutaj przedstawiłeś, zajmuję się w tej chwili raczej zarządzaniem Securing – czyli firmy zajmującej się testowaniem bezpieczeństwa i doradztwem z zakresu bezpieczeństwa aplikacji i systemów informatycznych.

Poza tym jestem jednym z liderów OWASP – czyli Open Web Application Security Project w Polsce.

Jest to organizacja „non-profit”, która zajmuje się poprawą bezpieczeństwa oprogramowania.

• OWASP TOP 10 to flagowy projekt tej organizacji. Na czym on polega i o co tam naprawdę w nim chodzi?

OWASP TOP 10 to lista 10 najgroźniejszych podatności czy typów podatności dla aplikacji webowych, aktualizowana raz na kilka lat.

I faktycznie jest to coś z czego OWASP jest najbardziej słynny.

Natomiast jest to o tyle ciekawy projekt, że on powstał raczej jako projekt edukacyjny.

Czyli projekt raczej uświadamiający programistów, a nie coś co ma być standardem.

Natomiast jego życie było takie, tak został przyjęty przez wiele organizacji, że skoro jest to lista 10 jakichś Top 10, to to się fajnie wdrażało na zasadzie – weźmy to i zobaczmy, czy nasza aplikacja nie ma którejś z tych podatności.

Albo weźmy to i spróbujmy zbudować aplikację tak, żeby nie miała tych podatności.

Poniekąd zaczął być używany jako standard, jako pewnego rodzaju „miarka” czy dana aplikacja jest bezpieczna czy nie – natomiast nie bardzo się do tego nadawał.

No i ojcowie tego projektu w obecnej wersji już dorobili tą część, która umożliwia stosowanie OWASP Top 10 jako czegoś w rodzaju standardu.

Czyli podatności zostały opisane w taki sposób, żeby były testowalne i żeby dało się to wpisać bezpośrednio w wymagania.

• Czyli OWASP to nie tylko Top 10 ale coś o wiele, wiele więcej. Jest wiele innych projektów, które mogą być równie ciekawe, ale jednak nie tak znane szerszemu gronu słuchaczy.

Zdecydowanie tak. Tych projektów jest tak naprawdę kilkaset. „O” w OWASP oznacza „open”.

Każdy może do tej organizacji się przyłączyć na zasadach „open source” i zaproponować swój projekt, który w jakikolwiek sposób pomaga rozwiązać problemy bezpieczeństwa aplikacji.

Takich projektów jest naprawdę bardzo dużo.

Oczywiście o różnym stopniu dojrzałości i o różnym stopniu jakości.

Dlatego też w OWASP wdrożono cały proces kwalifikowania tych projektów i w tej chwili takich projektów flagowych jest kilkanaście, które są powiedzmy w takiej wersji produkcyjnej, której można używać.

Tutaj jeśli chodzi o takie moje ulubione projekty, to z tych projektów dokumentacyjnych, których rezultatem jest powstanie jakiegoś dokumentu, standardu - na pewno poleciłbym ASVS czyli Application Security Verification Standard.

Jest to taka „checklista” ponad 150 potencjalnych podatności w aplikacjach webowych, na zgodność z którą można przetestować – jak sama nazwa wskazuje – czyli zweryfikować swoją aplikację.

Ale też można jej używać jako listy wymagań przy tworzeniu aplikacji.

Drugim takim dokumentem jest SAMM – Security Assurance Maturity Model.

I to jest taki mniej techniczny projekt, bardziej dla zarządzających bezpieczeństwem, pomagający wdrożyć bezpieczeństwo w cyklu rozwojowym oprogramowania.

Pokazuje on pewnego rodzaju „roadmapy” jakimi należy się poruszać.

W co najpierw zainwestować swój czas i pieniądze, żeby podnieść bezpieczeństwo na różnych etapach procesu wytwarzania oprogramowania.

Bardzo fajne opracowanie, jeżeli ktoś się zastanawia jak w swojej organizacji przejść „od zera” do jakiegoś uporządkowanego procesu.

Jeśli chodzi o bardziej techniczne dokumenty to tutaj poleciłbym cały zbiór dokumentów „cheatsheet series” - gdzie jak sama nazwa wskazuje są to takie „ściągi” – dotyczące rozwiązywania jakichś typowych problemów z bezpieczeństwem aplikacji.

Jak coś „zakodować”, jakich błędów uniknąć, posegregowane po różnych „hashtagach”.

No i w końcu też OWASP to nie tylko projekty dokumentacyjne, ale również projekty, w cudzysłowie na GitHub.

Czyli kawałki kodu, które można wykorzystać w swojej aplikacji.

Albo takie rozwiązania jak na przykład Security Shepherd – czyli platforma treningowa, na której można robić szkolenia, CTF-y i pokazywać programistom problemy bezpieczeństwa.

Innym takim projektem jest OWASP Juice Shop, czyli celowo podatna aplikacja „e-commerce”, gdzie można zobaczyć jak podatności mogą wyglądać w praktyce i dzięki temu uniknąć ich w swojej aplikacji.

• Czyli rzeczywiście OWASP to cała mnogość różnych rzeczy, które można znaleźć „online”. A co z tymi, którzy chcieliby się spotkać „offline”? Jak można dołączyć do OWASP? Powiedziałeś, że to otwarta fundacja – gdzie się spotykacie, gdzie można znaleźć o was informacje, jak można was wspomóc?

OWASP w poszczególnych krajach działa na zasadzie tak zwanych „Chapter”.

Tu nie znajduje polskiego odpowiednika – może to być oddział, ale to by sugerowało jakąś ustrukturyzowaną instytucję.

Natomiast OWASP jest otwarty, w związku z tym również nasze spotkania są otwarte.

W Polsce spotykamy się w Krakowie, Warszawie, we Wrocławiu – czasem również w Poznaniu.

Najłatwiej do nas dołączyć w ten sposób, że po prostu znaleźć nas na Meetup pod hasłem „OWASP Poland”.

Są tam „wylistowane” nasze spotkania.

W tych trzech, czasami czterech miastach i raz w roku organizujemy konferencję jednodniową o nazwie „OWASP Poland Day”.

Spotkania są – tak jak to meetupy – absolutnie darmowe.

Każdy może tam przyjść

Ale mało tego, każdy też może tam zaprezentować, jeżeli ma coś do powiedzenia na temat bezpieczeństwa aplikacji.

• No właśnie, powiedziałeś „konferencja”. Ty w branży „security” siedzisz już naprawdę długo, a więc zasiadasz w radach programowych wielu konferencji. Jak wybierasz prezentacje, które mają się znaleźć na takich konferencjach? Co Ciebie – jako osobę wybierającą, najbardziej interesuje? Jak powinna zacząć osoba, która coś robi i chciałaby się tą wiedzą podzielić z szerszym gronem odbiorców?

W ogóle zachęcam wszystkich do tego, żeby przesyłać swoje propozycje na wszelkiego rodzaju „Call For Papers”, bo świat bezpieczeństwa bez napływu świeżej krwi ciągle będzie się kręcił w miejscu, wokół tych samych prelegentów.

Tak że bardzo zachęcam.

Jak ja wybieram?

Po pierwsze, staram się nie patrzeć najpierw na nazwisko tylko czytam abstrakt, patrzę jaki pomysł na prezentację ma dana osoba.

Czy jest to coś świeżego, coś nowego albo czy jest to jakieś fajne opracowanie czegoś o czym warto powiedzieć.

No i też szukam innych prelekcji tego autora, bo uważam, że dobra prezentacja to połączenie tych twardych umiejętności – czyli „technikaliów”, natomiast też potrzebne są zdolności do przekazania tej wiedzy.

Ja patrzę też mocno na to jak dany prelegent umie prezentować.

Więc jeśli miałbym coś poradzić komuś, kto wysyła swoje zgłoszenia na różne konferencje, to to, żeby pisał po pierwsze nierozwlekły, konkretny abstrakt z jasną informacją o czym będzie i co będzie i żeby zamieścił gdzieś – jeżeli ma linki do innych swoich wcześniejszych prezentacji.

A jeśli jest to czyjś pierwszy raz to niech nagra po prostu kawałek filmu, żeby zobaczyć jak on się będzie prezentował i jak będzie wyglądał na danej konferencji.

Natomiast też weźcie pod uwagę, jeśli słuchacie tego potencjalni prezenterzy, że my jako rada programowa takiej czy innej konferencji mamy do przejrzenia setki zgłoszeń.

Więc naprawdę na waszym zgłoszeniu nie mamy szans przeczytać strony A4.

Chyba, że chodzi o szybkie jej przewijanie.

Mamy kilkanaście sekund na podjęcie decyzji – OK, czytam dalej bądź nie.

A więc weźcie to pod uwagę i też po prostu trzeba się dobrze sprzedać.

• Czyli nie zawsze więcej znaczy lepiej.

Zdecydowanie.

• Prowadzisz firmę, która zajmuje się testami penetracyjnymi. Jak z Twojej perspektywy zmieniało się bezpieczeństwo na przestrzeni lat?

My gdzieś na samym początku – te 17 lat temu, jak zaczynaliśmy tą firmę (a jeszcze wcześniej pracowałem jako pentester) to widziałem, że raczej skupienie było ogólnie na testowaniu całych środowisk.

Taki „pentest” ogólny całości organizacji albo sieci dowolnymi metodami.

Natomiast w tej chwili raczej i my i rynek koncentrujemy się na testach bezpieczeństwa poszczególnych systemów wchodzących w skład większej całości.

Zwłaszcza w testach bezpieczeństwa aplikacji.

Więc widać przesuniecie tego środka ciężkości od środowisk sieciowych do aplikacji.

Aczkolwiek, oczywiście moje spojrzenie może być skrzywione, bo moja firma specjalizuje się w testach bezpieczeństwa aplikacji.

No ale takie jest moje spojrzenie na rynek i to co się zmieniło.

Drugie co się zmieniło to skala.

Te „naście” lat temu bezpieczeństwo IT to było coś co funkcjonowało w bankach i instytucjach finansowych i tam gdzie to ryzyko jest namacalne i oczywiste.

Natomiast dzisiaj, zwłaszcza w ciągu kilku ostatnich lat, poszło to bardzo do przodu i bezpieczeństwem interesują się wszelkiego rodzaju instytucje, bo bezpieczeństwo IT jest teraz na nagłówkach gazet.

• Załóżmy, że jestem małą firmą i chcę przeprowadzić swój pierwszy test penetracyjny. Na co powinienem zwrócić uwagę zawierając kontrakt z firmą taką jak wasza?

Po pierwsze, na wyborze dostawcy w zależności od potrzeb.

Czy to ma być jakaś znana firma, która może udowodnić, że zna się na rzeczy czy raczej zależy wam na taniej usłudze i chcecie wynająć „freelancera”.

Czyli trzeba sobie zdefiniować w jakiej jakości potrzebujemy tej usługi.

Druga rzecz to spróbować jakoś zweryfikować tą jakość.

Poprosić o szablon raportu, zobaczyć jak będzie wyglądała współpraca.

Spytać o proces całości, ale też w końcu samemu dobrze się przygotować do tych testów.

Czyli po pierwsze – dobrze wyznaczyć cele (czyli po co to robimy) i dobrze wyznaczyć zakres.

Tutaj zakres może się dosyć poważnie różnić w zależności od danego przypadku testowego.

Żaden system informatyczny nie funkcjonuje przecież osobno tylko jest on połączony – te systemy miedzy sobą.

Więc trzeba wyznaczyć gdzie jest początek a gdzie koniec tego czym testerzy bezpieczeństwa mają się zająć.

• To ile średnio w waszej firmie trwa taki standardowy pentest?

Ze średnią zawsze mam problemy, bo to jest tak jak w tym dowcipie o nogach w piecu i głowie w lodówce.

To tak mniej więcej wygląda też przy tego typu usługach.

Czyli może to być od kilku do kilkudziesięciu nawet dni.

Natomiast średnio powiedziałbym, że jest to mniej więcej 10 dni, dwóch specjalistów dla przetestowania jakiegoś hipotetycznego, średniej wielkości systemu.

No bo tutaj też będziemy mówili o średniej wielkości aplikacji.

• Czyli całkiem sporo. Czy zdarzyło się kiedyś, że podczas takich testów nie znaleźliście żadnych błędów?

Ostatnio zdarza się.

To znaczy, że rynek idzie do przodu.

To nie jest tak, że nie znajdujemy żadnych błędów, ale nie znajdujemy żadnych kluczowych błędów albo takich o wysokim wpływie na ryzyko.

Zawsze jakieś tam pomyłki w konfiguracji się zdarzają ale też, zdarzają się systemy, które już są całkiem dobrze zabezpieczone.

Zwykle to dotyczy jakichś małych funkcjonalności, które „dotestowujemy”.

Na przykład bank rozwija swoją bankowość internetową od lat i dodaje jakąś funkcjonalność.

Czyli, że współpracujemy od dłuższego czasu i oni też przecież się uczą, rozwijają i podnoszą jakość swoich procesów, więc jest coraz bezpieczniej.

Jeżeli zakres tego testu nie jest zbyt duży, jest dobrze zdefiniowany i dana organizacja dba mocno o bezpieczeństwo, to zdarza się, że tych podatności zbyt wiele nie ma.

• Wynikiem takiego testu penetracyjnego powinien być raport. No ale raport to jest coś dla osób technicznych. W jaki sposób przedstawić tą techniczną wiedzę tak aby zrozumiał ją zarząd i mógł na jego podstawie podjąć kluczowe dla firmy decyzje?

Moim zdaniem nie koncentrować się na „technikaliach” tylko opisać to przez pryzmat potencjalnych szkód – zwłaszcza szkód dla biznesu.

Oraz opisać kto może daną podatność wykorzystać.

Ludzi decyzyjnych interesuje kto i co może zrobić, a już nie do końca ich interesuje jak to zostanie zrobione.

• Czy programowanie jest potrzebne w pracy pentestera?

Zdecydowanie tak.

Zwłaszcza w takiej branży jak testowanie bezpieczeństwa aplikacji to jeżeli ktoś nie jest bądź nie był programistą i nie zna programowania to w zasadzie go to trochę wyklucza, prawda?

W pracy pentestera potrzebne jest programowanie, bo dosyć często potrzeba coś sobie „oskryptować”, czy dodać jakąś funkcjonalność, czy napisać jakiś plugin, czy zrobić coś, do czego się nie ma narzędzi.

• No to może po prostu prace pentestera można zautomatyzować?

Teoria mówi, że tak – praktyka mówi, że nie.

Ja jestem zwolennikiem automatyzacji rzeczy, które dadzą się zautomatyzować.

Natomiast, części rzeczy takich jak na przykład znajdowanie podatności logicznych – nie da się zautomatyzować.

Druga sprawa – ciężko jest napisać automat, który coś wykrywa, co jest niejednoznaczne.

Jeżeli dana aplikacja „rzuci” w wyniku jakiegoś naszego działania błąd 500, czy jakiś inny - to jest to jakiś symptom, że coś tam się zadziało.

Natomiast jeżeli wyświetli jakąś „customową” stronę błędu – to już może być troszeczkę ciężej dla automatu to wykryć.

Można się posłużyć takim przypadkiem, że jeżeli manipulujemy na przykład identyfikatorem, który jest przekazywany w parametrach POST lub GET i staramy się zmienić ten identyfikator na inny – to rezultatem, który dostanie pentester jest dostanie się do cudzych danych.

Natomiast automat raczej tego nie wyczuje.

To znaczy, nie widzi przykładowo w bankowości internetowej, że dostaliśmy właśnie historię transakcji innego użytkownika.

Także jest wiele takich „specyfik”, które powodują, że automaty nadają się, ale raczej do wykrywania podatności, które są oczywiste i są takimi nisko wiszącymi owocami.

• Obserwujemy coraz większą popularność programów typu Bug Bounty. Czy stanowią one dla was jakieś niebezpieczeństwo? Czy starają się was wyprzeć? A może w ogóle razem współdziałacie i to jest bardziej działalność razem a nie osobno?

W sensie wyprzeć usługę testów penetracyjnych czy testów bezpieczeństwa?

• Tak, dokładnie tak.

W pewnym stopniu jest to coś, co jest podobne, ale raczej powiedziałbym, że jest to usługa uzupełniająca, komplementarna.

To jest trochę inny sposób testowania.

W przypadku programów Bug Bounty wynajmujemy cały świat do tego, żeby szukał u nas błędów.

A więc jest to symulacja takich przypadkowych ataków.

To znaczy, że ktoś coś sobie „wygrzebał”, ktoś coś gdzieś „poklikał” i coś znalazł.

A nie jest to symulacja ataku zorganizowanej grupy, która jest w stanie znaleźć bardziej zaawansowane błędy.

I też one z reguły dotyczą interfejsów, które są wystawione bezpośrednio w Internecie a nie aplikacji wewnętrznych

Chociaż oczywiście programy Bug Bounty bardzo ewoluują w tej chwili.

I ewoluują w kierunku tak naprawdę czegoś na kształt testów penetracyjnych.

Bo spotykamy się już z zamkniętymi programami Bug Bounty, gdzie klient końcowy dostaje wyselekcjonowany zespół Bug Bounterów, czy ludzi szukających błędów.

A więc jest to „de facto” to samo co testowanie bezpieczeństwa aplikacji w takiej bardziej zaawansowanej formie.

Natomiast w tej formie typowej, myślę i tak to duże organizację traktują – coś co jest uzupełnieniem procesu uzyskiwania bezpiecznej aplikacji – oprócz testów penetracyjnych.

• Coraz więcej usług rządowych przechodzi do chmury. Mamy już e-dowód, możemy sprawdzić co się działo z naszym samochodem. Jak według Ciebie wygląda bezpieczeństwo usług rządowych? Czy może warto było by zainwestować, aby te wszystkie usługi były open source, aby każdy mógł sprawdzić kod, który się tam znajduje? A może to podejście „black box” wcale nie jest takie złe?

Trudne pytanie.

Jeżeli bym wiedział to i tak bym nie powiedział, bo to oznacza, że zdradzałbym tajemnice swoich klientów.

Tak że, nie wiem jak jest z tym bezpieczeństwem.

Nie słyszałem w ostatnich latach o jakichś spektakularnych przykładach skutecznych ataków na te nowe usługi „e-państwa” czy jak to jeszcze nazwiemy.

Co do Twojego pytania, czy warto by było ten kod upublicznić – to być może.

To zależy od tego jaki jest tam model zaufania.

Jeżeli temu wystawiającemu usługę zależy na tym, aby to wszystko było transparentne i żeby było wiadomo jak ten kod w środku wygląda i żeby podnieść zaufanie w ten sposób – to na pewno tak.

Natomiast zdaję sobie sprawę z tego, że nie całość tego kodu mogłaby być wystawiona bo są tam jakieś interfejsy do systemów wewnętrznych lub innych rzeczy, które są w jakiejś większej klauzuli zaufania.

Ale jeśli chodzi o weryfikację bezpieczeństwa – tylko ten aspekt – to oczywiście odpowiedź brzmi tak – to miało by sens, żeby poddać to takiemu publicznemu sprawdzeniu.

• To może z innej beczki. Jaką książkę poleciłbyś słuchaczom? Książkę lub książki?

Słuchaczom to chyba ciężko będzie mi coś polecić, bo już dawno nie czytam książek takich bardzo technicznych.

Raczej czytam jakieś opracowania.

Szczerze powiedziawszy bardziej już jestem managerem niż pentesterem.

• Bardziej Excel niż Burp.

Mogę powiedzieć co ostatnio ja czytałem.

Z takich książek ogólnorozwojowych, bardzo mi się ostatnio podobała książka Miłosza Brzezińskiego – „Głaskologia”, mówiąca o tym jak budować sobie relacje między ludźmi.

A z takich książek, do których czasami wracam i akurat teraz wróciłem – Robert Heinlein – „Stranger in a strange land”.

Jak ktoś sięgnie do tego to fajnie zobaczyć jak gość, który pisał bodajże w latach sześćdziesiątych dosyć fajnie przewidział różne rzeczy, z których korzystamy teraz w teraźniejszości.

Jak uczyć młode pokolenie programistów pisania bezpiecznego kodu?

Jak uczyć młode pokolenie programistów zwłaszcza pisania bezpiecznego kodu?

Pierwsza część Twojego pytania to już jest pytanie samo w sobie.

• Jak uczyć młode pokolenie programistów.

I ja wiem, że tu jest wiele ciekawych podejść do tego.

Myślę, że na przykładach dobrego i złego kodu.

I pokazywać im skutki.

I to nie skutki takie na zasadzie – o tutaj jest XSS i wyświetlimy „alert(1)”.

Tylko pokazywać, że przez ten XSS da się zrobić więcej.

Pokazywać cały „killchain” kilku podatności, które mogą doprowadzić do czegoś istotnego.

Po to, żeby im się to „wryło” w pamięć, że błąd na każdym etapie, w każdym module oprogramowania może być gdzieś wykorzystany w jakimś scenariuszu ataku.

• Prowadzicie firmę już ładnych parę lat. Możesz się podzielić jakimiś bardzo ciekawymi przykładami – oczywiście bez podawania nazw firm – błędów, które pozostały w Twojej pamięci? Coś co było abstrakcyjne i głupie, że aż dziw bierze.

Takich przykładów chyba mamy dość dużo – niestety.

Raczej czasami powiedziałbym, że to nie tyle jest głupie co zaskakujące.

Że jakiś SQL Injection przez „1=1” w okienku logowania ciągle się gdzieś spotyka.

Czy przykłady takie, że ja mówię – no nie, to niemożliwe, to tylko w książkach takie rzeczy.

Ale faktycznie się zdarzają.

Natomiast coś co mi zwykle zapada w pamięć to „killchain” – czyli złożenie kilku podatności, w których okazuje się, że coś co się wydaje niewielką podatnością – po złożeniu z innymi – może doprowadzić do jakichś bardzo dużych skutków.

• Według Ciebie jaka podatność jest często ignorowana, a może prowadzić do bardzo poważnych konsekwencji?

Myślę, że XSS – ciągle.

To jest takie powszechne, że sporo ludzie jest w stanie to zignorować, zwłaszcza jeśli ta podatność jest „źle sprzedana”.

Ale też CSRF wydaje mi się, że jest taką podatnością, która może być dość łatwo zignorowana.

• Twoja firma zajmowała się tematem płatności mobilnych. Jakie jest Twoje zdanie na ten temat?

W sensie bezpieczeństwa?

• Tak, oczywiście.

Bo, nie w sensie bezpieczeństwa to oczywiście płatności mobilne są super wygodne.

Sam ich używam, więc to też coś mówi o tym , co sądzę o bezpieczeństwie.

Myślę, że na dzień dzisiejszy jest to wystarczająco bezpieczne, żeby móc używać zwłaszcza do tych niewielkich płatności.

Bo pamiętajmy o tym, że płatności mobilne „de facto” są płatnościami zbliżeniowymi.

A więc tam obowiązują limity, powyżej których trzeba i tak użyć technologii innych do tego, żeby uwierzytelnić większość płatność niż podstawowa.

A zawsze warto sobie ograniczyć ryzyko, w ten sposób, że po prostu ustawić limit na karty, które mamy zapisane w telefonie na niewielką kwotę, w zależności od swojego, że tak powiem, apetytu na ryzyko.

• Czy chmura zmieniła jakoś zasady gry? Czy testowanie aplikacji przez to, że są one hostowane w Amazonie albo Microsofcie utrudniła jakoś waszą pracę? A może wręcz przeciwnie?

Nie powiedziałbym, że utrudniła – na pewno uczyniła ją bardziej ciekawą.

Bo jest to nowy zestaw technologii.

Na początku, gdy wchodziły te technologie chmurowe każdemu się wydawało, że to jest tak samo jak zwykły serwer, tylko gdzie indziej.

Zamiast go trzymać tutaj lub w jakimś znanymi mi hostingu – to trzymam to w tak zwanej chmurze – czyli gdzieś w Google, Amazonie lub Microsofcie.

Natomiast jeżeli ktoś administrował usługami chmurowymi – zwłaszcza na przykład w AWS – to wie, że to jest kompletnie inny świat.

Więc z naszego punktu widzenia testowanie środowisk sieciowych – środowiska, w którym działa aplikacja i jest ona hostowana na przykład na AWS lub na Azurze – jest jednak zupełnie czym innym.

Trzeba się także dość mocno na tym znać i zainwestowaliśmy dość sporo czasu żeby poznać te technologie.

Ten świat jest dość zagmatwany, dość skomplikowany i dość szybko i dynamicznie się rozwijający, więc trzeba trzymać rękę na pulsie.

Ale z punktu widzenia bezpieczeństwa wiadomo, że wszystko co jest dużą funkcjonalnością i wszystko co jest bardzo skomplikowane - z reguły jest bardziej narażone na popełnienie błędu ludzkiego.

Czyli jakiejś złej konfiguracji tak jak „buckety” na AWS, do których czasami administratorzy czy użytkownicy czy aplikacje potrafią wrzucić jakieś ciekawe dla nas informacje.

• Wszystkie środowiska, w których przetwarzane są dane posiadaczy kart płatniczych powinny przeprowadzać testy PCI DSS. Czym takie testy różnią się od zwykłych testów penetracyjnych?

Akurat przy PCI DSS tam jest dosyć szczegółowy „guide” – taki przewodnik jak przeprowadzać testy bezpieczeństwa.

I co do samej techniki przeprowadzania testów bezpieczeństwa to myślę, że one się jakoś mocno nie różnią.

Natomiast są to inne projekty jeśli chodzi o wyznaczenie zakresu i ten zakres bezpośredni wynika z tego „guide” PCI DSS dotyczącego testów bezpieczeństwa.

Musi nim być objęte środowisko, w którym są przetwarzane karty i wszystkie systemy, które w jakikolwiek sposób mogą wpływać na ten system.

Nie chcę teraz wnikać w szczegóły, ale tam jest to dosyć mocno opisane, więc tym się to najbardziej różni, że jest dosyć dobrze ustalony zakres czego powinniśmy i co musimy ruszyć a czego nie powinnyśmy dotykać.

• Myślisz, że możliwa jest jakaś certyfikacja usług penetracyjnych? Czyli mam jakiś „guide” – testujemy go, a potem każda firma może wystawić jakiś wspólny certyfikat, po którym wiadomo, że to co jest testowane, jest testowane według jakiegoś standardu? Czy może po prostu tego się nie da zrobić, bo każda usługa jest indywidualna i do wszystkiego trzeba podchodzić indywidualnie?

Teoretycznie się da – bo mamy chociażby ASVS i na zgodność z nim możemy testować.

Wtedy mamy dosyć dobrze określony zakres takich testów i możemy firmę testującą z tego rozliczyć.

A też możemy naszym klientom pochwalić się później, że testowaliśmy nasz system na zgodność z jakimś standardem.

Natomiast, nie wydaje mi się, że dobrym podejściem byłoby narzucanie czegoś.

Takie w cudzysłowie „ustawowe”.

Raczej warto jest podnosić świadomość, że takie standardy jak ASVS istnieją i niech każdy sobie wybierze, czy chce swoją aplikację budować w zgodzie z tym standardem czy też nie.

Natomiast pojawiają się różnego rodzaju podejścia do certyfikacji firm bądź ludzi wykonujących testy bezpieczeństwa.

Nie słyszałem gdzieś, żeby było to wymagane – czyli, żeby była to taka licencja jak dla korporacji, detektywa, prawnika, ślusarza – jeśli już mówimy o otwieraniu czegoś.

Natomiast wiemy, że w Wielkiej Brytanii funkcjonuje chociażby CREST – czyli taki schemat według którego certyfikuje się zarówno pentesterów jak i firmy wykonujące pentesty.

Ale on jest dobrowolny.

Akurat w Wielkiej Brytanii ta dobrowolność się tak przyjęła, że w zasadzie żeby tam funkcjonować jako firma pentestowa trzeba mieć ten certyfikat.

Ale z tego co wiem, nie jest to narzucone w jakikolwiek sposób ustawowo, tylko ponieważ wszyscy przyjęli, że to jest coś dobrego – taka wspólna certyfikacja czy podstawowa weryfikacja jakości tych usług, to wszyscy to stosują.

• Prowadzenie firmy w Polsce nie jest takie proste – zwłaszcza jeśli rozpatrzymy to pod względem prawnym. A przecież atakowanie serwisów nie do końca jest legalne. Jak zatem takie testowanie trzeba „ogarnąć” od strony prawnej? No bo przecież Twoja firma coś zepsuje, to kto za to odpowiada

Trzeba sobie to „ogarnąć” w umowie z klientem.

Wyznaczyć zakres odpowiedzialności.

W przypadku testowania aplikacji najlepiej jest ten problem obejść testując na systemie testowym a nie na systemie produkcyjnym.

I my to zalecamy klientom nie tylko ze względu na nasze bezpieczeństwo wewnętrzne, ale po prostu do testowania służy system testowy – to jest logiczne.

Niektórzy mówią – OK jestem testerem funkcjonalnym. Czy mogę też zacząć testować bezpieczeństwo?

I tak i nie. Testowanie bezpieczeństwa to jest wszystko to, co nie jest funkcjonalnością.

Czyli my robimy scenariusze, wykonujemy scenariusze działań do których zwykły użytkownik nigdy nie będzie miał dostępu.

Manipulujemy tą aplikacją.

Szczerze powiedziawszy nie jesteśmy w stanie zapewnić w 100% tego, że nagle cały system informatyczny się gdzieś przy tym „nie wywróci”.

To jest poniekąd celem naszych testów.

Więc dlatego też zalecamy naszym klientom, żeby nie testować na systemach produkcyjnych tylko na systemach testowych, gdzie również przed tym ryzykiem o które spytałeś tutaj obie strony mogą się dobrze zabezpieczyć.

• Gdybyś mógł stworzyć nowy język programowania – czy postawiłbyś na jego elastyczność czy jego bezpieczeństwo?

No ja oczywiście na bezpieczeństwo – cokolwiek by to miało znaczyć.

Bo takie mam spojrzenie na to.

A bezpieczeństwo często nie idzie niestety w parze z elastycznością.

• Co liczy się bardziej – ilość błędów, czy ich jakość?

Zdecydowanie jakość.

Tak naprawdę liczy się ryzyko, ryzyko związane z istnieniem błędów w danej aplikacji, więc jeden dobry błąd, o takiej dużej wadze i takim dużym wpływie na ryzyko załatwia sprawę.

Powoduje, że cała aplikacja jest niebezpieczna albo nie powinna być wdrożona na systemie produkcyjnym.

Natomiast duża ilość małych błędów, może świadczyć źle o jakości tej aplikacji.

Natomiast da się z tym żyć.

• Czy w teście penetracyjnym można wykorzystywać socjotechnikę? A może jest to zarezerwowane tylko dla „redteamingu”?

Tutaj wkraczamy na bardzo śliski grunt nazewnictwa – co czym nazwiemy.

Prawda jest taka, że na dzień dzisiejszy testy bezpieczeństwa, weryfikacja bezpieczeństwa, redteaming i jeszcze milion innych nazw funkcjonują dosyć wymiennie.

Więc odnosząc się do wcześniejszego Twojego pytania, jeżeli ktoś nigdy nie miał do czynienia z testami bezpieczeństwa to też warto by było, żeby sobie zdefiniował co on tak naprawdę chce zrobić.

Albo co mu proponuje ta firma, która dostarcza te testy bezpieczeństwa.

Więc ciężko tutaj odpowiedzieć na to pytanie jeżeli sobie nie definiujemy zakresu.

Czasami ten zakres jest zdefiniowany tak, że OK – tutaj jest nazwa mojej firmy, proszę spróbować do mnie „wjechać” na wszystkie możliwe sposoby.

Wszystkie kroki są dozwolone.

Natomiast jeśli zakres jest zdefiniowany w taki sposób – tutaj jest bankowość internetowa na systemie testowym banku – powiedzmy bankowość mobilna.

Zbadajcie mi bezpieczeństwo tej aplikacji, to raczej tutaj miejsca na socjotechnikę za bardzo nie ma.

Chyba, że w zakres ma wchodzić też proces obsługi przez personel.

• A tak procentowo – jak dużo firm udostępnia wam swój kod źródłowy, a jak wiele firm nie chce tego robić i chce, żeby były to testy tylko i wyłącznie „black box” – czyli bez dostępu do kodu?

Na szczęście coraz więcej. Natomiast dalej nie jest to dużo procent – powiedziałbym 20% czy coś koło tego.

Natomiast coraz więcej firm da się namówić na to, żeby robić coś pośredniego – czyli „gray box”.

To znaczy – my testujemy te systemy tak jak je widzimy, ale na każdym etapie możemy zadzwonić czy spotkać się z klientem i dopytać się o to, jak ten system działa.

Albo poprosić o schemat architektury albo dowiedzieć się w jakich technologiach jest napisana dana aplikacja albo sprawdzić z jakich komponentów jest zbudowana.

I takie podejście ma uzasadnienie, bo atakujący mają cały czas tego świata na to, żeby atakować daną aplikację czy dany system.

Testujący bezpieczeństwo mają ten czas ograniczony przez budżet jaki jest wydany na testy bezpieczeństwa.

Klientowi raczej zależy, żeby budżet optymalizować.

Takie podejście „gray box” przy współpracy klienta, zwykle dosyć dobrze optymalizuje taki test.

• A myślisz, że skąd wynika ta niechęć do dzielenia się swoim kodem źródłowym?

Raczej są to jakieś obostrzenia wewnętrzne, przyjęte zasady w danej organizacji, że kod źródłowy nie powinien być pokazywany na zewnątrz.

Albo są to rzeczy związane z budżetem.

Jeżeli dają nam pełny dostęp do swojego kodu to prawdopodobnie chcą też zrobić jego przegląd.

A to jest kolejna usługa i kolejny poziom weryfikacji bezpieczeństwa.

• Jak wiele firm decyduje się na testowanie aplikacji mobilnych? Coraz więcej rzeczy robimy teraz na telefonie.

Zdecydowanie tak.

U nas jest to duży procent testów, które wykonujemy.

Nie chcę strzelać, ale pewnie koło połowy – jest 50/50 webowe kontra mobilne.

Nie mówiąc już o tym, że niektóre biznesy, mają tylko aplikację mobilną, a nie mają w ogóle interfejsów webowych.

Więc to podejście „mobile first” jest.

Większe znaczenie mają interfejsy mobilne niż interfejsy webowe.

My to widzimy zwłaszcza przy klientach z USA, gdzie czasami bywa tak, że zagląda się na stronę danej firmy i ona jest taka pisana dawno, dawno temu i nie odświeżana.

Natomiast aplikacja mobilna jest dopieszczona i bardzo nowoczesna.

• Na czym polega modelowanie zagrożeń i jakie korzyści może przynieść mojej firmie?

Ja lubię takie porównanie – to znaczy mówię, na modelowanie zagrożeń, że jest to coś w rodzaju testów penetracyjnych na kartce.

Czyli siadamy z klientem i zastanawiamy się kto i w jaki sposób może zaatakować dany system informatyczny.

Czasami ten system bądź ta aplikacja może być dopiero w fazie projektowania i wtedy to dosyć dobrze zmusza do myślenia o bezpieczeństwie i zaprojektowania właściwych mechanizmów bezpieczeństwa.

Więc pozwala uniknąć błędów, które powstaną później i są droższe do załatania.

• Czyli teoretycznie warto Twoją firmę wynająć już na etapie projektowania jakiegoś nowego produktu?

Moją lub jakąkolwiek inną, która dostarcza właściwą jakość jeśli chodzi o te kwestie bezpieczeństwa aplikacji.

W ogóle w tej chwili raczej obowiązuje takie hasło: „push to the left” – czyli przesuniecie bezpieczeństwa jak najbardziej w lewo w procesie wytwarzania oprogramowania.

Jeżeli zaczynamy od definiowania czym będzie aplikacja, przez architekturę, kodowanie i wypuszczenie tej aplikacji - to bardziej optymalnym podejściem jest zaczęcie myślenia o bezpieczeństwie jak najwcześniej w tym procesie.

A nie robimy to co nam się wydaje a na sam koniec robimy testy bezpieczeństwa.

Bo wtedy może się okazać, że podczas testów wyjdą takie podatności, które wymagają na przykład przerobienia całej architektury aplikacji.

I wtedy jest to zmiana albo bardzo kosztowna, albo niemożliwa do wprowadzenia.

Więc w rezultacie dostajemy osławione „łaty” - czyli nasza aplikacja wygląda jak ta nasza droga, która jest połatana jakimiś kawałkami asfaltu.

Wiadomo, że po takiej drodze się niezbyt płynnie i dobrze jedzie.

• Poruszyłeś temat łatania błędów. Jak przyspieszyć ten proces? Jeżeli patrzymy na publiczne programy Bug Bounty to nagle okazuje się, że sporej części firm łatanie błędów zajmuje rok, dwa lub nawet więcej.

Jeżeli dana podatność u nich nie będzie miała wystarczająco dużego priorytetu – co się może wiązać z tym, że po prostu ona nie ma dużego wpływu na ryzyko.

Ale może też wiązać się z tym, że pentester niewłaściwie wytłumaczył ryzyko albo ktoś nie był w stanie tego zrozumieć.

Dawno, dawno temu zajmowaliśmy się pewną aplikacja finansową, która opierała się na tym, że użytkownik był uwierzytelniony do systemu i potwierdzał transakcję za pomocą karty chip przypiętej do portu USB poprzez czytnik.

W tej aplikacji znaleźliśmy błąd CSRF.

Powodowało to, że w zasadzie każda strona, na której ktoś będzie razem z tym, że jest zalogowany do tej aplikacji finansowej może jakoś tam automatyzować tą aplikację.

No dobrze, ale była karta chip.

Tylko okazało się, że driver tej karty „cachował” PIN.

Co powodowało, że przez ten CSRF mogliśmy robić dowolne operacje finansowe.

I ten błąd istniał dosyć długo bo my opiekowaliśmy się tym systemem dłuższy czas.

Robiliśmy regularne testy i ciągle widzieliśmy ten błąd.

I w końcu doszliśmy do wniosku, że chyba ktoś tam nie rozumie.

To co my piszemy czarno na białym w raporcie chyba nie zostało gdzieś dobrze zrozumiane.

Bo przez cały czas managerowie z tamtej strony obniżali nam „rating” tego błędu.

I za którąś iteracją nagraliśmy film, pokazujący jak to zrobić i rezultat był natychmiastowy.

Moim zdaniem to, że firmy nie łatają błędów i że to zajmuje bardzo dużo czasu raczej wynika z tego, że ten „triage” po ich stronie jest niewłaściwy.

Jest niewłaściwe zrozumienie błędu co może też być pochodną tego, że my ten błąd jako pentesterzy źle tłumaczymy.

• Czyli wniosek jest taki, że aby ktoś coś zrozumiał należy to nagrać.

Niekoniecznie. Należy to dobrze wytłumaczyć.

A żeby dobrze wytłumaczyć trzeba przyjąć właściwe założenia odnośnie tego kto słucha.

Bo jeżeli po drugiej stronie jest zaawansowany technicznie specjalista od bezpieczeństwa to wystarczy mu napisać CSRF albo XSS i on to zrozumie.

Natomiast jeżeli po drugiej stronie jest ktoś, kto nie żyje tym bezpieczeństwem aplikacji czy IT na co dzień, to on naszego slangu po prostu nie zrozumie.

Więc trzeba mu bardzo dobrze wytłumaczyć jakie mogą być potencjalne skutki tego, że ta aplikacja będzie miała dalej tą podatność.

• Załóżmy, że pracuję w dużej firmie i jest tam jakiś zespół bezpieczeństwa, zespół pentesterów. Jak przekonać właścicieli, że potrzebne są testy penetracyjne od zewnętrznej firmy? A może one nie są potrzebne?

Odpowiem jak typowy specjalista, ekspert, doradca – to zależy.

To wynika z jakichś ustaleń wewnętrznych danej firmy bądź korporacji.

Często jest tak, że dla aplikacji o wysokim wpływie na ryzyko jest po prostu zalecenie wewnętrzne, że musi to przejść zarówno testy wewnętrzne i zewnętrzne testy bezpieczeństwa i nikt z tym nie dyskutuje.

Natomiast czasami firmy inwestują tylko w wewnętrzne testy bezpieczeństwa bo stać ich na swój dobry wewnętrzny zespół pentesterów.

Albo inwestują tylko i wyłącznie w zewnętrzne testy bezpieczeństwa, bo nie chcą mieć tego procesu u siebie.

Na pewno należy wziąć pod uwagę to, że z jednej strony ci ludzie, którzy są wewnętrznymi pracownikami czy testerami – po pierwsze z jednej strony mogą wiedzieć dużo więcej o danej aplikacji, bo robią to któryś raz, bądź znają specyfikę pracy danego teamu programistów.

Ale z drugiej strony nie mają świeżego spojrzenia na to.

• Załóżmy, że masz magiczną moc i możesz jednym pociągnięciem różdżki zmienić sposób logowania na wszystkich stronach świata. Jaki sposób byś wybrał? Czy użyłbyś biometrii, może klucza sprzętowego, a może stare sprawdzone hasła?

Trudne pytanie bo takie z cyklu wróżenia w przyszłości.

Ja może troszkę się wyłgam i powiem, w którą stronę moim zdaniem to pójdzie.

Ponieważ wszyscy mamy w kieszeniach telefony komórkowe, to ja myślę, że pójdzie to w kierunku potwierdzania swojej tożsamości na telefonach.

Tak jak to jest w tej chwili w aplikacjach bankowych przy potwierdzaniu transakcji.

Tą samą metodę możemy zastosować do uwierzytelnienia i jeżeli się to dobrze „zepnie”, to jestem w stanie założyć, że będzie to bezpieczniejsze niż hasła.

• A nie uważasz, że wtedy będzie to taki „single point of failure”? Że mamy wszystko w jednym miejscu i jeżeli ktoś nam ukradnie ten telefon to jesteśmy głęboko?

Telefon już jest single point of failure.

Każdy, kto zgubił telefon bądź komu telefon ukradli – to wie o czym mówię.

Nie ma tutaj dobrych i idealnych rozwiązań.

Wszystko trzeba dobrać do indywidualnej aplikacji.

Zwłaszcza jeśli chodzi o uwierzytelnianie to też musimy wziąć pod uwagę tak zwane „usability”.

Czyli użyteczność tych systemów.

Jeżeli tam postawimy w cudzysłowie potrójną ścianę ognia …

• I emacs przez sendmail.

Albo zrobimy jakieś „two” czy „three” FA no to raczej użytkownicy odrzucą nasz system.

Natomiast coraz więcej aplikacji odchodzi od tradycyjnego uwierzytelniania przy pomocy loginu i hasła.

Coraz częściej przerzuca to na jakichś dostawców zewnętrznych w postaci Facebooka, Google.

Ja uważam, że to też nie jest zbyt dobrym rozwiązaniem.

Jeżeli miałbym wybierać pomiędzy uwierzytelnieniem za pomocą Facebooka, Googla a uwierzytelnieniem jakąś metodą w moim telefonie to chyba wolałbym to drugie.

• Ile w pracy pentestera jest takiego rzemiosła – czyli powtarzania w kółko tych samych schematów a ile takiej finezji, czyli tworzenia czegoś nowego?

Znowu – to zależy.

Zależy od tego co się testuje.

Jeżeli te aplikacje są wszystkie podobne do siebie, to tego rzemiosła jest dużo.

Natomiast jeżeli mamy różnorodność projektów to jest więcej finezji.

My w firmie patrzymy też na to czy dany projekt będzie fajny.

Nie tylko czy da się na nim zarobić.

Po prostu dlatego, że każdy w swojej pracy się zużywa.

Tego rzemiosła nie jest dużo, ale też nie jest mało.

I najgorsze w pracy pentestera można powiedzieć jest to, że jeżeli gdzieś się wypalimy i nie będziemy na te fragmenty aplikacji, które wymagają solidnego rzemiosła, zwracać dużej uwagi to prawdopodobnie umknie nam coś istotnego.

Więc naszym lekarstwem jest „mixowanie” młodszych zawodników, dla których to co dla starszych jest trudnym rzemiosłem, dla nich jest czym świeżym.

I wtedy jeżeli dobierzemy ten zespół testujący w ten sposób to myślę, że jesteśmy w stanie utrzymać jakość.

• To może chciałbyś się czymś pochwalić? Czymś co jest publiczne dostępne, co jest stworzone przez Twoją firmę i jest po prostu fajne i mogło by zaciekawić naszych słuchaczy.

My jesteśmy raczej firmą usługową, więc dostarczamy usługi jako ten produkt, ale mamy przyjętą taką zasadę, że 20% czasu naszych specjalistów jest poświęcane na tak zwany „research”.

Czyli albo wynajdowanie nowych metod ataku, albo pisanie artykułów czy prezentacji, albo opracowywanie jakichś narzędzi, które mogą się komuś przydać do podniesienia bezpieczeństwa aplikacji.

Więc dwie rzeczy, które wypuściliśmy w ostatnich miesiącach, którymi mogę się pochwalić.

Pierwsza – iOS Security Suite napisana przez Wojtka Regułę.

To jest biblioteka do aplikacji iOS, która pozwala na zabezpieczenie ich na wykrywanie czy dana aplikacja jest uruchomiona na telefonie z „jailbreak”.

Albo czy jest podpięty debugger, czy są użyte techniki przy pomocy których ktoś próbuje manipulować w danej aplikacji.

Więc jeżeli ktoś się chce zabezpieczyć przed tego typu wektorami ataków - to polecam.

Jest to biblioteka open source dostępna na github.com/securing.

Drugą rzeczą, którą mogę się pochwalić jest SCSVS - Smart Contracts Security Verification Standard.

Napisany przez Damiana Rusinka i Pawła Kuryłowicza.

Jak sama nazwa wskazuje jest to standard weryfikacji bezpieczeństwa tak zwanych smart kontraktów. Czyli oprogramowania działającego na platformach block chain.

Więc jeżeli ktoś interesuje się tymi aplikacjami i zastanawia się jak powinno wyglądać bezpieczeństwo - to też polecam.

I również ten dokument jest dostępny na naszym GitHub.

• Smart kontrakty i kryptowaluty. Myślisz, że to przyszłość bankowości, a może to tylko taka chwilowa moda?

Bankowości to nie wiem, natomiast z tego co bardziej obracający się w tym temacie koledzy mówią i z tego jak ten rynek się rozwija – jest to technologia informatyczna, która pewnie ma jakąś przyszłość przed sobą.

Na pewno niesie ze sobą dużo ciekawych funkcjonalności.

Zwłaszcza jeżeli chodzi o rozproszenie kodu i danych.

Natomiast czy to się przyjmie rynkowo – ciężko powiedzieć.

Historia informatyki zna dużo zakrętów i nie ma tutaj żadnej pewności.

My po projektach, które realizujemy widzimy, że jest w wielu miejscach to implementowane w tej chwili.

To znaczy, że jest to jako technologia gdzieś tam pod spodem, a nie coś co widzi użytkownik.

• Czyli możemy z tego korzystać nie widząc o tym.

Podobnie jak z chmurą.

Takim popularnym „hashtagiem” parę lat temu był cloud.

Teraz – gdzie ten cloud?

Jako użytkownik nie widzimy tego.

Natomiast to, czy dana aplikacja, z której korzystamy działa gdzieś w tle na infrastrukturze chmurowej – tego my po prostu nie widzimy.

I podobnie będzie z blockchain.

Być może on tam będzie sobie w tle gdzieś działał.

Natomiast my o tym niekoniecznie jako użytkownik musimy wiedzieć i rozumieć.

Natomiast jako atakujący czy jako broniący się – zdecydowanie tak.

• Myślisz, że e-wybory są w naszym kraju możliwe?

Nie wydaje mi się, żeby Polska była jakąś specyfiką.

Można rozszerzyć to pytanie, czy bezpieczne e-wybory są możliwe.

Technicznie moim zdaniem są możliwe.

Byłbym hipokrytą, jakbym powiedział, że nie ma czegoś takiego jak bezpieczne systemy informatyczne.

Natomiast tutaj myślę, że jest trochę inny problem.

Wybory muszą być niepodważalne.

Jeżeli głosujemy na kartce papieru to każdy rozumie jak ten system działa.

Można łatwo uczynić ten system transparentnym.

Można łatwo powiedzieć wszystkim jak to działa, żeby oni to zrozumieli.

I teraz oczywiście – stosując systemy informatyczne możemy jeszcze lepiej zrobić to transparentnym (na blockchain).

Tylko pytanie, kto to zrozumie poza garstką „freaków”, którzy się interesują technologiami informatycznymi.

I problem z e-wyborami mógłby polegać na tym, że łatwo by było narobić szumu medialnego pod tytułem: „zostało sfałszowane”.

No i udowodnijcie teraz, że nie.

Masy i tak uwierzą w sensację.

• To może na koniec, jakaś rada dla słuchaczy, która podniesie bezpieczeństwo takiego zwykłego domowego użytkownika, a przy okazji nie będzie skomplikowana?

Używaj menadżera haseł.

Czyli używaj pojedynczych haseł, innych dla każdego innego serwisu i trzymaj je w bezpiecznym miejscu.

• I na tym zakończymy naszą rozmowę.

Wojtku bardzo serdecznie dziękuje Ci za poświęcony czas i za udzielone odpowiedzi.

• Dzięki!

Również dziękuję za zaproszenie.