it-swarm-id.com

Apa gunanya nonce klien?

Setelah membaca Bagian I dari buku Ross Anderson, Teknik Keamanan , dan mengklarifikasi beberapa topik di Wikipedia, saya menemukan ide Client Nonce (cnonce). Ross tidak pernah menyebutkannya dalam bukunya dan saya berjuang untuk memahami tujuan yang dilayaninya dalam otentikasi pengguna.

Nonce normal digunakan untuk menghindari serangan replay yang melibatkan penggunaan respons kedaluwarsa untuk mendapatkan hak istimewa. Server menyediakan nonce (Nomor digunakan SEKALI) klien yang terpaksa digunakan untuk hash responsnya, server kemudian hash respon yang diharapkan dengan nonce yang disediakan dan jika hash klien cocok dengan hash dari server maka server dapat memverifikasi bahwa permintaan tersebut valid dan segar. Ini semua yang dibuktikan; valid dan segar .

Penjelasan yang saya temukan untuk klien nonce namun kurang lurus ke depan dan dipertanyakan. Halaman Wikipedia untuk otentikasi akses digital dan beberapa tanggapan di sini di Stackoverflow tampaknya menyarankan bahwa klien tidak digunakan untuk menghindari serangan plaintext yang dipilih. Saya memiliki beberapa masalah dengan ide ini:

  • Jika seseorang dapat mengendus dan memasukkan paket-paket, kerentanan terbesar adalah serangan manusia-di-tengah yang tidak dapat diatasi oleh nonce atau cnonce, karena itu membuat keduanya tidak berarti.
  • Dengan asumsi bahwa penyerang tidak ingin terlibat dalam serangan man-in-the-middle dan ingin memulihkan rincian otentikasi, bagaimana conce memberikan perlindungan tambahan? Jika penyerang mencegat komunikasi dan membalas permintaan dengan nonce sendiri, maka respons dari klien akan berupa hash dari nonce, data dan cnonce selain cnonce dalam bentuk yang tidak terenkripsi. Sekarang penyerang memiliki akses ke nonce, cnonce dan hash. Penyerang sekarang dapat memotong tabel Rainbow dengan nonce dan cnonce dan menemukan kecocokan. Karena itu cnonce tidak memberikan perlindungan tambahan.

Jadi, apa tujuan dari conce?

Saya berasumsi ada beberapa bagian dari persamaan yang saya tidak mengerti tetapi saya belum menemukan penjelasan untuk apa bagian itu.

SUNTING Beberapa jawaban telah menyarankan bahwa klien dapat memberikan nonce dan itu akan melayani tujuan yang sama. Namun ini mematahkan model respons-tantangan, apa implikasinya?

85
user2014

A nonce adalah nilai unik yang dipilih oleh entitas dalam protokol, dan digunakan untuk melindungi entitas itu dari serangan yang termasuk dalam payung yang sangat besar dari "ulangan".

Misalnya, pertimbangkan protokol otentikasi berbasis kata sandi yang berbunyi seperti ini:

  • server mengirim "tantangan" (nilai yang seharusnya acak c ) ke klien
  • klien akan merespons dengan mengirim h (c || p) di mana h adalah fungsi hash aman (mis. SHA-256), p adalah kata sandi pengguna, dan ' || 'menunjukkan penggabungan
  • server mencari kata sandi dalam basis datanya sendiri, menghitung ulang respons klien yang diharapkan, dan melihat apakah cocok dengan yang dikirim klien

Kata sandi adalah nilai rahasia yang sesuai dengan otak manusia; dengan demikian, mereka tidak bisa sangat kompleks, dan dimungkinkan untuk membangun kamus besar yang akan berisi kata sandi pengguna dengan probabilitas tinggi. Dengan "besar" maksud saya "dapat disebutkan dengan cluster skala menengah dalam beberapa minggu". Untuk diskusi saat ini, kami menerima bahwa penyerang dapat memecahkan satu kata sandi dengan menghabiskan beberapa minggu perhitungan; ini adalah tingkat keamanan yang ingin kita capai.

