Mengapa hampir tidak ada kata sandi hash halaman web di klien sebelum mengirimkan (dan hashing lagi di server), untuk "melindungi" terhadap penggunaan kembali kata sandi?

46

Ada banyak situs di Internet yang memerlukan informasi login, dan satu-satunya cara untuk melindungi terhadap penggunaan kembali kata sandi adalah "janji" bahwa kata sandi di-hash di server, yang tidak selalu benar.

Jadi saya bertanya-tanya, seberapa sulit untuk membuat halaman web yang hash password di komputer klien (dengan Javascript), sebelum mengirimnya ke server, di mana mereka akan di-hash? Secara teori ini tidak memberikan keamanan ekstra, tetapi dalam praktiknya ini dapat digunakan untuk melindungi terhadap "situs jahat" yang tidak mengaitkan kata sandi Anda di server.

— Martín Fixman
sumber

18

kata sandi hash yang dikirim dengan jelas tidak lebih baik dari kata sandi yang dikirim dengan jelas jika server hanya membandingkan hash, man in the middle attacks menyukai "keamanan" semacam ini

3

Solusi terbaik adalah (imo) pengelola kata sandi sisi klien. Dengan begitu, Anda dapat menghasilkan string karakter acak sebagai kata sandi Anda dan Anda tidak mengandalkan server untuk 'melindungi' Anda.

— Dean Harding

2

@Jarrod - kedengarannya bagi saya, meskipun, seperti situs web yang berbeda menggunakan algoritma hashing sisi klien yang berbeda akan mencegah serangan yang dijelaskan oleh komik itu. Satu kata sandi yang banyak digunakan kembali menjadi banyak kata sandi yang berbeda melalui algoritma hash yang berbeda tersebut. Perhitungan hash sisi klien tidak mencegah jenis keamanan lain diterapkan - seperti mengirim hash melalui koneksi yang aman.

— Steve314

2

@ Steve314 poin saya adalah segala sesuatu di klien dikompromikan secara default. Anda dapat hash dan hash dan hash, jika itu dilakukan pada klien dan diteruskan bolak-balik ke server di cleardalamnya hanya masturbasi matematika pada saat itu. Saya harus memperbaiki sistem yang saya warisi, yang dirancang persis seperti yang Anda dan OP jelaskan, itu terus-menerus diretas oleh remaja dengan Wireshark. Kami hanya menguncinya ketika kami memasukkan REALenkripsi dan dienkripsi dan menandatangani semua muatan ke dan dari server, manipulasi akun berhenti dan tidak pernah terjadi lagi setelah itu.

5

Kedengarannya seperti rencana Anda untuk melindungi diri dari situs-situs jahat adalah meminta situs-situs jahat itu untuk mengatur keamanan yang lebih baik. ?

— pc1oad1etter

46

Kenapa tidak digunakan? Karena itu banyak pekerjaan ekstra untuk mendapatkan nol. Sistem seperti itu tidak akan lebih aman. Bahkan mungkin kurang aman karena memberikan kesan yang salah tentang lebih aman, mengarahkan pengguna untuk mengadopsi praktik yang kurang aman (seperti penggunaan kembali kata sandi, kata sandi kamus, dll).

— Rein Henrichs
sumber

2

Ini adalah jawaban terbaik sejauh ini.

1

Ini seperti enkripsi Blu-Ray dan DVD. Bahkan tidak memerlukan Kunci untuk membuka kunci. Satu-satunya "perlindungan" yang diberikannya adalah ketika DVD pertama kali keluar harganya lebih mahal untuk membeli disk untuk menyalinnya daripada membeli salinan penuh film. Tentu saja sekarang Anda dapat membeli dvd untuk satu dolar dan lebih banyak lagi adalah fakta bahwa kuncinya adalah pengetahuan umum sekarang. Hal yang sama terjadi dengan Blu-Ray

— Michael Brown

2

