Haruskah saya mencirikan kata sandi sebelum mengirimnya ke sisi server?


110

Saya perhatikan bahwa sebagian besar situs mengirim kata sandi sebagai teks biasa melalui HTTPS ke server. Apakah ada keuntungan jika saya mengirimkan hash kata sandi ke server? Apakah lebih aman?


5
@Jader Dias: Saya tahu Anda tidak menanyakan ini, tetapi tidak akan membuat lebih aman jika Anda hash, KEMUDIAN kirimkan melalui https. Faktanya, ini mungkin membuatnya kurang aman, karena garam Anda terpapar. Selain itu, (membicarakan sisi belakang saya di sini), pencampuran algoritme dapat menyebabkan lebih banyak tabrakan hash, dan membuatnya lebih dapat diretas.
Merlyn Morgan-Graham

@Merlyn "tabrakan hash" bagus!
Jader Dias

Algoritma pencampuran tidak meningkatkan kemungkinan tabrakan sama sekali. Itulah inti dari fungsi hash. Mengingat entropi masukan apa pun, kembalikan keluaran yang memiliki probabilitas yang sama untuk berada di mana saja dalam ruang keluaran yang memungkinkan.
JJ

@JJ "Algoritme pencampuran tidak meningkatkan probabilitas tabrakan sama sekali." Saya sangat ingin melihat bukti dari pernyataan itu. Izinkan saya menghentikan Anda: ini salah , secara umum ini meningkatkan tabrakan. Saya dapat dengan mudah membangun fungsi hashing sehingga h (x) tidak konstan 0 tetapi h (h (x)) = 0 untuk semua x. Jadi, Anda harus merujuk ke kumpulan algoritme hashing yang tepat dan cara Anda mencampurnya. Maka Anda perlu membuktikan pernyataan Anda. AFAIK bahkan untuk beberapa SHA (dengan garam) ini adalah masalah terbuka. Dan pada dasarnya kami yakin ini benar. Kriptografi itu sulit.
aneh

Jawaban:


155

Ini pertanyaan lama, tapi saya merasa perlu memberikan pendapat saya tentang masalah penting ini. Ada banyak informasi yang salah di sini

OP tidak pernah menyebutkan mengirim kata sandi dengan jelas melalui HTTP - hanya HTTPS, namun banyak yang tampaknya menanggapi pertanyaan mengirim kata sandi melalui HTTP untuk beberapa alasan. Yang mengatakan:

Saya percaya kata sandi tidak boleh disimpan (apalagi dikirim) dalam teks biasa. Artinya tidak disimpan di disk, atau bahkan di memori.

Orang-orang yang menanggapi di sini tampaknya berpikir HTTPS adalah peluru perak, padahal sebenarnya bukan. Ini tentu sangat membantu bagaimanapun, dan harus digunakan dalam setiap sesi yang diautentikasi.

Sebenarnya tidak perlu mengetahui apa itu kata sandi asli. Semua yang diperlukan adalah cara yang andal untuk menghasilkan (dan menghasilkan kembali yang andal) sebuah "kunci" otentikasi berdasarkan teks asli yang dipilih oleh pengguna. Dalam dunia yang ideal, teks ini harus segera menghasilkan "kunci" dengan mencirikannya menggunakan garam yang tidak dapat diubah. Salt ini harus unik untuk kredensial pengguna yang dibuat. "Kunci" ini akan menjadi apa yang digunakan sistem Anda sebagai kata sandi. Dengan cara ini jika sistem Anda pernah disusupi di masa mendatang, kredensial ini hanya akan berguna untuk organisasi Anda sendiri, dan tidak di tempat lain di mana pengguna bermalas-malasan dan menggunakan sandi yang sama.

Jadi kami punya kuncinya. Sekarang kita perlu membersihkan semua jejak kata sandi di perangkat klien.

Selanjutnya kita perlu mendapatkan kunci itu ke sistem Anda. Anda tidak boleh mengirimkan kunci atau sandi "dengan jelas". Bahkan tidak melalui HTTPS. HTTPS tidak bisa ditembus. Faktanya, banyak organisasi dapat menjadi MITM tepercaya - bukan dari perspektif serangan, tetapi untuk melakukan inspeksi pada lalu lintas untuk menerapkan kebijakan keamanan mereka sendiri. Ini melemahkan HTTPS, dan ini bukan satu-satunya cara itu terjadi (seperti pengalihan ke serangan HTTP MITM misalnya). Jangan pernah menganggapnya aman.

