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

128

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?

GladstoneKeep
źródło
45
Takie podejście jest ogólnie stosowane tylko bez uwierzytelniania w przypadku resetowania hasła. Niewysłowiony link zazwyczaj wygasa w krótkim czasie i może go użyć tylko ktoś, kto jest już częściowo uwierzytelniony (tj. Strona internetowa zna już adres e-mail, na który link został wysłany).
Robert Harvey
6
Powiązana dyskusja na temat security.SE: security.stackexchange.com/q/58215/37496
Mark
9
@MonkeyZeus to nie bezpieczeństwo przez zaciemnienie. Sekret, który zwykle jest hasłem, w tym przypadku jest adresem URL.
Davidmh
16
@MonkeyZeus: Bezpieczeństwo poprzez zaciemnienie odnosi się do zachowania tajności implementacji mechanizmu, a nie używania niejasnych kluczy. Jeśli niewybaczalne adresy URL zapewniają bezpieczeństwo poprzez zaciemnienie, wówczas silne hasła również są.
JacquesB
1
@GladstoneKeep pamiętaj o skracaczach adresów URL. Gdy ktoś złośliwy użyje jednego z nich, link będzie łatwiej odgadnąć / zapisać.
RookieTEC9

Odpowiedzi:

203

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.

JacquesB
źródło
7
Drobne kłótnie, ale „zwykle używane tylko do jednorazowych operacji” wydają się przesadne, biorąc pod uwagę, że Dropbox (i być może inne chmurne usługi) używają ich do „ochrony” dostępu do plików.
Steve Jessop
4
Dodam, że użytkowników uczy się, z ograniczonym sukcesem, aby chronić swoje hasła, ale nie chronić swoich adresów URL.
svavil
1
Należy dodać, że wiele problemów technicznych można złagodzić, stosując parametr w prywatnym adresie URL, więc xzy.com/myDoc?auth=8502375 i automatyczne przekierowanie do zwykłego adresu URL po sprawdzeniu autentyczności. - Ale to nie rozwiązuje wszystkich możliwych problemów
Falco
3
TL; DR - nie ma czegoś takiego jak tajny adres URL. Obecny atak ujawnia adresy URL złośliwemu aktorowi w hotspotach WiFi, nawet jeśli zwykle wysyłasz adres URL przez HTTPS. Atak narusza funkcję automatycznego wykrywania serwera proxy sieci Web (WPAD), zmuszając przeglądarkę do wysyłania wszystkich adresów URL do atakującego. Zobacz (np.) Arstechnica.com/security/2016/07/…
Harald
5
@JacquesB Czy niektóre z zidentyfikowanych zagrożeń nie zostały złagodzone poprzez umieszczenie części prywatnej we fragmentowej części adresu URL (tj. Po „#”, jak np. Stack Exchange odpowiada za odpowiedzi uwierzytelniające Oauth)? Na przykład nagłówek strony odsyłającej nie może zawierać fragmentu .
Jason C
48

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.

Charles Addis
źródło
4
Gdybym chciał podzielić się tajnym przepisem na colę z moim zespołem ds. Rozwoju produktu, wymagałoby to czegoś nieco innego niż gdybym chciał podzielić się przepisem na sałatkę ziemniaczaną, którą podawałem sąsiadom podczas grillowania w sąsiedztwie. Znowu kontekst. :-)
CVn
7
@ MichaelKjörling Nie jestem pewien, w jaki sposób ktoś wywnioskowałby inaczej niż mój post. Dość jasno stwierdziłem, że różne zasoby wymagają różnych poziomów uwierzytelnienia. Przepis na colę byłby o wiele cenniejszy niż przepis na ciasteczka babci.
Charles Addis,
9
@CharlesAddis Najwyraźniej nigdy nie próbowałeś ciasteczek mojej babci!
Brian
1
Myślę, że chociaż mogę się mylić, to, że @ Michael mówi twój 5-punktowy opis właściwości, które powinien mieć tajny adres URL, jest już przesadą w dzieleniu się tajnym przepisem z przyjaciółmi. Wydanie każdego jednorazowego użytku (a zatem wymagającego osobnego adresu URL dla znajomego, który uzyskuje dostęp do przepisu) wydaje się szczególnie kłopotliwe z powodu nieistotnych korzyści, zwłaszcza jeśli istnieje również termin ważności. Przeczytałem twoją odpowiedź na to, że „dopuszczalne jest użycie prywatnego adresu URL, ale prywatne adresy URL powinny mieć te 5 właściwości”, a IMO jest nieco błędne.
Steve Jessop
1
@BenjaminHodgson, który jest właśnie przyczyną pozycji nr 5 => jeśli link / adres URL trafi w niepowołane ręce, nie powinien ujawniać żadnych informacji o użytkowniku, który o to poprosił.
Charles Addis,
8

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.

