Długość hasła do konta Microsoft

Home

Niektóre decyzje giganta z Redmond podobają mi się, inne mniej, a niektóre w ogóle. Pół biedy kiedy kryje się za tym jakaś logika, ale niektórych rzeczy po prostu nie mogę zrozumieć. Ostatnio chciałem zmienić swoje hasło do konta Microsoft i niezmiernie się zdziwiłem kiedy okazało się, że moje hasło jest za długie gdyż miało więcej niż 16 znaków. WTF! W ogólności to nie nowa rzecz ale ja spotkałem się z nią pierwszy razo.

Na tym jednak nie koniec. Jakiś czas potem natknąłem się na to wytłumaczenie. Okazuje się, że hasła zawsze były ograniczone do 16 znaków, a jeśli wprowadzono dłuższy ciąg znaków to było to ignorowane. Teraz zamiast wydłużyć maksymalną dopuszczalną długość postanowiono nie pozwolić na wprowadzenie zbyt długich haseł, bo i po co użytkownik ma się męczyć i nadwyrężać pamięć.

Osobiście nie widzę żadnego "pozytywnego" argumentu za takim limitem na długość hasła. "negatywnym"  i moim zdaniem dość prawdopodobnym  argumentem może być to, że ileś lat temu podjęto błędną decyzję i odkręcenie tego teraz jest trudne i kosztowne.

Oczywiście Microsoft nie jest jedyną firmą, która narzuca "dziwne" ograniczenia na hasła. Tym niemniej jako firma o zasięgu globalnym, mająca setki milionów użytkowników, wypuszczająca rożnego rodzaju rekomendacje dotyczące bezpieczeństwa...  powinna zająć się również takimi podstawowymi rzeczami.

Liczba błędów/KLOC

Home

KLOC (ang. Kilo Lines Of Code) to bardzo stara miara złożoności programów na podstawie liczby linii kodu. Z pewnością ma wiele wad, bo jak porównywać kod w C/C++ z kodem w Java czy C#. Czy jako linie kody powinno liczyć się komentarze lub importy przestrzeni nazw, co z kodem generowanym automatycznie itd. Wszystko to prawda, ale osobiście uważam, że ta miara jednak coś mówi. Ostatnio natknąłem się na bardzo ciekawe dane dotyczące liczby błędów/KLOC.

W książce Code Complete Steve McConnell pisze, że średnia wynosi 15-50 błędów/KLOC dla produkcyjnego kodu (jak dla mnie dużo), a Microsoft osiąga podobno wynik 0.5 błędów na tysiąc linii produkcyjnego kodu. W publikacji Number of faults per line of code Myron Lipow cytuje zbliżone wyniki, czyli 5 do 30 błędów/KLOC. Metoda Cleanroom software engineering opracowana przez IBM pozwoliła osiągnąć w niektórych projektach dużo lepsze wyniki. W projektach prowadzonych przez NASA osiągnięto natomiast oszałamiający wynik zero błędów na 500 tysięcy linii kodu. Czemu się jednak dziwić. Na stronie The Flight of STS-1 można znaleźć informację, że NASA wydawała 1000$ na wyprodukowanie jednej linii kodu!!!, podczas gdy średnia przemysłowa na tamte czasy to 50$.

Źródła jakie zacytowałem są dość albo nawet bardzo stare. Sądzę jednak, że współczesne systemy są coraz bardziej skomplikowane i nawet pomimo zastosowania nowoczesnych narzędzi i techniki wyniki będą podobne. Według prezentacji ThoughtWorks z 2007 średnia liczba błędów na tysiąc linii kodu to 5 przy średnim koszcie wyprodukowania jednej linii kodu 5$ (wliczając testy, dokumentację itd.). NASA płaci natomiast 850$ za linię aby obniżyć współczynnik do 0.004 błędów/KLOC.

Pracowałem przy projekcie, w którym udało się uzyskać bardzo dobry wynik 0.23 błędów/KLOC przy czym dużo zmian zostało wprowadzonych przez stworzone przez zespół narzędzia do automatycznej modyfikacji kodu. Jestem ciekawy Waszych opinii na temat tej miary? Jaki wynik uważacie za dobry?