Saya pikir hashing sisi klien kata sandi tidak menambah keamanan. Jika saya mendengarkan, saya hanya bisa melihat hash Anda, bukan kata sandi Anda. Jika server mengirim tantangan (sebagaimana mestinya) hash bahkan tidak dapat digunakan kembali.

— Andomar

2

Saya pikir pendekatan x4u mungkin sangat sesuai untuk beberapa aplikasi di mana persyaratan keamanan berada di suatu tempat antara mentransmisikan kata sandi pada kabel dan menggunakan sertifikat. Saya pikir beberapa nay sayers mengabaikan bahwa hashing kata sandi sebelum mulai dilakukan dilakukan selain penanganan kredensial sisi server standar. Jadi pertanyaannya adalah ini: Apakah proposal x4u meningkatkan keamanan dalam skenario transmisi-sandi-on-the-the-wire atau tidak. Saya katakan itu. Kunci untuk mewujudkan ini terletak pada penggunaan garam per kata sandi.

— LOAS

6

Cara yang benar untuk mencegah serangan MITM adalah enkripsi ujung ke ujung. TLS (https) ada: gunakan Jangan ciptakan skema crypto Anda sendiri.

— Rein Henrichs

14

Secara teori ini tidak memberikan keamanan ekstra, tetapi dalam praktiknya ini dapat digunakan untuk melindungi terhadap "situs jahat" yang tidak mengaitkan kata sandi Anda di server.

Bagaimana tepatnya hal ini melindungi Anda? Kedengarannya semua yang ingin Anda lakukan adalah hash kata sandi hash yang tidak berguna. Karena kata sandi hash kemudian akan menjadi kata sandi.

Ada banyak situs di Internet yang memerlukan informasi login, dan satu-satunya cara untuk melindungi terhadap penggunaan kembali kata sandi adalah "janji" bahwa kata sandi di-hash di server, yang tidak selalu benar.

Bagaimana kalau tidak menggunakan kata sandi yang sama untuk lebih dari satu situs. Alasan situs web meng-hash kata sandi secara teori adalah untuk mencegah akses ke akun Anda jika MEREKA dikompromikan. Menggunakan kata sandi yang sama untuk banyak situs web adalah hal yang bodoh.

Jika Anda memang menggunakan javascript, yang harus dilakukan "peretas" adalah, gunakan metode yang sama pada kata sandi hashed-hashed. Setelah Anda memiliki informasi hash, itu hanya waktu yang diperlukan untuk menghitung kata sandi-> hash yang sama dalam basis data yang merupakan faktor yang mencegah akses ke akun.

— Ramhound
sumber

1

Jika browser Anda selalu hash dengan cara yang sama, maka ya hash Anda dapat digunakan sebagai kata sandi di tempat lain. Tetapi bagaimana jika browser menetapkan garam berdasarkan situs (mungkin domain?) Sebelum hashing dan mengirimkannya ke situs? Saya pikir ini ide yang menarik.

— Tesserex

2

jika itu pada klien itu dikompromikan, garam pada klien itu jelas, ini adalah pertanyaan yang tidak masuk akal. jika Anda tidak mengerti jawaban @ Ramhound Anda tidak boleh menulis kode yang perlu aman, dan mulai membaca tentang keamanan dan kriptografi dari awal.

3

Saat Anda mengutip poster asli, harap format teksnya (pilih teksnya dan gunakan ikon kutipan tepat di atas editor)

— Marjan Venema

1

Jarrod, silakan ikuti saran Anda sendiri dan dapatkan sedikit informasi sendiri sebelum Anda membuat klaim konyol. Seorang pria di serangan tengah tidak berguna terhadap fungsi hash aman dengan panjang garam yang masuk akal. Dan saran saya sama sekali bukan 'keamanan karena ketidakjelasan', sebenarnya aman berdasarkan apa yang saat ini diketahui dan diterima oleh para ahli di bidang ini dan digunakan dengan cara yang sama di banyak protokol. Ini bukan penemuan saya, saya hanya menerapkan prosedur yang dipahami dengan baik untuk login situs web. Asumsi keliru Anda tidak mendapatkan substansi apa pun oleh fakta bahwa mereka jelas juga dimiliki oleh banyak orang lain.

