it-swarm-id.com

https keamanan - haruskah kata sandi di-sisi-server atau sisi-klien?

Saya sedang membangun aplikasi web yang mengharuskan pengguna untuk masuk. Semua komunikasi melewati https. Saya menggunakan kata sandi bcrypt untuk hash.

Saya menghadapi dilema - dulu saya pikir lebih aman membuat hash sisi klien (menggunakan JavaScript) dan kemudian membandingkannya dengan hash di sisi server DB. Tapi saya tidak yakin ini lebih baik daripada mengirim kata sandi teks biasa melalui https dan kemudian hashing sisi server.

Alasan saya adalah bahwa jika penyerang dapat mencegat lalu lintas https (= baca kata sandi plaintext), misalnya, ia juga dapat mengubah JavaScript sehingga ia mengirim kata sandi plaintext bersama kata kunci hash - di mana ia dapat mencegatnya.

Alasan terhadap hashing sisi klien hanya kemudahan penggunaan. Jika saya hash sisi klien saya perlu menggunakan dua perpustakaan terpisah untuk hashing. Ini bukan masalah yang tidak dapat diatasi, tetapi merupakan gangguan.

Apakah ada keuntungan keamanan dalam menggunakan hashing sisi klien? Mengapa?

Haruskah saya juga menggunakan respons tantangan?

PEMBARUAN: apa yang paling menarik minat saya adalah ini - apakah teknik ini (hashing sisi klien, respons permintaan) menambahkan keuntungan keamanan yang signifikan jika - https digunakan? Jika demikian, mengapa?

116
johndodo

Jika Anda hash di sisi klien, kata sandi hash menjadi kata sandi yang sebenarnya (dengan algoritma hashing tidak lebih dari alat untuk mengkonversi ser-held mnemonic ke kata sandi yang sebenarnya).

Ini berarti bahwa Anda akan menyimpan penuh "plain-text" kata sandi (hash) dalam database, dan Anda akan kehilangan semua manfaat hashing di tempat pertama.

Jika Anda memutuskan untuk pergi dengan rute ini, Anda mungkin juga melewatkan hashing dan hanya mengirim dan menyimpan kata sandi mentah pengguna (yang, kebetulan, saya tidak akan merekomendasikan).

124
Nicole Calinoiu

Hashing pada klien masuk akal hanya jika Anda tidak mempercayai server dengan cara tertentu, dan tidak ingin menunjukkannya kata sandi "sebenarnya" (yang diingat oleh pengguna manusia). Mengapa Anda tidak ingin menunjukkan kata sandi ke situs yang digunakan kata sandi tersebut? Karena Anda memiliki menggunakan kembali kata sandi di tempat lain ! Sekarang itu biasanya buruk, tetapi ada versi yang relatif aman yang menjelma dalam berjuta ekstensi browser atau bookmarklet seperti yang ini atau yang it (saya tidak menjamin kualitasnya). Ini adalah alat di mana pengguna manusia mengingat "kata sandi utama", dari mana kata sandi khusus situs dihasilkan, menggunakan nama domain situs sebagai semacam garam, sehingga dua situs berbeda mendapatkan kata sandi yang berbeda.

Meskipun skenario ini masuk akal, melakukannya dengan Javascript yang dikirim oleh server itu sendiri tidak. Memang, maksud dari hashing sisi klien kata sandi adalah bahwa server berpotensi bermusuhan (mis. Ditumbangkan oleh penyerang), dan dengan demikian kode Javascript yang dikirim oleh server itu, paling tidak, adalah tersangka. Anda tidak ingin memasukkan kata sandi Anda yang berharga di Javascript yang bermusuhan ...


Kasus lain untuk hashing sisi klien adalah tentang hashing lambat. Karena kata sandi, menurut definisi, lemah, Anda ingin menggagalkan serangan kamus . Anda berasumsi bahwa orang jahat mendapat salinan database server, dan akan "mencoba kata sandi" di komputernya sendiri (lihat posting blog ini untuk beberapa diskusi tentang ini). Untuk memperlambat musuh, Anda menggunakan proses hashing yang inheren lambat (seperti bcrypt ), tetapi ini akan membuat pemrosesan menjadi lambat untuk semua orang, termasuk server. Untuk membantu server, Anda mungkin ingin membongkar sebagian pekerjaan pada klien, karenanya lakukan setidaknya sebagian dari itu dalam beberapa kode Javascript yang berjalan di browser klien ...

Sayangnya, Javascript sangat lambat dalam pekerjaan semacam ini (biasanya 20 hingga 100 kali lebih lambat daripada kode C yang layak), dan sistem klien tidak akan dapat berkontribusi banyak untuk upaya hashing. Idenya bagus tetapi harus menunggu untuk teknologi yang lebih baik (itu akan bekerja dengan Java klien, meskipun: dengan JVM yang layak, dioptimalkan Java kode sekitar 2 hingga 4 kali lebih lambat daripada kode C yang dioptimalkan, untuk pekerjaan hashing).


Singkatnya, tidak ada kasus yang sangat baik untuk melakukan hashing kata sandi sisi klien, dari kode Javascript yang dikirim oleh server itu sendiri. Cukup kirim kata sandi "apa adanya" ke server melalui terowongan HTTPS (halaman login, URL tujuan form, dan halaman apa pun yang dilindungi oleh kata sandi, harus semua dilayani melalui SSL, jika tidak Anda memiliki masalah keamanan yang lebih mendesak daripada penggunaan kata sandi).

