it-swarm-id.com

"Nama Pengguna dan / atau Kata Sandi Tidak Valid" - Mengapa situs web menunjukkan jenis pesan ini alih-alih memberi tahu pengguna mana yang salah?

Katakanlah seorang pengguna masuk ke situs tipikal, memasukkan nama pengguna dan kata sandi mereka, dan mereka salah mengetik input mereka. Saya perhatikan bahwa sebagian besar, jika tidak semua, situs menampilkan pesan yang sama (sesuatu di sepanjang baris, "Nama pengguna atau kata sandi salah") walaupun hanya satu input yang salah.

Bagi saya, sepertinya cukup mudah untuk memberi tahu pengguna tentang input yang salah dan ini membuat saya bertanya-tanya mengapa situs tidak melakukannya. Jadi, apakah ada alasan keamanan untuk ini atau itu hanya sesuatu yang telah menjadi norma?

103
bobble14988

Jika pengguna jahat mulai menyerang situs web dengan menebak kombinasi nama pengguna/kata sandi umum seperti admin/admin, penyerang akan mengetahui bahwa nama pengguna itu valid apakah itu mengembalikan pesan "Kata sandi tidak sah" dan bukannya "Nama pengguna atau kata sandi tidak valid".

Jika penyerang tahu nama pengguna itu valid, ia dapat memusatkan upayanya pada akun tersebut menggunakan teknik seperti injeksi SQL atau bruteforcing password.

128
user10211

Seperti yang disebutkan orang lain, kami tidak ingin Anda tahu apakah itu nama pengguna atau kata sandi yang salah sehingga kami tidak rentan terhadap brute-force atau kamus serangan ..

Jika beberapa situs web ingin memberi tahu penggunanya yang gagal saat masih berada dalam kebijakan keamanan hijau, mereka dapat mengimplementasikan " honeypot " nama pengguna (seperti Administrator, admin, dll.) Yang akan mengingatkan situs web admin bahwa seseorang menyelinap di situs web mereka. Anda bahkan dapat mengatur beberapa logika untuk mencekal alamat IP mereka jika mereka mencoba masuk dengan salah satu nama pengguna "honeypot" tersebut. Saya kenal satu orang yang benar-benar memiliki situs web dan memasukkan kode sumbernya komentar HTML seperti "Karena Anda terus lupa Richard: Nama pengguna: keju Kata sandi: Burger123" di dekat kotak masuk dengan maksud untuk memantau alamat IP yang berusaha digunakan nama pengguna/kata sandi itu. Menambahkan logika pemantauan seperti itu sangat menyenangkan ketika Anda sedang mengembangkan situs web.

Tentu saja, mencatat upaya login yang tidak valid dan menambahkan logika yang sesuai untuk menangani alamat IP tersebut juga berfungsi. Saya tahu beberapa orang akan tidak setuju dengan saya, tetapi tergantung pada jenis situs webnya, saya rasa itu bukan masalah besar untuk memberi tahu pengguna selama Anda menambahkan langkah-langkah keamanan tambahan dalam mencegah berbagai jenis serangan.

24
ROFLwTIME

Implementasi aman favorit saya dari ini dilakukan oleh bank yang saya gunakan. Jika saya mengetik nama pengguna saya dengan benar, itu akan mengatakan "Selamat datang Jimbob!" dan kemudian meminta saya untuk menjawab pertanyaan keamanan (jika saya belum pernah login dari browser ini di komputer ini), tunggu saya untuk menjawab pertanyaan keamanan dengan benar, dan kemudian akan membiarkan saya melihat gambar/keterangan keamanan saya dan memasukkan kata sandi saya. Jika saya mengetik nama pengguna yang salah, saya akan melihat sesuatu seperti "Selamat Datang Bessie/Kareem/Randal!" di mana nama yang ditampilkan sangat jarang - meskipun Anda akan selalu menjadi nama yang sama untuk nama pengguna yang sama (saya biasanya tidak yakin antara satu atau dua nama pengguna; dan yang salah secara konsisten memanggil saya Frenshelia). Saya menganggap ini diterapkan sebagai semacam hash non-kriptografi yang diterapkan pada nama pengguna yang dimasukkan yang secara unik memetakan ke satu nama pengguna pada daftar panjang nama-nama yang tidak biasa. Ini memungkinkan pengguna yang sah tahu jika mereka mengetikkan nama pengguna yang salah (bahkan jika Anda memiliki nama yang tidak biasa seperti Bessie; itu sangat tidak mungkin bahwa nama pengguna yang salah Anda secara acak menebak peta kembali ke nama tidak umum spesifik Anda), tanpa membuatnya jelas bagi orang yang mencoba untuk menemukan akun acak bahwa nama pengguna tidak ada.

Sebagai tambahan: Saya tidak terlalu menyukai pertanyaan keamanan/gambar keamanan, yang tampaknya berbatasan dengan teater keamanan. Penyerang canggih yang melakukan serangan man-in-the-middle (MITM) (mis., Setelah memasang sertifikat palsu di browser web Anda; dan spoofing DNS/ARP untuk mengarahkan yourbank.com ke alamat IP mereka) dapat menunggu hingga Anda mencoba masuk ke dalam situs, kemudian minta skrip otomatis masuk di komputer mereka ke situs asli, dapatkan pertanyaan keamanan, tampilkan pertanyaan keamanan yang dipilih kembali kepada Anda, kirim kembali jawaban ke situs sendiri dari browser mereka, tunggu untuk mendapatkan keamanan gambar, sajikan kembali gambar keamanan kepada Anda, dan kemudian tunggu Anda memasukkan kata sandi dari ujungnya di titik mana mereka menggunakan kata sandi untuk masuk saat Anda dan melakukan hal-hal jahat. Memberi pertanyaan + gambar membuat proses lebih sulit daripada memiliki semua waktu di dunia untuk mengumpulkan semua gambar keamanan untuk berbagai nama pengguna yang diserang dengan mengubahnya menjadi serangan yang harus dilakukan secara waktu nyata dan mungkin meninggalkan tanda tangan yang mencurigakan .

