Apa sajakah alternatif yang memungkinkan untuk menyediakan 'Kata Sandi Admin' untuk aplikasi desktop?


10

Saat ini saya mengelola dan memfaktorkan ulang perangkat lunak yang telah digunakan di perusahaan saya selama lebih dari satu dekade sekarang. Salah satu elemen dari aplikasi ini adalah semacam admin atau mode power-user yang menyediakan hal-hal seperti beberapa input tambahan / internal serta kemampuan untuk mematikan batas input.

Secara historis mode ini telah dihidupkan dengan menempatkan file bernama khusus di tempat tertentu di direktori sistem windows (keduanya hard coded ke dalam aplikasi), file tersebut bernama 'something.DLL', meskipun itu kosong File ASCII dan bukan dll.

Jadi saya baru-baru ini menambahkan beberapa kode dan bentuk modal kecil yang memungkinkan pengguna untuk memasukkan kata sandi admin untuk mengaktifkan fungsi ini. Ini adalah kata sandi yang ditetapkan, bukan khusus pengguna. Ketika kata sandi yang benar dimasukkan, ia melakukan hal yang sama dengan membuat 'file kunci' di direktori root aplikasi sehingga program dapat mulai dalam mode admin jika file itu ada.

Sekarang manajer departemen tempat software ini kebanyakan tidak begitu menyukai gagasan itu. Dia berpikir bahwa jika kita hanya memiliki kata sandi yang sederhana dan telah diset sebelumnya, kata sandi itu akan dengan mudah 'keluar', dan dia tidak ingin pengguna yang tidak berpengalaman mengakses fitur-fitur tambahan itu.

Jadi pertanyaan saya adalah, metode apa yang ada untuk menyediakan akses semacam ini yang agak lebih aman? Cukup banyak hanya saya ketika datang untuk memelihara dan mengelola perangkat lunak ini, sehingga apa pun yang hampir tidak sepenuhnya dibangun atau otomatis tidak akan membantu (seperti mengirim permintaan untuk 'kunci lisensi' atau sesuatu yang mirip dengan itu).

Catatan: Aplikasi ini ditulis dalam VB.NET (.NET 4.0), dan saya saat ini berencana menggunakan penyebaran klik-sekali ketika versi baru selesai.


1
Seseorang harus membuat keputusan pengguna mana yang "tidak berpengalaman" dan mana yang tidak. Siapa yang membuat keputusan itu? Siapa yang harus memasukkan keputusan itu ke dalam sistem?
Doc Brown

Jawaban:


13

Jika Anda memiliki Active Directory, Anda dapat menguji keanggotaan di Active Directory Group:

public bool IsInADGroup(string ADGroupName)
    {
        bool result = false;
        List<string> myGroups = new List<string>();

        using (PrincipalContext pc = new PrincipalContext(ContextType.Domain, SystemInformation.UserDomainName))
        {
            using (PrincipalSearchResult<Principal> src = UserPrincipal.FindByIdentity(pc, SystemInformation.UserName).GetGroups(pc))
            {
                src.ToList().ForEach(sr => myGroups.Add(sr.SamAccountName));
            }
        }
        result = myGroups.Contains(ADGroupName);
        return result;
    }

Ini adalah jawaban yang sangat bagus, dan sesuatu yang pasti akan saya ingat untuk ini dan proyek lainnya. Namun masalah sebenarnya adalah pengguna program ini di luar perusahaan kami. Kami menyediakannya untuk kedua perusahaan saudara kita dan beberapa pengguna pihak ketiga eksternal. Saya sebenarnya berpikir pada titik ini bahwa yang terbaik adalah menonaktifkan fitur-fitur ini untuk mereka yang berada di luar jaringan kami dan menggunakan saran Anda untuk tujuan internal.
Anthony

5

Manajer benar tentang kata sandi yang keluar . Ini bukan masalah jika, tetapi kapan.

Karena Active Directory bukan opsi untuk beberapa pengguna, Anda bisa membuat file teks yang ditandatangani dengan daftar nama login windows yang diizinkan akses super pengguna. Ini mengasumsikan bahwa orang tidak berbagi komputer atau login.

Nama-nama pengguna hanya akan masuk dalam file teks yang mudah didistribusikan yang akan dimasukkan ke dalam folder aplikasi. Bagian yang penting adalah menandatangani daftar nama pengguna. Tetap sangat sederhana. Satu nama pengguna per baris dan letakkan hash di baris terakhir. Sematkan semacam kunci rahasia dalam biner program Anda dan hash dengan nama pengguna. Kunci rahasia akan mencegah orang memodifikasi file dan kemudian menghitung hash sendiri (yang mungkin terlalu jauh untuk memulai).

