Apakah URL pribadi yang tidak dapat dilewati setara dengan otentikasi berbasis kata sandi?

128

Saya ingin mengekspos sumber daya di web. Saya ingin melindungi sumber ini: untuk memastikan itu hanya dapat diakses oleh orang-orang tertentu.

Saya dapat mengatur semacam otentikasi berbasis kata sandi . Misalnya, saya hanya bisa mengizinkan akses ke sumber daya melalui server web yang memeriksa permintaan masuk untuk kredensial yang benar (mungkin terhadap beberapa basis data pengguna yang mendukung) sebelum menyajikan file.

Bergantian saya bisa menggunakan URL pribadi . Yaitu, saya dapat dengan mudah meng-host sumber daya pada jalur yang tidak mungkin ditebak, misalnya https://example.com/23idcojj20ijf..., yang membatasi akses ke mereka yang mengetahui string yang tepat.

Dari sudut pandang pelaku kejahatan yang ingin mengakses sumber daya ini, apakah pendekatan ini setara? Jika tidak, apa yang membuat mereka berbeda? Dan sejauh rawatan, apakah ada pro dan kontra untuk kedua pendekatan yang harus saya ketahui sebelum menerapkan satu atau yang lain?

security authentication

— Gladstone. Terus
sumber

45

Pendekatan ini umumnya hanya digunakan tanpa otentikasi untuk hal-hal seperti pengaturan ulang kata sandi. Tautan yang tidak dapat diakses biasanya kedaluwarsa dalam waktu singkat, dan hanya dapat digunakan oleh seseorang yang sudah semi-autentikasi (yaitu situs web sudah mengetahui alamat email tempat tautan dikirim).

— Robert Harvey

6

Diskusi terkait security.SE: security.stackexchange.com/q/58215/37496

— Mark

9

@MonkeyZeus itu bukan keamanan melalui ketidakjelasan. Rahasianya, yang biasanya adalah kata sandi, dalam hal ini adalah URL.

— Davidmh

16

@MonkeyZeus: Keamanan-melalui-ketidakjelasan mengacu pada menjaga implementasi rahasia mekanisme, tidak menggunakan kunci yang tidak jelas. Jika url yang tidak dapat diakses adalah keamanan melalui ketidakjelasan, maka kata sandi yang kuat juga.

— JacquesB

1

@GladstoneKeep perlu mengingat bahwa pemendek URL. Setelah seseorang yang jahat menggunakan salah satunya, tautannya akan lebih mudah ditebak / ditulis.

— RookieTEC9

203

URL pribadi agak lebih lemah daripada autentikasi dengan kredensial, meskipun ukuran bit URL sama dengan kredensial. Alasannya, URL mungkin lebih mudah "bocor". Itu di-cache di browser, login di server dan sebagainya. Jika Anda memiliki tautan keluar, URL pribadi dapat muncul di tajuk pengarah di situs lain. (Ini juga bisa dilihat oleh orang-orang yang melihat dari balik bahu Anda.)

Jika bocor (secara tidak sengaja atau karena kecerobohan oleh pengguna), itu mungkin berakhir untuk umum dan bahkan diindeks oleh Google, yang akan memungkinkan penyerang untuk dengan mudah mencari semua URL yang bocor ke situs Anda!

Karena alasan ini, URL pribadi biasanya hanya digunakan untuk operasi satu-shot seperti pengaturan ulang kata sandi, dan biasanya hanya aktif untuk waktu yang terbatas.

Ada utas terkait di Keamanan informasi: Apakah URL acak merupakan cara aman untuk melindungi foto profil ? - satu jawaban membagikan cerita ini: Dropbox menonaktifkan tautan bersama yang lama setelah pengembalian pajak berakhir di Google . Jadi ini bukan hanya risiko teoretis.

— JacquesB
sumber

7

Berdalih kecil, tetapi "biasanya hanya digunakan untuk operasi satu-shot" tampaknya pernyataan berlebihan mengingat bahwa Dropbox (dan mungkin layanan berawan lainnya) menggunakannya untuk "melindungi" akses ke file.

— Steve Jessop

4

Saya ingin menambahkan bahwa pengguna diajarkan, dengan keberhasilan terbatas, untuk melindungi kata sandi mereka, tetapi tidak untuk melindungi URL mereka.

— svavil

1

