it-swarm-id.com

Adakah yang bisa memberikan referensi untuk menerapkan mekanisme pengaturan ulang kata sandi aplikasi web dengan benar?

Kami menerapkan setel ulang kata sandi mandiri pada aplikasi web, dan saya tahu bagaimana saya ingin melakukannya (waktu penyetelan ulang URL kata sandi terbatas email ke alamat email pra-terdaftar pengguna).

Masalah saya adalah bahwa saya tidak dapat menemukan referensi untuk mengarahkan pengembang di sekitar menggunakan teknik itu. Adakah yang bisa mengarahkan saya ke arah beberapa referensi yang baik tentang teknik ini?

96
bdg

Beberapa saran:

Jangan mengatur ulang kata sandi pengguna hingga dikonfirmasi. Jangan segera mengatur ulang kata sandi pengguna. Setel ulang hanya setelah pengguna mengklik tautan konfirmasi yang dikirim ke alamat email pra-terdaftar mereka.

Memerlukan CAPTCHA. Ketika pengguna meminta kata sandi mereka diatur ulang, paksa mereka untuk menyelesaikan CAPTCHA sebelum melanjutkan lebih jauh. Ini untuk mencegah alat otomatis dari mencoba memberikan kesedihan banyak pengguna, dan memaksa pengguna untuk membuktikan bahwa mereka adalah manusia (bukan robot).

Keacakan. URL penyetelan ulang sandi yang dibatasi waktu harus menyertakan komponen acak yang tidak dapat diakses. Pastikan Anda menggunakan keacakan kualitas kripto. Output dari /dev/urandom Atau System.Security.Cryptography.RNGCryptoServiceProvider Akan menjadi pilihan yang baik. Output dari Rand() atau random() atau System.Random Tidak cukup acak dan akan menjadi pilihan yang buruk. A GUID atau cap waktu tidak cukup acak dan tidak akan menjadi pilihan yang baik.

Sertakan batas waktu. Tautan konfirmasi reset harus berakhir setelah beberapa waktu yang masuk akal: katakanlah, 24 jam. Tautan hanya dapat digunakan sekali, dan harus segera kedaluwarsa begitu digunakan.

Sertakan teks penjelas dalam surel. Anda mungkin ingin menambahkan beberapa teks penjelas ke surel, untuk menjelaskan mengapa surel dikirim, jika seseorang meminta reset untuk akun yang bukan milik Anda. Anda dapat memasukkan beberapa teks seperti "Seseorang telah meminta agar kata sandi diatur ulang untuk akun Anda username pada site. Jika Anda membuat permintaan ini, klik di sini untuk mengubah kata sandi Anda. Jika Anda tidak membuat permintaan ini, klik di sini untuk membatalkan permintaan. "

Kirim email setelah kata sandi diatur ulang. Setelah kata sandi berhasil disetel ulang, kirim email ke pengguna untuk memberi tahu mereka bahwa kata sandi telah diubah. Jangan sertakan kata sandi baru dalam email itu.

Monitor pembatalan. Anda dapat mempertimbangkan untuk memasukkan beberapa logika untuk memonitor frekuensi pengguna mengklik tautan pembatalan yang menunjukkan bahwa mereka tidak meminta reset. Jika ini melampaui batas tertentu, mungkin berguna untuk mengirim peringatan ke operator sistem. Juga, jika tautan pembatalan untuk beberapa permintaan dikunjungi setelah tautan konfirmasi dikunjungi, itu indikasi potensial serangan terhadap pengguna itu - Anda mungkin ingin mengambil tindakan pada titik itu, misalnya , membatalkan kata sandi pengguna dan meminta mereka untuk mengatur ulang kata sandi mereka lagi. (Ini adalah pertahanan terhadap serangan berikut: penyerang mendapatkan akses ke kotak surat pengguna, lalu meminta agar kata sandi mereka di situs Anda disetel ulang, lalu mengunjungi tautan konfirmasi. Jika penyerang tidak menghapus email ini dari kotak masuk pengguna, kemudian ketika pengguna sebenarnya membaca email mereka, mereka dapat mengklik tautan pembatalan, memberi Anda indikasi kemungkinan masalah.)

