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

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?

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.

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:

1. Reset kata sandi email
2. Email Pembuatan Sertifikat
3. Akun / email konfirmasi email
4. Pengiriman konten yang dibeli (ebooks, dll)
5. 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:

1. Itu harus berakhir setelah jumlah waktu yang wajar
2. Ini harus berupa URL sekali pakai: IE harus kedaluwarsa setelah pertama kali diakses.
3. Ini harus menunda otentikasi pengguna ke entitas lain yang dipercaya untuk mengotentikasi pengguna dengan aman. (Dengan mengirimkan tautan melalui email atau SMS, dll)
4. 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.
5. 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.
6. 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.

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.

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.

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.

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.

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 /