Anda harus menambahkan, bahwa banyak masalah teknis dapat dikurangi dengan menggunakan parameter di URL pribadi sehingga xzy.com/myDoc?auth=8502375 dan pengalihan otomatis ke url biasa setelah otentikasi memeriksa. - Tapi ini tidak menyelesaikan semua masalah yang mungkin terjadi

— Falco

3

TL; DR - tidak ada yang namanya URL rahasia. Ada serangan saat ini yang mengekspos URL ke aktor jahat di hotspot WiFi bahkan jika Anda biasanya mengirim URL melalui HTTPS. Serangan itu menyalahgunakan Autodiscovery Web Proxy (WPAD), memaksa browser Anda untuk mengirim semua URL Anda ke penyerang. Lihat (misalnya) arstechnica.com/security/2016/07/…

— Harald

5

@ JacquesB Bukankah beberapa risiko yang Anda identifikasi dikurangi dengan menempatkan bagian pribadi di bagian fragmen URL (yaitu setelah "#", seperti yang dilakukan Stack Exchange untuk respons autentikasi Oauth-nya)? Misalnya, tajuk pengarah tidak diizinkan untuk menyertakan fragmen .

— Jason C

48

catatan:

Banyak orang tampaknya mengacaukan URL "pribadi" dengan otentikasi. Selain itu, tampaknya ada beberapa kebingungan bahwa mengirim tautan melalui entitas tepercaya adalah upaya otentikasi dua faktor. Untuk lebih jelasnya, kita berbicara tentang sumber daya yang dapat diakses publik, meskipun yang cukup sulit ditebak.

Saat menggunakan URL pribadi, Anda harus selalu berasumsi bahwa URL itu dapat dikompromikan - Anda harus merancang URL sedemikian rupa sehingga meskipun dikompromikan, sumber daya tidak akan membocorkan informasi kepada penyerang.

URL pribadi / sulit ditebak tidak setara dengan otentikasi berbasis kata sandi. Secara alami, URL pribadi tidak pribadi sama sekali - URL adalah sumber daya yang dapat diakses publik. Saya pikir istilah "pribadi" URL adalah nama yang salah, bukan URL "tidak jelas".

Ada kasus-kasus tertentu di mana penggunaan URL "pribadi" dapat diterima, tetapi secara inheren kurang aman daripada metode otentikasi tradisional seperti otentikasi kata sandi atau otentikasi berbasis kunci.

Beberapa tempat yang sering saya lihat URL "pribadi" yang digunakan adalah:

Reset kata sandi email
Email Pembuatan Sertifikat
Akun / email konfirmasi email
Pengiriman konten yang dibeli (ebooks, dll)
Hal-hal misc lainnya seperti check-in penerbangan, print boarding pass, menggunakan URL pribadi selain otentikasi tradisional

Kesamaan di sini adalah bahwa URL acak biasanya hanya baik untuk operasi satu-shot. Juga, otentikasi tradisional dan URL acak tidak saling eksklusif - memang, mereka dapat digunakan bersama satu sama lain untuk memberikan keamanan tambahan saat mengirimkan sumber daya.

Seperti yang ditunjukkan oleh Robert Harvey, satu-satunya cara untuk menggunakan URL acak / pribadi secara aman adalah dengan menghasilkan halaman secara dinamis dan mengirimkan URL kepada pengguna sedemikian rupa sehingga pengguna dapat dianggap semi-autentikasi. Ini bisa berupa email, SMS, dll.

URL yang dibuat secara acak / pribadi biasanya memiliki beberapa properti:

Itu harus berakhir setelah jumlah waktu yang wajar
Ini harus berupa URL sekali pakai: IE harus kedaluwarsa setelah pertama kali diakses.
Ini harus menunda otentikasi pengguna ke entitas lain yang dipercaya untuk mengotentikasi pengguna dengan aman. (Dengan mengirimkan tautan melalui email atau SMS, dll)
Seharusnya tidak mungkin bagi komputer modern untuk memaksa paksa URL dalam jangka waktu sebelum berakhirnya - baik dengan membatasi API yang mengekspos sumber daya atau dengan membuat titik akhir url dengan entropi yang cukup sehingga tidak dapat ditebak.
Seharusnya tidak membocorkan informasi tentang pengguna. IE: Jika halaman ini untuk mengatur ulang kata sandi: halaman tidak akan menampilkan informasi akun pemohon. Jika Alice meminta tautan setel ulang kata sandi dan Bob entah bagaimana menebak URL, Bob seharusnya tidak mengetahui kata sandi siapa yang disetel ulang.
Jika tidak membocorkan informasi tentang pengguna, itu harus digunakan di atas otentikasi tradisional, misalnya halaman dapat mempertimbangkan pengguna yang diautentikasi jika mereka memiliki cookie set atau jika session_id mereka masih valid.