Untuk menyiasati ini, kami mencirikan kunci dengan nonce sekali. Nonce ini unik untuk setiap pengiriman kunci ke sistem Anda - bahkan untuk kredensial yang sama selama sesi yang sama jika Anda perlu mengirimnya beberapa kali. Anda dapat membalikkan nonce ini setelah masuk di sistem Anda sendiri untuk memulihkan kunci otentikasi, dan mengautentikasi permintaan.

Pada titik ini saya akan melakukan hash secara permanen untuk terakhir kalinya sebelum disimpan secara permanen di sistem Anda sendiri. Dengan cara itu Anda dapat membagikan garam kredensial dengan organisasi mitra untuk tujuan SSO dan sejenisnya, sambil dapat membuktikan bahwa organisasi Anda sendiri tidak dapat meniru pengguna. Bagian terbaik dari pendekatan ini adalah Anda tidak akan pernah membagikan apa pun yang dibuat oleh pengguna tanpa izin mereka.

Lakukan lebih banyak penelitian, karena ada lebih banyak daripada yang telah saya ungkapkan, tetapi jika Anda ingin memberikan keamanan sejati kepada pengguna Anda, saya pikir metode ini saat ini merupakan respons paling lengkap di sini.

TL; DR:

Gunakan HTTPS. Mencirikan kata sandi secara aman, tidak dapat diubah, dengan salt unik per kata sandi. Lakukan ini pada klien - jangan mengirimkan kata sandi mereka yang sebenarnya. Mengirimkan kata sandi asli pengguna ke server Anda tidak pernah "OK" atau "Baik". Bersihkan semua jejak kata sandi asli. Gunakan nonce terlepas dari HTTP / HTTPS. Ini jauh lebih aman di banyak tingkatan. (Jawaban untuk OP).


25
Saya baru saja memeriksa gmail dan facebook - alat pengembang chrome memberi tahu saya POST dengan pesan berkode url yang berisi nama pengguna dan kata sandi saya dalam teks biasa (tanpa garam). Bagaimana / mengapa para pemain besar tidak menggunakan nonce salting pada klien?
gremwell

18
Anda mencirikan kunci dengan nonce dan mengklaim dapat membalikkan nonce di sisi server. Apakah Anda memaksa hash itu? Atau bagaimana Anda mengambil nonce ketika Anda mendapatkan hash = HASH (rahasia + nonce) HASH seharusnya merupakan fungsi yang tidak dapat diubah. Sudahkah Anda menerapkan ini? Saya tidak berpikir apa yang Anda jelaskan itu layak. Bisakah Anda membuat diagram alur protokol?
Perak

19
Jika Anda tidak mempercayai HTTPS, setiap upaya tidak ada gunanya! Kode Anda sendiri dikirim melalui kabel dan penyerang dapat mengubah / mengganti semua upaya Anda untuk mengamankan kata sandi saat transit
Sajid Kalla

3
MitM yang dapat menulis ulang sertifikat dapat menulis ulang nonce. Atau apa yang dikatakan Sajid.
leewz

4
Jika Anda khawatir tentang MITM dengan HTTPS, apa gunanya mengirimkan salt ke klien sehingga klien dapat mengasinkan kata sandi sebelum mengirimkan hash kembali ke server? Sepertinya tidak ada gunanya. Sebaiknya lakukan hash unsalted ke server, lalu gunakan salt untuk hash lagi di server. Jelas, klien tidak bisa menjadi generator garam klien baik karena login berikutnya, itu akan berbeda dan tidak menghitung sisi server hash yang sama.
hancurkan

24

Karena ini melalui HTTPS, tidak masalah untuk mengirim kata sandi tanpa hashing (melalui HTTPS itu bukan teks biasa). Selain itu, jika aplikasi Anda bergantung pada HTTPS untuk menjaga kontennya tetap aman, maka tidak ada gunanya meng-hash kata sandi sebelum mengirimkannya melalui HTTPS (yaitu jika penyerang dapat membatalkan enkripsi data pada kabel, Anda akan disekrup)


