Forgetting password is disastrous for the user

[nus-se-script]

I believe that the application is missing a feature to reset password, although it is not shown inside the future enhancements section inside the DG.

The reset password feature is essential because forgetting passwords is a very common phenomenon in any application that has authentication. However, not having a feature to handle this common phenonmenon of forgetting password might render the application almost unusable as the data will be constantly reset each time the user forgets the password.

recommendations: Do consider adding customisable personal security questions for users to answer during password creation, so as to help users reset password in future. Hence, user can only reset password when they have answered the right security questions which will make it less disastrous for the user.

---

_{[original: nus-cs2103-AY2425S1/pe-interim#1340] [original labels: severity.Medium type.FeatureFlaw]}

[anselmlong]

Team's Response

Thanks for your bug submission! However, this is not in scope and thus, not under our planned enhancements due to the following reasons:

Not Feasible for Local Applications
The password reset feature is indeed an important convenience for most applications with authentication. However, in the context of a local-only application like ours (where no external servers or databases are used due to the no-DBMS constraint), implementing a secure and reliable password reset mechanism is inherently challenging. Without a central authority to verify identity or reset credentials, any local reset mechanism (e.g., security questions or backup keys) would be susceptible to tampering or brute-forcing.

Case Study: Snapchat My Eyes Only (source) Snapchat's "My Eyes Only" feature adopts a similar stance. If users forget their passcode, Snapchat explicitly warns that the data stored in "My Eyes Only" will be irretrievable. This design ensures that even Snapchat cannot access this data without the correct passcode. This makes the data secure but introduces the trade-off of data loss if the user forgets their credentials.

Case Study: Apple's FileVault (source) Apple's FileVault, which protects sensitive data, operates on a principle where losing the associated passcode or recovery key makes it impossible to access encrypted data. Apple chooses this path to ensure no external party, not even Apple, can compromise user data.

Challenges of Security Questions for Local Apps
Security questions might seem like a feasible alternative, but they introduce significant vulnerabilities in a local-only context. Since the application and its data reside entirely on the user's device, the security questions and answers would also need to be stored locally, making them prone to tampering or theft if the device is compromised. This undermines the very purpose of secure authentication.

Why This is Not Under Planned Enhancements

Given the constraints and design goals of this application:

1. Security Prioritisation: Allowing password reset mechanisms locally would compromise the application's security. Without a centralised server for authentication or encrypted storage, such features cannot be implemented securely.

2. Transparency in Design: The User Guide already cautions users about the importance of safeguarding the password.txt file and the risks associated with tampering or losing access to it. This aligns with practices adopted by platforms prioritising privacy.

3. Scope and Trade-offs: Addressing this challenge would require deviating from the current no-DBMS constraint. Additionally, implementing server-based features for password recovery is beyond the scope of this project.

Thus, the absence of a password reset feature is not a flaw but a deliberate design decision due to the limitations of local-only architectures and a commitment to user data security.

Thank you!

Duplicate status (if any):

--