Pertama-tama, ini TIDAK meningkatkan keamanan aplikasi Anda (dengan asumsi itu adalah aplikasi web).
Gunakan SSL (Atau sebenarnya TLS, yang biasa disebut SSL), ini tidak terlalu mahal (Ukur waktu yang Anda gunakan untuk menemukan cara di sekitarnya dan gandakan dengan upah minimum, membeli sertifikat menang hampir selalu).
Mengapa ini sederhana? TLS memecahkan masalah (ketika digunakan dengan sertifikat yang dibeli, tidak ditandatangani sendiri) yang cukup besar dalam kriptografi: Bagaimana saya tahu server yang saya ajak bicara adalah server yang saya pikir saya ajak bicara? Sertifikat TLS adalah cara untuk mengatakan: "Saya, otoritas sertifikat, dipercaya oleh browser Anda, menyatakan bahwa situs web di [url] memiliki kunci publik ini, dengan kunci pribadi yang sesuai, yang (kunci pribadi) yang hanya diketahui oleh server, lihat Saya menandatangani tanda tangan saya di seluruh dokumen, jika ada yang mengubahnya, Anda dapat melihat ".
Tanpa TLS, enkripsi apa pun menjadi tidak ada gunanya, karena jika saya duduk di sebelah Anda dalam sebuah coffeeshop, saya dapat membuat laptop / smartphone Anda berpikir saya adalah server dan MiTM (Man in The Middle) Anda. Dengan TLS, laptop / smartphone Anda akan meneriakkan "SAMBUNGAN TIDAK TERPERCAYA", karena saya tidak memiliki otoritas sertifikat yang menandatangani sertifikat yang cocok dengan situs Anda. (Enkripsi vs. Otentikasi).
Penafian: pengguna cenderung mengklik kanan melalui peringatan ini: "Koneksi tidak tepercaya? Apa? Saya hanya ingin gambar anak kucing saya! Tambahkan Pengecualian Klik Konfirmasi Klik YAY! Anak kucing!"
Namun, jika Anda benar-benar tidak ingin membeli sertifikat, masih DO mengimplementasikan hash javascript sisi klien (dan menggunakan perpustakaan standford (SJCL) untuk itu, JANGAN PERNAH MELAKUKAN CRYPTO DIRI SENDIRI ).
Mengapa? Penggunaan kembali kata sandi! Saya dapat mencuri cookie sesi Anda (yang memungkinkan saya untuk berpura-pura ke server Anda bahwa saya adalah Anda) tanpa HTTPS dengan mudah (lihat firesheep). Namun jika Anda menambahkan javascript ke halaman login Anda yang, sebelum mengirim, hash kata sandi Anda (gunakan SHA256, atau bahkan lebih baik, gunakan SHA256, kirim mereka kunci publik yang Anda buat dan kemudian enkripsi hash password dengan itu, Anda tidak dapat menggunakan garam dengan ini), dan kemudian mengirimkan kata sandi hash / terenkripsi ke server. REHASH hash di server Anda dengan garam dan bandingkan dengan apa yang disimpan dalam database Anda (simpan kata sandi seperti ini:
(SHA256(SHA256(password)+salt))
(simpan garam sebagai plaintext dalam database juga)). Dan kirim kata sandi Anda seperti ini:
RSA_With_Public_Key(SHA256(password))
dan periksa kata sandi Anda seperti ini:
if SHA256(RSA_With_Private_Key(SHA256(sent_password))+salt_for_username) == stored_pass: login = ok
Karena, JIKA seseorang mengendus klien Anda, mereka akan dapat masuk sebagai klien Anda (pembajakan sesi) tetapi mereka TIDAK AKAN PERNAH melihat kata sandi plaintext (kecuali jika mereka mengubah javascript Anda, namun, peretas starbucks mungkin tidak akan tahu caranya / tertarik) dalam hal ini.) Jadi mereka akan mendapatkan akses ke aplikasi web Anda, tetapi tidak ke email / facebook / etc mereka. (di mana pengguna Anda kemungkinan akan menggunakan kata sandi yang sama). (Alamat email akan menjadi nama login mereka atau akan ditemukan di profil / pengaturan mereka di aplikasi web Anda).