— x4u

3

Jika garam diketahui oleh klien dan dikirim secara jelas dari server, apa pun di tengah tahu juga. Tidak pernah mengatakan, saya harus membatalkan hash, jika Anda tahu garam pada klien, maka tidak aman.

11

Karena itu akan menambah sedikit tanpa nilai. Alasan hashing adalah bahwa jika database Anda diretas, peretas tidak akan memiliki daftar kata sandi yang valid, hanya hash. Karenanya mereka tidak dapat menyamar sebagai pengguna. Sistem Anda tidak memiliki pengetahuan tentang kata sandi.

Aman berasal dari sertifikat SSL plus beberapa bentuk otentikasi. Saya ingin pengguna saya memberikan kata sandi sehingga saya bisa menghitung hash darinya.

Juga, algoritma hashing akan berada di server di area yang lebih aman. Menempatkannya di klien, sangat mudah untuk mendapatkan kode sumber untuk Javascript, bahkan jika file skrip direferensikan tersembunyi.

— Jon Raynor
sumber

3

Ini jawaban terbaik. Anda harus mengenkripsi di layer transport. Tanpa melakukan itu, sisanya tidak aman. Ya, Anda dapat menulis fungsi enkripsi ... tetapi fungsi itu akan terlihat oleh pengguna akhir (jahat). Gunakan SSL.

— pc1oad1etter

Keamanan algoritma hashing tidak boleh bergantung pada apakah itu rahasia. Algoritma Hashing untuk keamanan harus merupakan fungsi satu arah: bahkan jika Anda memiliki kode, sulit untuk membatalkannya. Sebaliknya, Anda harus menggunakan perpustakaan hash terkenal yang dirancang hanya untuk kata sandi. Jika itu tidak terkenal, itu hampir pasti buggy atau salah sasaran.

— leewz

6

Solusinya lebih sederhana dari itu. Sertifikat klien. Saya membuat sertifikat klien di mesin saya. Ketika saya mendaftar dengan situs web, kami berjabat tangan menggunakan sertifikat klien saya dan sertifikat server.

Tidak ada kata sandi yang dipertukarkan dan bahkan jika seseorang meretas basis data semua yang mereka miliki adalah kunci publik dari sertifikat klien saya (yang harus diasinkan dan dienkripsi oleh server untuk tingkat keamanan tambahan).

Sertifikat klien dapat disimpan pada kartu pintar (dan diunggah ke brankas online aman menggunakan kata sandi utama).

Keindahan dari semua itu adalah menghilangkan konsep phishing ... Anda tidak pernah memasukkan kata sandi ke situs web, Anda hanya berjabat tangan dengan situs web itu. Yang mereka dapatkan adalah kunci publik Anda yang tidak berguna tanpa kunci pribadi. Satu-satunya kerentanan adalah menemukan tabrakan selama jabat tangan dan itu hanya akan bekerja satu kali di satu situs web.

Microsoft mencoba menyediakan sesuatu seperti ini di Windows dengan Cardspace dan kemudian mengirimkannya sebagai standar terbuka. OAuth agak mirip tetapi bergantung pada "pihak penerbit" perantara. InfoCards di sisi lain dapat diterbitkan sendiri. Itu solusi nyata untuk masalah kata sandi ... menghapus kata sandi sekaligus.

OAuth adalah langkah ke arah yang benar.

— Michael Brown
sumber

5

Meskipun sertifikat klien adalah pendekatan yang masuk akal untuk beberapa kasus penggunaan, sertifikat itu bukan sesuatu yang dapat ditambahkan dengan mudah ke login situs web. Mereka membutuhkan banyak kerja sama dari pengguna dan tergantung pada seberapa aman kunci pribadi pengguna. Penggunaan kunci pribadi bisa aman atau nyaman tetapi tidak keduanya sekaligus.

