I was moving entries from Keepass to Bitwarden, but I couldn’t insert my SSH encryption key (4096 characters) because the limit for the password field is 1000 characters, and custom fields cannot have >1000 either, so I have to store it in the Notes section.
I’ve since reencrypted my SSH keys using 687 character passwords (it seems I can’t even get 1000 characters), but it would be preferable to not have such restrictions. I’d be fine with having this restriction only applying to the free version if space is a concern.
On another note, why can’t I get to 1000 characters? 688 is the real limit. I’ve even tried only using a-zA-Z characters just to make sure it wasn’t having to escape any special characters, and I still can’t get past 687 characters.
We would also like to see character limits increased to double what they currently are. File attachments are not very usable or searchable, so they are not a good option. Secure notes in particular would be nice to have a 20000 character limit?
This was a problem when I tried to migrate from Chrome by importing the csv file it generates, as it simply gave an error and cancelled the action. I had to manually edit the csv and look for the problem, since the manager didn’t even bother to tell me what entry was exceeding it, and it didn’t let me just ignore it and import the rest (it was a token that an Android app stored). Either way, it wouldn’t have been a problem if the limit was higher.
This feature request was recently linked on this github issue (it had diverged from the original issue to this). You can see other use cases that require a higher limit listed there, such as k8s tokens and ssh keys.
I am currently doing a PoC for my organization and ran into this. This is a deal breaker. Could you please be more specific about when and what you are going to implement? I don’t have a strict deadline of implementation but I would need some assurances in order to keep considering Bitwarden as a solution.
If the custom fields are handled the same as the password field then I just wonder why you don’t allow longer secrets in the password field. This is not an edge case for businesses! We as an Enterprise have hundreds of secrets which would need to make use of this workaround. I don’t consider this a solution as it introduces inconsistencies and I don’t even think this is practicable as a workaround. We have thousands of secrets which we would like to migrate from dozens of Azure key vaults to Bitwarden. We need a history for those secrets as well! We also want to automate some processes and having some secrets in another field than the password field is not going to work for us.
@tgreer I want to second @Xentrax’s request. Just increasing the limit for custom fields (and not the password field) will not work for us. We have Kubernetes Dashboard secrets with a length of I think ~1500 chars which have to be stored in the password field in order to get them auto-filled.
You should still be able to use autofill with the custom field so long as you name-match it. See:
Auto-fill Custom Fields
The Name specified for a custom field is critical to successfully setting up auto-fill for custom fields. When naming the custom field, you should use one of the following HTML form element attributes/values:
HTML form element’s id attribute.
HTML form element’s name attribute.
HTML form element’s corresponding label value.
HTML form element’s aria-label attribute.
HTML form element’s placeholder attribute.
Bitwarden will search the matched-URI webpage for those HTML form element attributes/values in the above priority-order. If a custom field’s name matches one of those attributes/values, auto-fill will be available into that HTML form element.
But I agree this feels like an unnecessary palaver. The new higher limit should apply to all fields.
Thanks, @Thames. I wasn’t aware of that. That would be at least a workaround.
Although I feel the same as you that this is not as comfortable as having the password field with the increased limit.