Kilka ciekawych komentarzy pojawiło się pod wpisem Ataki czasowe na OpenID i OAuth. Szczególną uwagę chciałbym zwrócić na kilka z nich.
Po pierwsze dwa komentarze Gynvaela. Pierwszy komentarz dotyczy (nie)skuteczności losowych opóźnień w trakcie uwierzytelnienia w kontekście ataków timing attacks. Drugi z nich z kolei dotyczy tego, jak działa operator równości dla stringów. Temat ten został poniekąd wywołany przeze mnie w dwóch komentarzach (pierwszy komentarz, drugi komentarz). Być może wrócę do tematu jak zmienia się czas porównania stringów w zależności od tego, gdzie się różnią. O ile będę miał trochę czasu na eksperymenty.
Drugi ciekawy temat podniósł Radekk. Twierdzi on, że wstawianie sztucznych opóźnień (sleep) do aplikacji jest złym pomysłem, gdyż może ułatwić atak DoS. Konkretnie wariant ataku polegający na wyczerpaniu dostępnych wątków/procesów. Jego uwaga jest słuszna, aczkolwiek warto zwrócić też uwagę na “otoczenie” takich opóźnień w aplikacji, o czym z kolei wspominałem ja. Po prostu w niektórych przypadkach wstawienie umiarkowanego sztucznego opóźnienia do aplikacji nie będzie miało istotnego wpływu na łatwość wykonania ataku typu DoS według opisywanego scenariusza.
Jeśli pojęcie koniunkcji nie jest Wam obce, doskonale wiecie, że jest ona przemienna. Przemienna, czyli a i b == b i a (że to w taki sposób zapiszę). W zasadzie jest to prawda. Prawie. A prawie robi różnicę.
Dziś dwa przykłady, w których na podstawie pewnych przesłanek wyciągnięty zostały pewne wnioski. Co w tym ciekawego? To, że wnioski te były nie do końca uzasadnione.
Jadę dzisiaj sobie spokojnie, jadę i coś mi nie pasuje. Nie wiem co, nie potrafię tego nazwać, ale nic to, jadę sobie dalej. Dojeżdżam do mostku, za którym zjeżdżam z drogi na ścieżkę i... OLŚNIENIE. Samochodem to ja tędy nie przejadę, tą trasą to ja jeżdżę na rowerze :)
Song et al showed that because SSH is an interactive remote shell service and typing different keystroke-combinations naturally produces slight timing characteristics, a network eavesdropper can build a Hidden Markov Model (HMM) to infer the keystrokes. When applied to guess a password, the attack achieves a 50-time speedup compared to a brute-force guessing attack, i.e., more than 6-bit reduction of the password’s entropy.
Małe podsumowanie komentarzy do wpisu Jak badać wygodę mechanizmów bezpieczeństwa? Komentarzy nie ma za wiele, więc nie chcę na ich podstawie wyciągać jakichś fundamentalnych wniosków.
Zdaję sobie sprawę, że komentarze na blogu są wykorzystywane również do pozycjonowania innych stron. Mógłbym dodać atrybut nofollow dla linków do stron komentujących, ale nie chcę tego robić. Wiem, że część komentujących trafia tu właśnie tylko po to, by zostawić link do swojego/reklamowanego serwisu. Jeśli komentarz składa się więcej niż z jednego słowa i ma minimum sensu, zostawiam go. Niektóre są śmieszne, na przykład ten komentarz:
przez przypadek zajrzałem na tego bloga. zacząłem czytać wpisy i doszedłem do tego. Szacunek! naprawdę – szacunek za wytrwałość:)
Cóż, zgodnie z filozofią wszyscy kłamią (której wyznawcą byłem na długo przed pojawieniem się pierwszego odcinka Dr House) spojrzałem w logi i...
Autor komentarza trafił na moją stronę najprawdopodobniej szukając miejsc, gdzie może zostawić link, który nie zostanie oznaczony atrybutem nofollow. Rzeczywiście, “przez przypadek” tak jest na mojej stronie.
Z tym czytaniem wpisów to też przesada, bo po otwarciu głównej strony po około minucie otwarty został komentowany wpis. Przy okazji ciekawa sprawa – po co przeglądarka komentującego pobierała pliki robots.txt oraz sitemap.xml? Jakaś wtyczka SEO? Wizyta zakończyła się zostawieniem komentarza. Jakoś przeglądania wpisów ani przed, ani po zostawieniu komentarza nie było.
Jak powiada staropolskie przysłowie: bujać to my, a nie nas.
Powoli dojrzewam do istotnej decyzji... Ten blog powstał w 2006 roku, to już cztery lata temu. Coś, co powstało w wyniku typowej nudy ludzi zajmujących się IT, nudy zabijanej tym komiksem, że o tym “teledysku” nie wspomnę, wyewoluowało do obecnej postaci. Ale w tak zwanym międzyczasie nastał Zmierzch...
Tak, zastanawiam się nad zmianą nazwy bloga, bo ja to tak trochę z innej bajki jestem. A z ciekawych książek “o wampirach” polecam:
We wpisie 6 mitów związanych z badaniami użyteczności można przeczytać, że już w badaniach z udziałem 5 użytkowników można zidentyfikować większość problemów z użytecznością aplikacji. Zapewne w większości przypadków jest to prawda, ale mimo wszystko mam problem z tematem badania user experience mechanizmów bezpieczeństwa. Wiadomo, że końcowe rozwiązanie to zawsze kompromis między bezpieczeństwem a wygodą użytkowania. Co ma zrobić osoba techniczna, odpowiedzialna za projektowanie mechanizmów bezpieczeństwa? Jak może poznać zdanie zwykłego użytkownika i dostosować tworzone mechanizmy do tych, którzy będą z nich korzystali?