Co robię z poufnymi...

Home

Post ten jest częściowo powiązany z poprzednim, w którym napisałem, jak podchodzę do bezpieczeństwa swoich danych. Tym razem opiszę, jak pozbywam się poufnych danych...

Zacznijmy od papierowych dokumentów, które są już nam do niczego potrzebne. Pomimo tego, że staram się ograniczyć ich "produkcję", to trochę się tego zbiera: paragony ze sklepów, rachunki, faktury, stare umowy, wyciągi z banków itd. Przynajmniej na części z nich można znaleźć nasze dane teleadresowe i na przykład powiązać wyciąg z banku z mieszkaniem numer X przy ulicy Y. Może i jestem przewrażliwiony, ale ja takich rzeczy nie wyrzucam do kosza. Już dawno temu sprawiłem sobie niszczarkę firmy Fellowers i wszystkie poufne dokumenty lądują właśnie w niej.

Podejście do poufnych dokumentów rozciąga się również na świat elektroniczny. Kiedy jakiś czas temu miałem problemy z telefonem i musiałem oddać go na gwarancję, usunąłem z niego wszystkie dane. Ponieważ jednak nie byłem pewny gdzie dokładnie trzymane są hasła do mojego konta Google oraz kont pocztowych na wszelki wypadek, przed oddaniem sprzętu do serwisu, zmieniłem hasła. Kiedy wyciekły hasła z portalu LinkedIn, to, pomimo tego sądzę, że moje oparłoby się metodzie słownikowej, a jego złamanie zajęłoby trochę czasu, bez zastanowienia je zmieniłem.

Rok temu chciałem zezłomować stary, niedziałający laptop. Niejeden pewnie wyrzuciłby go do kosza lub oddał to wyznaczonego punktu. I jak tak rozbiłem, ale wcześniej wyciągnąłem z niego dysk. Z jednej strony był jeszcze sprawny, a z drugiej po co ryzykować. Jeszcze nie potrzebowałem tego robić ale gdybym chciał się pozbyć dysku to najpierw użyłbym jakiegoś narzędzia do zamazywania danych (na przykład CCleaner), potem go sformatował, a na koniec uszkodził go fizycznie choćby przy pomocy młotka ;)

Co jeśli chcę usunąć jakieś pojedyncze pliki z dysku? W większości wypadków po prostu je usuwam i opróżniam Kosz, choć ta operacja tak naprawdę nie gwarantuje fizycznego usunięcia danych z dysku. W 99.9% przypadków to mi jednak wystarcza. Kiedy zależy mi na bezpowrotnym wymazania danych postępuję inaczej. Kiedyś korzystałem z opcji Wipe programu PGP. W tej chwili przestawiłem się na GPG, który nie posiada tej funkcji, a więc testuję program shred z pakietu GNU CureUtils. Jeśli nie chce się Wam używać takich narzędzi, to, moim zdaniem, przed usunięciem pliku warto przynajmniej otworzyć i nadpisać jego zawartość.

Jak zabezpieczam swoje dane

Home

Post ten będzie dotyczył rzeczy, na której mam chyba drobnego hopla, czyli tego jak zabezpieczyć się przed utratą danych np.: w wyniku kradzieży komputera. Moje podejście jest proste, aby czuć się bezpiecznym muszę posiadać 3 niezależne, fizycznie od siebie oddalone kopie swoich danych: na domowym komputerze oraz na dwóch dyskach przenośnych z czego jeden trzymam daleko poza domem. Tą drugą lokalizacją może być dom rodziców, skrytka bankowa, dom przyjaciela itd. Dysk trzymany w domu, po każdorazowym wykonaniu kopii bezpieczeństwa, zamieniam z tym drugim.

Do tworzenia kopii bezpieczeństwa nie używam jakiegoś specjalnego oprogramowania. Wszystkie dane, które są dla mnie istotne trzymam na komputerze w jednym miejscu, a więc zrobienie kopii polega na podłączeniu dysku i skopiowaniu na niego kilku folderów. Jeśli nie możecie znieść myśli o robieniu czegoś ręcznie ;) to łatwo to zautomatyzować. Dla mnie to zbyteczne, bo te kilka minut mnie nie zbawi. Takie kopie staram się wykonywać raz w miesiącu.

Do tematu szyfrowania kopii swoich danych podchodzę w ten sposób, że szyfruję tylko niektóre rzeczy np.: listy haseł, listy wydatków. W tym celu używam programu PGP/GPG oraz bardzo długiego i skomplikowanego hasła. Nie szyfruję wszystkiego ponieważ zajmuje to czas, a ja nie posiadam danych, których wyciek mógłby mi lub komuś zaszkodzić czy też skompromitować (to najlepsze z możliwych zabezpieczeń).

Jeśli pracuję nad czymś ważnym i nie mogę sobie pozwolić na czekanie do kolejnego backupu wykorzystuję Internet. Kiedyś wysyłałem archiwum na maila, teraz korzystam z dysków w chmurze. Przy czym, jeśli zależy mi na poufności danych, archiwum na wszelki wypadek zabezpieczam hasłem. Nie przypuszczam aby ktoś mnie szpiegował, ale przezorny zawsze zabezpieczony.

To prosty, ale mam nadzieję, że skuteczny system. Z mojej perspektywy najważniejsze jest fizyczne oddalenie od siebie kopii bezpieczeństwa. Jeśli w mój dom trafi meteoryt to zawsze pozostanie ta jedna kopia, nawet jeśli trochę stara. A Wy jak dbacie o swoje dane?

Warto też edukować swoją rodzinę i znajomych. Na przykład kupić im na Święta Bożego Narodzenia przenośny dysk i wytłumaczyć jak ważne jest robienie kopii zapasowej od czasu do czasu. Sądzę, że każdy ma jakieś dane warte zabezpieczenia: zdjęcia rodzinne, praca licencjacka, praca magisterska, kopia dokumentów urzędowych...

Metody rozszerzające w .NET 2.0

Home

.NET 2.0 to stara rzecz, ale wciąż z różnych powodów używana, na przykład dlatego, że klient nie chce zainstalować nowej wersji platformy na maszynach wszystkich użytkowników systemu. A co, jeśli pomimo tego wymarzy się nam użycie na przykład LINQ to Objects? Metody takie jak Select, Take itd. łatwo zaimplementować samemu, ale bez extensions methods ich użycie nie będzie takie przyjemne.

Zastanówmy się, co z tym robić. Metody rozszerzające obsługiwane są począwszy od .NET w wersji 3.5. Wiemy też, że mając kompilator dla .NET w wersji X możemy skompilować projekt dla .NET w wersji Y jeśli Y <= X. Do tego dodajmy, że extensions methods są mechanizmem czasu kompilacji i jako takie są niezależne od wersji platformy. Idąc tym tokiem rozumowania powinno być możliwe ich wykorzystanie w projektach używających .NET 2.0 o ile do kompilacji użyjemy nowszego kompilatora. Szybki eksperyment, czyli próba zdefiniowania metody rozszerzającej dla projektu używającego .NET 2.0 pokaże jednak, że coś jest nie tak i otrzymamy taki błąd kompilacji:

Cannot define a new extension method because the compiler required type 'System.Runtime.CompilerServices.ExtensionAttribute' cannot be found. Are you missing a reference?

Nie wszystko jednak stracone. Okazuje się, że wystarczy zdefiniować w projekcie następujący atrybut aby kompilacja zakończyła się powodzeniem:

namespace System.Runtime.CompilerServices
{
    [AttributeUsage(AttributeTargets.Assembly | AttributeTargets.Class | AttributeTargets.Method)]
    public sealed class ExtensionAttribute : Attribute { }
}

Trochę to brzydkie, ale możemy cieszyć się metodami rozszerzającymi w projektach korzystających ze starej wersji platformy. Atrybut ten jest potrzebny, ponieważ kompilator wykorzystuje go do oznaczenia metod tak, aby było wiadomo, które metody z różnych bibliotek są metodami rozszerzającymi.

Sztuczkę tą wykorzystują projekty takie jak LINQ for .NET 2.0 lub LinqBridge