it-swarm-id.com

Mengapa Menolak Karakter Khusus Dalam Kata Sandi?

Penyebab dalam kasus ini adalah bank tertentu (dan khususnya besar) yang tidak mengizinkan karakter khusus (dalam bentuk apa pun) dalam kata sandi mereka: Just [a-Z 1-9]. Apakah alasan mereka sah untuk melakukan ini? Tampaknya tidak produktif untuk menghentikan kekuatan kata sandi seperti ini, terutama untuk sistem yang melindungi informasi berharga tersebut.

Satu-satunya hal yang saya dapat lakukan adalah upaya yang lemah untuk menggagalkan suntikan SQL, tetapi itu akan menganggap kata sandi tidak hash (yang saya yakin harapan tidak benar).

68
Gary

Satu penjelasan yang belum saya lihat di sini adalah bahwa banyak lembaga keuangan terintegrasi erat dengan sistem yang lebih tua dan terikat pada keterbatasan sistem itu.

Ironi dari hal ini adalah saya telah melihat sistem yang dibangun agar kompatibel dengan sistem yang lebih lama, tetapi sekarang sistem yang lebih lama hilang dan kebijakan tersebut masih harus ada untuk kompatibilitas dengan sistem yang lebih baru yang dibangun agar kompatibel dengan sistem yang lebih lama.

(Pelajaran di sini adalah bahwa jika Anda harus kompatibel dengan sistem yang lama, biarkan untuk menghilangkan keterbatasan itu di masa depan).

65
Mark Burnett

Bagaimana dengan biaya dukungan? Misalkan kita mengizinkan siapa pun untuk membuat kata sandi terdiri dari karakter. Hore, kami dapat menggunakan karakter khusus dalam kata sandi kami. Tapi tunggu - bagaimana kita bisa mengetikkan kata sandi itu jika kita ingin mendapatkan akses ke bank kita dari ponsel-ponsel? Lebih mudah mengetik dari keyboard kami daripada dari ponsel.

Bagaimana dengan liburan? Kami berada di UK, yang hanya akses ke keyboard-UK. Dari pada kita dapat dengan mudah mengetik £. Kata easily sangat penting di sini. Untuk beberapa pengguna biasa, mengetik karakter untuk keyboard "baru" bisa menjadi masalah. Bagaimana dia akan mencoba menyelesaikannya? Dia mungkin akan menghubungi dukungan bank untuk meminta mereka mengubah kata sandi atau bertanya why the € character dissapeared from his keyboard.

13
p____h

Hal ini dapat (secara lemah) dibenarkan sebagai tindakan pertahanan-mendalam - jika ada suntikan atau bug penafsiran data lainnya, membatasi set karakter kata sandi dan panjangnya mungkin dapat mencegahnya dieksploitasi. Ini juga agak menyederhanakan implementasi, karena jika mereka hanya berurusan dengan 7-bit ASCII karakter, penanganan string karakter Unicode dan multibyte tidak relevan, dan implementasi yang lebih sederhana biasanya tidak mengandung bug.

Namun, menilai penurunan risiko ini terhadap peningkatan risiko karena kualitas kata sandi yang lebih rendah tidak mudah - saya berharap bahwa seiring dengan meningkatnya jumlah pengguna suatu sistem, jumlah kata sandi yang dapat dikompromikan juga meningkat, membuat investasi dalam mengangkat pembatasan lebih bermanfaat. Semua yang dikatakan, sebagian besar kata sandi pengguna akan mengerikan bahkan jika bidang itu sepenuhnya tidak dibatasi.

12
D Coetzee

Tebakan saya adalah kebijakan ada untuk semua bidang yang dimasukkan pengguna dan kebijakan input pengguna yang sama (tanpa karakter khusus) diterapkan ke bidang termasuk kata sandi untuk kesederhanaan. Atau di beberapa titik beberapa bank tidak hashing passwords dan memiliki serangan SQLi melalui bidang password mereka, dan kebijakan diputuskan bahwa password tidak dapat memiliki karakter khusus (dan alasan kebijakan dilupakan begitu hashing diperkenalkan).

Pasti ada manfaat keamanan dari tidak mengizinkan karakter khusus di bidang yang dimasukkan pengguna lainnya yang tidak hash dan dapat digunakan untuk berbagai serangan seperti SQLi atau XSS (pada administrator bank yang melihat akun). Namun, ancaman ini umumnya diselesaikan dengan selalu menggunakan parameter terikat dalam SQL dan selalu membersihkan input pengguna sebelum menampilkan/menyimpan ke db.

Tebakan saya yang lain adalah mereka ingin memiliki aturan khusus yang mungkin berbeda dari tempat lain, sehingga Anda tidak dapat dengan mudah menggunakan kembali kata sandi kuat standar Anda (yang mungkin hilang), dan harus membuat sesuatu yang unik untuk situs mereka.