Sumber daya yang berbeda membutuhkan tingkat keamanan yang berbeda pula. Misalnya, jika Anda ingin berbagi resep rahasia dengan beberapa teman, Anda dapat menggunakan URL acak / pribadi untuk membaginya dengan mereka. Namun, jika sumber daya tersebut dapat digunakan untuk mencuri identitas seseorang atau membahayakan akun mereka dengan penyedia layanan lain, Anda mungkin akan lebih peduli tentang membatasi akses ke sumber daya itu.

— Charles Addis
sumber

4

Jika saya ingin berbagi resep rahasia untuk Coke dengan tim pengembangan produk saya, itu akan memerlukan sesuatu yang agak berbeda dari jika saya ingin berbagi resep untuk salad kentang yang saya sajikan kepada para tetangga selama pesta barbekyu di lingkungan tempat tinggal. Sekali lagi, konteks. :-)

— a CVn

7

@ MichaelKjörling Saya tidak yakin bagaimana seseorang akan menyimpulkan perbedaan berbeda dari posting saya. Cukup jelas saya menyatakan bahwa sumber daya yang berbeda memerlukan tingkat otentikasi yang berbeda. Resep untuk kokas akan jauh lebih berharga daripada resep untuk kue nenek.

— Charles Addis

9

@CharlesAddis Jelas Anda belum pernah mencicipi kue nenek saya!

— Brian

1

Saya pikir, walaupun saya mungkin salah, bahwa @ Michael mengatakan deskripsi 5 poin Anda tentang properti yang seharusnya dimiliki URL rahasia, sudah berlebihan untuk berbagi resep rahasia dengan teman-teman. Membuat setiap penggunaan tunggal (dan karena itu membutuhkan URL terpisah per teman yang mengakses resep) khususnya tampaknya banyak kerumitan untuk manfaat yang dapat diabaikan, terutama jika ada juga waktu kedaluwarsa. Saya membaca jawaban Anda yang berarti, "boleh saja menggunakan URL pribadi, tetapi URL pribadi harus memiliki 5 properti ini", dan IMO itu sedikit salah.

— Steve Jessop

1

@BenjaminHodgson yang merupakan alasan tepat untuk item # 5 => jika tautan / URL berakhir di tangan yang salah, seharusnya tidak membocorkan informasi tentang pengguna yang memintanya.

— Charles Addis

8

Hampir semua skema otentikasi bermula untuk membuktikan bahwa Anda mengetahui sebuah rahasia. Anda mengotentikasi diri Anda ke beberapa layanan dengan membuktikan bahwa Anda mengetahui kata sandi rahasia, atau URL rahasia atau, ...

Beberapa protokol yang lebih canggih (mis., OAUTH, Kerberos, ...) memungkinkan Anda untuk membuktikan bahwa Anda mengetahui rahasianya tanpa benar-benar mentransmisikan rahasianya. Ini penting karena ada lebih banyak cara untuk mendapatkan rahasia yang "tidak dapat dilewati" selain menebaknya.

Saya bisa saja duduk di warnet yang sama dengan Anda, menguping koneksi WiFi Anda ketika Anda mengetik URL "tidak dapat dilewati". Pada titik itu, jika Anda tidak menggunakan SSL, atau jika saya dapat mengeksploitasi bug baru terbaru dalam implementasi SSL Anda, maka saya juga akan mengetahui rahasia Anda.

— Solomon Lambat
sumber

1

Agar adil, ini juga berlaku untuk otentikasi, atau komunikasi apa pun .

— Andy

"menguping pada koneksi WiFi Anda" berfungsi pada apa saja: URL, dilindungi CSRF <form>, data terenkripsi kelas militer JavaScript (mungkin diperlukan sniffing aktif). Sangat mudah untuk memperbaikinya: gunakan HTTPS.

— Gustavo Rodrigues

@ GustavoRodrigues Pertama-tama, jika menguping benar-benar "bekerja pada apa pun ", maka itu akan berfungsi pada HTTPS. Kalau tidak, apa artinya "sesuatu"? Atau, sihir apa yang menurut Anda ada di HTTPS yang menempatkannya di atas segalanya?

— Solomon Slow