5
Ini seharusnya tidak menjadi masalah. Jika klien menggunakan proxy, maka semua proxy akan melihat adalah data yang dienkripsi HTTPS. Jika Anda berbicara tentang serangan man-in-the-middle, sertifikat yang dikonfigurasi dengan benar akan mencegah hal ini.
Kiersten Arnold

7
@Jader: Tidak ada jumlah mengutak-atik data yang akan menghentikan serangan MITM, karena itu hanya dapat menyampaikan apa pun yang terjadi padanya. Tidak masalah apakah Anda mengirimkan kata sandi atau hash. Itu masalah yang sama sekali berbeda.
David Thornley

2
Tujuan SSL (HTTPS = HTTP over SSL) adalah untuk menggagalkan MITM.
yfeldblum

1
@carnold - MINTM - Bagaimana dengan pengalihan ke http? Akankah kebanyakan orang memperhatikan? sslstrip - securityfocus.com/brief/910
nate c

1
@ Jader Dias Anda mencoba menghentikan masalah yang tidak ada. HTTPS menghentikan masalah ini, hash sisi klien tidak menambah jumlah keamanan apa pun. Klien tidak pernah bisa dipercaya.
Benteng

17

Tidak, sebenarnya ini adalah kerentanan. Jika penyerang dapat memperoleh hash dari database, maka ia dapat menggunakannya untuk mengautentikasi tanpa perlu membobolnya. Dalam situasi apa pun pengguna atau penyerang tidak boleh mendapatkan sandi hashes.

Inti dari hashing password adalah untuk menambahkan lapisan keamanan ekstra. Jika penyerang dapat memperoleh hash dan garam dari database menggunakan SQL Injection atau cadangan yang tidak aman, maka ia harus menemukan teks biasa dengan paksa. John The Ripper biasanya digunakan untuk memecahkan hash sandi asin.

Tidak menggunakan https merupakan pelanggaran terhadap OWASP Top 10: A9-Insufficient Transport Layer Protection

EDIT: Jika dalam implementasi Anda, Anda menghitung a sha256(client_salt+plain_text_password)dan kemudian menghitung hash lain di sisi server sha256(server_salt+client_hash)maka ini bukan kerentanan yang serius. Namun, itu masih rentan terhadap penyadapan dan pemutaran ulang permintaan. Dengan demikian ini masih jelas merupakan pelanggaran terhadap WASP A9. Namun, ini masih menggunakan intisari pesan sebagai lapisan keamanan.

Hal terdekat yang saya lihat dengan pengganti sisi klien untuk https adalah diffie-hellman dalam pertukaran kunci dalam javascript . Namun, ini mencegah serangan MITM aktif dan dengan demikian sampai teknis merupakan pelanggaran terhadap OWASP A9. Penulis kode setuju bahwa ini bukan pengganti lengkap untuk HTTPS, namun lebih baik daripada tidak sama sekali dan lebih baik daripada sistem hashing sisi klien.


4
Sebenarnya saya akan melakukan hash lagi di server, jadi harap edit jawaban Anda dengan mempertimbangkan skenario ini.
Jader Dias

@Rook menggunakan pertukaran kunci diffie-hellman bersama dengan https adalah solusi "tidak berguna"? (Maksud saya, kami hanya dapat menggunakan https dan diffie helman tidak meningkatkan keamanan imao)
Michel Gokan

@Michel Kogan pertukaran kunci DH dapat digunakan di HTTPs bersama dengan alat lainnya.
Benteng

1
@Rook Merupakan praktik terbaik untuk menerapkan hash di server, jadi menurut saya Anda harus memperbarui awal jawaban Anda untuk tidak mengabaikan hashing sisi klien, dan hanya kemudian menyebutkan bahwa hash dan garam yang disimpan di server tidak boleh diekspos.
Levente Pánczél

8

Mengirimkan hash melalui kabel benar-benar mengalahkan tujuan hash, karena penyerang dapat dengan mudah mengirim hash dan melupakan kata sandinya. Singkatnya, sistem yang mengotentikasi menggunakan hash dalam teks yang jelas terbuka lebar dan dapat dikompromikan hanya dengan mengendus jaringan.