SUNTING: Dipikirkan lebih lanjut, tergantung pada bahasanya saya dapat memikirkan setidaknya tiga karakter spesial ASCII yang seharusnya dilarang/dicabut secara universal karena memungkinkan mereka hanya menggoda nasib. Khususnya: \0 (null - ascii 0), karena biasanya digunakan untuk menunjukkan akhir string dalam bahasa gaya-C (kemungkinan pengguna untuk mengubah memori setelah akhir string). Juga carriage return dan line feeds \r (ascii 13) dan \n (ascii 10), karena ini sering bergantung pada sistem apakah pemutusan jalur adalah \r\n atau \n dan itu memunculkan hal yang tak terhindarkan saya hanya bisa masuk dari windows bukan mesin mac/linux saya. Bahkan, tampaknya cukup masuk akal untuk hanya mengizinkan ascii yang dapat dicetak (32-126) dan mencekal yang tidak dapat dicetak ASCII 0-31 dan 127).

Tetapi jika dengan karakter khusus yang Anda maksudkan unicode bukan ASCII karakter (seperti ,./<>?;':"[]{}\|[email protected]#$%^&*(-=_+ tampaknya masuk akal untuk kesederhanaan implementasi dari beberapa sistem operasi/keyboard/browser untuk tidak mengizinkan karakter khusus. Bayangkan kata sandi Anda memiliki huruf kecil di dalamnya. Apakah itu pi Yunani (π) yang merupakan codepoint 0x3c0 atau pi koptik Koptik (ⲡ) yang merupakan codepoint 0x2ca1 - hanya satu yang akan bekerja dan jenis masalah karakter yang sama dengan codepoint yang berbeda akan ada di unicode. Hash Anda yang beroperasi pada bit tidak akan dapat menyamakan kedua π, jadi jika Anda mencoba masuk di tempat yang berbeda Anda dapat memasukkan karakter yang berbeda.

Demikian pula, meskipun masalah ini adalah salah satu programmer sebagian besar dapat mengontrol dan berusaha melakukan yang benar, memungkinkan karakter unicode menciptakan masalah pengkodean. Itu untuk karakter ascii dasar Anda semuanya direpresentasikan dalam angka satu byte. Namun, ada banyak skema berbeda untuk cara menyandikan unicode. Apakah itu UTF-7, UTF-8, UTF-16, UTF-32, Latin-1 (iso-8859-1), pengkodean Latin-N, dan (untuk beberapa pengkodean) berapa urutan byte (sedikit atau big endian) ? Codepoint unicode untuk pi (0x3c0) akan direpresentasikan sebagai byte 2b 41 38 41 2d dalam UTF-7, CF 80 dalam UTF-8, FF FE c0 03 dalam UTF-16, dan FF FE 00 00 c0 03 00 00 dalam UTF-32. Anda tidak akan dapat mewakili pi dalam bahasa Latin-1 (hanya memiliki 95 karakter yang dapat dicetak), tetapi jika Anda memiliki A1 dalam kata sandi Anda dan berada dalam penyandian berbeda, Anda mungkin harus mewakilinya dari salah satu karakter berikut ¡ĄĦЁ‘ก”Ḃ (yang dalam beberapa bahasa Latin-N mungkin ke A1).

Ya, halaman web mungkin memiliki charset yang ditentukan, tetapi pengguna dapat mengganti charset pada halaman di browser mereka atau telah menyalin dan menempelkan data dari tempat lain dalam pengkodean yang berbeda. Pada akhirnya, mungkin lebih mudah untuk hanya melarang karakter tersebut.

9
dr jimbob

Sebagai generalisasi, berikut adalah alasan paling umum bahwa lembaga keuangan membatasi kompleksitas panjang dan karakter.

(1) Layanan web adalah sistem front-end untuk warisan aplikasi mainframe, yang sering memiliki batasan delapan karakter yang hanya terdiri dari alfa dan angka huruf kecil. Tidak ada "karakter khusus." Anehnya, ini adalah batasan yang paling umum. +1 ke Mark Burnett di atas.

(2) Mereka tidak mem-hashing kata sandi, sehingga mereka tidak bisa begitu saja menyimpan string numerik panjang tetap (mis. Output hash - 32 byte SHA256 (kata sandi)). Karena itu mereka harus khawatir tentang membatasi ukuran input.

(3) Vektor ancaman injeksi SQL hanya masalah kata sandi jika kata sandi disimpan sebagai teks yang jelas. Banyak organisasi dan lainnya membuang-buang waktu dengan khawatir akan melarikan diri dari karakter kata sandi, ketika masalahnya segera diselesaikan dengan menyimpan kata sandi hash (idealnya asin dan diregangkan menggunakan sesuatu seperti PBKDF2).

Selain mendukung kata sandi dukungan pelanggan yang sederhana me-reset OVER keamanan, tidak ada alasan yang dapat diterima yang saya ketahui untuk mentransmisikan kata sandi pengguna dalam teks yang jelas dari perangkat pengguna. Anda tidak menginginkan tanggung jawab itu, jadi jangan pernah menerimanya. Untuk itulah hash crypto digunakan.

Berikut ini adalah posting blog yang bagus yang merangkum beberapa praktik terbaik dan termasuk contoh kode. http://crackstation.net/hashing-security.htm

4
OnTheShelf

Saya sebenarnya bertanya pada webshop besar itu (bol.com, tidak yakin apakah mereka internasional).

Saran mereka adalah menggunakan kata sandi yang kuat, sering mengubahnya, menggunakan huruf dan angka, sehingga harus panjang, dan mungkin beberapa hal lain yang saya lupa. Lagi pula, saran biasa yang tidak ada mengikuti. Tetapi mereka tampaknya peduli dengan kebijakan kata sandi.

Namun mereka tidak mengizinkan sebagian besar karakter khusus, dan panjang kata sandi maksimum adalah 12 karakter. Setelah bertanya, mereka mengatakan kepada saya bahwa jika tidak, terlalu banyak orang akan menghubungi dukungan.

Ketika saya mengirim mereka kembali untuk bertanya apa "Lupa kata sandi Anda?" fitur itu untuk, saya tidak mendapat balasan ...

Jadi untuk bank, di mana pengaturan ulang kata sandi sederhana melalui e-mail tidak mungkin, saya kira biaya dukungan benar-benar alasannya (seperti yang disarankan oleh orang lain di sini). Untuk situs web lain seperti bol.com ini, saya akan sangat tidak percaya apakah mereka memasukkan kata sandi. Anda harus menggunakan kata sandi yang lebih unik di sana, jika basis data bocor kata sandi Anda akan diketahui.

2
Luc

Membatasi karakter yang disetel ke alfanumerik membatasi kemungkinan skrip atau mengeksploitasi melewati tahap validasi input.

Pengguna selalu dapat meningkatkan keamanannya dengan menggunakan kata sandi yang lebih lama, tetapi aplikasi harus memiliki daftar putih khusus untuk membantu mencegah serangan.

1
Rory Alsop

Saya dapat mencoba memberikan pandangan saya tentang masalah di atas sebagai perancang antarmuka UI dan bukan programmer: titik kunci di sini adalah bahwa persyaratan masuk sebagian merupakan masalah desain antarmuka UI dan bukan masalah pemrograman saja.

Ada buku yang sangat bagus "Apress - Desain Antarmuka Pengguna untuk Programmer" yang menunjukkan masalah analog terkait dengan ukuran jendela yang akan saya posting di bawah ini:

Berikut pola pikir programmer yang umum: hanya ada tiga angka: 0, 1, dan n. Jika n dibolehkan, semua n juga memiliki kemungkinan yang sama. Pola pemikiran ini berasal dari konvensi pengkodean lama (mungkin pintar) bahwa Anda seharusnya tidak memiliki konstanta numerik dalam kode Anda kecuali untuk 0 dan 1.

Sekarang pemikiran di atas benar dalam masalah pemrograman saja, tetapi karena menyangkut antarmuka pengguna dan terutama windows tidak

Tapi itu tidak benar. Ternyata, itu tidak mungkin sama. Ada banyak alasan bagus mengapa Anda mungkin menginginkan sebuah jendela tepat di bagian atas layar (ini memaksimalkan real estat layar), tetapi sebenarnya tidak ada alasan untuk meninggalkan dua piksel antara bagian atas layar dan bagian atas jendela. . Jadi, pada kenyataannya, 0 jauh lebih mungkin daripada 2.

Sekarang datang ke masalah kita, secara teoritis semua karakter harus memiliki kemungkinan yang sama dan sama-sama diizinkan dari sudut pandang pemrograman dan formal, namun di sini kita juga dalam contoh masalah antarmuka UI dan kita harus menyadarinya dan memberikan bobot yang tepat untuk itu .

Jadi saya akan memparafrasekan jawaban dari utas di atas yang menurut saya benar:

Katakanlah bahwa kami mengizinkan siapa pun untuk membuat kata sandi yang berisi € char. Hore, kami dapat menggunakan karakter khusus dalam kata sandi kami. Tapi tunggu - bagaimana kita bisa mengetikkan kata sandi itu jika kita ingin mendapatkan akses ke bank kita dari ponsel-ponsel? Lebih mudah mengetik € dari keyboard kami daripada dari ponsel.

Itulah poin utama dari sudut pandang kegunaan dan kita tidak boleh menyalahkan pengguna jika dia menyadari beberapa tahun kemudian dengan smartphone ketika bertahun-tahun sebelum mereka tidak ada, bahwa dia menggunakan karakter yang seharusnya dia hindari.

Merupakan kewajiban kami untuk memikirkan jenis masalah ini dan membiarkan pengguna menghindarinya!

0
dendini

Sedikit terlambat ke pesta - Saya baru-baru ini membaca bahwa alasan untuk ini adalah bahwa bagi banyak bank, nilai dari peningkatan keamanan yang memungkinkan karakter-karakter tersebut dikalahkan oleh biaya implementasi dan biaya dukungan untuk berurusan dengan pelanggan yang tidak dapat mengingat kata sandi mereka .

Saya tidak mengatakan itu alasan yang bagus, tapi itulah cara saya menafsirkan apa yang saya baca.

http://www.theglobeandmail.com/technology/digital-culture/why-canadas-banks-have-weaker-passwords-than-Twitter-or-google/article18325257/

0
Steve Campbell