Mistakenly changing/corrupting the password.txt file will mean that you can no longer enter the application

[nus-pe-bot]

Accidentally corrupting/editing the password.txt file unintentionally would be disastrous as now the user need to reset all the data inside VBook. This means that the user will lose all his/her data.

---

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

[anselmlong]

Team's Response

Hi, thank you for your feedback and for raising this concern!

While it might initially seem like a flaw, this behaviour is a deliberate part of our security features and aligns with best practices for applications prioritising user data privacy.

1. The Security-User Experience Trade-Off

• This design prioritises security over convenience, a common trade-off in modern secure systems. By linking the password.txt file (containing the hash and salt) directly to the user's ability to access their data, we ensure:

  1. Data confidentiality: Only the user with the correct password can access their data.
  2. Tamper-proofing: If the password.txt is altered, the data becomes inaccessible, maintaining the integrity of the application.
• This approach is widely used in applications where security is paramount, such as encrypted vaults or password managers. For example:
  • Snapchat's "My Eyes Only" feature: If a user forgets their passcode, Snapchat explicitly states that the content is irretrievable, even by their support team. (source)
  • Apple’s FileVault: Losing your recovery key means data recovery is impossible. (source)

2. Risk Mitigation: User Warnings

• To address potential user errors, we have already included explicit warnings in our User Guide about the importance of safeguarding the password.txt file and avoiding tampering with it.
  • Please refer to the "Caution" section in the User Guide, as highlighted in the screenshot below:

3. The Realistic Likelihood of Tampering

• From a user perspective, it is extremely rare for users to unintentionally tamper with their own password.txt file. Our design assumes that users will exercise basic caution, as tampering with or corrupting critical security files is not typical user behaviour.
• For advanced users, the legitimate way to store the hash would be in a database, but the module constraint prohibits the use of a database. Storing the hash locally in password.txt is the best alternative while adhering to the project constraints.

4. Conclusion: Security Takes Priority

• Similar to real-world encrypted systems, our application is designed such that losing or tampering with critical security files renders data irretrievable. This ensures the data remains secure from unauthourised access even in edge cases.
• We encourage users to safeguard the password.txt file similar to how they would safe-keep a master password or recovery key in any other security-conscious application.

We hope this clarifies why this behaviour is a feature and not a bug. Thank you!

Duplicate status (if any):

--