Kata sandi teks biasa melalui HTTPS

93

Saat ini saya sedang mengerjakan penyedia PHP OpenID yang akan bekerja melalui HTTPS (karenanya dienkripsi SSL).
Apakah salah jika saya mengirimkan kata sandi sebagai teks biasa? HTTPS secara teori, tidak dapat dicegat, jadi saya tidak melihat ada yang salah. Atau apakah ini tidak aman pada tingkat tertentu dan saya gagal untuk melihatnya?

https password-protection

— WhyNotHugo
sumber

129

Itu aman. Begitulah cara kerja seluruh web. Semua sandi dalam formulir selalu dikirim dalam teks biasa, jadi terserah HTTPS untuk mengamankannya.

— Eduardo Scoz
sumber

20

Minor nitpick: beberapa formulir login menggunakan JavaScript untuk mencirikan kata sandi alih-alih mengirimkannya teks biasa.

— Thorarin

5

@Thorarin jika mereka benar-benar melakukan hash, itu berarti server menyimpan kata sandi dalam teks biasa sehingga dapat melakukan hash dengan garam yang sama untuk memverifikasi. Ih! Lebih baik mengirim kata sandi dalam bentuk teks ssl yang dibungkus, karena server tidak perlu menyimpan kata sandi dalam teks biasa.

— DGM

11

@DGM: hashing ganda juga merupakan opsi, jadi kata sandi teks biasa tidak terlalu diperlukan.

— Thorarin

3

@Denis: hashing sisi klien tidak banyak membantu. Ini mungkin membuat segalanya lebih sulit daripada teks biasa, tetapi seseorang yang benar-benar ingin mencuri kata sandi dapat melakukannya tanpa masalah. Hanya akan bekerja dengan aman jika Anda mengirim setidaknya satu kali token melalui saluran aman (ssl), dalam hal ini Anda mungkin juga mengirim kata sandi dalam SSL untuk memulai.

— Eduardo Scoz

4

Saya hanya mengatakan bahwa Yahoo merasa bahwa hashing sisi klien cukup aman sampai mereka mampu untuk pindah sepenuhnya ke ssl. Tapi hei, saya semua untuk https :)

— Denis

74

Anda masih perlu memastikan bahwa Anda mengirimkannya melalui permintaan POST, bukan GET. Jika Anda mengirimkannya melalui permintaan GET, ini bisa disimpan dalam teks biasa di log riwayat browser pengguna atau log akses server web.

— tak seorangpun
sumber

7

Ya, saya tahu itu, tapi masih merupakan komentar yang bagus untuk ditinggalkan bagi orang lain yang datang mencari di sini. :)

— WhyNotHugo

atau kirimkan di header

— james

22

Jika HTTP dinonaktifkan, dan Anda hanya menggunakan HTTPS, Anda tidak benar-benar mentransmisikan kata sandi sebagai teks biasa.

— Can Berk Güder
sumber

4

Namun server memang memiliki akses ke sandi teks biasa Anda, mereka dapat menyimpannya sebagai teks biasa, salah memasukkannya sebagai teks biasa, dll. Artinya, sandi Anda tidak berada di sisi klien, server juga melihat dengan tepat apa itu.

— xref

14

Sisi klien hash. Mengapa? Izinkan saya memberi tahu Anda tentang eksperimen kecil. Berjalan ke komputer di kafetaria perusahaan. Buka browser ke halaman login situs web perusahaan (https). Tekan F12, klik tab jaringan, centang log tetap, minimalkan konsol tetapi biarkan halaman web terbuka untuk halaman login. Duduk dan makan siang. Perhatikan sebagai karyawan setelah karyawan log on ke situs web perusahaan dan menjadi pekerja kecil yang baik logout setelah selesai. Selesai makan siang, duduklah di depan komputer, buka tab jaringan dan lihat setiap nama pengguna dan kata sandi dalam teks biasa dalam bentuk bodys.

Tidak ada alat khusus, tidak ada pengetahuan khusus, tidak ada perangkat keras peretasan yang mewah, tidak ada keylogger, hanya F12 lama yang bagus.

Tapi, hei, teruslah berpikir yang Anda butuhkan hanyalah SSL. Orang jahat akan mencintaimu karenanya.

— CodeDog
sumber

6

Komentar kafetaria Anda tidak masuk akal, tidak peduli seberapa banyak saya membacanya kembali. Mengapa orang-orang berjalan ke komputer dan mengetik kredensial mereka? apa yang kamu mau buktikan? Selain itu, hashing tidak akan membuat ini lebih tidak aman, dengan cara apa pun. Merupakan hal yang umum untuk mencirikan kata sandi dan mengirimkannya melalui HTTP teks biasa ketika pertanyaan ini ditulis, pada tahun 2009.

— WhyNotHugo

4

Aku upvoted kedua ini karena, ya, jawaban yang diterima adalah sedang dibaca bertahun-tahun kemudian. Sebaiknya @CodeDog menunjukkan beberapa strategi mitigasi. Dan ya, orang hanya akan berjalan ke PC acak, misalnya, di perpustakaan lokal, dan memasukkan detailnya!

— JoeAC

3

Saya mengenkripsi sisi klien kata sandi dengan kunci publik, kemudian memposting hanya kata sandi terenkripsi dalam formulir. Ini adalah kunci asimetris sehingga memiliki kunci publik sisi klien tidak berguna bagi penyerang. Setiap log itu menghasilkan pasangan kunci baru sehingga serangan replay juga tidak akan berfungsi. Kuncinya bahkan berubah pada upaya login yang gagal. Pasangan kunci dibuat di sisi server ketika pengguna tiba di layar masuk. Hanya kunci publik yang disediakan untuk kode sisi klien.

— CodeDog

