Czy prywatne, niemożliwe do odczytania adresy URL są równoważne z uwierzytelnianiem za pomocą hasła?

Chcę udostępnić zasób w sieci. Chcę chronić ten zasób: aby upewnić się, że jest on dostępny tylko dla niektórych osób.

Mogę skonfigurować uwierzytelnianie oparte na haśle . Na przykład mogłem zezwolić na dostęp do zasobu tylko za pośrednictwem serwera WWW, który sprawdza przychodzące żądania poprawnych danych uwierzytelniających (być może w oparciu o bazę danych użytkowników) przed podaniem pliku.

Alternatywnie mogę po prostu użyć prywatnego adresu URL . Oznacza to, że mógłbym po prostu hostować zasób na jakiejś niemożliwej do odgadnięcia ścieżce, na przykład https://example.com/23idcojj20ijf..., która ogranicza dostęp do tych, którzy znają dokładny ciąg.

Z punktu widzenia złoczyńcy, który chce uzyskać dostęp do tego zasobu, czy te podejścia są równoważne? Jeśli nie, co ich różni? A jeśli chodzi o łatwość utrzymania, czy istnieją zalety i wady któregoś z tych podejść, o których powinienem wiedzieć przed wdrożeniem jednego lub drugiego?

Prywatny adres URL jest nieco słabszy niż uwierzytelnianie przy użyciu poświadczeń, nawet jeśli rozmiar bitu adresu URL jest taki sam jak w przypadku poświadczeń. Powodem jest to, że adres URL może łatwiej „wyciekać”. Jest buforowany w przeglądarce, zalogowany na serwerze i tak dalej. Jeśli masz linki wychodzące, prywatny adres URL może pojawić się w nagłówku strony odsyłającej w innych witrynach. (Mogą to również zobaczyć osoby spoglądające przez ramię).

Jeśli wycieknie (przypadkowo lub z powodu nieostrożności ze strony użytkownika), może stać się publiczny, a nawet zaindeksowany przez Google, co umożliwi atakującemu łatwe wyszukiwanie wszystkich wyciekających adresów URL do Twojej witryny!

Z tego powodu prywatne adresy URL są zwykle używane tylko do jednorazowych operacji, takich jak resetowanie hasła, i zazwyczaj są aktywne tylko przez ograniczony czas.

W dziale Bezpieczeństwo informacji znajduje się powiązany wątek: Czy losowe adresy URL to bezpieczny sposób ochrony zdjęć profilowych ? - jedna odpowiedź podziela tę historię: Dropbox wyłącza stare udostępnione linki po tym, jak deklaracje podatkowe trafią do Google . Nie jest to więc tylko ryzyko teoretyczne.

Uwaga:

Wiele osób myli „prywatny” adres URL z uwierzytelnianiem. Wydaje się również, że istnieje pewne zamieszanie, że wysłanie łącza za pośrednictwem zaufanego podmiotu jest próbą uwierzytelnienia dwuskładnikowego. Mówiąc wprost, mówimy o zasobie publicznie dostępnym, choć wystarczająco trudnym do odgadnięcia.

Korzystając z prywatnego adresu URL, należy zawsze zakładać, że może on zostać skompromitowany - należy zaprojektować taki adres URL, aby nawet w przypadku jego naruszenia zasób nie ujawniał informacji atakującemu.

Prywatne / trudne do odgadnięcia adresy URL nie są równoważne z uwierzytelnianiem opartym na haśle. Z natury prywatne adresy URL wcale nie są prywatne - są zasobami publicznie dostępnymi. Myślę, że termin „prywatny” adres URL jest niewłaściwy, a raczej „niejasny” adres URL.

W niektórych przypadkach dopuszczalne jest użycie „prywatnego” adresu URL, ale są one z natury mniej bezpieczne niż tradycyjne metody uwierzytelniania, takie jak uwierzytelnianie za pomocą hasła lub uwierzytelnianie oparte na kluczu.

Niektóre miejsca, w których często widuję „prywatne” adresy URL to:

1. E-maile dotyczące resetowania hasła
2. Wiadomości e-mail dotyczące generowania certyfikatów
3. E-maile z potwierdzeniem konta / e-maila
4. Dostawa zakupionych treści (ebooki itp.)
5. Inne różne rzeczy, takie jak odprawa, wydrukowanie karty pokładowej, użycie tradycyjnych adresów URL oprócz tradycyjnego uwierzytelniania