Bayangkan penyerang pasif: penyerang menguping tetapi tidak mengubah pesan. Dia melihat c dan h (c || p) , jadi dia dapat menggunakan cluster-nya untuk menghitung kata sandi potensial sampai kecocokan ditemukan. Ini akan mahal baginya. Jika penyerang ingin menyerang dua kata sandi maka dia harus melakukan pekerjaan dua kali . Penyerang ingin memiliki sedikit pembagian biaya antara dua contoh serangan, menggunakan tabel prekomputasi ("Rainbow table" hanyalah semacam tabel prakomputasi dengan penyimpanan yang dioptimalkan; tetapi membangun tabel Rainbow masih membutuhkan enumerasi kamus lengkap dan hashing masing-masing kata sandi). Namun, tantangan acak mengalahkan penyerang: karena setiap contoh melibatkan tantangan baru, input fungsi hash akan berbeda untuk setiap sesi, bahkan jika kata sandi yang sama digunakan. Dengan demikian, penyerang tidak dapat membangun tabel prekomputasi yang berguna, khususnya tabel Rainbow.

Sekarang anggaplah penyerang menjadi aktif. Alih-alih hanya mengamati pesan, ia akan secara aktif mengubah pesan, menjatuhkan beberapa, menduplikasi yang lain, atau memasukkan pesannya sendiri. Penyerang sekarang dapat mencegat upaya koneksi dari klien. Penyerang memilih dan mengirimkan tantangannya sendiri ( c ') dan menunggu respons klien ( h (c' || p) ). Perhatikan bahwa server yang sebenarnya tidak dihubungi; penyerang hanya menjatuhkan koneksi secara tiba-tiba segera setelah respons klien, sehingga dapat mensimulasikan kesalahan jaringan jinak. Dalam model serangan ini, penyerang telah membuat peningkatan besar: ia masih memiliki tantangan c ' dan respons yang sesuai, tetapi tantangannya adalah nilai yang penyerang telah memilih sesuai keinginannya. Apa yang akan dilakukan penyerang adalah selalu menghadapi tantangan yang sama c '. Menggunakan tantangan yang sama setiap kali memungkinkan penyerang untuk melakukan perhitungan awal: ia dapat membangun tabel yang sudah dihitung sebelumnya (yaitu tabel Rainbow) yang menggunakan "tantangan" khusus itu. Sekarang penyerang dapat menyerang beberapa kata sandi yang berbeda tanpa menimbulkan biaya kamus-enumerasi untuk masing-masing.

A klien nonce menghindari masalah ini. Protokol menjadi:

  • server mengirimkan tantangan acak c
  • klien memilih nonce n (harus berbeda setiap kali)
  • klien mengirim n || h (c || n || p)
  • server mengkompilasi ulang h (c || n || p) (menggunakan p dari databasenya) dan melihat apakah nilai ini cocok dengan apa yang dikirim klien

Karena klien menyertakan nilai acak baru ("nonce") dalam input fungsi hash untuk setiap sesi, input fungsi hash akan berbeda setiap kali, bahkan jika penyerang dapat memilih tantangan. Ini mengalahkan tabel yang sudah dikomputasi (Pelangi) dan mengembalikan tingkat keamanan yang kami maksudkan.

Emulasi kasar dari notce unik adalah nama pengguna. Dua pengguna berbeda dalam sistem yang sama akan memiliki nama yang berbeda. Namun, pengguna akan mempertahankan namanya ketika ia mengubah kata sandi; dan dua pengguna yang berbeda mungkin memiliki nama yang sama pada dua sistem yang berbeda (mis. setiap sistem mirip Unix memiliki pengguna "root"). Jadi nama pengguna bukan nonce yang baik (tapi masih lebih baik daripada tidak memiliki client sama sekali).