— x4u

5

sebagian besar balasan di sini tampaknya benar-benar ketinggalan titik hashing kata sandi sisi klien.

intinya bukan untuk mengamankan akses ke server yang Anda masuki, karena mencegat hash tidak lebih aman daripada mencegat kata sandi teks biasa.

intinya adalah benar-benar untuk mengamankan kata sandi pengguna , yang biasanya jauh lebih berharga daripada akses masuk situs individu karena sebagian besar pengguna akan menggunakan kembali kata sandi mereka untuk beberapa situs (mereka seharusnya tidak tetapi kenyataannya adalah bahwa mereka melakukannya sehingga tidak boleh dilambaikan ).

ssl sangat bagus untuk melindungi dari serangan mitm, tetapi jika aplikasi login dikompromikan di server, ssl tidak akan melindungi pengguna Anda. jika seseorang memiliki akses jahat ke server web, mereka kemungkinan akan dapat mencegat kata sandi dalam teks biasa karena dalam banyak kasus kata sandi hanya diacak oleh skrip di server. maka penyerang dapat mencoba kata sandi tersebut di situs lain (biasanya lebih berharga) menggunakan nama pengguna yang serupa.

keamanan adalah pertahanan yang mendalam, dan hashing sisi klien cukup menambahkan lapisan lain. ingat bahwa sementara melindungi akses ke situs Anda sendiri adalah penting, melindungi kerahasiaan kata sandi pengguna Anda jauh lebih penting karena penggunaan kembali kata sandi di situs lain.

— kruk
sumber

2

Jawaban yang diterima membagikan poin Anda dengan cukup baik. Meskipun "kebanyakan balasan" tidak dan karena jawaban Anda tidak benar-benar menambah banyak nilai, tidak ada gunanya menghidupkan kembali pertanyaan ini.

— Frank

itu mungkin lebih merupakan komentar daripada jawaban (permintaan maaf karena tidak mencari cara untuk menambahkan ke utas komentar jawaban yang diterima), dan meskipun poin saya dibagikan dalam jawaban yang diterima, tampaknya itu tidak cukup jelas karena tampaknya jawaban untuk menyikatnya. terima kasih atas umpan baliknya

— crutchy

@ Jujur jawaban yang diterima berbatasan dengan terlalu lama untuk repot membaca. terlalu banyak detail tentang bagaimana ini dapat diimplementasikan dan melihat manfaat di akhir. Memiliki TL; DR dalam jawaban yang berbeda bermanfaat.

— Jules

2

@ Jules: Karena itulah pengeditan ada.

— Robert Harvey

1

@JarrodRoberson Saya pikir Anda bingung tidak lagi aman dengan tidak aman ? Jika MITM terjadi, akses ke situs sudah menyerah, bukan? Kecuali Anda menggunakan sertifikat klien, bukan kata sandi, yang akan terlalu rumit untuk pengguna biasa. Cara saya melihatnya, hashing sisi klien mencegah kata sandi yang sama dikompromikan di situs lain, dengan asumsi masing-masing algoritma hashing unik. Ini mungkin tidak lebih aman, tetapi juga tidak kurang aman? Jadi mengapa Anda mendorong ini dengan keras? Saya menemukan ini dari meta, dan ini adalah jawaban terbaik yang saya lihat sejauh ini.

— zypA13510

1

Ini sangat mungkin, dan sebenarnya Anda tidak perlu menunggu situs web.

Lihatlah SuperGenPass . Ini adalah bookmarklet.

Itu hanya mengenali bidang kata sandi, menggabungkan apa yang Anda ketik dengan domain situs web, hash itu, mangles itu agak sehingga hanya mendapatkan karakter "diterima" dalam kata sandi, dan hanya dengan itu kata sandi hash Anda dikirim pada kabel.

