Dahulu
kala , cukup memiliki nenek yang jahat di pintu masuk ruang mesin untuk melindungi kata sandi. Dahulu kala, di masa awal mainframe, ada otentikasi dua faktor yang sangat baik. Sebelum memasukkan kata sandi pribadi Anda di terminal, perlu melalui stan dengan penjaga. Semua ini secara otomatis mempersempit permukaan serangan ke beberapa orang yang secara fisik memiliki akses ke terminal. Saat itulah modem, hashing, dan kesenangan lain dari dunia modern muncul, ketika kata sandi secara teratur bocor dalam jutaan.
Jika Anda memiliki pengguna dan mereka login dengan password, saya sarankan mengambil melihat lagi pada rekomendasi terbaru dari organisasi seperti Institut Nasional Standar dan Teknologi dan Pusat Keamanan Cyber Nasional .
Secara khusus, tidak lagi modis untuk memerlukan rotasi kata sandi. Dan untuk menuntut simbol-simbol tertentu dalam tradisi terbaik lelucon tentang "FUCKING ROSE" juga. Mari kita bahas poin utama dan mencoba membuat pengguna lebih nyaman dan aman.
Otentikasi bukan biner
Tidak, saya mengerti bahwa penganut formulasi ketat sekarang akan mulai membenci. Secara teori, pengguna login atau tidak. Anda tidak akan bisa masuk sedikit pun. Namun panduan keamanan informasi modern menyiratkan pendekatan non-biner untuk kepercayaan pengguna.
Pengguna yang sangat tepercaya berhasil memasukkan kata sandi dengan benar dan masuk dari perangkat resmi. Sedikit kurang percaya pada pengguna yang login dari perangkat tepercaya, tetapi melakukan kesalahan saat memasukkan sandi. Dan itu sangat buruk jika pengguna memasukkan kata sandi dengan benar, tetapi perangkat tidak tepercaya, faktor kedua tidak dikonfirmasi, dan IP milik node keluaran Thor. Dalam kasus ketiga, saatnya menarik sakelar dengan tulisan “Alarm! Serigala mencuri kelinci! "
Tugas kita, sebagai orang yang menyediakan layanan, adalah membuat orang merasa nyaman, aman, dan tidak terlalu menyakitkan jika mereka melakukan kesalahan. Oleh karena itu, ada baiknya menempatkan tanda-tanda tertentu dari aktivitas abnormal untuk memasukkan tindakan tambahan tertentu untuk melindungi akun. Misalnya, setelah 3-5 entri kata sandi salah, minta pengguna untuk menelusuri CAPTCHA. Ya, semua orang membencinya, tetapi sebagian besar pengguna tidak akan menemukannya. Dan mereka yang telah menurunkan peringkat kepercayaan mereka akan melambat sedikit sebelum memasukkan kata sandi lagi. Tapi kami akan menghentikan serangan brute force otomatis.
Tidak perlu membatasi panjang kata sandi maksimum
Kata sandi yang panjang lebih aman. Izinkan pengguna menggunakannya.
Yah, bukannya itu tidak perlu sama sekali. Kata sandi tebal dengan panjang beberapa megabyte berpotensi menjadi bumerang di tempat yang tidak terduga atau efek aneh lainnya. Tetapi panjang maksimum bersyarat 300 karakter dijamin sesuai dengan pengguna biasa. Selain itu, NIST menganut rekomendasi yang sama:
Pengautentikasi harus mengizinkan pengguna untuk menggunakan kata sandi yang mudah diingat dengan minimal 64 karakter.
Dan untuk layanan yang sangat berbakat, NIST juga memberikan rekomendasi penting lainnya:
Dilarang memotong sandi pengguna.
Ya, ada layanan yang sangat aneh yang percaya bahwa 12 karakter sudah cukup, yang berarti bahwa 28 karakter yang tersisa dapat dengan aman dipotong dan dicek hash dari hanya fragmen pertama. Saya tidak tahu apa yang dipikirkan oleh pikiran yang terpengaruh tentang ini, tetapi organisasi perbankan yang sama sering kali menderita karenanya. Jangan lakukan itu. Jika seorang pengguna ingin menggunakan bagian dari Iliad menjadi dua dengan potongan teks dari grup Bloodstock, biarkan dia menggunakannya.
Pastikan semua karakter ASCII valid
Ada masalah tertentu dengan karakter khusus. Misalnya, penggunaan "{} / \" atau karakter serupa lainnya mungkin berpotensi tidak valid dalam beberapa situasi. Misalkan tanda kurung kurawal dapat merusak JSON yang valid dan menyebabkan pemrosesan kata sandi macet. Atau karakter apostrof, yang dapat digunakan dalam injeksi SQL. Ya, formulir entri kata sandi juga bisa menjadi gerbang masuk untuk serangan.
Secara teori, Anda dapat dengan mudah melarang penggunaan simbol semacam itu untuk memudahkan Anda sendiri. Tetapi dengan melakukan itu, Anda akan mengurangi entropi kata sandi pengguna dan membuatnya tidak nyaman baginya jika kata sandi dibuat secara otomatis. Anda harus memilih pola tertentu untuk pengecualian. Sekali lagi, mengacu pada NIST
Semua karakter ASCII [RFC 20] yang dapat dicetak, termasuk spasi, harus berupa sandi yang valid. Karakter unicode [ISO / ISC 10646] juga harus valid.
Iya. Semuanya benar. Ini adalah sakit kepala Anda dan pengujian tambahan. Tetapi jika pengguna ingin menggunakan ਬਹੁਤ ਮੁਸ਼ਕਲ ਪਾਸਵਰਡ atau මෙයද ඉතා දුෂ්කර මුරපදයකි, biarkan dia melakukannya. Atau tambahkan karakter burrito ke kata sandi Anda untuk kekuatan kriptografi. Memiliki hak untuk.
Selain itu, pengguna tertinggal dengan kebutuhan untuk menggunakan karakter khusus. Ya, jangan sentuh dia. Biarkan dia menggunakan apa yang dia inginkan. Studi tentang kebocoran massal menunjukkan bahwa orang masih menggunakan substitusi bodoh dengan karakter khusus, yang sama sekali tidak memperbaiki situasi. Secara khusus, Microsoft menulis:
Kebanyakan orang menggunakan pola yang sama, misalnya huruf kapital sebagai karakter pertama, karakter khusus dan angka pada dua posisi terakhir. Penjahat dunia maya menyadari hal ini dan menyesuaikan serangan kamus mereka dengan substitusi biasa seperti "s" untuk "$", "a" untuk "@" dan "i" untuk "l".
Ya, Microsoft yang sama, karena jutaan orang setiap bulannya membuat kata sandi baru yang tidak sama dengan yang sebelumnya, berisi karakter khusus dan huruf dalam kasus yang berbeda. Mereka adalah orang-orang yang sekarang menulis "Hilangkan persyaratan komposisi karakter" dalam pedoman mereka.
Lagi pula, pada akhirnya, utilitas umum seperti cain and abel, hashcat, john the ripper dapat menebak sandi selama beberapa jam atau bahkan menit pada kartu video biasa, jika kata kosa kata standar dan pola pengganti yang khas digunakan.
Jangan gunakan petunjuk kata sandi
Jauh lebih aman untuk mengubur kata sandi yang terlupakan selamanya daripada menyimpan petunjuk di database dalam teks yang jelas.
Pada 2013, Adobe membocorkan basis data kata sandinya. Itu dienkripsi dengan tidak benar, tetapi hal yang paling tidak menyenangkan adalah bahwa itu berisi petunjuk untuk pemulihan, yang Randal Monroe tidak gagal untuk mengejeknya di xkcd.
Pendapat yang sama juga dimiliki oleh NIST, yang tidak merekomendasikan penyimpanan petunjuk dalam bentuk apapun. Lupa - pulihkan lewat surat dengan semua pemeriksaan tambahan.
Kurangi beban di otak pengguna
Pusat Keamanan Cyber Nasional telah merilis infografik yang keren . Izinkan saya mengutip satu bagian kecil:
Perhatikan bahwa masalah utama dengan kata sandi adalah bahwa kata sandi yang baik bersifat acak dan hampir tidak mungkin diingat. Jika ada banyak layanan, maka pengguna hampir pasti akan menggunakan kata sandi yang sama jika memungkinkan. Yang tingkat lanjut akan melakukan sesuatu seperti "myp@ssword_habr.com". Biasanya, membobol kata sandi di satu tempat secara otomatis membobol akun di semua layanan lainnya.
Oleh karena itu, biarkan pengguna menggunakan pengelola kata sandi. Ya, ini seperti dompet khusus untuk kartu bank yang memungkinkan Anda kehilangannya pada saat yang bersamaan. Tetapi di sini Anda perlu memahami bahwa kompromi penyimpanan kata sandi offline adalah situasi yang agak jarang terjadi, berbeda dengan penyusupan kata sandi yang sama pada sumber daya yang berbeda. Pengelola kata sandi tidak harus sempurna. Ini harus lebih baik daripada jenis kata sandi yang sama di mana pun. Jangan seperti layanan buruk yang memblokir kemampuan untuk menempelkan kata sandi ke dalam bidang dari papan klip. Ini jelas memaksa pengguna untuk meninggalkan pengelola kata sandi dan menggunakan opsi yang lemah.
Poin kedua mengatakan bahwa tidak perlu memaksa pengguna untuk mengubah sandinya jika tidak ada tanda-tanda yang jelas dari penyusupannya. Ini hanya memotivasi dia untuk menggunakan pola dengan kata sandi yang sama. Jauh lebih baik untuk meningkatkan alarm jika kata sandi muncul di salah satu dari sekian banyak kamus yang bocor. Secara alami, Anda tidak dapat membiarkan pengguna membuat kata sandi yang telah dimasukkan dalam kamus.
kesimpulan
- Bersikaplah baik kepada pengguna. Jangan memaksanya untuk tampil dengan pola yang khas dan melakukan hal-hal bodoh. Persyaratan kebiasaan standar langsung mendorongnya ke hal ini. Ikuti saja beberapa poin:
- Gunakan otentikasi kunci alih-alih kata sandi jika memungkinkan.
- Jangan biarkan pengguna menggunakan password jika ada di kamus database. Tidak masalah jika dia membocorkannya di sana atau orang lain.
- , . . .
- , .
- , .