Gunakan HTTPS. Tautan harus menggunakan https (bukan http :), untuk melindungi terhadap berbagai serangan (mis., Serangan Firesheep pada pengguna yang menjelajahi web dari Internet) kafe).

Catat operasi ini. Saya sarankan mencatat semua permintaan tersebut. Selain mencatat nama pengguna pengguna, Anda mungkin ingin mencatat alamat IP klien yang meminta tautan reset dikirim ke email kepada pengguna, serta alamat IP klien yang mengunjungi tautan reset.

Bacaan tambahan. Anda mungkin juga ingin membaca posting blog yang sangat baik dari Troy Hunt, Segala sesuatu yang Anda ingin tahu tentang membangun fitur reset kata sandi yang aman . Terima kasih kepada @coryT untuk tautan ke sumber ini.

Terakhir, pertimbangkan otentikasi non-kata sandi. Kata sandi memiliki banyak masalah sebagai mekanisme otentikasi, dan Anda dapat mempertimbangkan metode lain untuk mengautentikasi pengguna, seperti menyimpan yang aman cookie terus-menerus pada mesin mereka dengan rahasia yang tidak dapat diungkap untuk mengautentikasi mereka. Dengan cara ini, tidak ada kata sandi untuk dilupakan dan tidak ada cara bagi pengguna untuk dihapus, meskipun Anda perlu memberikan cara bagi pengguna untuk mengotorisasi akses dari mesin baru atau browser baru (mungkin melalui email ke pra-pengguna pengguna) alamat email terdaftar). Makalah survei ini memiliki survei yang sangat baik tentang banyak metode otentikasi fallback dan kekuatan dan kelemahannya.

93
D.W.

Troy Hunt memiliki artikel yang sangat bagus tentang pertanyaan ini. Segala sesuatu yang Anda ingin tahu tentang membangun fitur reset kata sandi yang aman

15
coryT

Setiap tempat yang dapat mengirimkan kata sandi kepada Anda berarti mereka tidak memiliki kata sandi, tetapi simpan di tempat yang entah bagaimana dapat didekripsi menjadi 'plaintext'. Ini dengan sendirinya buruk.

Mungkin bukan "sebagian besar" aman, tetapi lebih aman adalah:

Atas permintaan kata sandi, kirim tautan setel ulang kata sandi ke pengguna dengan GUID tertanam. Sesi di GUID berakhir pada, hmm, jam atau lebih.

9
Rich Homolka

OK, jadi pertanyaan Anda adalah, bagaimana seharusnya Anda menyusun kata sandi/proses pemulihan akun? Itu akan tergantung pada apa yang ingin Anda optimalkan: pengalaman pengguna tanpa gangguan atau keamanan yang baik.

Jika Anda menginginkan keamanan yang baik:

  • Saat mendaftar, pengguna harus memasukkan alamat emailnya.
  • Saat mendaftar, pengguna harus memasukkan saluran sekunder untuk autentikasi - nomor ponsel atau pertanyaan & jawaban tantangan (mis. " apa nama gadis ibu Anda " atau lebih baik).

  • Selama pemulihan, sistem Anda pertama-tama mendapatkan verifikasi identitas secara kasar melalui saluran sekunder di atas - pertanyaan tantangan, atau dengan mengirimkan kode ke ponsel, atau sejenisnya.

  • Ketika pemeriksaan identitas pertama di atas dihapus, sistem mengirimkan email atur ulang kata sandi hanya ke alamat email yang dimasukkan sebelumnya. Ini merupakan tindakan tambahan dan penting untuk mencegah f.x. eksploitasi tipe Sarah Palin .

  • Email tidak boleh berisi kata sandi baru atau serupa. Seharusnya memiliki tautan yang dapat diklik ke laman web terenkripsi HTTPS di situs Anda yang a) ditautkan ke akun melalui nilai rahasia yang tidak dapat ditebak yang disediakan dalam URL, b ) terbatas waktu, jadi pemulihan akun hanya berfungsi selama x jam setelah diminta, c) menyediakan cara bagi pengguna akhir untuk membuat baru kata sandi.

  • Memiliki pencatatan yang baik pada semua transaksi pengaturan ulang akun, dan memiliki manusia yang benar-benar memonitor ini dan bertindak jika mereka tampak mencurigakan (lihat log server untuk alamat IP fx, apakah banyak permintaan berasal dari alamat IP yang sama, apakah ada contoh pengguna mencoba mengatur ulang kata sandi dari negara yang berbeda dengan pemilik akun terdaftar, dll.).