Wspólną cechą jest to, że losowe adresy URL są zwykle dobre tylko w przypadku operacji jednorazowych. Ponadto tradycyjne uwierzytelnianie i losowe adresy URL nie wykluczają się wzajemnie - w rzeczywistości można ich używać w połączeniu ze sobą, aby zapewnić dodatkowe bezpieczeństwo podczas dostarczania zasobu.

Jak zauważył Robert Harvey, jedynym sposobem bezpiecznego korzystania z losowego / prywatnego adresu URL jest dynamiczne wygenerowanie strony i przesłanie adresu URL użytkownikowi w taki sposób, aby można było uznać go za częściowo uwierzytelniony. Może to być e-mail, SMS itp.

Losowo generowany / prywatny adres URL zazwyczaj ma kilka właściwości:

1. Powinno wygasnąć po rozsądnym czasie
2. Powinien to być adres URL jednorazowego użytku: IE powinien wygasnąć po pierwszym otwarciu.
3. Powinien odroczyć uwierzytelnianie użytkownika w innym zaufanym podmiocie w celu bezpiecznego uwierzytelnienia użytkownika. (Wysyłając link e-mailem, SMS-em itp.)
4. Nowoczesny komputer nie powinien mieć siły wymusić adresu URL w przedziale czasowym poprzedzającym wygaśnięcie - albo przez ograniczenie szybkości interfejsu API, który ujawnia zasób, albo przez utworzenie punktu końcowego adresu URL z wystarczającą entropią, tak że nie można go zgadnąć.
5. Nie powinno to ujawniać informacji o użytkowniku. IE: Jeśli strona ma zresetować hasło: strona nie powinna wyświetlać informacji o koncie osoby żądającej. Jeśli Alice zażąda linku do resetowania hasła, a Bob w jakiś sposób zgadnie adres URL, Bob nie powinien mieć możliwości dowiedzenia się, czyje hasło resetuje.
6. Jeśli ujawnia informacje o użytkowniku, należy go użyć oprócz tradycyjnego uwierzytelnienia, na przykład strona może uznać użytkownika za uwierzytelnionego, jeśli ma ustawiony plik cookie lub jego identyfikator sesji jest nadal ważny.

Różne zasoby wymagają różnych poziomów bezpieczeństwa. Jeśli chcesz na przykład udostępnić tajny przepis niektórym przyjaciołom, dopuszczalne byłoby użycie losowego / prywatnego adresu URL w celu podzielenia się nim z nimi. Jeśli jednak zasób ten mógłby zostać wykorzystany do kradzieży czyjejś tożsamości lub naruszenia bezpieczeństwa kont z innymi usługodawcami, prawdopodobnie bardziej zależy ci na ograniczeniu dostępu do tego zasobu.

Prawie wszystkie schematy uwierzytelniania sprowadzają się do udowodnienia, że ​​znasz sekret. Uwierzytelniasz się w niektórych usługach, udowadniając, że znasz tajne hasło lub tajny adres URL lub ...

Niektóre bardziej zaawansowane protokoły (np. OAUTH, Kerberos, ...) pozwalają udowodnić, że znasz sekret, nie przekazując go. Jest to ważne, ponieważ istnieje więcej sposobów na uzyskanie „nieuchwytnego” sekretu oprócz zgadywania.

Mógłbym siedzieć w tej samej kafejce internetowej, co ty, podsłuchując twoje połączenie Wi-Fi, gdy wpiszesz „niemożliwy do odczytania” adres URL. W tym momencie, jeśli nie korzystasz z protokołu SSL lub jeśli mogę wykorzystać najnowszy nowy błąd w implementacji protokołu SSL, poznałbym również twój sekret.

Wiele dobrych odpowiedzi już w tym wątku, ale bezpośrednio na pytanie:

Z punktu widzenia złoczyńcy, który chce uzyskać dostęp do tego zasobu, czy te podejścia są równoważne? Jeśli nie, co ich różni?

Pozwól mi ustalić definicję. „Uwierzytelnianie” to podawanie poświadczeń potwierdzających roszczenie tożsamości. Kontrola dostępu zwykle opiera się na identyfikacji użytkownika.

Twój tajny adres URL nie jest powiązany z konkretnym użytkownikiem. Jak zauważyli inni, może to skończyć się plikiem dziennika proxy lub żądaniem wyszukiwania indeksowanym przez google lub wieloma innymi sposobami wycieku.

Z drugiej strony hasło jest powiązane z unikalnym kontem użytkownika. Możesz go zresetować lub zezwolić na używanie go tylko z lokalizacji domowej użytkownika, znanego adresu IP lub dowolnej liczby innych elementów sterujących.

