Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00416 007367 11264322 na godz. na dobę w sumie
Bezpieczeństwo tożsamości i danych w projektach Web - ebook/pdf
Bezpieczeństwo tożsamości i danych w projektach Web - ebook/pdf
Autor: , Liczba stron:
Wydawca: Promise Język publikacji: polski
ISBN: 978-83-7541-329-8 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie
Porównaj ceny (książka, ebook, audiobook).

Najlepsze praktyki
Nie ma tygodnia, byśmy nie usłyszeli o kolejnym wycieku danych klientów, przechwyconych numerach kart kredytowych lub kradzieży tożsamości. Znalezienie właściwego kompromisu pomiędzy wygodą użytkowania a bezpieczeństwem aplikacji lub witryny może być niezwykle trudne. Ta praktyczna książka pokazuje podejście nastawione na wyniki, pozwalające osiągnąć obydwa cele bez rezygnowania z najważniejszych cech każdego.
Zwraca uwagę nie tylko na to, co trzeba mieć na uwadze podczas budowania systemu, ale przede wszystkim, jak tworzyć solidną infrastrukturę przy użyciu mechanizmów, które są zarazem użyteczne, jak i bezpieczne. Dzięki temu możliwe będzie wzmocnienie infrastruktury chroniącej dane i zastosowanie sprawdzonych technik chroniących przed włamaniami i wyciekami danych. Przedstawione są również przyszłe, projektowane technologie, które będą miały wpływ na bezpieczeństwo danych i tożsamości.
¦    Omówienie dzisiejszego stanu zabezpieczeń witryn i aplikacji Web
¦    Projektowanie szyfrowania haseł i zwalczanie typowych ataków na hasła
¦    Tworzenie cyfrowych odcisków palców w celu identyfikowania użytkowników poprzez ich przeglądarkę lub urządzenie
¦    Budowanie systemów bezpiecznej transmisji danych przy użyciu OAuth i OpenID Connect
¦    Stosowanie alternatywnych metod identyfikacji jako drugiego składnika uwierzytelniania
¦    Uodpornianie aplikacji na ataki
Jonathan LeBlanc jest laureatem nagrody Emmy w dziedzinie oprogramowania, autorem oraz szefem działu Global Developer Advocacy w firmie PayPal. Specjalizuje się w zagadnieniach tożsamości, autoryzacji i zabezpieczeń, łączności sieciowej i technikach drążenia danych.
Tim Messerschmidt zajmuje stanowisko Program Manager of Developer Relations w Google, kierując regionem obejmującym Niemcy, Austrię i Szwajcarię (DACH). Przed dołączeniem do Google kierował zespołami Developer Evangelism firm PayPal i Braintree w regionie obejmującym Europę, Bliskim Wschód i Afrykę (EMEA) oraz Azję i Pacyfik (APAC).
„To świetna książka zarówno dla nowicjuszy, jak i doświadczonych programistów. Prezentuje podstawy i szybko przechodzi do tego, jak i dlaczego wszystko funkcjonuje, pokazując mnóstwo przydatnych fragmentów kodu. Pozycja obowiązkowa dla każdego projektanta Web.”
—Lenny Markus
Sr. Manager, PayPal Engineering

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Bezpieczeństwo tożsamości i danych w projektach Web Jonathan LeBlanc Tim Messerschmidt przekład: Marek Włodarz APN Promise Warszawa 2016 ##7#52#aSUZPUk1BVC1WaXJ0dWFsbw== Bezpieczeństwo tożsamości i danych w projektach Web © 2016 APN PROMISE SA Authorized translation of English edition of Identity and Data Security for Web Development ISBN 978-1-491-93701-3 Copyright © 2016 Jonathan LeBlanc, Tim Messerschmidt. All rights reserved. This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls of all rights to publish and sell the same. APN PROMISE SA, ul. Domaniewska 44a, 02-672 Warszawa tel. +48 22 35 51 600, fax +48 22 35 51 699 e-mail: mspress@promise.pl Wszystkie prawa zastrzeżone. Żadna część niniejszej książki nie może być powielana ani rozpowszechniana w jakiejkolwiek formie i w jakikolwiek sposób (elektroniczny, mechaniczny), włącznie z fotokopiowaniem, nagrywaniem na taśmy lub przy użyciu innych systemów bez pisemnej zgody wydawcy. Logo O’Reilly jest zarejestrowanym znakiem towarowym O’Reilly Media, Inc. Fluent Python, ilustracja z okładki i powiązane elementy są znakami towarowymi O’Reilly Media, Inc. Wszystkie inne nazwy handlowe i towarowe występujące w niniejszej publikacji mogą być znakami towarowymi zastrzeżonymi lub nazwami zastrzeżonymi odpowiednich firm odnośnych właścicieli. Przykłady firm, produktów, osób i wydarzeń opisane w niniejszej książce są fikcyjne i nie odnoszą się do żadnych konkretnych firm, produktów, osób i wydarzeń. Ewentualne podobieństwo do jakiejkolwiek rzeczywistej firmy, organizacji, produktu, nazwy domeny, adresu poczty elektronicznej, logo, osoby, miejsca lub zdarzenia jest przypadkowe i niezamierzone. APN PROMISE SA dołożyła wszelkich starań, aby zapewnić najwyższą jakość tej publikacji. Jednakże nikomu nie udziela się rękojmi ani gwarancji. APN PROMISE SA nie jest w żadnym wypadku odpowiedzialna za jakiekolwiek szkody będące następstwem korzystania z informacji zawartych w niniejszej publikacji, nawet jeśli APN PROMISE została powiadomiona o możliwości wystąpienia szkód. ISBN: 978-83-7541-209-3 Projekt okładki: Karen Montgomery Ilustracje: Rebecca Demarest Przekład: Marek Włodarz Korekta: Ewa Swędrowska Skład i łamanie: MAWart Marek Włodarz ##7#52#aSUZPUk1BVC1WaXJ0dWFsbw== Spis treści Przedmowa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii 1 Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Problemy z obecnymi modelami zabezpieczeń. . . . . . . . . . . . . . . . . . . . . . . . . . . .1 Kiepskie hasła . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 Bezpieczeństwo kontra użyteczność . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 Niewłaściwe szyfrowanie danych. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 Najsłabsze ogniwo: ludzie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 Pojedyncze logowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 Pojęcie entropii a bezpieczeństwo haseł. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 Entropia losowo generowanych haseł . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 Entropia haseł tworzonych przez ludzi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 Nazwa użytkownika i hasło – analiza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 Zabezpieczanie istniejących standardów dla ochrony tożsamości . . . . . . . . . . .12 Dobre i złe algorytmy zabezpieczeń . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13 Jakie dane powinny być chronione? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 Mechanizmy odzyskiwania kont a socjotechnika . . . . . . . . . . . . . . . . . . . . .14 Problem pytań bezpieczeństwa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 Co dalej? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 2 Hasła: szyfrowanie, haszowanie i solenie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Dane w spoczynku kontra dane w ruchu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17 Dane w spoczynku. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 Dane w ruchu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 Wektory ataku na hasła. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 Ataki siłowe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 Tworzenie CAPTCHA przy użyciu reCAPTCHA. . . . . . . . . . . . . . . . . . . . .22 Ataki słownikowe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 Odwrotne tabele wyszukiwania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29 Tęczowe tabele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30 Solenie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32 Generowanie losowej soli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33 Ponowne użycie soli. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34 Długość soli. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34 Gdzie przechowywać sól. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34 Pieprz. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35 Wybieranie właściwej funkcji haszującej dla haseł . . . . . . . . . . . . . . . . . . . . . . . .36 ##7#52#aSUZPUk1BVC1WaXJ0dWFsbw== iii bcrypt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36 PBKDF2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37 scrypt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39 Weryfikowanie hasła względem wartości haszowanej . . . . . . . . . . . . . . . . .40 Rozciąganie kluczy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41 Ponowne obliczanie skrótów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42 Co dalej? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42 3 Podstawy bezpieczeństwa tożsamości . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Istota koncepcji różnych typów tożsamości. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43 Tożsamość społecznościowa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44 Tożsamość zweryfikowana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44 Tożsamość minimalna. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45 Ulepszanie środowiska użytkownika dzięki wykorzystaniu tożsamości . . . . . .45 Wprowadzenie do koncepcji stref zaufanych. . . . . . . . . . . . . . . . . . . . . . . . . . . . .46 Odcisk palca przeglądarki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47 Konfiguracje bardziej odporne na identyfikowanie przeglądarek . . . . . . .48 Identyfikowalne informacje przeglądarki. . . . . . . . . . . . . . . . . . . . . . . . . . . .49 Przechwytywanie szczegółów przeglądarki . . . . . . . . . . . . . . . . . . . . . . . . . .50 Śledzenie oparte na lokalizacji. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52 Odcisk palca urządzenia (telefon / tablet) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54 Odcisk palca urządzenia (urządzenia sparowane przez Bluetooth). . . . . . . . . .55 Implementowanie tożsamości . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56 4 Zabezpieczanie logowania przy użyciu OAuth 2 i OpenID Connect . . . . . . . . . . 57 Różnica pomiędzy uwierzytelnieniem a autoryzacją . . . . . . . . . . . . . . . . . . . . . .57 Uwierzytelnianie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57 Autoryzacja. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58 Czym są OAuth i OpenID Connect? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58 Wprowadzenie do OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61 Obsługa autoryzacji przy użyciu OAuth 2.0. . . . . . . . . . . . . . . . . . . . . . . . . .63 Korzystanie z tokenu Bearer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64 Autoryzacja i uwierzytelnianie przy użyciu OpenID Connect . . . . . . . . . .65 Różnice uwarunkowań zabezpieczeń pomiędzy OAuth 2 i OAuth 1.0a . . . . . .66 Budowanie serwera OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67 Tworzenie aplikacji Express . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67 Konfigurowanie bazy danych naszego serwera. . . . . . . . . . . . . . . . . . . . . . . . . . .68 Generowanie kodów autoryzacyjnych i tokenów . . . . . . . . . . . . . . . . . . . . .68 Punkt końcowy autoryzacji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71 Obsługa czasu życia tokenu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75 Obsługa żądań zasobów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78 Korzystanie z tokenów odświeżania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81 Obsługa błędów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83 iv | Spis treści ##7#52#aSUZPUk1BVC1WaXJ0dWFsbw== Dodawanie funkcjonalności OpenID Connect do serwera. . . . . . . . . . . . . . . . .87 Schemat ID Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88 Modyfikowanie punktu końcowego autoryzacji . . . . . . . . . . . . . . . . . . . . . .89 Dostosowywanie punktu końcowego Token . . . . . . . . . . . . . . . . . . . . . . . . .90 Punkt końcowy UserInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92 Zarządzanie sesją przy użyciu OpenID Connect. . . . . . . . . . . . . . . . . . . . . .93 Budowanie klienta OAuth 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93 Używanie kodów autoryzacyjnych . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93 Autoryzacja przy użyciu poświadczeń właściciela zasobu lub poświadczeń klienta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96 Dodawanie funkcjonalności OpenID Connect do klienta. . . . . . . . . . . . . .98 Przepływ podstawowy OpenID Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . .98 Poza OAuth 2.0 i OpenID Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100 5 Alternatywne metody identyfikacji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Identyfikowanie urządzeń i przeglądarek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101 Uwierzytelnianie dwuskładnikowe oraz n-składnikowe . . . . . . . . . . . . . . . . . .102 Uwierzytelnianie n-składnikowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102 Hasła jednorazowe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103 Implementowanie dwuskładnikowego uwierzytelniania przy użyciu Authy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106 Biometria jako uwierzytelnienie zamiast hasła . . . . . . . . . . . . . . . . . . . . . . . . . .112 Jak oceniać skuteczność biometrii. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113 Rozpoznawanie twarzy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114 Skanowanie siatkówki i tęczówki. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114 Rozpoznawanie naczyń krwionośnych. . . . . . . . . . . . . . . . . . . . . . . . . . . . .115 Przyszłe standardy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115 FIDO Alliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .116 Oz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117 Blockchain. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118 Co dalej? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118 6 Wzmacnianie aplikacji Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Zabezpieczanie sesji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119 Różne typy sesji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120 Jak Express obsługuje sesje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121 Obsługa XSS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125 Trzy typy ataków XSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125 Testowanie mechanizmów ochrony przed XSS . . . . . . . . . . . . . . . . . . . . . .126 Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130 Ataki CSRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131 Obsługa CSRF za pomocą csurf. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131 ##7#52#aSUZPUk1BVC1WaXJ0dWFsbw== Spis treści | v Wartościowe zasoby dla platformy Node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132 Lusca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132 helmet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133 Node Security Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134 Inne techniki neutralizacyjne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135 Nasze odkrycia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136 7 Bezpieczeństwo transmisji danych . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 SSL/TLS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137 Typy certyfikatów i urzędów certyfikacji . . . . . . . . . . . . . . . . . . . . . . . . . . .138 Tworzenie samopodpisanego certyfikatu na potrzeby testów . . . . . . . . . .140 Kryptografia asymetryczna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148 Przypadki zastosowań . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .148 Przykład implementacji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .150 Zalety, wady i zastosowania kryptografii asymetrycznej . . . . . . . . . . . . . .157 Kryptografia symetryczna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .158 Wektor inicjujący . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159 Dopełnienie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159 Tryby działania szyfrów blokowych . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161 Korzystanie z AES w trybie szyfrowania CTR. . . . . . . . . . . . . . . . . . . . . . . . . . .164 Korzystanie z AES w trybie szyfrowania z uwierzytelnieniem GCM. . . .166 Zalety, wady i zastosowania kryptografii symetrycznej . . . . . . . . . . . . . . .168 A Repozytoria GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 B Wymagania techniczne i warunki wstępne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Słowniczek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Indeks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 vi | Spis treści ##7#52#aSUZPUk1BVC1WaXJ0dWFsbw== Przedmowa Firmy tracą rocznie 400 miliardów dolarów na skutek działań hackerów.1 – Inc. Magazine Raport bezpieczeństwa rynku informatycznego, opublikowany przez Cybersecurity Ventures w czwartym kwartale 2015 roku, stwierdza, że cyberataki kosztują biznes od 400 do 500 miliardów dolarów rocznie2. Jednocześnie wydatki na bezpieczeństwo IT wzrosły o 4,7 w roku 2015, osiągając wartość 75,4 miliarda USD, zaś szacuje się, że ogólne wy- datki światowe na ten cel wzrosną do 101 miliardów dolarów w roku 2018 i będą dalej rosnąć do 170 miliardów w roku 2020. Można przewidywać, że w branży bezpieczeństwa informatycznego pojawi się niedobór pracowników sięgający 1,5 miliona osób w roku 2019, jako że ogólnoświatowe zapotrzebowanie ma wzrosnąć do 6 milionów. Jako projektanci aplikacji i witryn Web, inżynierowie i twórcy nie możemy dłużej żyć w przekonaniu, że możemy powierzyć zagadnienia bezpieczeństwa tożsamości i danych komuś innemu. W dzisiejszych czasach projektant witryny może bezwiednie otworzyć lukę zabezpieczeń jedynie dlatego, że nie wiedział, jak właściwie ochronić dane w trakcie transmisji. Nieświadomość tego, że uważany dotąd za bezpieczny algorytm zabezpiecza- nia haseł zawiera błędy, może spowodować podatność na potężny atak, o ile nie nadamy odpowiedniego priorytetu zadaniu ponownego zaszyfrowania bazy danych użytkowni- ków. W interesie każdej osoby pracującej z jakimś systemem jest zadbanie o to, że nasi użytkownicy i ich dane są chronione. Pomimo tego wydaje się, że każdego tygodnia pojawiają się nowe zdarzenia, gdy różne firmy, od startupów po wielkie korporacje, tracą poufne informacje użytkowników, dane kart kredytowych, rejestry medyczne i wiele innych typów informacji, które zdecydowanie powinny być chronione. Okazuje się często, że wiele z tych organizacji nigdy nie zadało sobie trudu, aby właściwie zabezpieczyć dane, przechowując wszystko w postaci jawnego tekstu i czekając, aż jakiś hacker to wykorzysta. 1 http://www.inc.com/will-yakowicz/cyberattacks-cost-companies-400-billion-each-year.html 2 http://cybersecurityventures.com/cybersecurity-market-report/ ##7#52#aSUZPUk1BVC1WaXJ0dWFsbw== vii Prawdziwy problem polega na tym, że hacking nie jest już tylko hobby indywidua- listów, którzy pragną udowodnić, że potrafią włamać się do jakiegoś systemu. Dziś jest to sfera zorganizowanej przestępczości, wykorzystującej techniki hackerskie dla pieniędzy lub w celu zniszczenia innej firmy. W miarę przeglądania każdej koncepcji i idei w kolejnych rozdziałach będziemy po- kazywali, jak pozatykać dziury w istniejących systemach, ochronić się przed potencjalnie skutecznymi wektorami ataku i jak pracować w środowiskach, które są w naturalny sposób niezabezpieczone. Przyjrzymy się takim zagadnieniom, jak: • Aktualny stan zabezpieczeń sieci Web i aplikacji wraz omówieniem rozmaitych koncepcji. • Zapewnianie bezpiecznego szyfrowania haseł i przeciwdziałanie możliwym atakom na hasła. • Tworzenie cyfrowych „odcisków palców” w celu dodatkowej identyfikacji użytkow- ników poprzez unikatowe cechy ich przeglądarek, urządzeń mobilnych lub wykry- waniu sparowanych elementów. • Budowanie systemów bezpiecznego uwierzytelniania przy użyciu standardów OAuth i OpenID Connect. • Korzystanie z  alternatywnych metod identyfikacji jako drugiego składnika uwierzytelniania. • Wzmacnianie odporności aplikacji na potencjalny atak. • Tworzenie systemu bezpiecznej transmisji danych przy użyciu SSL/TLS, a także symetrycznej i asymetrycznej kryptografii. Na koniec lektury Czytelnik powinien mieć szerokie pojęcie na temat bieżącego stanu zabezpieczeń tożsamości i danych, będzie znał techniki ochrony siebie samego przed po- tencjalnymi atakami, a przede wszystkim będzie wiedział, jak zabezpieczyć dane swoich użytkowników. Konwencje użyte w tej książce W tej książce używane są następujące konwencje typograficzne: Kursywa Wskazuje nowe terminy, adresy URL, adresy e-mail, nazwy plików i rozszerzenia plików. Stała szerokość Służy do wydruków programów, a także wewnątrz akapitów do odwołań do elemen- tów programu, takich jak nazwy zmiennych lub funkcji, bazy danych, typy danych, zmienne środowiskowe, instrukcje i słowa kluczowe. viii ##7#52#aSUZPUk1BVC1WaXJ0dWFsbw== Stała szerokość i pogrubienie Pokazuje polecenia lub inny tekst, który powinien być wpisany dokładnie tak przez użytkownika. Stała szerokość i kursywa Pokazuje tekst, który powinien być zastąpiony wartościami podanymi przez użyt- kownika lub wyznaczonymi przez kontekst. Ten element oznacza wskazówkę lub sugestię. Ten element oznacza uwagę ogólną. Ten element wskazuje ostrzeżenie lub przestrogę. Podziękowania Przede wszystkim chcielibyśmy podziękować wydawnictwu O’Reilly za opublikowanie tej książki i umożliwienie nam podzielenia się swoją wiedzą, przemyśleniami i opiniami z czytelnikami na całym świecie. Szczególne podziękowania należą się naszej redaktorce Meg Foley za jej cierpliwość i pomoc w doprowadzeniu tej pracy do końca. Podziękować chcielibyśmy również recenzentom książki, Lenny Markusowi, Allenowi Tomowi Aaronowi Pareckiemu, którzy starannie przejrzeli rękopis i pomogli znacząco poprawić jego jakość. Wyrazy wdzięczności należą się naszemu zespołowi projektowemu za korekty, uwagi krytyczne, a przede wszystkim za zapewnienie dostatecznej ilości czasu, abyśmy mogli pracować nad książką. Na koniec chcemy wyrazić wdzięczność Wam, naszym Czytelnikom, za kupienie tej książki. Mamy nadzieję, że się spodoba! ##7#52#aSUZPUk1BVC1WaXJ0dWFsbw== ix Jonathan Chciałbym zacząć od podziękowań dla mojego wspólnika zbrodni, Tima, za to, że mo- głem z nim współpracować przy tej książce. Bez naszych ciągłych rozmów, tworzenia pomysłów i rozkładania ich na czynniki w celu stworzenia nowych, hybrydowych kon- cepcji, książka nie byłaby tym, czym jest. Twoje koncepcje, zapał i humor sprawiły, że było to wspaniałe doświadczenie. Moja żona Heather pomogła mi zachować zdrowie umysłowe, gdy postanowiłem na- pisać swą pierwszą książkę blisko pięć lat temu. Pomimo tego, że trwało to wówczas tak długo, wsparłaś mnie ponownie, gdy zdecydowałem się napisać kolejną. Bez ciebie nie poradziłbym sobie z tą pracą bez popadania w szaleństwo. Wielką pomoc okazała też moja córka Scarlett – dziękuję za twoją cierpliwość i zrozumienie. Wreszcie chciałbym podziękować mojej grupie, moim przyjaciołom. Choć podążamy odrębnymi drogami, rozproszeni po różnych firmach i różnych częściach świata, zawsze będę uważał was za najbliższych przyjaciół. Tim Chciałbym podziękować Jonathanowi, który jest nie tylko fantastycznym kolegą i przyja- cielem, ale również wielkim współautorem tej książki. To było niezwykłe doświadczenie, ciągła wymiana idei i pomysłów i jestem przekonany, że książka ta byłaby znacznie mniej interesująca bez jego udziału. Mojej żonie, Karin, należą się wielkie podziękowania – i zapewne jeszcze większy bukiet kwiatów – za zapewnienie mi całego tego czasu, którego potrzebowałem na ukoń- czenie pracy. Joe Nash, Alan Wong, Steven Cooper i Cristiano Betta stanowili fantastyczny zespół pomagający w tworzeniu i redagowaniu tej książki i zdecydowanie zasługują na to, aby o nich wspomnieć w tym miejscu. Szczególne podziękowania należą się Danese Cooper, szefowej działu Open Source w PayPal, która jako pierwsza zachęcała mnie, aby spisać moje przemyślenia w czymś więcej, niż postach na blogu. Na koniec chcę podziękować Johnowi Lunnowi i Taylorowi Nguyen, którzy nieustan- nie wspierali mnie i doradzali podczas pisania tej książki – i nie tylko. x ##7#52#aSUZPUk1BVC1WaXJ0dWFsbw== Rozdział 1 Wprowadzenie Jonathan LeBlanc i Tim Messerschmidt Jedne z najważniejszych inwestycji, jakie możemy poczynić w swoim systemie, przedsię- biorstwie lub aplikacji, dotyczą infrastruktury zabezpieczeń i tożsamości. Nie ma tygo- dnia, byśmy nie usłyszeli o kolejnym wycieku danych klientów, przechwyconych nume- rach kart kredytowych lub kradzieży tożsamości. Nawet jeśli umieścimy całą serię prze- szkód na drodze potencjalnego napastnika, zawsze będzie istniało prawdopodobieństwo, że nasze bazy danych zostaną naruszone, informacje skradzione, a napastnicy zaczną próbować złamać przechowywane w nich poufne dane (o ile zostały zaszyfrowane). Nie istnieje całkowicie niezawodna, bezpieczna metoda ochrony naszych danych i toż- samości – bezpieczeństwo danych zawsze sprowadza się do ograniczania ryzyka, ochrony zabezpieczonych danych i kupowania czasu wystarczającego na podjęcie działań i zredu- kowania strat, gdy coś takiego przydarzy się właśnie nam. W miarę zagłębiania się w koncepcje, techniki i metodologie programistyczne kryjące się za budowaniem bezpiecznego interfejsu dla danych i tożsamości będziemy analizować decyzje, kompromisy i kluczowe koncepcje, które trzeba zrozumieć, by móc podejmować świadome decyzje dotyczące zabezpieczeń. Najlepszym początkiem będzie przeanalizowanie głównych problemów dotyczących bezpieczeństwa danych i tożsamości, przed którymi obecnie stoi branża informatyczna. Problemy z obecnymi modelami zabezpieczeń Bieżący (niezadowalający) stan bezpieczeństwa informatycznego nie polega na tym, że technika nie jest w stanie poradzić sobie z potencjalnymi kierunkami ataków. Wynika on z tego, że wybory projektowe doprowadziły nas do powstawania słabych systemów. Jednym z największych błędów, które wielu z nas stale popełnia, jest założenie, że użyt- kownik będzie wiedział, jak chronić swoje własne zasoby, na przykład stosując silne ha- sła lub uwierzytelnianie dwuskładnikowe, a nawet jeśli to zrobi, że nie będzie wybierał ##7#52#aSUZPUk1BVC1WaXJ0dWFsbw== 1 najłatwiejszych rozwiązań. To my, jako projektanci, musimy chronić naszych użytkowni- ków tak samo, jak próbujemy ochronić nasze własne systemy i musimy zakładać, że użyt- kownicy sami tego nie zrobią. Oznacza to, że musimy wyrzucić z naszych przemyśleń kilka błędnych założeń: Użytkownik zawsze posłuży się najbezpieczniejszymi opcjami Prosty fakt jest taki, że najgorsze, co możemy zrobić, to polegać na tym, że użytkownik będzie w stanie lub będzie chciał użyć opcji, która zabezpieczy jego samego i jego dane. To na właścicielu witryny lub usługi musi spoczywać brzemię odpowiedzialności za to, że dane dostar- czane przez użytkownika dla jego bezpieczeństwa (takie jak hasło) są dostatecznie silne, aby zapewnić minimalny wymagany poziom zabezpieczeń (więcej informacji o szyfrowaniu danych i zabezpieczeniach zawiera rozdział 2). Dla przykładu w sy- stemach oferujących jako opcję uwierzytelnianie dwuskładnikowe typowy poziom zainteresowania wynosi od 5 do 10 użytkowników. Powinniśmy zawsze zapewnić większe bezpieczeństwo systemów, nawet kosztem użytecz- ności Jest to jedna z typowych reakcji na poprzedni punkt. Decydujemy się sprawić, by system był tak bezpieczny, jak to możliwe, kosztem użyteczności i wygody dla użyt- kownika. W rzeczywistości nie ma konieczności takiego kompromisu. Istnieją liczne mechanizmy, które można wdrożyć w celu podniesienia bezpieczeństwa, a które nie wpływają znacząco na doświadczenia użytkownika. Tym zagadnieniem zajmiemy się w podpunkcie „Bezpieczeństwo kontra użyteczność” w dalszej części rozdziału. Nasze zabezpieczenia nigdy nie zostaną złamane Od startupów po wielkie korporacje, wielu inżynierów pokłada zbyt wielkie zaufanie w jakości zabezpieczeń swoich syste- mów. Prowadzi to do lekceważenia standardów szyfrowania danych, przez co osobiste i poufne informacje, takie jak dane kart kredytowych, adresy itp. są przechowywane jako czysty tekst, dane nieszyfrowane w żaden sposób. Gdy nastąpi włamanie, hackerzy nie muszą się wysilać, aby przejąć i wykorzystać te dane. Zawsze należy zakładać, że dane zostaną skradzione i stosować odpowiednie szyfrowanie W czerwcu 2015 nastąpił masowy wyciek danych instytucji rządowych Stanów Zjednoczonych, w którym ujawniono dane osobiste milionów pracowników, ponieważ dane same w sobie nie zostały zaszyfrowane (Computer World). Nieważne, jak mała lub wielka jest firma, powinniśmy zawsze zakładać, że ist- nieje ryzyko przełamania zabezpieczeń naszej bazy danych i kradzieży danych. Wszystkie informacje poufne powinny zawsze być odpowiednio szyfrowane. Spróbujmy bardziej zagłębić się w niektóre z tych problemów, aby zrozumieć przyczyny i skutki wyborów dokonywanych przez nas jako projektantów. 2 | Rozdział 1: Wprowadzenie ##7#52#aSUZPUk1BVC1WaXJ0dWFsbw== Kiepskie hasła Jak wspomniałem wcześniej, użytkownicy notorycznie wybierają skrajnie niebezpieczne hasła dla swoich kont. Aby to pokazać, przyjrzyjmy się hasłom, które najczęściej były sto- sowane w roku 2015, zgodnie z zestawieniem przygotowanym przez SplashData z plików zawierających miliony skradzionych haseł opublikowanych w sieci w minionym roku1. Tabela 1-1 Najpopularniejsze hasła roku 2015 1: 123456 2: password 3: 12345678 4: qwerty 5: 12345 6: 123456789 7: football 8: 1234 9: 1234567 10: baseball 11: welcome 12: 1234567890 13: abc123 14: 111111 15: 1qaz2wsx 16: dragon 17: master 18: monkey 19: letmein 20: login 21: princess 22: qwertyuiop 23: solo 24: passw0rd 25: starwars Zanim jednak zaczniemy potępiać ludzi wybierających takie hasła, musimy zauważyć, że dane te są obarczone pewnymi wadami, które trzeba wziąć pod uwagę: • Ponieważ większość tych danych pochodzi z wycieków informacji, można założyć, że hasła te były łatwiejsze do złamania atakiem słownikowym lub siłowym. • Nie znamy pochodzenia większości tych danych, zatem nie możemy zweryfi- kować jakości zabezpieczeń stosowanych w witrynach lub usługach, z których je wykradziono. • Dane te mogą zawierać anomalie lub po prostu błędy. Jeśli jakieś hasło jest domyśl- nie ustawiane przez usługę, w której następuje wiele wycieków danych (a hasło to nie jest nigdy zmieniane), znajdzie się ono na wyższej pozycji w tabeli, co jednak nie oznacza wcale, że jest powszechnie używane. Jeśli analizujemy dane z wielu źródeł używając informacji, które zostały źle przetworzone lub zawiera podobne anomalie, cała lista będzie zdeformowana. Tym niemniej, nawet jeśli pokazane hasła mogą występować w mniejszej liczbie, niż su- geruje powyższa lista, a dane mogą być mocno „skrzywione”, nadal istnieją. Oznacza to, że przy budowaniu systemu zabezpieczeń dla danych i tożsamości musimy zapewnić odpowiedni poziom ochrony ludziom, którzy wybierają takie hasła. Typowo będziemy chcieli tworzyć konstrukcję eliminującą najsłabsze elementy systemu uwierzytelniania. Pod wieloma względami właśnie stąd wynikają nasze oczekiwania co do haseł tworzo- nych przez użytkowników: używania różnych wielkości liter, co najmniej jednego symbolu oraz cyfry, tworzenia ciągów znaków nierozpoznawalnych w słownikach lub możliwych do wydedukowania na podstawie znajomości danej osoby. Tego typu wymagania powodu- ją jednak, że system jest mało wygodny dla użytkownika i nie będzie on w stanie zapamię- tać hasła, co sprawi, że będzie szukał najprostszego sposobu wejścia lub po prostu zapisze 1 http://www.teamsid.com/worst-passwords-2015/ Problemy z obecnymi modelami zabezpieczeń | 3 ##7#52#aSUZPUk1BVC1WaXJ0dWFsbw== hasło na karteczce przylepionej do monitora. Użyteczność (a może lepiej byłoby napisać użytkowalność) musi być częścią projektu systemu zabezpieczeń, aby był on skuteczny. Bezpieczeństwo kontra użyteczność Jeśli zabezpieczenia będą miały zbyt duży priorytet względem wygody, używanie witryny stanie się trudne lub niemożliwe. – Anthony T, założyciel UX Movement Naszym głównym celem podczas obsługiwania danych użytkowników jest zapewnienie bezpieczeństwa tych danych i ich tożsamości, ale jednocześnie nie chcielibyśmy zniechę- cać ich wszystkich używając zbyt złożonego systemu logowania. Jeszcze gorsze mogłoby być wymuszanie wieloekranowego, pracochłonnego procesu rejestracji przy kupowaniu produktów lub ciągłe żądanie od użytkownika podawania szczegółów identyfikacyjnych w trakcie korzystania z serwisu. To gwarantowane sposoby zapewnienia, że użytkownik nigdy nie wróci. Niektóre z głównych powodów wskazywanych przez użytkowników, którzy porzucają swoje koszyki i rezygnują z zakupów, obejmują niewygodę samego procesu zakupowego (jest zbyt złożony lub długotrwały), a także wymóg za- logowania się/rejestracji przed zakupem. Wiele z tych zagadnień można roz- wiązać dzięki rozwiązaniom zwiększającym użyteczność, takim jak pojedyncza strona logowania i umożliwienie uproszczonej rejestracji gości. Zagadnienie „bezpieczeństwo czy użyteczność” jest zawsze sprawą kompromisu. Musimy zapewnić, że mamy wystarczająco wysoką pewność co do bezpieczeństwa naszych użyt- kowników, a jednocześnie zrobić to w tak dyskretny i przezroczysty sposób (w tle), aby nie niszczyć ich doświadczeń ciągłym wymaganiem weryfikacji. Możemy sobie w tym momencie postawić następujące pytania: • Czy możemy uzyskać informacje o tożsamości, zwiększające nasze przekonanie, że użytkownik jest tym, za kogo się podaje, bez nakładania na niego dodatkowych wymogów weryfikacji? • Czy jeśli mamy wysokie przekonanie, że użytkownik jest tym, za kogo się podaje, możemy zbudować bardziej użyteczne środowisko dla tego użytkownika w porów- naniu z takim, dla którego brak takiej pewności? • Jaka zawartość wymaga identyfikacji użytkownika i kiedy powinienem zastosować dodatkowe poziomy zabezpieczeń, aby ją zweryfikować? Koncepcje te przeanalizujemy głębiej w rozdziale 3, gdy będziemy omawiać strefy zaufania i budowanie informacji weryfikujących tożsamość dla użytkownika. 4 | Rozdział 1: Wprowadzenie ##7#52#aSUZPUk1BVC1WaXJ0dWFsbw== Niewłaściwe szyfrowanie danych Problematyka bezpieczeństwa danych i identyfikowania użytkowników nie polega na pla- nowaniu na najlepszy możliwy wariant, ale na najgorszy. Jeśli istnieje prawdopodobień- stwo, że coś może się wydarzyć, należy zakładać, że się wydarzy i mieć na taką okoliczność gotowy plan, pozwalający zmniejszyć lub ograniczyć powstałe szkody. 27 marca 2015 Slack ogłosił, że ich systemy zostały przełamane i skradziono dane użytkowników. Straty wynikające z tego incydentu zostały jednak ograniczone dzięki stosowanym metodom silnego szyfrowania danych. Jak można przeczytać na firmowym blogu, „Slack utrzymuje centralną bazę danych użytkowników, która zawiera nazwy użytkowników, ich adresy email oraz jednokierunkowo zaszyfrowane (haszowane) hasła. Używana przez Slack funkcja haszująca to bcrypt, z losowo generowanym komponentem salt dla każdego hasła, co oznacza, że odtworzenie haseł z tej postaci jest obliczeniowo niewykonalne”. Dodatkowo po tym zdarzeniu firma wprowadziła uwierzytelnianie dwu- składnikowe oraz przełącznik wygaszania haseł dla właścicieli zespołów, który pozwalał im automatycznie wylogować wszystkich użytkowników ze wszystkich urządzeń i wymu- sić utworzenie nowych haseł. W tym przypadku szyfrowanie danych oraz szybka reakcja uniemożliwiły masową kradzież kont użytkowników i zmniejszyły straty wizerunkowe oraz spadek zaufania użyt- kowników. Szyfrowanie danych nie musi jedynie służyć ochronie danych przed kradzieżą. Pozwala też spowolnić działania hackerów, aby móc podjąć odpowiednie przeciwdziała- nie, a w części przypadków rozszyfrowywanie danych jest wystarczająco długotrwałe, aby działanie takie straciło sens. Najsłabsze ogniwo: ludzie Naszym najważniejszym zadaniem, jako projektantów czy dostawców usług, powinno być traktowanie danych naszych użytkowników z największą troską, jaką możemy zapewnić. Z tego względu staramy się zabezpieczyć dowolne rodzaje informacji dostarczane przez użytkowników, wykorzystując algorytmy szyfrowania, oferując bezpieczne metody komu- nikacji i ciągle wzmacniając naszą infrastrukturę w nieustannych wysiłkach. Najważniejszy element tego łańcucha, człowiek, często jest pomijany w równaniu, przez co tworzone aplikacje czy usługi bywają otwarte na zagrożenia, które w ogóle nie były rozważane przy projektowaniu i wdrażaniu zabezpieczeń. Prawda jest następująca: ludzie mają skłonność do wybierania najłatwiejszych dróg. Dla nas oznacza to, że ludzie będą wybierać łatwe do zapamiętania i krótkie hasła, proste do odgadnięcia nazwy użyt- kowników i nie będą mieli pojęcia o nowoczesnych technikach uwierzytelniania, takich jak uwierzytelnianie dwuskładnikowe (nazywane czasem 2FA od angielskiego terminu two-factor authentication). Technikę tę omówimy szczegółowo w piątym rozdziale tej książki – zdecydowanie zasługuje ona na większą uwagę i skupienie. Przeanalizujemy tam również wywodzącą się z 2FA technikę nazywaną po prostu uwierzytelnianiem ##7#52#aSUZPUk1BVC1WaXJ0dWFsbw== Najsłabsze ogniwo: ludzie | 5 n-składnikowym, która reprezentuje skalowane podejście do  zabezpieczeń, zależne od konkretnego zastosowania. Łatwo można zrozumieć, dlaczego ludzie mają skłonność do używania, a zwłaszcza ponownego używania łatwych haseł – oszczędza im to czas przy tworzeniu profili użyt- kowników i sprawia, że uwierzytelnianie w usługach i aplikacjach jest zadaniem prostym i szybkim. Zwłaszcza w przypadku usług mobilnych często mamy do czynienia z niewiel- kim ekranem i dotykowymi klawiaturami, które sprawiają dodatkowe kłopoty. Zjawisko to znane jest jako zmęczenie hasłami. Szczęśliwie istnieje wiele narzędzi, któ- re my, jako projektanci, możemy wykorzystać w celu poradzenia sobie z tymi problemami i zapewnić płynny i wygodny przebieg rejestracji i uwierzytelniania w naszych aplikacjach, nadal zapewniając bezpieczeństwo użytkowników. Wiele systemów operacyjnych, przeglądarek lub aplikacji próbuje rozwiązać problem zmęczenia hasłami, pozwalając na generowanie losowych haseł i jed- nocześnie oferując metodę przechowywania tych haseł pod kontrolą pojedyn- czego hasła głównego. Popularnym przykładem może być aplikacja zarządzania hasłami Keychain, wprowadzona w systemie Mac OS 8.6. Keychain jest głęboko zintegrowany z OS X, a obecnie również z iOS (za pośrednictwem iCloud) i pozwala przecho- wywać różne rodzaje danych, w tym numery kart kredytowych, hasła i klucze prywatne. Coraz liczniejsze usługi, takie jak 1Password, Dashlane lub LastPass, oferują generowanie haseł dla swoich użytkowników. Usuwa to potrzebę samodzielnego wymyślenia bezpiecz- nego hasła i jest często postrzegane jako wygodna metoda przyśpieszenia rejestracji konta użytkownika. Katie Sherwin, członek Nielsen Norman Group, opublikowała artykuł2 o upraszcza- niu przebiegu uwierzytelniania hasłem i wyliczyła trzy poniższe podejścia jako sposoby poprawienia wrażeń użytkownika: • Pokaż reguły • Pokaż to, co wpisuje użytkownik • Pokaż miernik siły hasła Dzięki zastosowaniu tych reguł możemy zagwarantować, że użytkownik będzie się czuł pewnie co do używanych przez siebie haseł i otrzyma jasny sygnał, jak są silne. Dalsze badanie wskazują, że użytkownicy widzący miernik siły wybierają bardziej bezpieczne hasła – nawet jeśli miernik ten nie jest zbyt dobrze zaimplementowany3. 2 http://www.nngroup.com/articles/password-creation 3 http://research.microsoft.com/pubs/227130/WhatsaSysadminToDo.pdf 6 | Rozdział 1: Wprowadzenie ##7#52#aSUZPUk1BVC1WaXJ0dWFsbw== Ci, którzy widzą miernik, wykazują skłonność do wybierania silniejszych haseł od tych, którzy takiego miernika nie mieli, ale typ samego miernika nie robi zna- czącej różnicy4. —Dinei Florencio, Cormac Herley i Paul C. van Oorschot, w publikacji „An Administrator’s Guide to Internet Password Research” Pojedyncze logowanie Mechanizm pojedynczego logowania (single sign-on, SSO) polega na wykorzystaniu ist- niejącego konta użytkownika do uwierzytelniania w wielu różnych usługach. Koncepcja sprowadza się do wypełnienia i zabezpieczenia centralnego konta użytkownika zamiast zmuszania go do rejestrowania się ciągle w kolejnych usługach i systemach. Często spotykane rozwiązania próbujące wykorzystać ponowne użycie profilu użyt- kownika, aby bądź udostępnić informacje profilu, bądź po prostu zapewnić uwierzytel- nienie w innych usługach, obejmują OpenID, OAuth 1.0, OAuth 2.0 oraz różne modele hybrydowe, takie jak OpenID Connect. W rozdziale 4 zajmiemy się wybranymi tech- nikami uwierzytelniania i omówimy zarówno techniczne szczegóły implementacji, jak i implikacje dla zabezpieczeń. Pojęcie entropii a bezpieczeństwo haseł Zanim zagłębimy się w szczegóły, musimy najpierw rozstrzygnąć, jak można odróżnić hasło słabe od silnego, gdy hasło to jest tworzone przez człowieka. Standardowy mecha- nizm ustalania siły hasła wykorzystuje pojęcie „entropii informacji”, która jest mierzona liczbą bitów informacji w dostarczonym źródle, takim jak hasło. Typowo przy stosowaniu fraz hasłowych dobry poziom entropii powinien wy- nosić (jako minimum) 36,86 bitów, co odpowiada średniemu poziomowi en- tropii trzech losowych słów wybranych z listy 5000 dostępnych, unikatowych wyrazów. Entropia hasła jest po prostu miarą tego, jak bardzo nieprzewidywalne jest to hasło. Miara ta zależy od kilku kluczowych cech: • Użyty zbiór symboli. • Rozszerzenie tego zbioru symboli dzięki rozróżnianiu małych i wielki liter. • Długość hasła. 4 http://research.microsoft.com/pubs/227130/WhatsaSysadminToDo.pdf Pojęcie entropii a bezpieczeństwo haseł | 7 ##7#52#aSUZPUk1BVC1WaXJ0dWFsbw== Przy użyciu powyższych informacji można wykorzystać entropię hasła (wyrażoną liczbą bitów) do przewidzenia, jak trudne będzie złamanie tego hasła poprzez odgadnięcie, atak słownikowy, atak siłowy (brute force) itp. Przystępując do ustalania ogólnej entropii hasła można rozróżnić dwie główne metody generowania haseł, którymi należy się zająć: hasła tworzone losowo (generowane przez komputer) oraz hasła wybierane przez ludzi. Zgodnie z badaniem zatytułowanym „A Large-Scale Study of Web Password Habits” autorstwa Dinei Florencio i Cormaca Herley a z Microsoft Research, po- ziom entropii przeciętnego hasła można oszacować na 40,54 bitów5. Entropia losowo generowanych haseł Jeśli przyjrzymy się entropii losowo wybieranych haseł (generowanych przez komputer), proces ustalenia ogólnej entropii jest stosunkowo prosty, gdyż nie trzeba uwzględniać wpływu elementu ludzkiego. Zależnie od wybranego zbioru symboli, z którego będziemy budować hasło, można łatwo utworzyć serię haseł o pożądanym poziomie entropii. Powszechnie stosowany wzór używany do obliczania entropii informacji (w naszym przypadku hasła) to: H = log2 ( bl ) gdzie • H = Entropia hasła wyrażona w bitach • b = Liczba dostępnych znaków w zbiorze symboli (moc zbioru symboli) • l = Liczba symboli użytych w haśle (długość hasła) Aby określić wartość b, możemy po prostu wybrać odpowiedni zbiór symboli spośród pokazanych w tabeli 1-2. Tabela 1-2 Entropia pojedynczego znaku z poszczególnych zbiorów symboli Nazwa zbioru symboli Cyfry arabskie (0-9) Cyfry szesnastkowe (0-9, A-F) Alfabet łaciński bez rozróżniania wielkości liter (a-z lub A-Z) Znaki alfanumeryczne bez rozróżniania wielkości liter (0-9, A-Z lub a-z) Alfabet łaciński z rozróżnianiem wielkości liter (A-Z, a-z) Liczba znaków w zbiorze 10 16 26 36 52 Entropia na symbol (w bitach) 3,332 4,000 4,700 5,170 5,700 5 http://research.microsoft.com/pubs/74164/www2007.pdf 8 | Rozdział 1: Wprowadzenie ##7#52#aSUZPUk1BVC1WaXJ0dWFsbw== Tabela 1-2 Entropia pojedynczego znaku z poszczególnych zbiorów symboli Nazwa zbioru symboli Znaki alfanumeryczne z rozróżnianiem wielkości liter (A-Z, a-z, 0-9) Wszystkie drukowalne znaki ASCII Wszystkie drukowalne znaki rozszerzonego ASCII Binarne znaki (0-255, 8-bitowy bajt) Losowo wybierana lista wyrazów (diceware) Liczba znaków w zbiorze 62 95 218 256 7776 Entropia na symbol (w bitach) 5,954 6,570 7,768 8,000 12,925 Spośród powyższych zbiorów symboli mniej znanym może być losowo wy- bierana lista wyrazów (diceware). Metoda ta polega na użyciu zwykłej kostki do gry (ang. dice, stąd nazwa techniki) i wyrzuceniu jej pięć razy. Uzyskane wartości tworzą pięciocyfrową liczbę (np. 46231, gdzie cyfry odpowiadają poszczególnych wynikom). Liczba ta służy do wyszukania określonego słowa z wstępnie zdefiniowanej listy. Istnieje 7776 możliwych wartości, zatem lista powinna zawierać tyle właśnie wyrazów. Warto zauważyć, że jest to więcej, niż liczba słów używanych na co dzień przez większość (nawet wykształconych) lu- dzi. Szersze omówienie (w języku angielskim) oraz przykładowe listy wyrazów z różnych języków dla metody diceware można znaleźć pod adresem http:// world.std.com/~reinhold/diceware.html. Używając przedstawionego wcześniej wzoru i znając długość hasła oraz liczbę symboli w wybranym zbiorze można oszacować liczbę bitów entropii losowo wygenerowanego hasła. Entropia haseł tworzonych przez ludzi Zanim zaczniemy próbować mierzyć poziom entropii hasła, które zostało utworzone przez człowieka, a nie wygenerowane losowo zgodnie ze standardami zabezpieczeń, mu- simy uświadomić sobie, że obliczenia te nie są trywialne. Zaproponowano wiele różnych metod realizacji tego zadania (NIST, Shannon Entropy, Guessing Entropy itd.), ale wszyst- kie one wykazują pewne wady i niedociągnięcia. Metoda Shannona wydaje się zwracać zbyt optymistyczną ocenę bezpieczeństwa hasła (a zarazem nie daje praktycznych wskazówek jego poprawienia), zaś metoda NIST jest niedokładna (choć konserwatywna, czyli zwraca niedoszacowania). Ponieważ zawsze powinniśmy kierować się stronę większego bezpieczeństwa, a nie większego ryzyka, przyj- rzyjmy się krótko opracowaniu NIST na temat mierzenia haseł wybieranych przez ludzi, co powinno dać nam dobry punkt wyjścia do dalszych rozważań. Pojęcie entropii a bezpieczeństwo haseł | 9 ##7#52#aSUZPUk1BVC1WaXJ0dWFsbw== Zgodnie z artykułem NIST oznaczonym jako 800-63-2, jeśli mamy hasło wybra- ne przez człowieka, możemy zmierzyć jego przybliżoną entropię zgodnie z poniższym algorytmem6: • Entropia pierwszego znaku wynosi 4 bity. • Entropia kolejnych 7 znaków wynosi po 2 bity na znak (autorzy stwierdzają, że jest to „w przybliżeniu zgodne z oszacowaniem Shannona, że efekty statystyczne dla ciągów mających nie więcej niż 8 znaków mają entropię około 2,3 bitów na znak”). • Znaki od 9 do 20 mają entropię wynoszącą 1,5 bitów na znak. • Kolejne znaki (21. i dalej do końca hasła) mają entropię 1 bit na znak. • Dodajemy 6-bitowy bonus do hasła spełniającego reguły wymagające stosowania różnych wielkości liter i znaków niealfabetycznych (to również jest dość pesymi- styczne oszacowanie, jako że autorzy publikacji NIST zauważają, że owe znaki spe- cjalne najczęściej pojawiają się na początku lub na końcu hasła, co redukuje całko- witą przestrzeń przeszukiwania). • Dodatkowy 6-bitowy bonus otrzymują hasła o długości od 1 do 19 znaków, które spełniają warunki zaawansowanego testu słownikowego w celu sprawdzenia, że ha- sło nie jest wyrazem występującym w (obszernym) słowniku. Powodem, dla którego hasła dłuższe niż 20 znaków nie otrzymują tego bonusu, jest to, że zakłada się, że składają się z one z wielu wyrazów słownikowych, czyli są frazą hasłową. Spróbujmy zastosować te reguły do obliczenia entropii kilku przykładowych haseł: • monkey (6 znaków) = 14 bitów entropii łych 5 znaków) (4 bity za pierwszy znak, 10 za pozosta- • Monkey1 (7 znaków) = 22 bity entropii (4 bity za pierwszy znak, 12 za pozostałych 6 znaków, bonus 6 bitów za użycie wielkiej litery i znaku niealfabetycznego) • tvMD128!Rrsa (12 znaków) = 36 bitów entropii (4 bity za pierwszy znak, 14 bi- tów za kolejnych 7 znaków, 6 za następne 4 znaki, bonus 6 bitów za użycie wielkich liter i znaków niealfabetycznych, 6 bitów za niesłownikowy ciąg w pierwszych 19 znakach) • tvMD128!aihdfo#Jh43 (19 znaków) = 46,5 bitów entropii (4 bity za pierwszy znak, 14 bitów za kolejnych 7 znaków, 16,5 za kolejnych 11 znaków, bonus 6 bitów za użycie wielkich liter i znaków niealfabetycznych, 6 bitów za niesłownikowy ciąg w pierwszych 19 znakach) • tvMD128!aihdfo#Jh432 (20 znaków) = 42 bity entropii (4 bity za pierwszy znak, 14 bitów za kolejnych 7 znaków, 18 za kolejnych 12 znaków, bonus 6 bitów za użycie wielkich liter i znaków niealfabetycznych) 6 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pdf 10 | Rozdział 1: Wprowadzenie ##7#52#aSUZPUk1BVC1WaXJ0dWFsbw==
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Bezpieczeństwo tożsamości i danych w projektach Web
Autor:
,

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: