# Software Engineering - Password Management System - Related Files: https://bwsyncandshare.kit.edu/s/agqLWmiPCTPWSG8 - Password: zP4jmFgNdG ## Initial customer info - [Moodle Customer Discussion](https://elearning.hs-offenburg.de/moodle/mod/forum/view.php?id=230029) > Our current system landscape at HSO Inc. consists of several legacy applications (student admission system, payroll, time management etc.). Each of these has its own user / password / logon functionality. Our long-term goal is to enable all these applications with a centrally managed system. As a first step we do want to build our own password / user manager / access control system: > - It must support fast generation of user accounts and secure passwords, safely store them and evaluate them as part of an access control request. >- Any PMS service (to/from) request must be made available via a programmatic interface. We do NOT require any UI/Browser functionality! >- The PMS must maintain an up to date record of „pwned“ passwords to support checking a password against recently leaked passwords OR initiate service requests to an external „pwned“ database service. > > In case of questions / required clarifications just reply to this message!      ## Schaads Ideas        ## PMS Customer Discussion **Open Questions:** - Will the user sign in at the PMS only and this will authenticate him automatically for all services? - Or will the user sign in to the services individually and those will check the provided credentials through the PMS? - Option maintain leaked passwords records, because more secure okay or other cirteria? - Does it need an externally/remotely available management interface? - Does it need an externally/remotely available configuration interface? - Is there specific criteria for the communication between PMS and service, e.g. in terms of security (special encryption...)? - How can the PMS communicate with other HSO services? What interfaces do these services provide? What interface / interface format need to be supported by the PMS? **Schaads answers:** Dear contractor, based on your questions here is is aggregated feedback from our internal business groups, sorry for the answer to be a bit unstructured, but we are all a bit busy these days at HSO Inc.: * The core idea is that the system should generate passwords according to some rules we can define. * Could we also make sure that the system creates passwords that have not been leaked in the Internet? We think it would also be great to support that we can check a password a user created herself for having been leaked as well as conforming to the policy. * The thing is, our idea is that a user has got severall accounts in different applications and it should be possible to have different policies for each account. * Our users are identified by their email "surname@hsoinc.com", so can the system actually store usernames and passwords as well as maintain which legacy applications a user has access to (e.g. Library, HR, CanteenManagement, StudentAdmission, ...)? * What would be great is to allow our legacy applications to send a username / application-specific password to the PMS and get some kind of access token back. * There should be no fixed length. In fact, we wold like to be able to "dynamically" define attributes such as length or minimum number of special characters, min/max upper lower case, last date of change (policy), next required change. * We think it makes sense to keep all this information in a separate (secure?) data store / structure. * Password generation should be random but according to defined criteria. Passwords should not have been leaked "in the wild". * Batch generation should be also supported (at a minimum in .csv). * And by the way, we like to frequently update our password policy. How do we deal with passwords that have been issued but do not satisfy the policy anymore? * This PMS system should also allow to map a password with a user account and support some basic authentication by a legacy app. * The PMS must also store some kind of application id together with password and user_id. * The PMS should offer some kind of API to receive a username + password form a legacy application and answer with some kind of yes or no. * On average we have about 12000 logons through the applications a days. If we update a password policy we assume that any accounts are updated within 24 hrs. * Just to make sure, we do not need any UI or command line interface - just a bunch of REST/JSON services we can integrate in our existing infrastructure. So you also do not need to take care of any transport layer security. And no, we do not want any of this modern SSO/Kerberos, webtoken, yubikey, JWT stuff. So if a user logs on to an application, the application calls your PWM service and gets a simple yes or no answer whether access should be granted. We know this is not really state of the Art but good enough for us in the "Länd". We strongly prefer that you use an external specialised pwned password service. * To avoid any legal problems also refrain from cloning any existing open-source projects or using any specialised libraries other than for handling in-/outbound service requests or basic data processing such as password hashing (e.g. Argon). But you must use flask in later production. Please note that we use the Python unittest framework. Best, HSO Inc. --- old: - how will the PMS system communicate with the HSO INC systems? - does the system need an UI to allow end-users to view and manage their credentials for different services? - Passwordvault to store all credentials of the individual user? - Single log-in -> System transfers safed/corresponding log-in credentials to legacy-systems --- ## Requirements (NFR and FR) ### Brainstorm current idea  ### Formal table > "I said he's an idiot" > -> Johannes Patrcek - func to delete application? - func to change application? | ID | Type | Description | Related requirements | Unit test id | Comments | | - | - | - | - | - | - | | SR1 | NFR | **System shall manage user accounts** | | | | SR1.1 | FR | A function *user_create* to create accounts has to be provided |SR2.4, SR3.1, SR4.2| test_user_create | | SR1.2 | FR | A function *user_delete* to delete accounts has to be provided | SR2.4| test_user_delete | | SR1.3 | FR | A function *user_update* to update accounts has to be provided |SR2.4, SR4.2 | test_user_update | | SR1.4 | FR | Create function *user_authenticate* to authenticate users for HSO services | | test_user_authenticate | | | | SR1.5 | FR | A function *user_update_password* to let a HSO service change a user password | SR7.1 | test_user_change_password | | SR2 | NFR | **System shall manage access rights of users** | | | | SR2.1 | FR | Store access rights in the user entity (database) | SR5.4 | | | | SR2.2 | FR | Create function *application_add* to add applications that are managed via PMS | |test_application_add | | SR2.3 | FR | Create function *application_check_admin* | | test_application_check_admin |Checks if an user has administration privileges for a given application | | | SR2.4 | FR | Create function *pms_check_admin* | | test_pms_check_admin | Provide a function co check if a user is a pms admin. This is used internally. |SR2.5|FR|Create function *set_application_status*|SR5.5|test_set_application_status|activate or deactivate an application |SR2.6|FR| Create function *set_application_status_check*|SR5.5|test_set_application_status_check|checks if application is activated or deactivated | SR3 | NFR | **System has to generate passwords (single and in batch)** | | | | SR3.1 | FR | Function *password_generate* to generate a single password enforcing the password rules | SR4.4 | test_password_generate | | SR3.2 | FR | Wrapper function *password_generate_batch* to generate password batches out of the single password creator function | SR3.1 |test_password_generate_batch | SR3.3 | FR | Function *password_hash* to generate the hash of a password | | test_password_hash | Argon2id with a minimum configuration of 19 MiB of memory, an iteration count of 2, and 1 degree of parallelism. OWASP Guide PW-Hashing| | SR4 | NFR | **System needs to enforce customizable password policies** | | | | SR4.1 | FR | Create a function *password_policy_set* to set the password policy for a certain application | SR2.3 |test_password_policy_set | | SR4.2 | FR | Create a function *password_policy_check* to check whether a password is valid | SR4.4 |test_password_policy_check| | SR4.3 | FR | Create a wrapper function *password_check_policy_all* to check all passwords | SR4.2 |test_password_check_policy_all | | SR 4.4 | FR | Create a function *password_policy_get* to get the current application password policy | | test_password_policy_get | | SR5 | NFR | **Store data seperately and securely** | | | | SR5.1 | FR | Use a relational database as storage solution | | | | SR5.2 | FR | Store passwords hash in database *password_hash_store* | | test_password_hash_store| | SR5.3 | FR | 3 tables: Applications, Users, Password | | test_database_tables_existing | | SR5.4 | FR | User: user_id, username, access_to, admin_for | | test_user_table_created | | SR5.5 | FR | Application: application_id, application_name, application_enabled | | test_application_table_created | | SR5.6 | FR | Password table combining the application specific password, user_id and application_id | | test_password_table_created | | SR6 | NFR | **Passwords shall be checked if they have been leaked** | | | | SR6.1 | FR | Create a function *password_leak_check* checking a password for a leak | | test_password_leak_check | | SR6.2 | FR | Create a wrapper function *password_leak_check_all* to check all passwords for leaks | SR6.1 | test_password_leak_check_all | Execute regularly through a cronjob | | SR7 | NFR | **System shall be able to handle invalid passwords** | | | | SR7.1 | FR | Create a wrapper function *password_check* to check for policy breaking and leaked passwords | SR4.2, SR6.1 | test_password_check | Invokes check for leaked password and for password policy, e.g. when creating a user | | SR7.2 | FR | Create a function *user_password_reset* to reset the user password and add a new valid password | |test_user_password_reset | !! Meets your requirements, but doesn't follow best practices security guidlines -> fine? (needs to be discussed) | | SR9 | NFR | **System shall be able to handle 12 000 logins a day** | | | | SR9.1 | FR | Add a benchmark to check the system for its performance | |test_benchmark | | SR10 | NFR | **System shall apply password policies changes within 24 hours** | | | | SR10.1 | FR | Create function *passwords_update_all* to create new passwords adhering to the policy | SR7.2, SR10.2|test_passwords_update_all | | SR10.2 | FR | Create a function *password_send* to send newly generated passwords to users | |test_password_send | Security? | SR11 | NFR | **System shall provide its functionality via REST/JSON interface** | | | | SR11.1 | FR | Use flask | | | | SR11.2 | FR | Use unittest framework | | | | SR11.3 | FR | Provide endpoints for public functions | SR1.1, SR1.2, SR1.3, SR1.4, SR2.2, SR4.1 | | ## Technical Architecture Model (Original Drawio File see top of document)  ## User story **Starting scenario:** As a HSO service (who) I want to make an authentication request to the PMS and get an authentication response (what), stating whether access is allowed (why). **Normal flow / control flow:** I want to pass username and password of the user who wants to authenticate himself/herself to the PMS and receive the authentication status - yes or no. **What can go wrong?:** Authentication request timeout **Concurrent activities:** Authentication request happening at the same time as access rights are edited **Expected result:** Receive authentication response ## Use case diagram  ## Tag 1 (06.04.2023): - Diskussion Access Management/Password Management --> wie soll PWM funktionieren? - User loggt sich bei PWM ein -> bekommt Token von System -> kann sich mithilfe von Token im Druckersystem anmelden -> fragt nur ab, ob User bei PWM angemeldet ist und erhält dadurch Zugriff auf System - User loggt sich bei PMW ein -> PWM gibt Authentifizierung zu Druckersystem weiter -> dieses schickt Token an PWM -> schickt Token an User (erteilt Zugriff auf Drucker) -> (Credentials hinterlegt, übermittelt bei Anfrage) - Ausarbeitung von zwei Lösungen oder nur einer verlangt (fragen Kunden welche Lösung er haben möchte oder ob beide präsentiert werden sollen --> The PMS must maintain an up to date record of „pwned“ passwords to support checking a password against recently leaked passwords OR initiate service requests to an external „pwned“ database service)? - Stellen der Fragen für weitere Informationen vom Kunden: Diskussion ob, wie viele Fragen gestellt werden sollen / sollen verschiedene Lösungen dem Kunden vorgestellt werden oder soll von vornerein geklärt werden, was genau der Kunde möchte? - Spezielle Verschlüsselung fürs Passwort, Fehlermeldung bei Eingabe, spezielle Kriterien für Passwort müssen erfüllt sein (Länge, Sonderzeichen, Nummern) ### Was genau soll System machen? - soll Passwörter generieren - Access Roles (wer darf was / welcher Account hat Zugriff auf was?) / password managen - Kunde soll password Kriterien bestimmen können (kein Hardcode) - leaked password check, batch password generation - handle invalid password (after leak check) ### Frage: - Ein username, ein password / ein username, mehrere passwörter? - verschiedene Accounts mit usernames / passwords / ein zentraler Account mit einem Password, aber mit verschiedenen Zugangsberechtigungen? - --> application id mit password und user_id --> Id verknpüfung zu Application / user - username + access -> passwörter separat in Datenbank -> Zuordnungstabelle - Passwort per Application (API, E - Mail) oder per Post verschicken? - wie ändert man PW innerhalb von 24 h? - bekommt Einmalpasswort per Post, muss es dann online ändern (innerhalb von 24 h?)