Haruskah saya memaksakan panjang maksimum pada kata sandi?

162

Saya dapat memahami bahwa memaksakan panjang minimum pada kata sandi masuk akal (untuk menyelamatkan pengguna dari diri mereka sendiri), tetapi bank saya memiliki persyaratan bahwa kata sandi berukuran antara 6 dan 8 karakter, dan saya mulai bertanya-tanya ...

Bukankah ini hanya akan memudahkan serangan brute force? (Buruk)
Apakah ini menyiratkan bahwa kata sandi saya disimpan tidak terenkripsi? (Buruk)

Jika seseorang dengan (mudah-mudahan) beberapa profesional keamanan TI yang bekerja untuk mereka memaksakan panjang kata sandi maksimal, haruskah saya berpikir untuk melakukan hal serupa? Apa pro / kontra dari ini?

security encryption passwords

— nickf
sumber

16

Hampir pasti ada kebijakan "tiga serangan dan Anda keluar", yang menghilangkan ancaman serangan brute force.

— Stu Thompson

23

Tidak ada alasan untuk ini untuk sistem non-legacy, seperti situs web modern.

— mparaz

7

Saya tidak berpikir jawabannya murni IT. Ukuran minimum (6) dan batas maksimum upaya "kemungkinan" untuk menghilangkan tebakan liar. Dugaan saya adalah bahwa ukuran maksimum (8) adalah untuk membatasi jumlah panggilan (dan akibatnya biaya) dari dukungan untuk "Ups saya lupa kode saya" atau "Saya ketik kode untuk berpuasa" atau "Saya salah ketik satu karakter" dll. Selain kertas tempat Anda menulis kata sandi jika Anda tidak dapat mengingatnya ..

— hubungi saya Steve

17

Universitas tempat saya mendaftar memiliki aturan kata sandi yang sangat bodoh: hanya 8 karakter, setidaknya 1 angka, tetapi tidak di awal atau akhir kata sandi, membutuhkan karakter dari lebih dari 2 baris atas keyboard, dll. mereka membuat bruteforcing lebih mudah dengan memiliki aturan ini -.-. Aku sadar kamu tidak sebodoh itu, tapi tolong jangan membuat aturan konyol seperti itu! (Hanya harus mengeluarkannya dari sistem saya :))

— cwap

17

@ panggil Yah jika Anda memaksakan panjang maksimal untuk alasan itu maka Anda akan mendapatkan panggilan "Saya lupa kata sandi" dari saya , karena kata sandi unik situs saya panjang, dan membatasi saya hingga 12 karakter adalah cara pasti untuk menjamin saya akan tidak ingat itu.

— Roman Starkov

193

Kata sandi di-hash menjadi 32, 40, 128, berapa pun panjangnya. Satu-satunya alasan untuk panjang minimum adalah untuk mencegah kata sandi yang mudah ditebak. Tidak ada tujuan untuk panjang maksimal.

Wajib XKCD menjelaskan mengapa Anda melakukan pengguna Anda merugikan jika Anda memaksakan panjang max:

— epochwolf
sumber

6

Mungkin bank mungkin memilih untuk membatasi kata sandi karena pada ATM Anda tidak dapat memasukkan lebih dari, katakanlah, 8 karakter.

— André Chalella

11

setidaknya di ATM, jika Anda mencoba serangan brute force, itu akan memakan kartu Anda. Yang saya maksudkan adalah kata sandi untuk login online saja.

— nickf

39

Sayangnya itu mengasumsikan bahwa kata sandi selalu hash. Kata sandi panjang maksimum adalah gejala kata sandi yang disimpan dalam plaintext.

— jevon

14

Huh, bahkan di PayPal, "staples baterai kuda yang benar" adalah 8 karakter di atas panjang maksimum <sensor> ... headdesk

— Roman Starkov

3

@kleinfreund karena jika hash, panjang kata sandi tidak masalah bagi mereka (fungsi hash mengonversi string dengan panjang berapa pun menjadi panjang tetap).

— Vicky Chijwani

75

Panjang maksimum yang ditentukan pada bidang kata sandi harus dibaca sebagai PERINGATAN KEAMANAN . Setiap pengguna yang masuk akal dan sadar keamanan harus menganggap yang terburuk dan berharap bahwa situs ini menyimpan kata sandi Anda secara harfiah (yaitu tidak diacak, seperti yang dijelaskan oleh epochwolf).

Dalam hal ini masalahnya:

Hindari menggunakan situs ini seperti wabah jika memungkinkan. Mereka jelas tidak tahu apa-apa tentang keamanan.
Jika Anda benar-benar harus menggunakan situs ini, pastikan kata sandi Anda unik - tidak seperti kata sandi yang Anda gunakan di tempat lain.

Jika Anda mengembangkan situs yang menerima kata sandi, jangan berikan batas kata sandi konyol, kecuali jika Anda ingin mendapatkan tar dengan kuas yang sama.

[Secara internal, tentu saja kode Anda hanya dapat memperlakukan 256/1024 / 2k / 4k / (apa pun) byte pertama sebagai "signifikan", untuk menghindari pengetikan pada kata sandi raksasa.]

— tardate
sumber

17

Saya juga mengirim email standar kepada situs web tersebut, menyebutkan bahwa mereka memaksa saya untuk menggunakan kata sandi yang lebih pendek dan kurang aman, yang juga saya gunakan kembali pada setiap situs web yang menerapkan batasan konyol seperti itu. Ini membuat mereka tahu bahwa ini adalah masalah dan mungkin memberi Joe Coder beberapa pengaruh untuk diperlihatkan kepada atasan: bukti bahwa pengguna benar-benar berpikir buruk tentang situs web sebagai akibat dari ini.

— Roman Starkov

3

Saya tidak yakin Anda harus berasumsi bahwa kata sandi maksimum berarti mereka menyimpan kata sandi teks biasa. Kadang-kadang, mereka memotong input, dan hanya melewatkan karakter x pertama ke hashing (). (Cara untuk memeriksa adalah mengatur kata sandi di luar batas, kemudian mencoba masuk dengan variasi karakter kata sandi di luar panjang maksimal).

— benc

5

@Benc yakin, itu mungkin, tetapi intinya adalah sebagai pengguna Anda tidak memiliki cara untuk mengetahui apakah ini yang mereka lakukan. Panjang maksimal (terutama yang pendek) adalah tanda peringatan dan saya pikir yang terbaik adalah menganggap yang terburuk (atau menghubungi penyedia untuk meminta mereka mengonfirmasi).

— tardate

1

Tolong jelaskan. Jawaban ini hanyalah pernyataan belaka.

— kleinfreund

1

Kata sandi maksimum tidak berarti disimpan sebagai teks biasa; bisa karena alasan teknis, misalnya bcrypt hanya mengizinkan kata sandi hingga 72 karakter.

— emorris

58

Mengizinkan panjang kata sandi yang sama sekali tidak terikat memiliki satu kelemahan utama jika Anda menerima kata sandi dari sumber yang tidak tepercaya.

Pengirim dapat mencoba memberi Anda kata sandi yang begitu panjang sehingga mengakibatkan penolakan layanan untuk orang lain. Misalnya, jika kata sandi adalah 1GB data dan Anda menghabiskan seluruh waktu Anda menerimanya sampai kehabisan memori. Sekarang anggaplah orang ini mengirimkan kata sandi ini sebanyak yang Anda mau terima. Jika Anda tidak berhati-hati dengan parameter lain yang terlibat, ini dapat menyebabkan serangan DoS.

Mengatur batas atas ke sesuatu seperti 256 karakter tampaknya terlalu murah hati dengan standar saat ini.

— Jason Dagit
sumber

35

Anda masih dapat mengirim data 1gb dengan batas maksimum. Perangkat lunak yang melakukan pembatasan hampir selalu berada di belakang server web.

— epochwolf

6

Anda masih dapat menghapus semua kecuali 256chars pertama sebelum melakukan sesuatu yang intensif secara komputasi. Menjalankan hash pada 1gb data akan memakan waktu lebih lama daripada hash yang sama pada 256 karakter.

— rcreswick

2

@Eyal: Apa pun yang terjadi di sisi klien aplikasi web pada dasarnya tidak dipercaya; dengan demikian, hash menjadi kata sandi yang setara, menjadikan ini latihan sia-sia. (peramban web mungkin tidak akan menerima input teks 1-GB, dan klien khusus mungkin mengirim string 1-GB di bidang formulir "thisisthehashedpassword")

— Piskvor meninggalkan gedung

4

@Piskvor: Tapi toh tidak ada cara untuk mencegah string 1-GB. Seorang pengguna selalu dapat meminta example.com/?password=abcabcabcabc ... dan membuat permintaannya sebesar yang ia inginkan. DoS standar.