18
dr jimbob

Jawaban lain memberikan wawasan yang baik tentang alasan keamanan di balik perilaku ini. Meskipun benar, saya cukup yakin bahwa setidaknya beberapa situs web hanya memiliki rutinisasi otorisasi yang diprogram dengan cara yang tidak mungkin untuk mengetahui apa yang salah - masuk atau kata sandi.

Permintaan sampel:

SELECT COUNT(*) FROM users WHERE login = 'john' AND hash = '2bbfcdf3f09ae8d700402f36913515cd'

Ini akan mengembalikan 1 pada upaya logging yang berhasil dan jika tidak ada pengguna dengan nama seperti itu atau pengguna ini memiliki kata sandi yang berbeda. Tidak ada cara untuk mengetahui bagian mana dari kondisi gagal. Jadi ketika datang ke menampilkan programmer pesan kesalahan hanya dengan jujur ​​memberitahu Anda bahwa ada sesuatu yang salah dan dia tidak benar-benar yakin apa itu sebenarnya.

Saya pribadi melihat pertanyaan serupa di beberapa situs web berbasis PHP jadi saya cukup yakin bahwa sebagian alasannya berasal dari cara proses otentikasi dikodekan, sungguh.

13
Dyppl

Namun, ada teknik menarik lain yang bisa diterapkan untuk melakukan user enumeration attack (dan banyak lagi). Ini disebut Timing attack. Penyerang hanya mengukur waktu respons untuk permintaan otentikasi dan bagaimana perbedaan antara login yang valid dan yang tidak valid.

  1. Skala Nanosecond Serangan Timing Jauh Pada PHP Aplikasi: Waktu Untuk Mengambil Mereka Serius?
    http://blog.astrumfutura.com/2010/10/nanosecond-scale-remote-timing-attacks-on-php-applications-time-to-take-them-seriously/

  2. Pelajaran dalam serangan waktu
    http://codahale.com/a-lesson-in-timing-attacks/

  3. Perbandingan string waktu konstan dalam PHP untuk mencegah serangan timing
    (https://codereview.stackexchange.com/questions/13512/constant-time-string-comparision-in-php-to-prevent-timing-attacks

Maksud saya adalah bahwa pesan seperti itu tidak cukup jika Anda ingin mengamankan aplikasi Anda dari ancaman semacam ini.

8

Alasan keamanan di baliknya adalah jika tidak, maka menjadi jauh lebih mudah untuk menemukan nama pengguna yang valid.

5
Lucas Kauffman

Selain semua jawaban hebat yang telah diberikan, ada prinsip keamanan umum yang mengatakan Anda tidak boleh memberikan informasi yang tidak diminta kepada pengguna yang tidak sah. Yaitu. jika Anda memiliki pilihan untuk menjawab "data otentikasi Anda tidak valid" atau menjelaskan bagian mana yang tidak valid - Anda harus selalu memilih yang pertama. Beberapa serangan kriptografi yang sangat jahat didasarkan pada jumlah terkecil dari informasi kesalahan yang disediakan oleh implementasi yang mencoba menjadi "membantu" - lihat Padding Oracle attack . Jadi adalah ide yang baik untuk selalu memilih sedikit informasi yang mungkin diungkapkan kepada entitas yang tidak sah - yaitu, jika kombo nama pengguna/kata sandinya tidak baik, Anda selalu menjawab "nama pengguna/kata sandi tidak baik", dan tidak pernah mengungkapkan lagi data. Bahkan jika dalam kasus tertentu (seperti gmail di mana nama pengguna bersifat publik) itu tidak penting, ini adalah praktik yang baik untuk diterapkan secara default.

5
StasM

Katakanlah Anda memasukkan nama pengguna acak dan kata sandi yang sama acak (cukup catat kata sandi apa yang Anda masukkan). Sekarang kata sandi dapat umum di antara n pengguna. Jadi, jika situs web mengatakan kata sandi itu benar ... maka Anda tahu apa yang mengikuti selanjutnya .. kekacauan di antara pengguna asli karena mendapatkan nama login cukup mudah.

4
aayush anand

Memberikan jawaban yang ambigu berguna untuk mencegah enumerasi pengguna serangan.

Dalam beberapa kasus penyerang tidak perlu berkompromi dengan akun pengguna. Informasi bahwa pengguna memiliki akun sudah cukup tanpa tindakan lain. Misalnya itu adalah informasi berharga untuk perdagangan bahwa pelanggan mereka memiliki akun di toko web yang kompetitif.

4
Jakub Šturc

Saya menghargai berbagai jawaban di atas karena mereka mengatakan yang paling tetapi kadang-kadang Aplikasi juga tidak menyadari apa yang salah Nama Pengguna atau Kata Sandi. Dalam kasus otentikasi berbasis token khusus untuk mengimplementasikan SSO (Single Sign On) mis. IBM Tivoli Access Manager aplikasi Anda menerima token yang berhasil atau mendapatkan kesalahan kembali.

4
Niks

jika login adalah alamat email, mudah untuk mengetahui bahwa seseorang terdaftar di sebuah situs web - Saya mungkin tidak menginginkannya >> Terkadang orang menggunakan kata sandi akun email asli untuk situs web yang mereka daftarkan ketika mereka menggunakan id email sebagai id login :)

3