2

... tapi ada adalah sihir yang wards off penyadap: Ini kriptografi kunci publik. Berikut ini contoh sederhana: Layanan mengirimi saya tantangan yang berisi angka acak dan cap waktu. Saya menandatangani tantangan dengan kunci pribadi saya dan mengembalikannya. Jika mereka dapat memvalidasi respons saya dengan kunci publik terdaftar saya, maka itu membuktikan bahwa saya tahu rahasianya (rahasia adalah kunci pribadi saya), tetapi saya membuktikannya tanpa pernah mengungkapkannya kepada seorang penyadap yang potensial. Tidak akan membantu penguping untuk mengulangi tanggapan saya, karena layanan tidak akan pernah mengirim tantangan yang sama dua kali.

— Solomon Slow

HTTPS (Yaitu, HTTP over SSL) menggunakan crypto kunci publik, tetapi FYI, implementasi SSL paling populer memiliki sejarah bug yang memungkinkan para penyadap untuk menguping masuk walaupun ada kriptografi. Bug baru (alias, "exploit") tampaknya ditemukan dua atau tiga kali setiap tahun, dan semua pengembang dari semua produk yang menggunakan SSL harus berkeliaran dengan rambut mereka terbakar sampai eksploit terbaru ditambal. (Jangan tanya saya bagaimana saya tahu!)

— Solomon Slow

3

Banyak jawaban bagus sudah ada di utas ini, tetapi untuk langsung menjawab pertanyaan:

Dari sudut pandang pelaku kejahatan yang ingin mengakses sumber daya ini, apakah pendekatan ini setara? Jika tidak, apa yang membuat mereka berbeda?

Biarkan saya membuat definisi. "Otentikasi" adalah pemberian kredensial untuk membuktikan klaim identitas. Kontrol akses biasanya didasarkan pada identifikasi pengguna.

URL rahasia Anda tidak terikat pada pengguna tertentu. Seperti yang orang lain tunjukkan, itu bisa berakhir di file log proxy, atau permintaan pencarian yang diindeks oleh google, atau banyak cara lain yang bisa bocor.

Di sisi lain, kata sandi terikat ke akun pengguna yang unik. Anda memiliki kemampuan untuk meresetnya, atau hanya memperbolehkannya digunakan dari lokasi rumah pengguna, atau alamat IP yang diketahui, atau sejumlah kontrol lainnya.

Nama pengguna / kata sandi memberi Anda lebih banyak kendali akses.

Kontrol akses memungkinkan identitas (subjek) akses ke sumber daya (objek). Dalam contoh URL Anda, identitasnya adalah "siapa saja yang pernah mendapatkan URL, melalui cara apa pun."

Pergilah dengan nama pengguna / kata sandi jika Anda bisa. URL bocor dengan berbagai cara yang tidak terduga seiring waktu.

— JesseM
sumber

1

URL rahasia sama amannya dengan kata sandi rahasia. Namun, kata sandi lebih mudah dirahasiakan daripada URL, karena semua orang dan programnya tahu bahwa kata sandi harus tetap dirahasiakan.

Misalnya, browser Anda tidak akan menampilkan kata sandi di layar, hanya menyimpan kata sandi dengan izin Anda, dan menawarkan cara untuk melindungi penyimpanan kata sandi tersebut (seperti penyimpanan terenkripsi yang tidak dikunci oleh kata sandi utama). Sebaliknya, ia akan selalu menampilkan URL di layar, mungkin membocorkannya melalui tajuk pengarah, dan menyimpannya secara otomatis dalam riwayat penelusuran Anda tanpa perlindungan lebih lanjut.

Demikian juga, proksi HTTP biasanya tidak akan mencatat kata sandi, sedangkan URL umumnya dicatat.

Menggunakan URL untuk autentikasi juga berarti bahwa berbagi URL berbagi autentikasi, yang membuatnya sulit untuk secara individual mencabut (atau merekam) akses.

Dan tentu saja, URL rahasia mewarisi semua kelemahan kata sandi rahasia. Secara khusus, menggunakan kata sandi untuk otentikasi akan mengungkapkan kata sandi itu ke server dan siapa pun yang dapat membaca komunikasi Anda.

— meriton
sumber

3

Jawaban ini membuat banyak asumsi yang salah. Jika Anda masuk ke situs dengan HTTPS, dan mengetikkan nama pengguna dan kata sandi Anda, hop di antaranya dan prokinya tidak akan tahu kata sandi Anda.