— Eyal

4

@Piskvor dan Eyal, untungnya, Apache dan IIS (dan mungkin server dewasa lainnya) membatasi panjang bidang yang dilewati melalui URL: boutell.com/newfaq/misc/urllength.html

— sampablokuper

21

Pertama, jangan berasumsi bahwa bank memiliki profesional keamanan TI yang bekerja untuk mereka. Banyak yang tidak .

Yang mengatakan, panjang kata sandi maksimum tidak berharga. Sering kali mengharuskan pengguna untuk membuat kata sandi baru (argumen tentang nilai menggunakan kata sandi yang berbeda di setiap situs selain untuk saat ini), yang meningkatkan kemungkinan mereka hanya akan menuliskannya. Ini juga sangat meningkatkan kerentanan untuk menyerang, oleh vektor apa pun dari brute force ke social engineering.

— Sparr
sumber

Sepakat! Lihatlah bahwa rangkaian kegagalan keamanan akses online bank Inggris dalam beberapa tahun terakhir ...

— Stu Thompson

6

Saya sudah menggunakan kata sandi yang berbeda di setiap situs web melalui skema yang memungkinkan saya mengingat semuanya, tetapi semuanya agak panjang. Satu-satunya websies yang kata sandinya saya tulis pada catatan tempel adalah yang memberlakukan batasan panjang maks moronik dan dengan demikian memaksa saya menjauh dari kata sandi pilihan saya namun unik ...

— Roman Starkov

@romkyns Saya anggap skema Anda tidak menggunakan simbol? Saya pernah memiliki skema seperti itu yang menghasilkan kata sandi pendek yang sulit diurai, tetapi saya harus mengabaikannya ketika 10-20% situs yang saya gunakan melarang karakter khusus umum.

— Sparr

tidak ada karakter khusus, tidak, tetapi selalu menambah angka dan karakter huruf besar, karena saya tahu beberapa situs menuntut itu. Seandainya saya tahu tentang batas panjang maksimal ketika saya datang dengan itu ... Tapi skema (sederhana) yang saya buat untuk kerabat dekat telah bekerja dengan baik sejauh ini!

— Roman Starkov

1

@romkyns masalah lain dengan skema seperti itu: situs yang membagikan kata sandi. Jika skema Anda adalah sesuatu seperti nameofwebsitefO0 (googlefO0 yahoofO0 dll) lalu bagaimana Anda ingat bahwa Anda seharusnya menggunakan "yahoofO0" di flickr.com, atau stackoverflowfO0 di askubuntu.com? situs yang kedaluwarsa kata sandi. maka Anda perlu memperluas skema untuk memasukkan bagian yang dapat berubah. tapi itu gagal jika aturan kedaluwarsa memeriksa substring.

— Sparr

13

Mengatur panjang kata sandi maksimal kurang dari 128 karakter sekarang tidak disarankan oleh OWASP Authentication Sheet Cheat

https://www.owasp.org/index.php/Authentication_Cheat_Sheet

Mengutip seluruh paragraf:

Kata sandi yang lebih panjang memberikan kombinasi karakter yang lebih besar dan akibatnya mempersulit penyerang untuk menebak.

Panjang minimum kata sandi harus diberlakukan oleh aplikasi. Kata sandi yang lebih pendek dari 10 karakter dianggap lemah ([1]). Sementara penerapan panjang minimum dapat menyebabkan masalah dengan menghafal kata sandi di antara beberapa pengguna, aplikasi harus mendorong mereka untuk menetapkan frasa sandi (kalimat atau kombinasi kata) yang bisa lebih lama dari kata sandi biasa dan lebih mudah diingat.

Panjang kata sandi maksimum tidak boleh terlalu rendah, karena akan mencegah pengguna membuat kata sandi. Panjang maksimum khas adalah 128 karakter. Frasa sandi yang lebih pendek dari 20 karakter biasanya dianggap lemah jika hanya terdiri dari karakter Latin dengan huruf kecil. Setiap karakter penting !!

Pastikan setiap karakter yang diketik pengguna benar-benar dimasukkan dalam kata sandi. Kami telah melihat sistem yang memotong kata sandi dengan panjang lebih pendek dari yang diberikan pengguna (misalnya, terpotong pada 15 karakter ketika mereka memasukkan 20). Ini biasanya ditangani dengan mengatur panjang SEMUA bidang input kata sandi sama persis dengan panjang maksimum kata sandi. Ini sangat penting jika panjang kata sandi maks Anda pendek, seperti 20-30 karakter.