32
Thomas Pornin

Saya menemukan semua kekhawatiran Anda terdengar, tetapi rekomendasi saya adalah melakukannya di sisi server.

Selalu ada peluang yang cukup besar bahwa pengguna akan membiarkan terminal mereka tidak terkunci, memungkinkan manipulaton. Dan juga; jika logika hashing Anda adalah sisi klien, Anda mengeksposnya.

Pilihan lain adalah membuat sisi server kata sandi; maka Anda tidak mengirim kata sandi teks yang jelas. Tetapi Anda masih perlu mengkomunikasikan kata sandi kepada pengguna. Dan karena sebagian besar pengguna masih tidak menggunakan email terenkripsi, saya menganggapnya kurang aman.

Saya telah melihat solusi untuk mengirim kata sandi melalui terowongan terenkripsi ke ponsel; tapi saya ragu keamanannya lebih baik dari SSL. Mungkin seseorang bisa membuktikan/menyangkal ini?

11
rmorero

Memukul sisi server penting karena semua jawaban lain telah mengindikasikan, tetapi saya ingin menambahkan bahwa hashing sisi klien akan menjadi fitur keamanan yang bagus selain it hashing sisi server.

Hashing sisi klien memiliki manfaat dalam skenario berikut:

  1. Melindungi kata sandi pengguna ketika server dikompromikan. Yaitu. jika klien tidak dikompromikan, tetapi servernya adalah, jika klien memiliki kata sandi, server masih bisa mendapatkan akses ke satu sistem, tetapi Anda telah melindungi kata sandi pengguna yang penting jika mereka menggunakan kata sandi itu di tempat lain.
  2. Melindungi kata sandi pengguna ketika pengguna berpikir mereka masuk ke satu server tetapi mereka benar-benar masuk ke yang lain (kesalahan pengguna). Sebagai contoh, jika saya memiliki dua akun perbankan, dan saya secara tidak sengaja memasukkan salah satu kata sandi bank saya ke situs web bank yang salah, jika bank tersebut mem-hash sisi klien, bank itu tidak akan mengetahui kata sandi bank saya yang lain. Saya pikir itu akan menjadi hal yang "sopan" untuk dilakukan untuk hash sisi klien sehingga kata sandi teks mereka tidak pernah dikirimkan melalui kabel.

Sebagian besar itu menunjukkan rasa hormat terhadap kata sandi pengguna. Pengguna berbagi rahasia yang mungkin tidak eksklusif untuk perangkat lunak Anda, jadi jika Anda menghormati rahasia itu, Anda harus melakukan segala daya untuk melindunginya.

10
Samuel

Jika Anda berada di terowongan HTTPS, kata sandi atau hash harus diamankan dari pengawasan Ethernet.

Di sisi klien mungkin Anda bisa memberi garam hash dengan id sesi.
Ini bisa lebih sulit untuk disimulasikan Javascript jahat.

2
bua

Anda bisa melakukan keduanya, Anda hash di klien sehingga jika penyerang bisa melewati keamanan https mereka tidak akan dapat melihat kata sandi teks biasa. Kemudian hash lagi di server jadi jika penyerang mendapatkan kata sandi yang disimpan di server dia tidak bisa hanya mengirimkannya ke server dan mendapatkan akses ke kata sandi.

1
nat that

Hashing kata sandi sisi klien akan membutuhkan Javascript. Beberapa orang menonaktifkan Javascript di browser mereka. Anda harus menangani skenario ini.

Saya telah melihat perangkat lunak forum yang melakukan hashing sisi klien, dan mengirimkan hash saat login jika mungkin, jika tidak kata sandi dikirim dalam teks biasa. Jadi itu berfungsi di kedua situasi.

Mengirim kata sandi secara jelas bukan masalah utama jika Anda akan menggunakan https. Idealnya server Anda kemudian harus menolak untuk melayani halaman di http untuk menghindari man in the middle attack. Alasannya adalah: seorang penyerang bisa secara paksa 'menurunkan' koneksi Anda dari https ke http dan mulai mengendus lalu lintas (misalnya dengan alat seperti SSL Strip).

1
Anonymous

Jawaban yang diterima dari @ Nicole Calinoiu tentu saja benar tetapi mungkin sulit dipahami di awal.

Intinya adalah kata sandi harus di-hash di server agar orang jahat tidak dapat menggunakan hash yang telah diretasnya dari database dari server untuk mendapatkan akses ke akun atau data Anda.

Seperti yang sudah dikatakan jika Anda hash di sisi klien dan back-end mendukung itu, maka hash menjadi kata sandi Anda dan jika hash dicuri melalui peretasan, maka peretas memiliki kata sandi.

@ Thomas Pornin jawaban juga muncul dengan poin yang sangat bagus mengapa Anda ingin mengaitkan kata sandi pada klien, tetapi hal yang ia jelaskan dalam cerita pertamanya hanya dapat dilakukan jika back-end server memang mendukung penanganan kata sandi hash (yaitu jangan hash kata sandi jika sudah hash, tetapi seseorang mencoba untuk mendukung sesuatu seperti itu sangat tidak mungkin ), yang sebagian besar waktu tidak akan terjadi kurasa. Kisah kedua tentang dirinya sangat bagus.

0
Ini