Nazwa użytkownika / hasło zapewnia znacznie bardziej szczegółową kontrolę dostępu.

Kontrola dostępu umożliwia dostęp tożsamości (podmiotu) do zasobu (obiektu). W przykładzie adresu URL tożsamością jest „każdy, kto kiedykolwiek otrzyma adres URL, w jakikolwiek sposób”.

Idź z nazwą użytkownika / hasłem, jeśli możesz. Adresy URL wyciekają z czasem na różne nieoczekiwane sposoby.

Tajny adres URL jest tak samo bezpieczny jak tajne hasło. Jednak hasła łatwiej utrzymać w tajemnicy niż adresy URL, ponieważ wszyscy i ich programy wiedzą, że hasła muszą pozostać tajne.

Na przykład Twoja przeglądarka nie wyświetla hasła na ekranie, przechowuje tylko hasła za Twoją zgodą i oferuje środki do ochrony tego hasła (np. Magazynu szyfrowanego odblokowanego hasłem głównym). W przeciwieństwie do tego zawsze będzie wyświetlać adresy URL na ekranie, może przeciekać je przez nagłówek strony odsyłającej i automatycznie zapisywać je w historii przeglądania bez dalszej ochrony.

Podobnie serwery proxy HTTP zwykle nie rejestrują haseł, podczas gdy adresy URL są zwykle rejestrowane.

Użycie adresów URL do uwierzytelnienia oznacza również, że udostępnianie adresów URL dzieli uwierzytelnianie, co utrudnia indywidualne odwołanie (lub zarejestrowanie) dostępu.

I oczywiście tajne adresy URL dziedziczą wszystkie słabości tajnych haseł. W szczególności użycie hasła do uwierzytelnienia ujawni to hasło serwerowi i każdemu, kto może odczytać Twoją komunikację.

Kolejnym nigdzie nie odnotowanym jest ograniczanie „domysłów”. W przypadku większości systemów uwierzytelniania za pomocą hasła istnieje ograniczona liczba prób odgadnięcia hasła dla użytkownika, zanim dalsze próby uwierzytelnienia zostaną zablokowane lub ograniczone.

Chociaż możesz zrobić coś podobnego z „domysłem” w stosunku do twojego schematu URL, nieco trudniej byłoby go wdrożyć. Jeśli istnieje generowalny wzór generowania adresu URL, może być trudno powstrzymać kogoś, kto konfiguruje się do pracy w Twojej „losowej” przestrzeni URL.

Jest jeszcze jeden aspekt, o którym jeszcze nie wspominałem - skracacze adresów URL.

W ostatniej publikacji (kwiecień 2016 r.) Twierdzono, że usługi skracania adresów URL całkowicie niwelują zwiększone bezpieczeństwo zapewniane przez losowo generowane „niemożliwe do odczytania” adresy URL. Przestrzeń URL krótszej usługi jest znacznie mniejsza niż losowo generowany URL - co oznacza, że ​​każdy taki „bezpieczny” adres URL współdzielony z usługą skracacza można odgadnąć w łatwiejszy sposób niż oczekiwano.

Aby to zilustrować - załóżmy, że Twój losowy adres URL ma długość 128 bitów (tj. Przewodnik). Załóżmy również, że twój generator liczb losowych jest naprawdę silny i że generujesz te bity w jednolity sposób. Odgadnięcie liczby 128-bitowej jest bardzo trudne i może zająć dużo czasu - Twój adres URL jest skutecznie chroniony kluczem 128-bitowym.

Następnie załóżmy, że ktoś udostępnił ten adres URL w skracaczu adresów URL Google. Obecnie usługa ta emituje identyfikator o długości 10 znaków, złożony z liter i cyfr. (26 + 10) ^ 10 ~ = 3,6 * 10 ^ 15 <2 ^ 52 - więc skutecznie zmniejszyliśmy siłę klucza o połowę z 128 do 52 bitów.

Dodaj do tego fakt, że generatory nie wykorzystują całej przestrzeni z innych powodów i możesz wykonać skuteczny atak, który łączy brutalną siłę z bocznymi kanałami (najprawdopodobniej wstępnie przydzielone losowe bufory adresów URL).

Oryginalny artykuł: http://arxiv.org/pdf/1604.02734v1.pdf Wpis na
blogu podsumowujący artykuł (autor): https://freedom-to-tinker.com/blog/vitaly/gone-in- sześć znaków-krótkie adresy URL-uważane za szkodliwe dla usług w chmurze /