Anda juga dapat menghindari kompleksitas ini sama sekali: Ini masih dini, tetapi OAuth/OpenID/masuk melalui Facebook, Google dll menghapus kompleksitas ini sepenuhnya dari sistem Anda, tetapi dengan mungkin kegunaan kurang mapan .

9
Jesper M

Cara paling aman untuk melakukan pengaturan ulang kata sandi adalah dengan menghasilkan token pengaturan ulang satu kali acak unik yang besar, dengan tanggal kedaluwarsa, terkait dengan ID pengguna. Token harus di hash dalam database, karena penyerang dengan akses SQL dapat menggunakannya untuk mengatur ulang kata sandi pengguna yang sewenang-wenang.

Tautan reset harus dikirim ke alamat email, yang berisi token reset. Ketika pengguna mengklik tautan, hash token harus ditemukan di database, dan tanggal kedaluwarsa diverifikasi di masa depan. Jika kondisi ini dipenuhi, pengguna harus diberi layar yang memungkinkan mereka mengetikkan kata sandi baru.

Seluruh proses ini harus dilakukan melalui SSL, jika tidak seorang penyerang dapat mengendus URL dan mereset kata sandi sebelum pengguna melakukannya.

Beberapa tips lainnya:

  1. Rahasia mempertanyakan gangguan kecil pada penyerang dan gangguan besar bagi pengguna. Hindari mereka sepenuhnya.
  2. Hadir pengguna dengan tantangan verifikasi manusia (mis., CAPTCHA) sebelum mengirim setel ulang kata sandi. Ini mencegah permintaan reset otomatis.
  3. Periksa apakah alamat IP yang melakukan reset adalah salah satu yang telah berhasil masuk ke akun sebelumnya. Jika tidak, tanyakan detail lebih lanjut tentang akun/pengguna, mis. tahun pembuatan akun, tanggal lahir, baris pertama alamat.
  4. Tambahkan tautan "Saya tidak meminta email ini", sehingga pengguna dapat melaporkan permintaan pengaturan ulang kata yang salah.
6
Polynomial

Satu lagi yang mungkin atau mungkin tidak sesuai untuk aplikasi Anda, tetapi digunakan dalam aplikasi perbankan online dan sejenisnya adalah mengirim setengah kode reset dengan SMS pesan ke ponsel terdaftar). Dari sudut pandang penyerang, ini adalah PITA yang lengkap karena membutuhkan kompromi dari beberapa saluran agar bisa putus.

6
Rory Alsop

Otentikasi 2 faktor melalui SMS! 1 Anda mengenal pelanggan dan nomor ponsel mereka, SMS mereka kode unik untuk ditambahkan ke situs web untuk memvalidasinya adalah mereka: )

0
frank

Buatlah beberapa langkah prosedur. Misalnya sesuatu seperti ini:

  1. Pengguna lupa kata sandinya. Dia mengklik "Saya lupa kata sandi saya, mengirim saya email apa yang harus dilakukan selanjutnya" (label tombol mungkin berbeda;))
  2. Server Anda mengiriminya tautan www.yourdomain.com/lostpassword?param_1=x;param_2=y
  3. Dia mengklik tautan dan mampu membuat sendiri kata sandi baru
  4. Dia mengklik kirim. Semuanya dilakukan. Semua orang senang

Satu-satunya tangkapan ada di poin 3). Nilai X dan Y harus acak, tidak dapat diprediksi, dan terhubung ke akun tertentu ini. Mereka harus juga hanya digunakan satu kali dan akan menjadi basi setelah periode waktu yang singkat (24 jam?). Menyimpan kedua nilai dalam tabel khusus dengan kolom yang sesuai:

| some_id | user_id | X | Y | expire_time

Jika pengguna mencoba menggunakan tautan yang tepat untuk memeriksa apakah waktu kedaluwarsa tidak terpenuhi dan jika tidak, izinkan dia mengubah kata sandi.

0
Andrzej Bobak