Refleksi PMPL Sprint 2

Gregorius Aprisunnea
6 min readOct 30, 2020

Artikel ini dibuat sebagai refleksi Sprint 2 Proyek Kelas mata kuliah PMPL (Penjaminan Mutu Perangkat Lunak) di Faultas Ilmu Komputer Universitas Indonesia.

Apa yang dimaksud dengan Proyek Kelas disini?

“ Proyek Kelas” pada mata kuliah PMPL merupakan suatu Perangkat lunak yang dikembangkan bersama-sama oleh seluruh mahasiswa didalam mata kuliah PMPL semester gasal 2020. Proyek kelas ini didasarkan pada satu proyek setengah jadi yang dibuat dengan Django Framework. Pengerjaan proyek kelas ini dibagi menjadi dua fase Sprint dan mahasiswa diberikan kebebasan pada setiap sprint untuk membuat fitur baru atau meningkatkan fitur yang telah ada sebelumnya. Dari yang saya pahami, tujuan dari proyek kelas ini adalah untuk melatih mahasiswa dalam mengembangkan perangkat lunak dengan tetap menjamin kualitas dari kode yang dibuat.

Pengalaman pada Sprint 2

Sesuai penjelasan sebelumnya, mahasiswa diberikan kebebasan untuk membuat fitur baru ataupun meningkatkan fitur yang telah ada. Setiap fitur yang hendak dikerjakan oleh mahasiswa harus dikonsultasikan juga ke asisten dosen dan apabila ada mahasiswa yang kebetulan memikirkan fitur yang sama, maka harus ada yang mengalah dan mengusulkan fitur baru untuk dikerjakan. Kebetulan, fitur saya ada yang bertabrakan dengan fitur mahasiswa lain sehingga saya harus memikirkan fitur lainnya.

Apakah fitur yang saya kerjakan pada Sprint 2?

Pada sprint 2, saya menambahkan fitur untuk mengecek tingkat kekuatan dari password yang digunakan oleh pengguna aplikasi proyek kelas ini. Pengecekan kekuatan password ini didasarkan pada password policy yang umum digunakan (minimal 8 karakter dengan kombinasi upper case letter, lower case letter, digit, dan special character). Pengecekan tingkat kekuatan password ini akan dilakukan khususnya pada fitur register dan berpengaruh pada fitur-fitur lain yang membutuhkan tingkat kekuatan password, misalnya fitur change password.

Apakah pentingnya password policy yang baik?

Password policy adalah aturan-aturan terkait manajemen dan penggunaan password. Dewasa ini, berbagai macam alat yang digunakan oleh peretas mampu ‘menebak’ password dengan sangat cepat dan mudah, baik menggunakan dictionary attack maupun bruteforce. Tentunya, penggunaan password yang kuat akan mempersulit peretas untuk memperoleh password yang dimiliki oleh pengguna. Sebagai seorang developer / CISO, sebaiknya menentukan dan membuat suatu password policy yang kuat sehingga dapat memaksa pengguna untuk menggunakan password yang sesuai standard yang dibutuhkan dan penggunaan password dapat sesuai protokol yang ada.

Bagaimana saya mengimplementasi password policy ini?

TDD: Test sebelum implementasi kode

Sebelum melakukan implementasi, tentunya kita harus memulai dengan membuat test terlebih dahulu. Membuat test sebelum implementasi ini adalah kunci yang harus dipegang dalam pelaksanaan TDD (Test Driven Development). Test yang saya lakukan adalah unit testing untuk menguji password policy validator (minimal 8 karakter dengan kombinasi upper case letter, lower case letter, digit, dan special character) dan unit testing untuk menguji implementasi password policy pada fitur register. Berikut merupakan unit testing yang saya lakukan:

Gambar 1. Unit test untuk validator
Gambar 2. Potongan kode test untuk validasi register

Test pada gambar 1 merupakan test untuk validator yang akan digunakan untuk mengecek “Apakah password sudah sesuai policy yang diinginkan?”. Pada test ini, saya menguji satu demi satu setiap kemungkinan yang diinginkan sesuai dengan password policy. Salah satu hal yang menarik merupakan penggunaan assertRaises(<jenis error / exception>, <fungsi yang ingin diuji>, <params dari fungsi yang ingin diuji>). Fungsi ini akan mengecek apakah kekuatan password sudah sesuai policy, apabila belum maka akan muncul ValidationError yang artinya belum sesuai policy. Apanila muncul ValidationError, maka validator yang akan saya implementasi berhasil menangkap kelemahan di password tersebut.

Test pada gambar 2 merupakana potongan kode unit test dalam pengecekan register utuk user admin. Test yang saya buat men-cover pengecekan kekuatan password register tidak hanya untuk admin, tetapi sekaligus untuk kontributor. Pengecekan ini dilakukan satu demi satu untuk setiap kemungkinan yang sesuai dengan password policy. Test ini dilakukan dengan pengiriman request untuk pembuatan user dengan variasi password. Apabila aplikasi ini menolak password yang digunakan pengguna karena tidak sesuai dengan policy, maka akan di cek (setelah request ini) bahwa tidak akan ada objek user yang dibuat di database dan akan muncur notifikasi kepada pengguna (sebagai response) mengenai kekurangan dari password yang diberikan pengguna.

Implementasi Kode

