Saya telah menemukan dalam beberapa kasus, memaksa pengguna untuk mengubah kata sandi mereka secara teratur menjadi lebih berat pada pemeliharaan daripada bantuan untuk keamanan. Juga, saya telah melihat pengguna menuliskan kata sandi baru mereka karena mereka juga tidak mendapatkan cukup waktu untuk mengingat kata sandi mereka dan tidak dapat diganggu untuk mempelajari kembali kata sandi lain.
Apa manfaat keamanan untuk memaksa perubahan kata sandi?
Jawaban:
Berikut ini pendapat berbeda dari buku harian SANS:
Aturan kata sandi: Ubah setiap 25 tahun
Ada satu manfaat praktis. Jika seseorang memiliki kata sandi Anda, dan yang mereka inginkan hanyalah membaca email Anda dan tetap tidak terdeteksi, mereka dapat melakukannya selamanya, kecuali jika Anda akhirnya mengubah rahasia masuk Anda. Jadi, secara teratur mengubah kata sandi tidak banyak membantu seseorang yang masuk dan membuatnya dengan barang-barang Anda, tetapi itu TIDAK memberi Anda kesempatan untuk menyingkirkan penguntit atau pengintai yang mungkin Anda miliki mengakses akun Anda. Ya ini bagus. Tetapi apakah manfaat ini sendiri sepadan dengan kerumitan dan kerugian yang disebutkan memaksa pengguna untuk mengubah kata sandi mereka setiap 90 hari, saya ragu.
Memaksa perubahan kata sandi saat Anda menebaknya (dengan menjalankan program menebak kata sandi pada semua pengguna Anda sepanjang waktu).
Sulit untuk berdebat dengan "Anda harus mengubah kata sandi Anda" ketika jawaban untuk "mengapa?" adalah "karena kami dapat menebaknya buta". Secara otomatis memberi penghargaan kepada mereka yang memilih kata sandi yang sulit ditebak, dan mengajari pengguna Anda kata sandi apa yang lemah. Jika mereka memilih "kata sandi1", itu akan kedaluwarsa sebelum mereka dapat masuk sekali. Jika pengguna memilih 16 karakter, kata sandi acak, huruf besar-kecil, alfanumerik, Anda tidak akan pernah menebaknya - dan begitu pula orang lain. Biarkan mereka menyimpannya dalam waktu yang sangat lama, dan mereka bahkan akan dapat menghafalnya.
Ini adalah trade off. Membutuhkan perubahan kata sandi yang sering memang menghasilkan kata sandi dengan kualitas lebih rendah. Bahkan ada penelitian untuk efek ini.
Karena itu, satu-satunya cara yang andal yang saya temukan untuk mencegah pengguna membagikan kata sandi adalah dengan meminta perubahan kata sandi secara berkala. Pengalaman saya menunjukkan bahwa 90 hari tampaknya merupakan kompromi yang layak antara kegunaan dan keamanan. Jika Anda melangkah lebih lama, orang-orang mulai mengandalkan kata sandi bersama - lebih cepat dan Anda berakhir dengan "November09", "December09".
Hal terburuk tentang memaksakan perubahan kata sandi bukanlah Anda benar-benar menyebabkan orang mengubah kata sandi mereka. Biasanya hal itu muncul dengan sedikit atau tanpa peringatan, dan mereka langsung diserang dengan masalah yang harus mereka selesaikan, jadi daripada memberi seseorang waktu untuk memikirkan kata sandi yang baik, itu lebih cenderung menjadi kata sandi yang kurang aman tetapi lebih mudah diingat, atau lebih aman tetapi baru saja ditulis, sehingga meniadakan keuntungan keamanan.
Jika kata sandi memiliki kompleksitas yang cukup sehingga tidak mudah ditebak, dan tidak dibagikan di antara sistem, dan tidak mungkin dikompromikan, maka mengubah kata sandi mungkin tidak terlalu penting.
Namun, jika salah satu dari itu terjadi, dan dua yang pertama mungkin lebih umum daripada tidak, memaksa orang untuk mengubah kata sandi secara berkala berarti mereka cenderung berbagi kata sandi, setidaknya.
Yang mengatakan, saya akan memilih untuk mendidik pengguna Anda tentang arti kata sandi yang baik, dan mengapa sangat buruk untuk membagikannya. Menuliskannya adalah hal biasa, apa pun yang Anda lakukan.
Saya merekomendasikan orang-orang memilih kata sandi dari buku yang mereka tahu, dengan mengingat beberapa kutipan yang tidak terlalu dikenal darinya, atau membuat frase. Gunakan huruf pertama dari setiap kata, dan tambahkan dua angka di dalam sana. Kebanyakan orang dapat mengingatnya setelah mereka mengetiknya beberapa kali.
Saya tidak melihat manfaat dalam praktik itu sama sekali.
Kata sandi yang kuat jauh lebih penting. Maksud saya maksud baik 9+ simbol alfanumerik + khusus, atau 15+ [az] - hanya kata sandi / frase non-kamus (ini didasarkan pada studi terbaru tentang biaya bruteforcing password menggunakan Amazon EC2).
Sistem yang diakses dari jarak jauh harus memiliki deteksi bruteforce dan perangkat lunak pencegahan (misalnya fail2ban) pada semua layanan yang terpapar. Ini jauh lebih penting, IMO, daripada kebijakan penggantian kata sandi reguler.
Masalah dasarnya adalah bahwa kata sandi, sebagai mekanisme keamanan, berbau busuk.
Jika Anda meminta orang untuk sering mengubahnya, mereka menuliskannya. Jika Anda meminta mereka untuk menggunakan kata sandi 30 huruf dengan setidaknya 3 angka, 4 huruf besar, dan karakter kontrol, mereka melupakannya atau menuliskannya atau melakukan hal-hal konyol lainnya. Jika sederhana, pengguna akan menggunakan kata sandi bodoh seperti bunny7 atau Bunny7. Dan mereka akan menggunakan kata sandi buruk yang sama untuk semuanya, termasuk akun porno dan akun hotmail mereka.
Saya suka alat seperti Mobile OTP , yang memungkinkan pengguna untuk menggunakan ponsel mereka sebagai alat otentikasi dua faktor.
Dalam jangka panjang, sepertinya kita akan mendarat di dunia dengan sertifikat terenkripsi sebagai mekanisme identifikasi pengguna. Hal-hal seperti OpenID dan CAS menyederhanakan otentikasi pengguna dan memungkinkan satu-masuk yang mudah.
Dalam jangka panjang, taruhan terbaik adalah mengurangi berapa kali pengguna perlu menerbitkan kredensial - singkirkan kata sandi "SDM" dan kata sandi "lembar waktu" dan kata sandi "CRM". Menyatukan mereka ke dalam infrastruktur otentikasi umum yang mengharuskan pengguna untuk menerbitkan kredensial mereka sekali. Kemudian minta mereka menggunakan sesuatu seperti MobileOTP atau RSA SecurID yang menggunakan otentikasi dua faktor.
Dalam jangka pendek, kebijakan kata sandi akan menjadi topik perang agama. Lakukan saja apa pun yang diminta bos Anda, dan jika Anda bosnya, gunakan penilaian Anda berdasarkan basis pengguna dan profil keamanan yang diharapkan.
Semoga berhasil!
Praktek ini, yang tidak sepenuhnya sia-sia, jauh lebih penting sejak dulu. Perdebatan kebijakan ini sebenarnya kontraproduktif, karena mengalihkan perhatian dari ancaman saat ini yang jauh lebih serius.
Mempertimbangkan:
Jika Anda menggunakan Windows / AD, dan sebuah akun tidak memiliki kotak yang dicentang untuk "Akun sensitif dan tidak dapat didelegasikan", akun itu dapat digunakan melalui peniruan, dan tidak diperlukan kata sandi. Kode untuk melakukan ini sepele.
Jika workstation windows seseorang dikompromikan dari kerentanan keamanan, token keamanan windows in-memory mereka dapat digunakan untuk mengakses komputer lain. Sekali lagi, tidak perlu kata sandi.
Omong-omong, itulah mengapa Anda hanya boleh mengakses server menggunakan akun yang berbeda dari akun pengguna biasa Anda sehari-hari. Perhatikan juga bahwa kedua skenario sepenuhnya mengalahkan mekanisme otentikasi dua faktor yang paling kuat.
Hal terbaik yang dapat terjadi sehubungan dengan keamanan kata sandi adalah berhenti berdebat dan fokus pada ancaman yang lebih kontemporer dan serius.
Informasi lebih lanjut:
Lihat presentasi Luke Jennings, "Satu tanda untuk mengatur semuanya":
http://eusecwest.com/esw08/esw08-jennings.pdf
Insomnia Shell - contoh kode yang diperlukan untuk mengkompromikan token pada server ASP.Net:
http://www.insomniasec.com/releases/tools
Cara: Menggunakan Transisi Protokol dan Delegasi Terkendala dalam ASP.NET 2.0
http://msdn.microsoft.com/en-us/library/ms998355.aspx
Cari "tanpa kata sandi".
Semakin lama kata sandi tidak berubah semakin besar kemungkinan akan dikompromikan, hanya karena akan ada lebih banyak kesempatan untuk situasi di mana ia mungkin dikompromikan untuk terjadi (mengingat jumlah waktu yang tak terbatas segala sesuatu mungkin terjadi). Ini juga membuat lebih sulit untuk berubah di masa depan karena pengguna akan terbiasa dengan yang lama. Risiko lebih lanjut adalah bahwa jika itu dikompromikan dan pengguna tidak menyadari fakta bahwa ada potensi untuk penyalahgunaan serius yang berkelanjutan dari akun pengguna untuk terjadi. Perubahan berkala setidaknya akan memitigasi bahwa perubahan kata sandi yang dipaksakan berikutnya akan membuat kata sandi yang dikompromikan menjadi tidak berguna.
Dalam pengalaman saya, skenario yang paling mungkin menyebabkan pengguna untuk menuliskan kata sandi adalah kurangnya pemikiran bersama dalam infrastruktur keamanan Anda, seperti memiliki beberapa sistem yang berbeda yang semuanya memerlukan nama pengguna dan kombo kata sandi yang unik. Lempar 5 dari mereka pada pengguna dan Anda akan mendapatkan sindrom kuning-lengket-catatan dengan balas dendam.
Kebijakan kata sandi yang masuk akal yang memungkinkan pengguna untuk memilih kata sandi yang mudah diingat tetapi sulit untuk dipecahkan, ditambah dengan beberapa pendidikan pengguna yang baik, beberapa otentikasi terpadu yang solid, dan kebijakan penguncian dan kedaluwarsa yang layak, semua didukung oleh AUP yang secara eksplisit melarang berbagi kata sandi, adalah jalan terbaik.
Jika Anda melakukan caching kredensial (yang dilakukan kebanyakan orang untuk ketersediaan) maka ini adalah suatu keharusan. Jika komputer dicuri secara fisik dan caching kredensial diaktifkan, maka pencuri dapat dengan paksa memaksa mesin keluar dari jaringan tanpa takut kebijakan penguncian akun diaktifkan. Mereka kemudian memiliki kredensial yang valid ke sumber daya jaringan Anda. Mengubah kata sandi ini secara berkala dapat membantu meminimalkan kerusakan ini.
Ini adalah alasan yang tepat bahwa Anda tidak pernah masuk dengan akun istimewa, Anda selalu masuk sebagai pengguna terbatas dan meninggikan permintaan individu, ini mencegah kredensial istimewa dari menjadi kasar dipaksa saat terjadi pencurian / pembobolan.
Aku jauh di perkemahan yang tidak pernah membutuhkan perubahan kata sandi. Atau seperti kata artikel itu - setiap 25 tahun - ya saya akan mati saat itu. Baik. Inilah sebabnya ... Saya memiliki 12 kata sandi untuk diingat di pekerjaan saya. Sebagian besar dari mereka berubah dan yang berubah berada pada jadwal yang sama sekali berbeda. Mereka semua memiliki persyaratan kekuatan yang berbeda. Bagaimana manusia yang lemah bisa mengatasi ini? Beberapa cara yang pernah saya lihat: Tulis di papan tulis. Tuliskan di atas kertas dan simpan di laci yang tidak terkunci. atau metode pilihan saya: simpan dalam spreadsheet google doc yang tidak aman. Tidak ada cara Anda dapat meyakinkan saya bahwa salah satu metode ini (yang SANGAT biasa) tidak sepenuhnya mengimbangi manfaat keamanan kecil yang diperoleh dengan meminta perubahan.
Saya punya waktu untuk menulis posting ini karena saya sedang menunggu seseorang di dukungan TI untuk membuka kunci salah satu akun saya. Tampaknya saya tidak memperbarui spreadsheet dengan benar terakhir kali. Apakah ada penelitian yang menghitung MILIARAN $$$ yang hilang karena omong kosong ini?