passwords
passwords copied to clipboard
marius-wieschollek
Encrypted files inside the database
Current Status It is possible to link files from Nextcloud_files.
Feature Description I should be able to load files directly into the passwords-database, so that I am just able to see it there and not inside Nextcloud_files.
Additional context Sometimes I want to store e.g. 2FA Backup Codes or certificates inside the database, that have to be protected very well; I dont want to see them inside my nextcloud_files for security reasons and also because of the risk of deleting or sharing them. Should probably be added after #80 .
@lu4p https://git.mdns.eu/nextcloud/passwords and https://github.com/marius-wieschollek/passwords are the same repository. This here is the official and only way to make feature requests or bug reports.
There are some issues to take into account with this feature. One is the uploading / downloading of files. We can't just send them as part of a password entry since that might easily exceed POST/upload limits configured for the server. Also since passwords are always fetched as whole, adding them directly to the password will slow down the entire app since the files would constantly be downloaded/uploaded. The all passwords section would download all files. Storing files in the server database (MySQL etc.) is also not a good idea. Obviously encrypting/decrypting whole files is also slow on the server & client. I would suggest to circumvent this by creating a "file" entity (which contains only metadata like name, type etc.) that is then linked to the password. Similar to how tags work. Files could then also be attached directly to folders without a password. The api would only return the file entity with passwords and folders and the actual download would be handled in a separate request.
There is also issues with shared passwords. These passwords are usually created in every user account and then synchronized. That would require the files to be synchronized to every user account as well.
That leaves the issues with file storage. There is also issues with the Nextcloud quota system. The file upload in the app should not allow users to bypass quota restrictions. We can probably store files in the users directory and check quota manually. I would also suggest a rather low file size limit, like 4 or 8 MB.
All in all i would be happier if the NC e2ee app would provide an easy way to integrate instead of doing this.
There are some issues to take into account with this feature. One is the uploading / downloading of files. We can't just send them as part of a password entry since that might easily exceed POST/upload limits configured for the server. Also since passwords are always fetched as whole, adding them directly to the password will slow down the entire app since the files would constantly be downloaded/uploaded. The all passwords section would download all files. Storing files in the server database (MySQL etc.) is also not a good idea. Obviously encrypting/decrypting whole files is also slow on the server & client. I would suggest to circumvent this by creating a "file" entity (which contains only metadata like name, type etc.) that is then linked to the password. Similar to how tags work. Files could then also be attached directly to folders without a password. The api would only return the file entity with passwords and folders and the actual download would be handled in a separate request.
There is also issues with shared passwords. These passwords are usually created in every user account and then synchronized. That would require the files to be synchronized to every user account as well.
That leaves the issues with file storage. There is also issues with the Nextcloud quota system. The file upload in the app should not allow users to bypass quota restrictions. We can probably store files in the users directory and check quota manually. I would also suggest a rather low file size limit, like 4 or 8 MB.
All in all i would be happier if the NC e2ee app would provide an easy way to integrate instead of doing this.
Thanks for the explanation.
