For our team we created also a group to store license keys for applications and other stuff. But sometimes license are also files. So this feature would be great to have.
I’d like to store the QR image TOTP apps use to set up accounts for enabling 2FA on shared service-accounts.
Shared accounts are not the best thing to do, but they do exist, and this helps making it shared between a select group of people instead of shared by attackers also.
Hi, I believe this become bigger issue and will be urgent very soon.
Those days almost all users using MFA. In lots of cases we need to store Barcodes for MFA, option to add barcode to user account will be crucial for our and many organisations.
It is essential for us to share Wireguard certificates in order to connect to the VPN along with other credentials.
It is unlikely we will use one software for credentials and another one for certificate files so it is essential for both credentials and files to be supported by Passbolt.
I see it’s 5 years since this first appeared as a requirement, does anyone have any insight in this?
What would be a reasonable file size for such attachment? Basically the main issues with file are the ones related to performance (encryption/decryption speed), configuration compatibility (max request size) and space (network usage, and storage usage). So according to you what should be the maximum file size for one entry? 1MB? More?
ideally Passbolt should give a default size (5-10MB seems reasonable to me) then if a user wants to tweak it to something bigger he should be able via configuration file or web interface but with a big warning regarding performance.
The default size should allow to attach secret files (which are never bigger than some hundreds KB), if one wants to attach PDF files or other documents, as some suggested, a simple external link would be sufficient so that’s not the use case imho.
Passbolt should not become a secure encrypted data storage, it should simply allow to attach small files inherent to authentication/mfa/secrets and these should never be bigger than the default in most cases.
It would be interesting to me to know how these would be stored: inside the db or as encrypted files?
I would suggest to encrypt them and store them as encrypted files outside of the db, in this latter case one would not clutter the db with binary streams, a clear documented procedure to decrypt the files manually in case of disastery recovery would be a plus imho.
It is yet to be decided. Personally I’m inclined to using symmetrically encrypted files (with the key stored in a secret table, like a regular password). In this scenario we would then store the files in DB with an additional cache on file, pretty much like we did for avatar.
This way the files are only accessed from DB when cache is warming up. This facilitate making backups (only one source of data), which we know from experience a lot of people struggle with. Also we don’t have to implement and test multiple file storage configuration and options (as people will want to use S3 buckets, NTFS, etc. for high availability setup).
The disadvantage obviously is more strain on the database.
I think this is workable if the files are small. But it’s up for debate with the team, we will most likely experiment before making a decision.
Finding out that attachments aren’t possible are a big deal breaker to me, as I’ve used it extensively in keepass.
So far I’ve noticed that Passbolt has no offline functionality and you cannot attach files either.
The reason why file attachments are quite important to me is because I keep a digital copy of important documents (e.g. tax / insurance / national ID / my bank’s ITAN listing), along with some other rather critical files such as SSH/Wireguard config packages.
Of course, I could read these out and write an elaborate Description text but this is something that absolutely must be supported in the app itself.
Must have: this is critical for me to have this
Should have: this is important for me to have this
Could have: this could be nice to have
Won’t have: we should not schedule this (explain why)