Paweł Goleń, blog

Właśnie przygotowuję się do kolejnej edycji szkolenia z bezpieczeństwa aplikacji internetowych. W tak zwanym międzyczasie miało miejsce kilka spektakularnych wycieków haseł i hashy haseł.

Tak w ramach ciekawostki polecam zapoznanie się z artykułem Our password hashing has no clothes. Troy Hunt pokazuje w nim eksperymentalnie jak efektywne może być łamanie hashy haseł z wykorzystaniem kart graficznych (w tym wypadku: AMD Radeon HD 7970). W tym wypadku atakowane były hashe SHA1, wykorzystany był salt. Jest to o tyle istotne, że ten sposób przechowywania haseł jest domyślny w ASP.NET jeśli korzysta się z domyślnego providera (choć to się zmienia: Stronger password hashing in .NET with Microsoft’s universal providers).

Dla porządku napiszę to jeszcze raz – jeśli masz przechowywać hasła, korzystaj z czegoś w rodzaju bcrypt, scrypt czy PBKDF2. Pamiętaj, że nawet wówczas hashe haseł nie są nieśmiertelne. Kupujesz im tylko trochę więcej czasu.

I ponownie porada dla użytkowników:

  • używaj długich, złożonych haseł,
  • używaj różnych haseł w różnych serwisach,
  • korzystaj z narzędzi do zarządzania/przechowywania haseł (np. KeePass),
  • okresowo zmieniaj hasła,

Oryginał tego wpisu dostępny jest pod adresem Czas sobie mija... Hasła dalej ciekną

Autor: Paweł Goleń

OWASP ASVS jest fajny, ale są takie punkty na tej liście, które są dyskusyjne i trochę zależą od interpretacji, albo nie zawsze pasują do wykorzystanego w danym przypadku środowiska. Dziś trochę na temat jednego z takich punktów dotyczącego zarządzania sesją:

V3.2 Verify that sessions are invalidated when the user logs out.

Czytaj dalej...

Gynvael już wspomniał o konferencji Security BSIDEs Polska, umieścił również agendę, z której jasno wynika, że pojawię się na niej. Konkretnie będę mówił o aplikacjach mobilnych, dokładniej o mechanizmach uwierzytelnienia w tych aplikacjach i o tym, jak mechanizm ten można spektakularnie zepsuć...

Oryginał tego wpisu dostępny jest pod adresem Security BSIDEs Polska

Autor: Paweł Goleń

Ciekawy przypadek: Jak zostać słupem? Czyli fałszywe oferty pracy “testera bankowości”. Nie pozostaje nic innego, jak z dużą dozą nieufności realizować jakikolwiek przelew. Bo w końcu skąd mamy wiedzieć, że ten rachunek sprzedawcy na allegro to rzeczywiście jego rachunek, a nie rachunek “techniczny” do aktywacji konta w innym banku? Skąd dane osobowe? Adres dostawy, dane do faktury... Znajdzie się kilka pomysłów.

Mnie pomysł z potwierdzaniem tożsamości przy pomocy przelewu podoba się umiarkowanie. Podejście to zakłada, że:

  • posiadacz konta ma nad nim przez cały czas wyłączną kontrolę,
  • posiadacz konta wie, co robi,

W ogólności spełnienie tych dwóch powyższych warunków wcale nie jest takie oczywiste. Opisywany atak wykorzystywał social engineering (często najłatwiejszy sposób ataku), ale warto też pamiętać, że przelewy na niewielkie kwoty w części banków nie wymagają autoryzacji (mechanizm heurystyczny decydujący, czy dana transakcja powinna być autoryzowana, czy nie).

Zanim ktoś zacznie tyradę typu “ale głupi ci rzymianie” przypominam, że banki działają zgodnie z prawem, co wspominał dokładnie w komentarzu Piotrek Konieczny. Szczerze mówiąc ciekawy jestem, jak sprawa się rozwinie. Podpisywanie umowy z klientem przez internet jest dla banków wygodne. Te banki, które chcą szybko zbudować sobie bazę klientów z tego typu rozwiązań chętnie korzystają i mam wątpliwości, czy będą z nich chciały zrezygnować. Ciekawy jestem również tego, jak zakończą się ewentualne spory między bankami a ich nie do końca(?) klientami.

Oryginał tego wpisu dostępny jest pod adresem Łańcuch kontroli

Autor: Paweł Goleń

No i wrócił do mnie mój laptop, matryca znów świeci, a całość zamknęła się w absolutnie akceptowalnych pieniądzach. Okazało się, że zarówno świetlówka, jak i inwerter były OK (może lekko sponiewierane, ale działające i o parametrach mieszczących się w normie). Problemem okazał się być drucik, który postanowił się przepalić. Jeśli ktoś przypadkiem potrzebowałby serwisu sprzętu komputerowego, mogę dodać do listy możliwości ten, z którego usług korzystałem tym razem: TEDENET ITSERVICE.

Chciałem podziękować wszystkim za komentarze pod poprzednim wpisem, zarówno te dotyczące potencjalnych powodów awarii i możliwości ich usunięcia, jak i te związane z wyborem sprzętu. Zainteresowała mnie na przykład informacja o wadzie w kartach Nvidii. Dziękuję również za propozycję pomocy z moim drobnym problemem związanym z polskojęzyczną wersją systemu.