Solomon Slow
źródło
1
Aby być uczciwym, to odnosi się również do uwierzytelniania lub jakiejkolwiek komunikacji.
Andy
„podsłuchiwanie połączenia Wi-Fi” działa na dowolnych elementach: adresy URL, pliki CSRF chronione <form>, dane szyfrowane JavaScript klasy wojskowej (być może konieczne będzie aktywne wykrywanie) Łatwo to naprawić: użyj HTTPS.
Gustavo Rodrigues
@GustavoRodrigues Przede wszystkim, jeśli podsłuchiwanie naprawdę „działało na czymkolwiek ”, działałoby to na HTTPS. W przeciwnym razie, co oznacza „cokolwiek”? Lub, jak myślisz, jaka magia tkwi w HTTPS, która stawia ją ponad wszystko inne?
Solomon Slow
2
... ale jest magia, która chroni przed podsłuchującymi: to kryptografia klucza publicznego. Oto prosty przykład: usługa wysyła mi wyzwanie zawierające losową liczbę i znacznik czasu. Podpisuję wyzwanie moim prywatnym kluczem i zwracam go. Jeśli potrafią zweryfikować moją odpowiedź za pomocą mojego zarejestrowanego klucza publicznego, oznacza to, że znam sekret (sekret to mój klucz prywatny), ale udowodniłem to, nie ujawniając go potencjalnemu podsłuchującemu. Nie pomoże podsłuchującemu odtworzyć mojej odpowiedzi, ponieważ usługa nigdy nie wyśle ​​dwukrotnie tego samego wyzwania.
Solomon Slow
HTTPS (to znaczy HTTP przez SSL) wykorzystuje szyfrowanie z kluczem publicznym, ale FYI, najpopularniejsze implementacje SSL mają historię błędów, które pozwoliły podsłuchującym włamać się nawet pomimo kryptografii. Wydaje się, że nowe błędy (znane również jako „exploity”) są wykrywane dwa lub trzy razy w roku, a wszyscy twórcy wszystkich produktów korzystających z SSL muszą biegać z włosami do czasu załatania najnowszego exploita. (Nie pytaj mnie, skąd to wiem!)
Solomon Slow
3

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.

JesseM
źródło
1

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ę.

meriton
źródło
3
Ta odpowiedź zawiera wiele błędnych założeń. Jeśli zalogujesz się na stronie za pomocą HTTPS i wpiszesz swoją nazwę użytkownika i hasło, przeskoki pomiędzy nimi i serwery proxy nie będą znać Twojego hasła.
Pieter B
Przez „przechwytywanie komunikacji” miałem na myśli możliwość rekonstrukcji jej treści. HTTPS może temu zapobiec lub nie. W szczególności zaufanie do jednego złego certyfikatu (na przykład przez niektóre korporacyjne proxy HTTPS, które używa tego samego klucza prywatnego dla wszystkich instalacji) pozwala atakującemu na zarządzanie ruchem HTTPS.
meriton
2
ale kodując sekret w adresie URL, w zasadzie sprawiasz, że HTTPS jest całkowicie bezużyteczny. Każdy przeskok między klientem a serwerem ma swój sekret.
Pieter B
4
Nonsens; w HTTPS adres URL jest przesyłany tylko w zaszyfrowanym strumieniu. Musisz pomylić to z domeną lub adresem IP, które są widoczne odpowiednio w polach wyszukiwania DNS i nagłówku IP.
meriton
1

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.

Paddy
źródło
0

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 /

Ran Biron
źródło
2
Cóż, tak, ale można mieć nadzieję, że każdy, kto korzysta z takich usług do poufnych danych, będzie wiedział lepiej niż publikować adresy URL w dowolnym miejscu , w tym do usługi skracania. To tak naprawdę nie różni się od powiedzenia, że Gah! My password/private key is too long and complex. I know! I'll just write it in a text document and put that in a zip file with an easier password.oba są przejrzystymi porażkami, na co liczy się w nadziei, że ludzie nie będą wystarczająco głupi. Ale tak, w rzeczywistości niestety prawdopodobnie potrzebne jest twoje ostrzeżenie;)
underscore_d
@underscore_d tak właśnie - jeśli znasz ten temat wystarczająco szczegółowo, aby móc komentować, nie jest to punkt warty bloga.
Robert Grant,