— kravietz
sumber

11

Sumber ini tidak mengecilkan batas panjang kata sandi maksimum, tetapi mencegah batas panjang kata sandi maksimum rendah (kurang dari 128 karakter).

— Matius

9

Salah satu alasan yang dapat saya bayangkan untuk menegakkan panjang kata sandi maksimum adalah jika frontend harus berinteraksi dengan banyak sistem backend yang lama, salah satunya memaksakan panjang kata sandi maksimum.

Proses pemikiran lain mungkin adalah bahwa jika seorang pengguna dipaksa untuk pergi dengan kata sandi singkat mereka lebih mungkin untuk menciptakan omong kosong acak daripada kata-kata atau julukan catch catching (oleh teman / keluarga mereka). Pendekatan ini tentu saja hanya efektif jika frontend memberlakukan pencampuran angka / huruf dan menolak kata sandi yang memiliki kata-kata kamus, termasuk kata-kata yang ditulis dalam l33t-speak.

— mbac32768
sumber

1

Meskipun dapat dimengerti, sistem warisan terkadang harus menentukan desain. Jika memungkinkan, mereka TIDAK boleh mempengaruhinya. Hal terakhir yang Anda inginkan dalam sistem baru adalah kebijakan keamanan yang dirancang sebelum serangan keamanan modern bahkan menjadi hal biasa. Atau lebih buruk, perangkat lunak yang lebih baru tetapi tidak dirancang dengan benar. Sistem perusahaan yang ada dapat menggunakan HTTP tetapi itu bukan pembenaran untuk tidak menggunakan SSL dalam sistem atau ekstensi baru. Demikian juga, kebijakan kata sandi tidak boleh terus menjadi rentan hanya karena orang-orang TERAKHIR itu salah. Dan jika menjaga, sebaiknya ada studi biaya / manfaat BESAR.

— Katastic Voyage

6

Salah satu alasan yang berpotensi sah untuk memaksakan beberapa panjang kata sandi maksimum adalah bahwa proses hashing itu (karena penggunaan fungsi hashing lambat seperti bcrypt) memakan terlalu banyak waktu; sesuatu yang bisa disalahgunakan untuk menjalankan serangan DOS terhadap server.

Kemudian lagi, server harus dikonfigurasi untuk secara otomatis menjatuhkan penangan permintaan yang terlalu lama. Jadi saya ragu ini akan menjadi masalah.

— AardvarkSoup
sumber

4

Saya pikir Anda sangat tepat pada kedua poin tersebut. Jika mereka menyimpan kata sandi hash, sebagaimana seharusnya, maka panjang kata sandi tidak mempengaruhi skema DB mereka sama sekali. Memiliki panjang kata sandi terbuka membuka satu variabel lagi yang harus diperhitungkan oleh penyerang brute-force.

Sulit untuk melihat alasan untuk membatasi panjang kata sandi, selain desain yang buruk.

— Lucas Oman
sumber

3

Satu-satunya manfaat yang bisa saya lihat untuk panjang kata sandi maksimum adalah untuk menghilangkan risiko serangan buffer overflow yang disebabkan oleh kata sandi yang terlalu panjang, tetapi ada banyak cara yang lebih baik untuk menangani situasi itu.

— DrStalker
sumber

1

Harus ada panjang input maksimum, ya, tetapi seharusnya tidak boleh <64. Panjang maksimal 8 atau 12 hanya konyol.

— Dan Bechard

2

Abaikan orang yang mengatakan tidak memvalidasi kata sandi yang panjang. Owasp secara harfiah mengatakan bahwa 128 karakter seharusnya cukup. Hanya untuk memberi ruang napas yang cukup, Anda bisa memberi sedikit lebih banyak, katakanlah 300, 250, 500 jika Anda menginginkannya.

https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Password_Length

Panjang Kata Sandi Kata sandi yang lebih panjang memberikan kombinasi karakter yang lebih besar dan akibatnya mempersulit penyerang untuk menebak.

...

Panjang kata sandi maksimum tidak boleh terlalu rendah, karena akan mencegah pengguna membuat kata sandi. Panjang maksimum khas adalah 128 karakter . Frasa sandi yang lebih pendek dari 20 karakter biasanya dianggap lemah jika hanya terdiri dari karakter Latin dengan huruf kecil.

— CommonSenseCode
sumber