Dengan menggunakan domain situs dalam proses, Anda mendapatkan kata sandi unik per situs, bahkan jika Anda selalu menggunakan kembali kata sandi yang sama.

Ini tidak terlalu aman (base64-MD5), tetapi Anda dengan sempurna mendistribusikan implementasi berbasis sha-2 jika Anda menginginkannya.

Satu-satunya downside adalah jika perubahan domain, dalam hal ini Anda harus meminta situs web untuk mengatur ulang kata sandi Anda karena Anda tidak dapat memulihkannya sendiri ... itu tidak sering terjadi, jadi saya menganggapnya sebagai trade-off yang dapat diterima.

— Matthieu M.
sumber

Inilah yang saya pikirkan ketika saya membaca pertanyaan; praktis tidak berguna bagi situs untuk melakukan hashing sisi klien mereka sendiri, tetapi ekstensi browser yang melakukannya (menggunakan garam berdasarkan domain) akan secara efektif membatalkan risiko yang terkait dengan penggunaan kembali kata sandi. Tentu saja, bagian yang menyenangkan datang ketika Anda mencoba masuk dari komputer lain ...

— Aaronaught

3

ini tidak lagi aman daripada skema lain yang meneruskan kata sandi di tempat yang jelas. Itu membuat kata sandi unik tetapi tetap tidak dienkripsi , tetapi jika saya memiliki server di tengah, saya hanya dapat mengambil kata sandi yang rumit tetapi masih jelas dan menggunakannya sebanyak yang saya inginkan, itu tidak berubah. Hash bukanlah beberapa peluru ajaib, bahkan bukan enkripsi, mereka disebut hash kriptografi, tetapi itu tidak berarti mereka adalah enkripsi. Tidak masalah jika kata sandi saya adalah passwordatau atau SHA-256 dari passworddengan sedikit garam yang diketahui klien, seorang pria di tengah lampiran dapat menangkapnya.

@Jarrod Roberson: Anda dapat menggunakan kata sandi tentu saja, tetapi Anda tidak dapat menggunakannya kembali untuk akun saya yang lain, yang merupakan intinya. Oleh karena itu, jika salah satu situs web yang saya hubungkan memiliki basis kata sandi dicuri, dan mereka menyimpannya dengan jelas, maka akun saya yang lain aman.

— Matthieu M.

@Aaronaught: di situlah ia bersinar. Karena kata sandi yang dikirim murni berasal dari domain situs web yang Anda masuki dan kata sandi utama pilihan Anda, Anda dapat masuk dari komputer mana pun (dan peramban) selama Anda memiliki bookmarklet. Inilah sebabnya mengapa ini agak lebih nyaman daripada sertifikat.

— Matthieu M.

6

@Jarrod: Ini bukan ukuran keamanan untuk situs , ini adalah ukuran keamanan bagi pengguna . Jika semua orang menggunakan skema seperti ini, penggunaan kembali kata sandi tidak akan menjadi masalah. Sebuah skema MITM bisa menggunakan password klien-hash untuk mendapatkan akses ke yang situs, tetapi hanya bahwa situs. Di situlah letak perbaikan. Biasanya Anda berharap dapat memperoleh akses ke banyak akun hanya dengan memecahkan satu kata sandi, karena kata sandi itu kemungkinan akan digunakan kembali; dalam hal ini, kata sandi yang dipecahkan secara praktis dijamin hanya berlaku untuk situs atau basis data tempat ditemukannya.

— Aaronaught

0

Saya suka jawaban X4u, tetapi menurut saya sesuatu seperti itu harus diintegrasikan ke dalam browser / spesifikasi html - karena saat ini hanya setengah dari jawabannya.

