The field Notes must be a string with a maximum length of 10000.

[oldrich-s]

Are there any plans on increasing the maximum length? I am importing everything from Lastpass but I cannot import one important note that has ca. 15 000 characters.

PS; The note is is a HTML file which is used to install a digital signature on a new PC.

[kspearrin]

No plans since this is what file attachments are for.

[oldrich-s]

Thanks for the prompt answer 👍 Did not notice this feature was available ;)

[watsoncj]

Consider mentioning attachments in the validation message about notes length.

[valpackett]

An option to just skip these long fields would be nice. Encountered this error, turns out I've had a copy of some old google terms of service (lol) in my 1password export, accidentally saved by a browser extension…

[RealDudePerson]

On the importer It fails and states that "An error has occurred. Ciphers[346]: The field Notes exceeds the maximum encrypted value length of 10000 characters."

Maybe its a confusing name that I created, or maybe its not telling me which entry is over the 10000 character max. It would be very helpful to know which entry the importer choked on that was over 10000 characters.

[kspearrin]

It would be very helpful to know which entry the importer choked on that was over 10000 characters.

Open the CSV file in a spreadsheet program. It's index 346

[luvis]

I'm having this problem with import from 1password as well "An error has occurred. Ciphers[348]: The field Notes exceeds the maximum encrypted value length of 10000 characters."

I have checked through all my passwords and not a single one has any Notes with more than 700 characters. When I check index 348 by opening the .pif file in excel, that specific entry is a short domain name and a password and has no notes.

Please help, where/how do I find the entry?

[valpackett]

@luvis hm — 1pif is lines of JSON, not CSV. Anyway, it's not necessarily notes, it can be any form field. I opened the 1pif file in a text editor and found a very very long line where 1password saved google terms of service as a form field

[RealDudePerson]

@luvis I'm not sure if @myfreeweb is correct in saying that the export is json instead of csv but my fix doesn't apply if (s)he is correct.

My index was 346 in my csv file, but there were a few rows at the top of the csv file with metadata, so the actual row ended up being 349 or 350. I split those notes into two files and it worked flawlessly.

[luvis]

@idiotonuni @myfreeweb Thanks for your suggestions. I followed your suggestions and eventually just removed any entry that was longer than a descently long url.. obviously not 10000 characters.. but I'm guessing the problem was in the 1password export on mac. I created a virtual machine solely for this and installed windows and the windows version of 1password only to export the passwords from there. Voila, no more issues and the import was fine. So if anyone else has problems with importing from 1password, hope it helps..

[flybyray]

No plans since this is what file attachments are for.

But attachments are not imported at all see https://github.com/bitwarden/clients/issues/2814 Currently just 'String' entries are imported: https://github.com/bitwarden/jslib/blob/master/src/importers/keepass2XmlImporter.ts#L54

[Crocmagnon]

Hi there 👋 Somebody is indeed damaged by this limitation: the Bitwarden team. The business model behind Bitwarden Premium includes encrypted file attachments. Notes are for small amounts of text, like a product license key for example. A big "note" of more than 10'000 chars is likely an SSH key or a GPG key. If you use these, you're likely the target of the premium membership (which I found very reasonably priced, and I'm not affiliated with BW). This limitation pushes you in the direction of buying the premium plan.

I do agree though that the error message is not clear and should be improved. Also, fields with more than 10'000 chars could automatically create a text file attachment for users with premium. See bitwarden/web#194

[mprasil]

@Crocmagnon I think the actual issue and reason for the limitation on the field is that these fields are synced to all clients on every sync. This means that every time any client calls the /api/sync endpoint, the server sends all the data for every single password stored. Data transfer is one bottleneck here, the other is that this needs to be decrypted client side. This is already quite a pain - especially on mobile devices.

Attachments on the other hand are only downloaded and decrypted when you try to open them.

I like your suggestion about creating textfile attachment automatically. It is not very straightforward to implement as you'd have to do the import in multiple steps instead of one big json POST that is generated now. This comes with a ton of edge cases that are sometimes tricky due to the fact that everything is client-side encrypted and server usually does not have any information to do something more than dumb data storage service..

[gardner]

That is interesting. So, it is a full download instead of some sort of rsync style reconciliation protocol? Could the entries be hashed and timestamped to send a map of what needs to be synced instead of sending everything?

[mprasil]

I should add that I have experience from working on 3rd party server, so take this with a grain of salt - it might have changed.

But yeah, the sync endpoint just respond with all the items the user has access to.

[tonymet]

why not skip the offending entry?