Tidak relevan dengan diskusi. Pertanyaannya adalah apakah ada manfaat untuk membatasi panjangnya, bukan apakah 128 sudah cukup.

— vikki

1

Penyimpanan murah, mengapa membatasi panjang kata sandi. Bahkan jika Anda mengenkripsi kata sandi sebagai lawan dari hanya hashing string 64 karakter tidak akan mengambil lebih dari string 6 karakter untuk mengenkripsi.

Kemungkinannya adalah sistem bank overlay sistem yang lebih lama sehingga mereka hanya dapat memberikan ruang untuk kata sandi dalam jumlah tertentu.

— Lisb
sumber

9

Kecuali ada alasan yang sangat valid, kata sandi harus diacak. Hash menghasilkan string panjang tetap. Tidak ada ruang argumen untuk dibuat, kecuali sistem menyimpan kata sandi yang sebenarnya, yang bisa dibilang ide yang buruk.

— Stu Thompson

8

Mengenkripsi kata sandi adalah ide yang buruk. Hanya karyawan yang tidak bertanggung jawab yang diperlukan untuk membocorkan satu trilyun kata sandi. Simpan masalahnya dengan tidak pernah menyimpannya di tempat pertama.

— Roman Starkov

1

Bank saya juga melakukan ini. Ini digunakan untuk mengizinkan kata sandi apa pun, dan saya memiliki 20 karakter. Suatu hari saya mengubahnya, dan lihatlah itu memberi saya maksimal 8, dan telah memotong karakter non-alfanumerik yang ada di kata sandi lama saya. Tidak masuk akal bagi saya.

Semua sistem back-end di bank bekerja sebelumnya ketika saya menggunakan kata sandi 20 char saya dengan non-alpha-numerics, jadi dukungan lama tidak bisa menjadi alasannya. Dan bahkan jika itu, mereka masih harus memungkinkan Anda untuk memiliki kata sandi sewenang-wenang, dan kemudian membuat hash yang sesuai dengan persyaratan sistem warisan. Lebih baik lagi, mereka harus memperbaiki sistem warisan.

Solusi kartu pintar tidak cocok dengan saya. Saya sudah memiliki terlalu banyak kartu karena ... Saya tidak perlu trik lain.

— Vincent McNabb
sumber

Mereka memotong keyspace penting yang memperpanjang waktu untuk serangan brute force ketika (dan maksud saya KETIKA) database hash mereka dicuri (dengan asumsi mereka bahkan garam / hash / peregangan, yang saya yakin tidak). Saatnya berganti bank.

— Chris Gomez

1

Jika Anda menerima kata sandi berukuran sewenang-wenang maka orang menganggap bahwa kata sandi itu dipotong ke panjang tirai untuk alasan kinerja sebelum hash. Masalah dengan pemotongan adalah bahwa ketika kinerja server Anda meningkat dari waktu ke waktu Anda tidak dapat dengan mudah menambah panjang sebelum pemotongan karena hash-nya jelas akan berbeda. Tentu saja Anda bisa memiliki periode transisi di mana kedua panjang hash dan diperiksa tetapi ini menggunakan lebih banyak sumber daya.

— Pengguna
sumber

1

Cobalah untuk tidak memaksakan batasan apa pun kecuali perlu. Berhati-hatilah: mungkin dan akan diperlukan dalam banyak kasus berbeda. Berurusan dengan sistem warisan adalah salah satu alasan ini. Pastikan Anda menguji kasus kata sandi yang sangat panjang dengan baik (dapatkah sistem Anda menangani kata sandi panjang 10MB?). Anda dapat mengalami masalah Denial of Service (DoS) karena Key Defivation Functions (KDF) yang akan Anda gunakan (biasanya PBKDF2, bcrypt, scrypt) akan membutuhkan banyak waktu dan sumber daya. Contoh kehidupan nyata: http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-surity/

— Marek Puchalski
sumber

0

Haruskah ada panjang maksimal? Ini adalah topik yang aneh di IT dalam hal itu, kata sandi yang lebih panjang biasanya lebih sulit untuk diingat, dan karena itu lebih mungkin untuk dituliskan (yang BESAR tidak-tidak karena alasan yang jelas). Kata sandi yang lebih lama juga cenderung lebih dilupakan, yang walaupun tidak selalu menimbulkan risiko keamanan, dapat menyebabkan kerepotan administratif, kehilangan produktivitas, dll. Admin yang percaya bahwa masalah ini mendesak cenderung memaksakan panjang maksimum kata sandi.

