I’m creating a password manager experiment.
As it’s a prototype, it has a field to register the website, login, and password; that is, one login and password for each website.
In addition, it shows the date the password was created/changed. I’ve included an option for the user to be notified if the password is still valid for 120 days and if they want to change it.
All of this is stored in the cloud.
On another screen, I want to show this password when selecting the website.
Since it’s only for storing data like login and password and displaying this information, there will always be risks of identity theft, but is there a way to avoid this?
I thought about a cryptographic extension where, when requesting login and password, it would come encrypted and a key would decrypt the message.
If this is more than a learning experiment, you should not build your own password manager.
It doesn’t matter whether the frontend is built with App Inventor, native Android, or anything else—the hard part is security architecture, not UI.
A password manager is one of the most difficult types of applications to implement securely.
The real problem is not the frontend
The security risks depend entirely on:
How the backend/cloud storage is implemented
Where the encryption happens
How the keys are generated and stored
How the master password is handled
Most prototype implementations fail because:
Encryption is added after the design instead of being the design
The encryption key is stored together with the data
No proper key derivation is used
The server can still access plaintext data
If any of those happen, encryption becomes almost useless.
The biggest misconception
“If I encrypt login and password before storing them in the cloud, it should be safe.”
Only if:
Encryption happens locally on the device
The key is derived from a master password
The key is never stored in the cloud
A proper KDF is used (Argon2 or PBKDF2)
A modern authenticated encryption mode is used (AES-GCM or ChaCha20-Poly1305)
Most experiments fail at #2 and #3.
What real password managers do
Professional tools like:
Bitwarden
KeePass
use a zero-knowledge architecture:
The server never sees plaintext passwords
The server never sees encryption keys
All encryption happens locally
The master password is never transmitted
Even experienced security engineers treat this as high-risk software.
If this is a learning project
Then it’s totally fine—but:
Do not store real passwords
Clearly label the app as insecure
Treat it as a cryptography experiment
Minimum baseline (still not production-safe)
If you want to make the prototype less unsafe:
Add a master password
Derive a key using Argon2 or PBKDF2
Encrypt locally using AES-GCM
Store only ciphertext in the cloud
Assume the database will leak
Never store the encryption key remotely
Even with all of this, it’s still not production-grade security.
Bottom line:
The frontend technology (including App Inventor) is not the core issue.
The real difficulty is designing a correct cryptographic and key-management architecture—and that’s where most custom password managers fail.