BTW Saya telah melihat peretasan ini digunakan di pusat bisnis hotel oleh staf untuk mengumpulkan kode sandi untuk nomor kamar. Mereka akan menggunakan kode akses untuk mendapatkan nirkabel dan menggunakan PC pusat bisnis dan akan ditagihkan ke kamar.

— CodeDog

Saya melakukan percobaan seperti itu sendiri dengan masuk ke rekening bank saya dan harus setuju dengan @CodeDog - Minta payload termasuk login dan kata sandi saya, keduanya teks biasa.

— Artur Michajluk

6

Mari kita buat beberapa catatan untuk jawaban sebelumnya.

Pertama, itu mungkin bukan ide terbaik untuk menggunakan sisi klien algoritma hash. Jika kata sandi Anda diasinkan di sisi server, Anda tidak akan dapat membandingkan hash (setidaknya tidak jika Anda tidak menyimpan hash klien dalam database di salah satu lapisan hashing dari kata sandi, yang sama atau lebih buruk). Dan Anda tidak ingin mengimplementasikan algoritma hashing yang digunakan oleh database di sisi klien, itu akan konyol.

Kedua, menukar kunci kriptografi juga tidak ideal. MITM secara teoritis (mengingat dia memiliki sertifikat root yang diinstal pada klien) mengubah kunci kriptografi, dan mengubah dengan kuncinya sendiri:

Koneksi asli (tidak mempertimbangkan tls) dari server teoritis yang bertukar kunci:

Klien meminta kunci publik> server memegang kunci privat, menghasilkan kunci publik ke klien> server mengirimkan kunci publik ke klien

Sekarang, di jalur MITM teoretis:

Klien meminta kunci publik> MITM menghasilkan kunci privat palsu > Server menyimpan kunci privat, menghasilkan kunci publik ke klien> MITM menerima kunci publik dari server asli, sekarang, kami bebas untuk mengirim kunci publik palsu kami ke klien, dan setiap kali permintaan datang dari klien, kami akan mendekripsi data klien dengan kunci palsu, mengubah muatan (atau membacanya) dan mengenkripsi dengan kunci publik asli > MITM mengirimkan kunci publik palsu ke klien.

Itulah tujuan memiliki sertifikat CA tepercaya di TLS, dan begitulah cara Anda menerima pesan dari peringatan browser jika sertifikat tersebut tidak valid.

Menanggapi OP: menurut pendapat saya Anda tidak dapat melakukan itu, karena cepat atau lambat, seseorang akan ingin menyerang pengguna dari layanan Anda dan akan mencoba untuk melanggar protokol Anda.

Apa yang dapat Anda lakukan, bagaimanapun, adalah menerapkan 2FA untuk mencegah orang mencoba masuk dengan kata sandi yang sama. Waspadai serangan replay.

Saya tidak ahli dalam kriptografi, mohon koreksi jika saya salah.

— Lucca Ferri
sumber

Ingatlah bahwa diskusi ini dari tahun 2009. Hampir semua itu adalah praktik terbaik pada saat itu.

— WhyNotHugo

3

@WhyNotHugo Saya sadar. Saya memutuskan untuk meninggalkan jawaban karena jawaban google teratas untuk pertanyaan ini membawa saya ke sini, jadi mengapa tidak.

— Lucca Ferri

4

Poster lainnya benar. Sekarang bahwa Anda menggunakan SSL untuk mengenkripsi transmisi dari password, pastikan Anda sedang hashing dengan algoritma yang baik dan garam sehingga itu dilindungi ketika itu saat istirahat , juga ...

— grossvogel.dll
sumber

Ya, saya menyadari ini, terima kasih, saya hanya mengacu pada transmisi di sini.

— WhyNotHugo

0

Contoh @CodeDog memiliki masalah ..

Ya, saya yakin pengguna akan masuk ke kotak caffeteria. Jika Anda menangkap log dari caffeteria perusahaan, maka Anda adalah pelanggaran keamanan. Kotak caffeterias perusahaan harus dinonaktifkan, misalnya tanpa syarat, tidak ada pencatat, tidak ada akses jarak jauh, dll. Untuk mencegah Anda, peretas dalam.

Contohnya adalah keamanan akses komputer yang baik, dan tidak terlalu terkait dengan keamanan jaringan. Ini disediakan sebagai pembenaran untuk hashing sisi klien, tetapi jika Anda memiliki akses komputer, Anda bisa menggunakan pencatat penekanan tombol dan melewati itu. Hash sisi klien sekali lagi tidak relevan. Contoh oleh @CodeDog adalah peretasan akses komputer dan membutuhkan teknik yang berbeda dari peretasan lapisan jaringan.

Selain itu, peretasan komputer publik dilindungi dengan melumpuhkan sistem dari ancaman, seperti yang disebutkan di atas. misalnya menggunakan chromebook untuk komputer kafetaria publik. Tapi itu dilewati oleh peretasan fisik . Di luar jam kerja, pergi ke kafetaria dan siapkan kamera rahasia untuk merekam penekanan keyboard oleh pengguna. Maka tidak masalah jika komputer caffeteria lumpuh, ATAU jenis enkripsi apa yang digunakan.

lapisan fisik -> lapisan komputer -> lapisan klien -> lapisan jaringan -> lapisan server

Untuk jaringan, tidak masalah jika Anda hash di sisi klien karena lapisan https / ssl akan mengenkripsi passwd biasa. Jadi seperti yang disebutkan orang lain, hashing klien berlebihan jika TLS aman.

— ramakarl
sumber

1

Meskipun Anda membuat poin bagus, Anda membalas sebuah jawaban (yang sebenarnya tidak relevan dengan pertanyaan yang diajukan) jadi tidak terlalu sesuai untuk model T&J Stackoverflow.

— Martin