2
Ini sepertinya omong kosong ... Bagaimana hash kurang aman dari kata sandi?
Levente Pánczél

1
Ini hanya berlaku untuk hash "bodoh". Pertimbangkan ini: Server mengirimkan salt S ke klien dan klien melakukan HASH (S + PASSWORD), dan mengirimkannya ke server. Server menghormati hash spesifik itu hanya untuk sesi saat ini. Penyerang memang dapat mengirim hash dan melupakan kata sandinya, tapi HANYA UNTUK SESI SAAT INI. Oleh karena itu, ini lebih aman daripada teks biasa.
Hello World

Pembaruan: Otentikasi Akses Intisari bahkan lebih canggih: en.wikipedia.org/wiki/Digest_access_authentication
Hello World

2
Hanya untuk memperjelas: ketika saya mengatakan "mengalahkan tujuan hash", saya mengacu pada praktik umum dan aman dari hashing password sebelum menyimpannya dalam database. Namun demikian, argumen tersebut menyatakan bahwa mengirim nilai hash alih-alih kata sandi tidak melakukan apa pun untuk meningkatkan keamanan tanpa langkah tambahan.
Paul Keister

Hanya untuk menambah apa yang Paulus katakan: jenis serangan ini disebut "serangan ulangan" jika ada yang ingin membaca lebih banyak tentang itu di tempat lain.

5

Sandi dalam teks biasa tidak pernah (bahkan saat menggunakan HTTPS) keluar dari klien. Ini harus di-hash secara permanen sebelum meninggalkan klien karena server tidak perlu mengetahui kata sandi yang sebenarnya.

Hashing lalu transmisi memecahkan masalah keamanan untuk pengguna malas yang menggunakan kata sandi yang sama di beberapa lokasi (saya tahu saya melakukannya). Namun ini tidak melindungi aplikasi Anda sebagai peretas yang memperoleh akses ke database (atau dengan cara lain dapat memperoleh hashnya) karena peretas hanya dapat mengirimkan hash dan meminta server menerimanya.

Untuk mengatasi masalah ini, Anda tentu saja bisa melakukan hash yang diterima server dan menyebutnya sehari.

Pendekatan saya untuk masalah ini dalam aplikasi web berbasis soket yang saya buat adalah bahwa pada koneksi ke klien, server menghasilkan garam (string acak untuk ditambahkan sebelum hashing) dan menyimpannya di variabel soket, kemudian mengirimkan hash ini kepada klien. Klien mengambil kata sandi pengguna, melakukan hash, menambahkan garam dari server dan meng-hash semuanya, sebelum mengirimkannya ke server. Kemudian dikirim ke server yang membandingkan hash ini dengan hash (hash dalam garam DB +). Sejauh yang saya tahu ini adalah pendekatan yang baik, tetapi sejujurnya saya belum banyak membaca tentang topik ini dan jika saya salah tentang apa pun, saya ingin dikoreksi :)


3

Gunakan HTTP Digest - ini mengamankan kata sandi bahkan melalui http (tetapi penggunaan terbaik adalah intisari http melalui https)

Wikipedia:

Otentikasi akses intisari HTTP adalah salah satu metode yang disetujui yang dapat digunakan server web untuk menegosiasikan kredensial dengan pengguna web (menggunakan protokol HTTP). Otentikasi intisari dimaksudkan untuk menggantikan penggunaan otentikasi akses Dasar yang tidak terenkripsi, yang memungkinkan identitas pengguna dibuat dengan aman tanpa harus mengirim kata sandi dalam teks biasa melalui jaringan. Otentikasi intisari pada dasarnya adalah aplikasi hashing kriptografi MD5 dengan penggunaan nilai nonce untuk mencegah kriptanalisis.

Tautan: http://en.wikipedia.org/wiki/Digest_access_authentication

Jika Anda ingin melihat penggunaan "kehidupan nyata", Anda dapat melihat phpMyID - penyedia openid php yang menggunakan http digest authentication http://siege.org/phpmyid.php