Saya pribadi percaya pada masalah khusus ini, untuk masing-masing pengguna. Jika Anda pikir Anda dapat mengingat kata sandi 40 karakter, maka semakin besar kekuatan untuk Anda!

Karena itu, kata sandi dengan cepat menjadi mode keamanan yang ketinggalan jaman, Smart Card dan otentikasi sertifikat terbukti sangat sulit untuk tidak mungkin dilakukan karena Anda menyatakan masalah, dan hanya kunci publik yang perlu disimpan di server dengan private. kunci pada kartu / komputer Anda setiap saat.

— puzzleegreg
sumber

Orang dapat dengan mudah mengingat lirik lagu favorit, ayat Alkitab, atau perkataan lainnya. Itu sangat panjang dibandingkan dengan kata sandi biasa. Saya baru saja menguji satu dan muncul di 79 karakter! (Memang, kemungkinan kesalahan naik semakin lama frasa sandi adalah. Lebih buruk lagi ketika situs web STUPID tidak menunjukkan karakter terakhir yang Anda masukkan dalam kotak kata sandi.)

— Katastic Voyage

0

Kata sandi yang lebih panjang, atau frasa sandi, lebih sulit untuk dipecahkan hanya berdasarkan panjangnya, dan lebih mudah diingat daripada membutuhkan kata sandi yang rumit.

Mungkin yang terbaik untuk pergi untuk panjang minimum yang cukup panjang (10+), membatasi panjang tidak berguna.

— benPearce
sumber

0

Sistem legacy (sudah disebutkan) atau interfacing sistem vendor luar mungkin mengharuskan tutup 8 karakter. Ini juga bisa merupakan upaya sesat untuk menyelamatkan pengguna dari diri mereka sendiri. Membatasinya dengan cara itu akan menghasilkan terlalu banyak password pssw0rd1, pssw0rd2, dll. Dalam sistem.

— Membuang
sumber

0

Salah satu alasan kata sandi mungkin tidak di-hash adalah algoritma otentikasi yang digunakan. Misalnya, beberapa algoritme intisari memerlukan versi plaintext dari kata sandi di server karena mekanisme otentikasi melibatkan klien dan server yang melakukan perhitungan matematika yang sama pada kata sandi yang dimasukkan (yang umumnya tidak akan menghasilkan keluaran yang sama setiap kali kata sandi dikombinasikan dengan 'nonce' yang dibuat secara acak, yang dibagi antara dua mesin).

Seringkali ini dapat diperkuat karena pencernaan dapat menjadi bagian yang dihitung dalam beberapa kasus, tetapi tidak selalu. Rute yang lebih baik adalah agar kata sandi disimpan dengan enkripsi yang dapat dibalik - ini berarti sumber aplikasi perlu dilindungi karena mengandung kunci enkripsi.

Digst auth ada untuk memungkinkan otentikasi melalui saluran yang tidak dienkripsi. Jika menggunakan SSL atau enkripsi saluran lengkap lainnya, maka tidak perlu menggunakan mekanisme intisari digest, artinya kata sandi dapat disimpan dengan hash sebagai gantinya (karena kata sandi dapat dikirim dengan teks biasa melalui kabel dengan aman (untuk nilai keamanan tertentu).

— Chris J
sumber

-4

Kata sandi yang panjang hanya 8 karakter terdengar salah. Jika seharusnya ada batasan, maka setidaknya 20 char adalah ide yang lebih baik.

— pengguna17000
sumber

3

Tapi itu masalahnya - seharusnya tidak ada batasan sama sekali.

— Luke Stevenson

-4

Saya pikir satu-satunya batas yang harus diterapkan adalah seperti batas 2000 huruf, atau sesuatu yang terlalu tinggi, tetapi hanya untuk membatasi ukuran database jika itu merupakan masalah

— Josh Hunt
sumber

9

Kata sandi harus hash ... Dan ukuran basis data tidak akan menjadi masalah adalah kata sandi hash.

— epochwolf

4

@epochwolf - Saya dapat memikirkan satu alasan mengapa kata sandi tidak selalu harus di-hash (karena saya menemukannya sendiri hari ini): kata sandi yang perlu diserahkan ke pihak ketiga atas nama pengguna tidak dapat disimpan sebagai hash nilai. [Misalnya aplikasi yang perlu menyimpan kredensial untuk mengirim email melalui domain eksternal.]

— Kenny Evitt