Jeśli chodzi o moją obecną matrycę w tym D520 to jest to 1400x1050. W SL500 mam już matrycę panoramiczną 1680x1050, mój (nie koniecznie) nowy laptop musi mieć co najmniej taki obszar roboczy, przy czym raczej skłaniam się ku matrycy wielkości 15”. Jako drugi monitor w tej chwili podłączyłem sobie LCD z komputera stacjonarnego, który odszedł do wieczności, o rozdzielczości 1280x1024. Niby niewiele mniej, a jednak już trochę brakuje...

Swoją drogą człowiek ma wiele różnych przyzwyczajeń. Pamiętam jak długo opierałem się przed nabyciem sprzętu z matrycą panoramiczną. Gdy już zostałem do tego zmuszony, jakoś się przekonałem do tego rozwiązania, choć uparłem się na większą niż “standardowo” rozdzielczość. Może i tak samo przekonałbym się do matrycy 14” albo polskiego systemu? :)

Mam nadzieję, że przez niekoniecznie najbliższy czas nie będę miał bardziej lub mniej ciekawych tematów dotyczących (nie)działania sprzętu.

P.S. Tak z zupełnie innej beczki – postanowiłem sobie nabyć w miarę szybką kartę SD i wykorzystać ją w tym SL500 pod ReadyBoost. Nie mogę powiedzieć, bym odczuwalnie doświadczał jakiejś wielkiej różnicy, ale według perfmon cache działa.

Oryginał tego wpisu dostępny jest pod adresem Fin de siecle II: Happy ending

Autor: Paweł Goleń

Jakiś mroczny psuj grasuje w moim sprzęcie komputerowym. Wczoraj mój laptop postanowił przestać podświetlać matrycę. Albo inaczej – samo podświetlanie działa, ale błyskawicznie się wyłącza. Jeśli dobrze posłuchać, to można usłyszeć ten charakterystyczny “śpiewający” dźwięk padającej elektroniki, a w chwili wyłączenia matrycy – pyknięcie.

Czytaj dalej...

Punkt A1 Injection nie dotyczy tylko błędów typu SQL Injection. Coraz częściej dostęp do danych jest realizowany za pośrednictwem jakiejś warstwy abstrakcji (np. ORM). Użycie tego typu rozwiązań nie gwarantuje odporności na błędy typu injection, np. CWE-564: SQL Injection: Hibernate.

Czytaj dalej...

W piątek mój bardzo stary komputer zakończył swój żywot. Bardzo stary, bo jego początek datował się gdzieś w okolicy roku 2001- 2002. Najpierw uporczywie rzucał BSOD, a potem zaśmierdział paloną elektroniką. Najwięcej zabawy miałem jednak z odzyskiwaniem danych z dysków. Nie to, by się uszkodziły, ale nie było też tak, że mogłem sobie dysk po prostu podpiąć i odczytać dane.

Czytaj dalej...

Szooooook! Alior Sync: internauci skarżą się na limit znaków w haśle.

A mnie to Lotto. Szansa na trafienie szóstki to 1:13 983 816. Hasło o długości 10 znaków składające się z samych małych liter to 141 167 095 653 376 możliwości. Nawet zakładając, że jest 10 prób na zgadnięcie hasła, to i tak mam większe szanse na zgarnięcie puli w kumulacji, niż trafienie we właściwe hasło. A jak już mi się przypadkiem uda trafić w prawidłowe hasło, to się okaże, że nadal nie mogę wyprowadzić pieniędzy, bo jest jeszcze coś, co się nazywa autoryzacja transakcji.

PIN karty to (zwykle) 4 cyfry. Tylko 10000 możliwości, a jednak samo skopiowanie paska magnetycznego nie wystarcza, jeszcze skimmerzy po coś montują te kamerki...

Oryginał tego wpisu dostępny jest pod adresem Hasło nie jest (aż tak) ważne

Autor: Paweł Goleń

Od dłuższego czasu mam pewną ideę. Pisałem już dawno temu, że jestem znudzony wyszukiwaniem podstawowych dość podatności związanych z walidacją danych wejściowych, kodowaniem na wyjściu, prostymi przypadkami SQL injection czy błędami kontroli dostępu do funkcji i do danych. Wyszukiwanie podstawowych przypadków tych wymienionych podatności to praca mozolna, metodyczna, ale również do pewnego stopnia mechaniczna. Nie twierdzę, że w czysto mechaniczny sposób uda się zidentyfikować 100%25 podatności tego typu, z doświadczenia jednak wiem, że jeśli w aplikacji są podatności, to często występują również takie proste błędy.

Moja idea zakłada(ła) nauczenie testerów funkcjonalnych prostych technik, które pozwolą na zidentyfikowanie wymienionych typów podatności. Muszę przyznać jednak, że pomysł ten muszę chyba jednak w pewnym stopniu zrewidować. Teraz coraz bardziej dochodzę do wniosku, że oprócz nauczenia tego, jak mechanicznie szukać prostych podatności, konieczne jest obudzenie w ludziach ukrytego upierdliwca/anarchisty/destruktora.

Czytaj dalej...