Singkatnya, klien nonce adalah tentang melindungi klien dari serangan replay ("server" sebenarnya adalah seorang penyerang, yang akan mengirimkan tantangan yang sama ke setiap klien yang ingin diserang). Ini tidak diperlukan jika tantangan dijalankan melalui saluran yang mencakup otentikasi server yang kuat (seperti SSL). Pertukaran Kunci Otentikasi Kata Sandi adalah protokol canggih yang memastikan otentikasi berbasis kata sandi bersama antara klien dan server, tanpa memerlukan kepercayaan apriori ("sertifikat root" ketika klien SSL mengotentikasi sertifikat server SSL) dan melindungi terhadap penyerang aktif dan pasif (termasuk serangan "cluster-selama-dua-minggu" pada satu kata sandi, jadi itu lebih baik daripada protokol di atas, nonce atau no nonce).

138
Thomas Pornin

Izinkan saya mencoba menjawab pertanyaan Anda: "Dengan anggapan bahwa penyerang tidak ingin terlibat dalam serangan manusia-di-tengah dan ingin memulihkan detail otentikasi, bagaimana cara conce memberikan tambahan perlindungan?"

Biasanya klien tidak hanya termasuk notce dengan permintaan, tetapi menandatangani seluruh permintaan, termasuk nonce. Ini berarti bahwa bahkan jika penyerang mencegat pesan antara klien dan server:

  1. Serangan replay tidak akan berfungsi (karena server melacak nonces klien).
  2. Penyerang tidak bisa hanya menghasilkan pesan baru dengan klien baru , karena ia tidak tahu bagaimana caranya tanda pesan baru dengan tepat (yaitu tidak memiliki rahasia klien, atau kunci pribadi).
7
Bosh

Menurut RFC 2617 , parameter cnonce dan nc melindungi dari serangan plaintext yang dipilih. Bagaimana ini melindungi dari serangan seperti itu?

Jika Eve mengubah nonce yang dikirimkan server ke klien, apa yang didapat Eve? Eve tidak dapat menghasilkan h(password || nonce) from h(password || fake_nonce) dan secara teori sepertinya server tidak seharusnya menerima h(password || fake_nonce) tetap karena server harus tahu berapa kali ini dikeluarkan dan apa lagi yang belum.

1
paynes_bay

Saya pikir ide yang baik adalah membaca tentang bagaimana nilai nonce digunakan dalam sesuatu seperti Oauth . Singkatnya, ketika aplikasi menggunakan OAuth membuat permintaan ke penyajian yang didukung OAuth, permintaan tersebut harus berisi banyak bidang, dua di antaranya adalah stempel waktu dan nonce. Tujuan dari formulir jelas: ini memberikan indikasi jangka waktu bahwa pesan telah dikirim sehingga server dapat membuat tebakan yang lebih baik, apakah pesannya basi atau tidak. Yang terakhir ini jelas sekelompok karakter acak/byte.

Ketika seluruh tajuk OAuth di hash dengan rahasia konsumen, kedua bidang ini disertakan. Lalu tanda tangan ditambahkan ke permintaan (apakah itu parameter kueri atau tajuk HTTP) dan dikirim pada ke server. Badan aktual dari permintaan adalah bukan di-hash.

Server OAuth harus melacak nilai Ncece set sebelumnya untuk klien yang diberikan untuk memastikan bahwa mereka tidak digunakan kembali. Mengingat bahwa isi pesan dapat berubah (pada dasarnya tidak memiliki efek pada hash) penting untuk memiliki sesuatu yang lain yang akan berubah (mis. the nonce) untuk memastikan bahwa permintaan unik. Mengingat sifat terbuka/teks biasa dari HTTP, ini cukup penting.

Apakah ini membantu menjelaskan tujuannya sama sekali? (semoga saja :)).

1
OJ.