W mechanizmach kryptograficznych wykorzystywanych w ASP.NET wykryty został błąd. Microsoft opublikował stosowny dokument: Vulnerability in ASP.NET Could Allow Information Disclosure. Informacje na temat tej podatności są nieco chaotyczne, ale z kontekstu można przypuszczać, że pozwala ona nie tylko na rozszyfrowanie danych i ustalenie klucza, którym zostały zaszyfrowane.
Ciąg dalszy "Wyrocznia w ASP.NET" »Saturday, September 18. 2010
Wednesday, September 15. 2010
HOTP i OCRA
HMAC-based One Time Password jest opublikowanym w 2005 roku algorytmem, który służy do generowania haseł jednorazowych. Hasło to generowane jest w oparciu o unikalny dla każdego tokenu tajny, ale współdzielony z serwerem klucz, oraz licznik. Ze szczegółami algorytmu można zapoznać się w RFC4226.
OCRA czyli OATH Challenge-Response Algorithms (przy okazji warto zapoznać się z OATH) to algorytm, a właściwie ich zbiór, który oferuje uwierzytelnienie typu challenge-response. Jedno lub dwustronne. Szczegóły można znaleźć w dokumencie OCRA: OATH Challenge-Response Algorithms.
Algorytm OCRA w najbardziej ogólnym przypadku można przedstawić w sposób następujący:
OCRA = CryptoFunction(K, DataInput)
Gdzie wejściem do funkcji CryptoFunction są:
- Klucz ,
- inne dane, określone jako DataInput,
Do specjalistów od PR słów klika
Szanowni Wysokiej Klasy Specjaliści od PR!
Cieszę się, że mój blog został uznany za wystarczająco interesujący, by znaleźć się w obszarze Państwa zainteresowania. Jednakże gdyby Państwo zadali sobie odrobinę trudu i zapoznali się z jego zawartością, niewątpliwie zauważylibyście, że nie publikuję na nim notatek prasowych. Skoro do tej pory nie opublikowałem żadnej notatki prasowej, co każe Państwu przypuszczać, że zrobię wyjątek dla informacji nadesłanej akurat przez Państwa?
Uprzejmie proszę proszę o zaprzestanie zaśmiecania mojego czasu marketingowym bełkotem. Z naciskiem na bełkot.
Z góry dziękuję!
Monday, September 13. 2010
I śmiech niekiedy może być nauką
Używanie tego samego hasła w wielu serwisach jest ZŁE! Ta historyjka pokazuje dlaczego. No, przynajmniej jeden możliwy scenariusz. Przy okazji wyjaśnieniu ulega kwestia, dlaczego Google nie jest Evil i nie przejmuje kontroli nad światem :)
Ciąg dalszy "I śmiech niekiedy może być nauką" »Tuesday, September 7. 2010
OR 1=1 -- na banlistę
Jednym ze sposobów exploitowania sql injection jest wyświetlenie większej ilości danych poprzez zmianę warunków zapytania SQL. Można to zrobić w prosty sposób poprzez dopisanie do zapytania OR z warunkiem, który zawsze będzie prawdziwy. Z tą techniką jest jednak jeden problem - tak zmodyfikowane zapytanie zwraca często dużo danych. Na tyle dużo, że aplikacja może sobie nie poradzić z ich przetworzeniem i z SQLi robi się wyjątkowo skuteczny atak DoS... Technika z AND jest jednak nieco bezpieczniejsza. A jeśli już OR, to warto dodać limity na ilość zwracanych danych.