.. atau Anda dapat memulai dari contoh auth php di http://php.net/manual/en/features.http-auth.php

Ringkasan http rfc: http://www.faqs.org/rfcs/rfc2617

Dari pengujian saya, semua browser modern mendukungnya ...


HTTP Digest mengimplementasikan apa yang saya maksud dalam pertanyaan ini, tetapi apakah kita akan mendapat keuntungan jika menggunakan HTTPS Digest (SSL + HTTP Digest)?
Jader Dias

Satu perbedaan utama adalah bahwa semuanya dikirim / diterima dienkripsi - header http dikirim dan diterima dan balasan html. Bagi seseorang yang secara acak mencoba "meretas" ssl menggunakan man-in-the-middle-attack, intisari http akan menjadi motif tambahan untuk membuatnya mencari target lain yang lebih mudah, atau jika dia mencatat semua lalu lintas yang ditangkap, kata sandi Anda masih lebih aman. Saya mungkin salah paham dengan pertanyaannya, bahasa Inggris bukanlah bahasa pertama saya.
vlad b.

Hash over password memiliki satu keuntungan besar: jika lalu lintas dicatat atau ditangkap entah bagaimana itu akan membuat pekerjaan lebih sulit bagi orang itu. Selain itu, dengan intisari http, jika ssl tidak selalu diperlukan, Anda dapat membiarkan pengguna memilih antara http dan https. Atau Anda dapat menggunakan protokol yang berbeda untuk server yang berbeda (misalnya saya tidak menerapkan https untuk melihat / mengubah lebih sedikit data impor dan (nama pengguna, pengunggahan avatar) tetapi menerapkan https pada penagihan dan bagian lain dari situs (dengan cara itu saya dapat mengurangi beban pada beberapa server, jika / bila diperlukan).
vlad b.

3

Jika Anda ingin mengganti kata sandi teks biasa melalui HTTPS dengan kata sandi hash melalui HTTP, maka Anda sedang mencari masalah. HTTPS menghasilkan kunci transaksi bersama secara acak saat membuka saluran komunikasi. Itu sulit untuk dipecahkan, karena Anda cukup terbatas pada memaksa kunci bersama yang digunakan untuk transaksi jangka pendek (relatif). Sedangkan hash Anda bisa saja diendus, diambil off-line dan dicari di meja pelangi atau hanya dipaksakan secara kasar dalam waktu yang lama.

Namun, kebingungan sandi sisi klien dasar (bukan hash) yang dikirim melalui HTTPS memang memiliki beberapa nilai. Kalau tidak salah teknik ini sebenarnya digunakan oleh beberapa bank. Tujuan dari teknik ini bukan untuk melindungi kata sandi agar tidak mengendus melalui kabel. Sebaliknya, ini untuk menghentikan kata sandi agar tidak dapat digunakan untuk alat mata-mata bodoh dan plugin browser yang hanya mengambil setiap permintaan GET / POST HTTPS yang mereka lihat. Saya telah melihat file log yang diambil dari situs web jahat yang 400MB transaksi GET / POST acak diambil dari sesi pengguna. Anda dapat membayangkan bahwa situs web yang hanya menggunakan HTTPS akan muncul dengan kata sandi teks biasa di log, tetapi situs web dengan kebingungan yang sangat mendasar (ROT13) juga akan muncul dengan kata sandi yang tidak segera digunakan.


"tetapi situs web dengan kebingungan yang sangat mendasar (ROT13) juga akan muncul dengan sandi yang tidak segera digunakan" - ini bertentangan dengan pernyataan asli. Kuncinya adalah bahwa mereka tidak SEGERA digunakan, tetapi itu benar-benar sia-sia. Kata sandi dan ROT13-nya setara. TETAPI jika Anda SHA2 kata sandinya, kata sandinya tidak akan ada di log (jadi admin Anda tidak mengetahui kemungkinan kata sandi pengguna untuk sistem lain), dan Anda TIDAK LAGI melanggar hampir setiap Undang-Undang privasi.
Levente Pánczél

2

Jika Anda terhubung ke server https, aliran data antara server dan browser harus dienkripsi. Data tersebut hanya berupa teks biasa sebelum dikirim dan setelah diterima. Artikel Wikipedia


Jangan proxy mencegat data ini?
Jader Dias

Seperti yang saya pahami, mereka melakukannya, tetapi proxy tidak bertanggung jawab atas enkripsi / dekripsi dan kecuali itu adalah proxy yang tidak bermoral hanya meneruskan data. Jenis dan kekuatan enkripsi bergantung pada apa yang dapat didukung oleh server dan klien.
jac

1
Meskipun proxy tidak bertanggung jawab, ia tidak dapat mendekripsi data karena dienkripsi menggunakan kunci publik server. Satu-satunya cara proxy dapat mendekripsi data adalah dengan memalsukan sertifikat server dengan kunci yang berbeda
Kiersten Arnold

@Jamur_kejang Jika mereka melakukannya, itu akan membuat HTTPS sangat timpang. saat Anda mengautentikasi ke server dengan HTTPS, Anda mendapatkan jaminan (dengan asumsi sertifikat tersebut valid) bahwa Anda tersambung ke server tertentu, dan memiliki jalur terenkripsi dari satu ujung ke ujung lainnya. Secara hipotetis, serangan man in the middle dapat dilakukan untuk menipu Anda tentu saja, tetapi itu tidak sama dengan proxy web dasar.
Peter Recore

2

Penafian: Saya sama sekali bukan pakar keamanan - dan saya memposting dengan harapan orang lain akan mengkritik posisi saya karena terlalu berhati-hati atau tidak dapat diperbaiki dan saya akan belajar darinya. Karena itu, saya hanya ingin menekankan bahwa hashing ketika meninggalkan klien Anda tidak berarti Anda tidak perlu melakukan hash di backend sebelum memasukkannya ke dalam database.

Lakukan keduanya

Lakukan keduanya karena:

  1. Hashing dalam perjalanan membantu menutupi kerentanan transportasi, jika koneksi SSL terganggu, mereka masih tidak dapat melihat kata sandi mentah. Tidak masalah dalam hal dapat meniru pengguna resmi, tetapi itu akan melindungi pengguna Anda agar sandi mereka dibaca dalam kaitan dengan email mereka. Kebanyakan orang tidak mengikuti praktik terbaik dan menggunakan kata sandi yang sama untuk banyak akun mereka, jadi ini bisa menjadi kerentanan serius bagi pengunjung Anda.

  2. Jika seseorang, entah bagaimana, dapat membaca kata sandi dari database (ini memang terjadi, pikirkan injeksi SQL), mereka masih tidak akan dapat menjalankan tindakan istimewa yang meniru pengguna melalui API saya. Ini karena asimetri hash; bahkan jika mereka tahu hash yang disimpan di DB Anda, mereka tidak akan tahu kunci asli yang digunakan untuk membuatnya dan itulah yang digunakan middleware auth Anda untuk mengautentikasi. Ini juga mengapa Anda harus selalu menggarami penyimpanan hash Anda.

Memang, mereka dapat melakukan banyak kerusakan lain jika mereka memiliki kebebasan untuk membaca apa yang mereka inginkan dari database Anda.

Saya hanya ingin menekankan di sini bahwa jika Anda memutuskan untuk melakukan hash kunci sebelum keluar dari klien, itu tidak cukup-- hashing backend, im, jauh lebih penting dan inilah alasannya: Jika seseorang mencegat lalu lintas dari Anda klien, lalu mereka akan melihat konten passwordbidang. Baik ini hash, atau teks biasa, tidak masalah - mereka dapat menyalinnya secara verbatim untuk meniru klien resmi. (Kecuali Anda mengikuti langkah-langkah yang diuraikan @ user3299591, dan saya sarankan Anda melakukannya). Hashing kolom DB, di sisi lain, adalah sebuah kebutuhan dan sama sekali tidak sulit untuk diterapkan.



0

Sebenarnya akan kurang aman untuk melakukan hash kata sandi dan mengirimkannya melalui saluran yang tidak dienkripsi. Anda akan mengekspos algoritma hashing Anda pada klien. Peretas bisa saja mengendus hash kata sandi dan kemudian menggunakannya untuk meretas nanti.

Dengan menggunakan HTTPS, Anda mencegah peretas mendapatkan sandi dari satu sumber, karena HTTPS menggunakan dua saluran, keduanya dienkripsi.


1
Sebenarnya saya akan melakukan hash lagi di server, dan saya akan tetap menggunakan HTTPS, jadi harap edit jawaban Anda dengan mempertimbangkan skenario ini.
Jader Dias

@Jader, intinya adalah, semua yang dibutuhkan penyerang sekarang adalah hash pertama, bukan kata sandi. Akibatnya, hash yang Anda ambil dari kata sandi di sisi klien sekarang sama bermanfaatnya dengan kata sandi itu sendiri. Jadi Anda tidak benar-benar mendapatkan banyak keamanan.
Peter Recore

apakah ada yang pernah berpikir untuk tidak mengirimkan bagian dari token? seperti jika Anda tahu metode hashing, mengapa Anda mengirimkannya. bukankah server harus mengetahui kunci klien untuk mendekripsi?
jemiloii

0

Apakah ada keuntungan, dan apakah itu lebih (atau kurang) aman sangat bergantung pada penerapan. Bisa dibilang ada beberapa keuntungan, tetapi jika Anda menerapkannya dengan buruk, Anda pasti dapat membuat solusi yang kurang aman daripada memasukkan bahkan sandi teks biasa.

Ini dapat dilihat dari perspektif dua jenis serangan - satu dengan akses ke lalu lintas jaringan, dan lainnya dengan akses ke database.

Jika penyerang Anda dapat mencegat versi teks biasa dari lalu lintas jaringan, melihat hash kata sandi lebih aman daripada melihat kata sandi dalam teks biasa. Meskipun penyerang masih bisa masuk ke server Anda menggunakan hash itu, itu akan membutuhkan crack brute-force (terkadang sudah dihitung sebelumnya) dari hash itu untuk menentukan kata sandi yang mungkin berguna di sistem lain. Orang-orang harus menggunakan kata sandi yang berbeda pada sistem yang berbeda, tetapi seringkali tidak.

Jika penyerang memperoleh akses ke database, mungkin melalui salinan cadangan, maka Anda ingin memastikan bahwa seseorang tidak dapat masuk hanya dengan pengetahuan itu. Jika, misalnya, Anda menyimpan hash yang diasinkan dengan nama login sebagai hash(login_name+password), dan Anda meneruskan hash yang sama dari klien untuk perbandingan langsung, maka penyerang dapat memilih pengguna secara acak, mengirim hash yang telah dibaca dari database dan masuk sebagai pengguna tersebut tanpa mengetahui sandinya, meningkatkan cakupan pelanggaran. Dalam hal ini, mengirim kata sandi dalam teks biasa akan lebih aman karena penyerang perlu mengetahui teks biasa untuk masuk, bahkan memiliki salinan database. Di sinilah penerapan adalah kuncinya. Baik Anda mengirim sandi teks biasa atau hash sisi klien dari sandi tersebut, Anda harus mencirikan nilai tersebut di sisi server dan membandingkan hash tersebut dengan hash yang disimpan dalam catatan pengguna.

Konsep yang perlu diperhatikan:

  • Anda "mengasinkan" hash dengan mencampurkan beberapa nilai unik cakupan ke hash Anda, biasanya unik baris. Tujuannya adalah untuk menjamin keunikan hash dari satu sama lain meskipun nilai teks biasa yang mereka wakili adalah sama, jadi dua pengguna dengan sandi yang sama masih akan memiliki hash yang berbeda. Tidak perlu memperlakukan garam sebagai rahasia.
  • Saat mengautentikasi, selalu lakukan hash di sisi server, apa pun nilai yang Anda berikan dari klien sebagai kata sandi (meskipun sudah di-hash) dan bandingkan dengan nilai yang telah di-hash sebelumnya yang disimpan di database. Ini mungkin memerlukan penyimpanan versi double-hash dari kata sandi asli.
  • Saat Anda membuat hash, pertimbangkan untuk menambahkan salt server / cluster-unique ke hash serta salt unik baris untuk menjaga agar tidak mencocokkan hash yang telah dihitung sebelumnya dalam tabel pencarian.
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.