Apa itu otentikasi intisari?

101

Apa perbedaan Digest Authentication dengan Basic Authentication selain dari mengirim kredensial sebagai teks biasa?

digest-authentication

— SoftwareGeek
sumber

Penjelasan bagus oleh @Gumbo di sini: stackoverflow.com/a/5288679/591487

— inorganik

Sesuatu yang TIDAK PERNAH Anda gunakan. Tidak melindungi kata sandi saat transit dan mengharuskan server untuk menyimpan kata sandi secara sederhana.

— CodesInChaos

Intisari memang memberikan keamanan saat transit yang lebih baik daripada otentikasi Dasar untuk lalu lintas tidak terenkripsi , tetapi lemah. JAUH lebih aman menggunakan Autentikasi dasar yang dikombinasikan dengan SSL / TLS, karena dengan cara itu Anda juga dapat menyimpan sandi di server terenkripsi.

— rustyx

Jawaban:

179

Perbedaan utamanya adalah tidak perlu mengirimkan nama pengguna dan kata sandi melalui kawat dalam teks biasa. Ia juga kebal terhadap serangan ulang, karena menggunakan nomor satu kali dari server.

Server memberi klien nomor sekali pakai (nonce) yang digabungkan dengan nama pengguna, bidang, sandi, dan permintaan URI. Klien menjalankan semua bidang tersebut melalui metode hashing MD5 untuk menghasilkan kunci hash.

Ia mengirimkan kunci hash ini ke server bersama dengan nama pengguna dan ranah untuk mencoba mengotentikasi.

Di sisi server, metode yang sama digunakan untuk menghasilkan hashkey, hanya saja alih-alih menggunakan kata sandi yang diketikkan ke browser, server mencari kata sandi yang diharapkan untuk pengguna dari DB penggunanya. Itu mencari kata sandi yang disimpan untuk nama pengguna ini, berjalan melalui algoritma yang sama dan membandingkannya dengan apa yang dikirim klien. Jika cocok maka akses diberikan, jika tidak maka dapat mengirim kembali 401 Unauthorized (tidak ada login atau login gagal) atau 403 Forbidden (akses ditolak).

Otentikasi intisari distandarisasi di RFC2617 . Ada gambaran bagus tentang itu di Wikipedia :

Anda bisa memikirkannya seperti ini:

Klien membuat permintaan
Klien mendapatkan kembali nonce dari server dan permintaan otentikasi 401
Klien mengirim kembali array respons berikut (nama pengguna, ranah, generate_md5_key (nonce, nama pengguna, ranah, URI, password_given_by_user_to_browser)) (ya, itu sangat disederhanakan)
Server mengambil nama pengguna dan wilayah (ditambah ia tahu URI yang diminta klien) dan mencari kata sandi untuk nama pengguna itu. Kemudian ia pergi dan melakukan versinya sendiri dari generate_md5_key (nonce, username, realm, URI, password_I_have_for_this_user_in_my_db)
Ini membandingkan output dari generate_md5 () yang didapatnya dengan yang dikirim klien, jika cocok, klien mengirim kata sandi yang benar. Jika tidak cocok, kata sandi yang dikirim salah.

— Ian C.
sumber

Penjelasan yang bagus. Apakah nama pengguna & sandi untuk pengguna windows? Dari mana mereka dihasilkan?

— SoftwareGeek

Mereka adalah apa pun yang diketik pengguna di browser. Kata sandi harus cocok dengan apa pun yang disimpan server untuk kata sandi untuk pengguna itu. Kemungkinan besar itu adalah sesuatu yang spesifik untuk aplikasi web itu dan bukan kata sandi Windows Anda. Ini sangat tergantung pada cara aplikasi web disusun.

— Ian C.

Jawaban ini berumur 6 tahun, tapi saya rasa semua sistem yang sadar keamanan menyimpan kata sandi dalam format hash-asin sekarang. Tidak ada, dan tidak boleh ada, metode untuk mendapatkan kata sandi asli dari database sehingga otorisasi intisari tidak mungkin dilakukan.

— Ramon de Klein

Jika intisari hash nama pengguna dan kata sandi disimpan dalam db dan bukan kata sandi biasa, maka masih memungkinkan untuk menggunakan digest auth @RamondeKlein

— karakays

@BlueBockser Saya pikir karakays berarti bahwa alih-alih menggunakan kata sandi biasa, hash yang dihasilkan dari menggabungkan nama pengguna dan kata sandinya harus disimpan di server saat mendaftar dan dihitung di sisi klien sebelum mengautentikasi. Ini juga dapat dilakukan hanya dengan hash kata sandi.

— logo_writer

Hash kredensial dikirim melalui kawat.

HA1 = MD5(username:realm:password)

Wikipedia memiliki artikel yang sangat bagus tentang topik ini

— Philip Fourie
sumber

dari klien ke server? Bisakah Anda memberikan langkah-langkah untuk interaksi? Artikel Wikipedia bagus tapi saya butuh penjelasan atau contoh yang lebih baik.

— SoftwareGeek

Ya, klien menghasilkan nilai hash dan mengirimkannya ke server. Artikel Wikipedia menjelaskan protokol secara rinci, saya sarankan Anda merujuknya untuk informasi lebih lanjut.

— Philip Fourie

Satu-satunya cara untuk mendapatkan hash HA1 dari kredensial adalah dengan mengetahui kata sandinya. Server mengetahui HA1 tetapi bukan kata sandi yang membuatnya. Jika HA1 diketahui oleh penyerang, ia bisa masuk ke sistem. Jadi tidak dikirim ke kabel. Hash lebih lanjut berdasarkan nonce, dll. Dilakukan sebelum melakukan ini, dan ini harus sesuai dengan perhitungan serupa yang dilakukan di server. Jadi, selama server merahasiakan HA1, sistem aman.

— Chris Oakley
sumber

Ini adalah penjelasan untuk otentikasi Digest, di mana kata sandi tidak dikirim dalam teks biasa (yang merupakan kasus untuk

— Autentikasi