— Pieter B

Dengan "mencegat komunikasi Anda", saya bermaksud untuk merekonstruksi isinya. Ini mungkin atau mungkin tidak dicegah oleh HTTPS. Secara khusus, mempercayai satu sertifikat buruk (misalnya oleh beberapa proksi HTTPS perusahaan yang menggunakan kunci pribadi yang sama untuk semua instalasi) memungkinkan penyerang untuk mengatur lalu lintas HTTPS.

— meriton

2

tetapi dengan menyandikan rahasia di url Anda pada dasarnya membuat HTTPS benar-benar tidak dapat digunakan. Setiap hop antara klien dan server memiliki rahasia. Tidak diperlukan sertifikat yang dikompromikan.

— Pieter B

4

Omong kosong; dalam HTTPS, URL hanya dikirimkan dalam aliran terenkripsi. Anda harus membingungkannya dengan domain atau IP, yang masing-masing terlihat di bidang pencarian DNS dan header IP.

— meriton

1

Item lain yang tidak dicatat di mana pun adalah pembatasan 'tebakan'. Untuk sebagian besar sistem otentikasi kata sandi, Anda mendapatkan sejumlah upaya terbatas dalam menebak kata sandi untuk pengguna sebelum upaya otentikasi lebih lanjut dikunci, atau dibatasi.

Meskipun Anda bisa melakukan sesuatu yang mirip dengan 'tebakan' terhadap skema URL Anda, itu akan agak sulit untuk diterapkan. Jika ada pola yang dapat dikenali untuk pembuatan URL Anda, maka mungkin sulit untuk menghentikan seseorang yang mengatur cara mereka melalui ruang URL 'acak' Anda.

— Padi
sumber

0

Ada aspek lain yang belum saya lihat - penyingkat URL.

Dalam publikasi terbaru (April 2016), diklaim bahwa layanan pemendek URL benar-benar membatalkan peningkatan keamanan yang disediakan oleh URL "tidak dapat diterima" yang dibuat secara acak. Ruang URL layanan lebih pendek jauh lebih kecil daripada URL yang Anda buat secara acak - yang berarti bahwa setiap URL "aman" yang dibagikan dengan layanan yang lebih pendek dapat ditebak dengan cara yang lebih mudah daripada yang diantisipasi.

Sebagai ilustrasi - anggaplah URL acak Anda panjangnya 128bit (yaitu panduan). Juga, mari kita asumsikan bahwa generator angka acak Anda benar-benar kuat dan Anda menghasilkan bit-bit itu dengan cara yang seragam. Menebak angka 128bit sangat sulit dan bisa memakan waktu cukup lama - URL Anda secara efektif dilindungi kunci 128bit.

Lalu, mari kita asumsikan seseorang membagikan URL ini pada penyingkat URL google. Saat ini layanan itu memancarkan 10 karakter ID panjang, terdiri dari huruf dan angka. (26 + 10) ^ 10 ~ = 3,6 * 10 ^ 15 <2 ^ 52 - jadi kami telah membagi dua kekuatan kunci dari 128 bit menjadi 52 bit.

Tambahkan ke fakta bahwa generator tidak menggunakan seluruh ruang karena pertimbangan lain dan Anda dapat melakukan serangan efektif yang menggabungkan kekuatan kasar dengan saluran samping (kemungkinan besar buffer URL acak yang dialokasikan sebelumnya).

Artikel asli: http://arxiv.org/pdf/1604.02734v1.pdf
Sebuah posting blog yang merangkum artikel (oleh penulis): https://freedom-to-tinker.com/blog/vitaly/gone-in- enam karakter-pendek-url-dianggap-berbahaya-untuk-cloud-layanan /

— Ran Biron
sumber

2

Yah, ya, tapi orang akan berharap siapa pun yang menggunakan layanan tersebut untuk data sensitif akan lebih tahu daripada mengirim URL di mana saja , termasuk ke layanan pemendekan. Ini tidak benar-benar berbeda dengan mengatakan

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.

Keduanya transparan gagal, yang satu harapan terhadap harapan orang tidak akan cukup bodoh untuk melakukannya. Tapi ya, pada kenyataannya, sayangnya peringatan Anda mungkin diperlukan;)

— underscore_d

@underscore_d ya persis - jika Anda tahu subjek ini cukup detail untuk berkomentar maka ini bukan poin yang layak untuk blog.

— Robert Grant