UserName1
UserName2
.
.
.
UserName34
<HashOfUserNamesAndSecretKey>

Ini, tentu saja, mengharuskan seseorang di suatu tempat untuk bertindak sebagai admin dari daftar pengguna yang berwenang. Admin harus memiliki program (ditulis oleh Anda!) Yang menghasilkan file dan hash. Jika tidak ada yang lain, itu bisa saja mengambil file teks dari nama pengguna dan menambahkan hash.

Untuk kepentingan menyeluruh, seseorang yang telah dicabut aksesnya dapat mengambil salinan file yang masih memiliki nama login mereka di dalamnya. Kapan pun mereka menginginkan akses, mereka bisa meletakkan salinannya di tempatnya. Mungkin bukan sesuatu yang perlu dikhawatirkan.


3

Karena Active Directory bukan opsi, saya akan hash tanggal saat ini. Gunakan elemen dengan entropi pertama (hari dalam sebulan) dan yang paling sedikit entropi (tahun). Jika perlu, tambahkan garam khusus domain (ID pelanggan, nama perusahaan, dll. Karena digunakan di luar perusahaan Anda). Ini harus menghasilkan kata sandi yang sangat berbeda setiap hari yang secara praktis tidak mungkin ditebak oleh pengguna akhir, dan bisa berbeda untuk perusahaan yang menggunakan perangkat lunak tersebut.

Ini pada dasarnya adalah masalah ayam dan telur karena perangkat lunak harus dapat mengotentikasi pengguna tanpa menelepon ke rumah. Jadi buatlah telur dengan mekanisme retak yang sangat tidak jelas: sementara keamanan melalui ketidakjelasan bukanlah keamanan nyata, ini adalah yang terbaik yang Anda berikan sebagai parameter masalah Anda.

Ini juga lebih baik daripada menempatkan file teks di suatu tempat: itu tidak lebih baik daripada kata sandi statis karena begitu rahasia keluar, permainan berakhir.


0

Gunakan Daftar Kontrol Akses .

Cara cepat dan kotor untuk melakukan ini adalah menghapus semua izin dari direktori aplikasi (termasuk izin baca), lalu tambahkan izin ini untuk setiap pengguna yang diizinkan untuk menjalankan aplikasi. Tentu saja, pengguna dengan izin dapat dengan mudah menyalin direktori aplikasi ke lokasi publik, tetapi ini tidak mungkin terjadi secara tidak sengaja, sedangkan berbagi kata sandi dapat dengan mudah terjadi secara tidak sengaja.

Tentu saja ini mengasumsikan bahwa komputer yang terlibat aman (mudah-mudahan dengan direktori aktif).


Jika komputer yang terlibat diamankan dengan direktori aktif, mungkin yang terbaik adalah dengan mengamankan fungsi lanjutan dengan keanggotaan ke grup keamanan. Pengguna dapat ditambahkan ke grup berdasarkan kebutuhan dan izin sistem file tidak relevan
Kevin

@ Kevin: Setuju. Saya pikir Jawaban Dan mencakup itu.
Brian

0

Preferensi saya adalah seperti yang disarankan @Dan - gunakan direktori aktif. Jika ini tidak memungkinkan, maka penghasil kata sandi berdasarkan waktu dapat berguna. Dalam situasi yang sama, (masa lalu sangat jauh) satu perusahaan saya saya bekerja untuk digunakan 9999-MMDD. Ini memang keluar setelah beberapa tahun. Jika Anda melempar hhmm dan mencampurnya sedikit, Anda mungkin mendapatkan satu atau dua tahun sebelum seseorang membiarkan kucing mengeluarkan tas.

Anda selalu bisa menulis program yang menghasilkan kata sandi menggunakan strategi yang serupa tetapi lebih rumit. Lemparkan nama yang digunakan juga nama mesin. Manajer Anda dapat menjalankan program itu untuk mendapatkan kata sandi saat ini hanya untuk mesin itu. Menyimpan beberapa informasi dalam file sehingga tidak valid jika disalin ke komputer lain atau jika pengguna lain login. Kemudian terserah manajer Anda untuk menjaga program tetap aman dan jika kucing keluar, itu salahnya.

Skema ini dianggap lemah dan tidak dapat diandalkan dari perspektif cyrpto, tetapi cukup untuk masalah yang Anda miliki.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.