Setelah melakukan testing yang pastinya akan menghasilkan error bila dijalankan (karena belum ada implementasi), kita dapat mulai mengimplementasi kode. Hal ini mungkin terdengan konyol karena kita harus men-kode test kita sebelum men-kode aplikasi kita. Akan tetapi, bila kita telah membuat test terlebih dahulu, kita dapat menjadi lebih yakin akan implementasi yang akan dilakukan. Hal ini dikarenakan kita sudah tau apa yang harus kita lakukan sehingga kita hanya perlu “mengimplementasi kode dengan memperbaiki test hingga tidak error”. Implementasi yang saya lakukan ada 3:

1. Mengimplementasikan PasswordPolicyValidator

Berikut merupakan implementasi yang saya lakukan untukPasswordPolicyValidator untuk mengecek kekuatan password dari pengguna:

Gambar 3. PasswordPolicyValidator

Setelah mengimplementasi PasswordPolicyValidator, saya mengubah settings.py untuk projek ini sebagai berikut:

Gambar 4. Definisi penggunaan PasswordPolicValidator di settings.py

Pada gambar 4, saya mengubah konfigurasi proyek kelas ini agat autentikasi untuk password validator menggunakan PasswordPolicyValidator yang telah saya implementasikan tadi. Di Django, penggunaan custom validator dapat didefinisikan pada bagian AUTH_PASSWORD_VALIDATORS pada settings.py. Sebagai catatan tambahan, validator ini nantinya akan dipanggil untuk fitur register yang implementasinya seperti pada nomor 2.

2. Mengimplementasikan password policy untuk register

Implementasi password policy enforcement untuk fitur register dilakukan dengan mengubah logic dari views.py. Berikut merupakan gambar views.py sebelum dan sesudah implementasi yang saya lakukan:

Gambar 5. Implementasi views.py sebelum password policy enforcement
Gambar 6. Implementasi views.py sesudah password policy enforcement

Perbedaan yang dapat diamati adalah bahwa pada gambar 5 (Sebelum), pada fungsi post() hanya akan di cek mengenai validitas form dan apabila valid akan dilakukan registrasi pada RegistrationService.create_new_admin(). Sebagai tambahan, pengecekan yang diimplementasikan oleh UserForm di forms.py tidak mengecek password policy sehingga pada gambar 5, kita perlu menambahkan pengecekan password policy di views.py. Berikut kode untuk UserForm:

Gambar 7. Implementasi forms.py pada register

Seperti yang nampak pada gambar 7, terkait password, forms hanya mengecek apabila password yang dimasukkan pengguna sama dengan repeat password yang dimasukkan pengguna tersebut. Oleh kerena itu, password policy enforcement dilakukan dengan mengubah views.py dari gambar 5 menjadi seperti gambar 6.

Pada gambar 6, tampak bahwa registrasi user akan dilakukan pada RegistrationService.create_new_admin() yang akan mengembalikan data yang berisi state saat ini, yaitu apakah registrasi sukses ataukah gagal. Apabila RegistrationService sukses mendaftarkan pengguna, maka akan melanjutkan ke login user, dan apabila gagal akan mengembalikan kembali form yang telah diisi oleh pengguna kepada pengguna tersebut dengan keterangan tambahan mengenai error yang terjadi (kekurangan di kekuatan password). Implementasi yang saya lakukan adalah untuk user admin dan kontributor , yang saya jelaskan pada ilustrasi diatas hanyalah untuk user admin (untuk user kontributor hampir mirip). Untuk “bagaimana validasi dengan Validator dilakukan?” akan dibahas pada nomor 3.

3. Mengimplementasikan integrasi register ke service

Pada nomor 1 dan 2 telah dijelaskan mengenai implementasi password validator dan bagaimana password validator ini akan digunakan oleh aplikasi. Pada bagian ini, saya akan menjelaskan secara spesifik dimana validator akan dipanggil dan melakukan pengecekan terhadap password yang dimasukkan pengguna. Segala fungsionalitas ini akan terjadi didalam resitration service yang implementasinya seperti ini:

Gambar 8. Implementasi RegistrationService sebelum password policy enforcement
Gambar 8. Implementasi RegistrationService sesudah password policy enforcement

Sesudah implementasi password policy enforcement, maka pada RegistrationService, akan dipanggil validate_password(). validate_password() inilah yang bertanggung jawab untuk memanggil validator yang telah saya definisikan di AUTH_PASSWORD_VALIDATORS pada settings.py. Dengan demikian, aplikasi ini akan menguji password tersebut dengan kelas PasswordPolicyValidator yang telah saya buat sebelumnya. Apabila terdeteksi ada yang melanggar password policy, maka validate_password() akan menghasilkan ValidationError yang akan ditangkap oleh exception untuk memberikan informasi bahwa pembuatan user gagal (success=False) dan akan ditambahkan keterangan error pada form sehingga user mengerti mengapa registrasinya gagal. Namun, apabila validator tidak menemukan pelanggaran terhadap policy, maka user akan dibuat di database dan akan melanjutkan proses selanjutnya di views.py yaitu untuk register (seperti yang tampak pada gambar 6).

Penutup Refleksi

Demikian merupakan refleksi saya untuk Sprint 2 PMPL. Melalui Sprint 2 PMPL ini, saya belajar sebuah hal baru, yaitu validasi password di Django menggunakan django.contrib.auth.password_validation.validate_password. Selain itu, saya juga belajar untuk menulis (untuk refleksi ini) dan melakuan debugging untuk fitur autentikasi seperti pengecekan password ini. Terima kasih atas kesediaannya membaca refleksi ini. Mohon masukan dan saran yang membangun.

-GREG

--

--