Inilah masalah yang saya miliki sebagai pengguna - saya tidak tahu apakah kata sandi saya akan di-hash di ujung yang lain ketika disimpan dalam database. Garis-garis antara saya dan server mungkin dienkripsi tetapi saya tidak tahu apa yang terjadi pada kata sandi saya setelah mencapai tujuan - mungkin disimpan sebagai teks biasa. Admin admin database mungkin akhirnya menjual database dan sebelum Anda menyadarinya, seluruh dunia tahu kata sandi Anda.

Sebagian besar pengguna menggunakan kembali kata sandi. Orang yang tidak teknis karena mereka tidak tahu yang lebih baik. Orang-orang teknis karena begitu Anda mendapatkan kata sandi ke-15 atau lebih banyak orang tidak akan mengingatnya kecuali mereka menuliskannya (Yang kita semua tahu juga merupakan ide yang buruk).

Jika Chrome atau IE atau apa pun yang saya gunakan bisa memberi tahu saya bahwa kotak kata sandi secara instan akan menjadi hash sisi klien menggunakan garam yang dihasilkan server dan secara efektif mengamplas kata sandi itu sendiri - maka saya akan tahu bahwa sebagai pengguna saya dapat menggunakan kembali kata sandi dengan risiko lebih kecil. Saya masih ingin saluran yang dienkripsi juga dan saya tidak ingin ada saluran jatuh selama transmisi.

Pengguna perlu tahu bahwa kata sandi mereka bahkan tidak tersedia untuk dikirim ke server - hanya hash. Saat ini bahkan menggunakan solusi X4U, mereka tidak memiliki cara untuk mengetahui hal ini karena Anda tidak tahu apakah teknologi itu digunakan.

— Chris Nevill
sumber

1

itu diintegrasikan ke dalam browser mencari otentikasi digest dan Anda akan melihat langkah bolak-balik yang diambil di http untuk mendapatkan kata sandi hash, dengan info tambahan, dan diverifikasi di server.

— gbjbaanb

-1

Saya pikir ini adalah metode yang baik untuk digunakan ketika membangun sesuatu seperti kerangka kerja, CMS, perangkat lunak forum, dll, di mana Anda tidak mengontrol server yang mungkin diinstal. Ya, Anda harus selalu merekomendasikan penggunaan SSL untuk login dan aktivitas login, tetapi beberapa situs yang menggunakan framework / cms Anda tidak akan memilikinya, sehingga mereka masih bisa mendapat manfaat dari ini.

Seperti yang telah ditunjukkan orang lain, manfaatnya di sini BUKAN bahwa serangan MITM tidak dapat mengizinkan orang lain untuk masuk ke situs khusus ini seperti Anda, tetapi bahwa penyerang itu tidak akan dapat menggunakan kombo nama pengguna / kata sandi yang sama untuk masuk ke kemungkinan lusinan situs lain tempat Anda mungkin memiliki akun.

Skema seperti itu harus digarami dengan garam acak, atau kombo garam khusus-situs dan spesifik-pengguna, sehingga seseorang yang mendapatkan kata sandi tidak dapat menggunakannya untuk nama pengguna yang sama di situs lain (bahkan situs yang menggunakan skema hashing yang sama ), atau terhadap pengguna situs situs lain yang mungkin memiliki kata sandi yang sama.

Yang lain menyarankan bahwa pengguna harus membuat kata sandi unik untuk setiap situs yang mereka gunakan, atau menggunakan pengelola kata sandi. Meskipun ini adalah nasihat yang bagus dalam teori, kita semua tahu ini adalah kebodohan untuk bergantung pada dunia nyata. Persentase pengguna yang melakukan hal-hal ini kecil dan saya ragu itu akan berubah dalam waktu dekat.

Jadi pengolah kata sandi javascript adalah jenis yang paling sedikit yang dapat dilakukan oleh pengembang kerangka / cms untuk membatasi kerusakan seseorang yang mencegat kata sandi dalam perjalanan (yang mudah melalui jaringan wifi saat ini) jika pemilik situs dan pengguna akhir menjadi lalai tentang keamanan (yang kemungkinan besar).

— matthewv789
sumber