Password Maximum Length Error message shows wrong length #87
Comments
|
This is expected. The limit is there to stop abuse. Is there a real use case for a password that large? |
|
Did you even read the whole issue? The problem isn't the length limit, it's that the error message is inconsistent with the actual length of the entered password. |
|
I can totally understand the need for a length limit. it just seems that the ACTUAL length limit is hidden |
|
This is because the server has no idea what the original length of the password is. All the server sees is encrypted data, which is larger than the original... |
|
Wouldn't it be possible to just limit the length of the data on the client side before it is even sent to the server? |
|
Client-side validation only is not safe, especially with what we're trying to achieve here. Additionally, encrypted data can be different lengths so there is not an exact length we can relate it to in encrypted form. |
|
i didn't mean client side only, i meant both. Whatever the reasoning, the fact remains that to an end user, entering in a 688 character password and receiving an error about it being over 1000 characters long is weird. |
|
Would this be better?
This error message is very rare. |
|
How about:
|
|
while both of these error messages are technically correct, I don't believe they offer feedback that will actually help the user solve the issue. I'm not sure why this is even an issue. most websites have a hard cap on password length before it is hashed. The other thing I don't understand is the claim that the server doesn't know the length of the encrypted password. If the server had NO IDEA what the length was, the error would either never appear or would always appear. It also is always triggered by a password exactly 688 or more characters. |
|
It looks like this is defined in CypherRequestModel/LoginType. This field also uses the EncryptedString validator which indicates that the format of the encrypted password could change based on the type of encryption used (I'm not sure why so many formats are supported but hey). So in short, the password is encrypted and base-64 encoded along with some metadata needed to decode it (e.g. encryption type, iv, mac)(see here for details), so the encrypted password size really is variable, just in case someone else was curious. But we can estimate it. For aes-mac you have 25 bytes of IV (16 bytes, base-64 encoded, and separator), 45 bytes of mac (sha256, base-64 encoded, and separator), and 2 bytes for type, leaving us at 928 bytes, and since base 64 encoding is ~75% efficient that's about 696 password bytes, but since cbc mode operates in blocks of 16 bytes you have to round down to the nearest 16 byte block size which is, well what do you know, 687 bytes. (The number of characters depends on character encoding.). For RSA encryption type the limit is based on the padding scheme which would limit a 2048 bit key to passwords of at most 242 bytes. I don't know how the different encryption types are selected, or if it's even possible to use a non-mac or rsa encryption type for passwords. That satisfies my curiosity and verifies where the limits come from, but doesn't help answer what the error message should say. If given the option I would prefer to increase the backend limit to 1500 and keep the messaging the same 😆 (1000 password bytes would comfortably fit inside 1500 byte limit for encrypted password + metadata and is a nice round number). But I realize that may not be possible right away so instead I would say something like |
|
i like where this is going, and @infogulch thank you a ton for your response, it was very eye-opening! i feel like we could go farther than that and limit the client side input to 650 characters to avoid error messages entirely (unless text is pasted in the password field) |
|
You do need to be careful not to just truncate text pasted into the password field... that can cause a user to think the entire password is stored, thus locking them out. |
|
So I can't use Bitwarden to store some of my GPG keys!? |
|
It is kind of pointless to display a generic message without at least providing some sort of context of which record needs to be fixed. If I have hundreds of entries in my import file, what am I supposed to do with a generic error like the one above or the password one where it says the limit is 1000 characters for the password field. I understand the technical reasons for it, to an extent, but the UX is just terrible. |
|
I have LastPass "notes" that contain lots of text including ssh keys etc. I would like to use BitWarden and move from LastPass but because I effectively can't migrate any "note" with more than 1000 chars I can switch :( |
|
Running into this as well with trying to import my LastPass items. I use LastPass Secure Notes to store things like environment files, SSH keys, vpn configuration files, gpg keys, recovery codes, and more. |
kubernetes token? ¯_(ツ)_/¯ |
|
I think the problem is that LastPass notes should be imported as a
Bitwarden note and not into a password field.
A secure note by definition should be a last unrestricted field to store
any data. It's not necessarily a password but could be private or security
related data you want to keep safe.
…On Thu, 07 Nov 2019, 15:40 awkwrd, ***@***.***> wrote:
This is expected. The limit is there to stop abuse. Is there a real use
case for a password that large?
kubernetes token? ¯_(ツ)_/¯
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#87?email_source=notifications&email_token=AABTNSU2EYVEQYHDEAFZDQ3QSQLDNA5CNFSM4D5YFWUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDMNXNQ#issuecomment-551082934>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABTNSUHZADGPQXRBCOBR6TQSQLDNANCNFSM4D5YFWUA>
.
|
|
@kspearrin, just what @awkwrd mentioned here, caused me trouble trying to import from 1PW. I had one entry that contained a K8S token with 1270 characters. So there is a real use case for sure :) |
|
This error happened to me while simply importing the csv that I exported from Chrome. I guess I can try to edit the csv to remove long entries, but this certainly shouldn't be expected of a new user just trying to switch. |
|
I mean, I thought it was an obvious use case anyway. If I'm using a password manager, why would I not use the maximum password length available to me on every website? That's basically the entire reason I started using password managers in the first place... |
|
This is weird, bitwarden should help us remember complex passwords, and should not restrict how we set passwords k8s token, gpg, etc. are all very long, it would be weird to restrict them |
|
Prevented me also from switching to bitwarden. Storing PGP keys. Also can't locate Entry based on Error message [X] |
|
cant import passwords from chrome! |
|
Password length limitation of 128ch is limiting in real world scenarios. Other password managers (KeePass, IT Glue even) supports longer passwords, so this is a strange limitation IMHO. I get that longer passwords will create higher workload for encrypt/ decrypt operations.
If not for the free version, maybe extending maximum characters for passwords could be a premium or self hosted feature? Thought I finally had a worthy replacement for KeePass, but not yet I guess. |
|
@o-l-a-v Although I certainly commend you for using the longest and most complex password possible, what scenario are you defending against for which a 128 character complex password is vulnerable to? |
|
I'm just saying it's a stupid limitation that you can not create passwords as long as the maximum length for passwords in BitWarden itself (1000 after encryption), not even Azure AD max length of 260ch. Whether a "only" 128ch long randomized passwords is a security issue, thats a different discussion, but I agree that it's not really a problem in that matter. Should you cap it to 128ch for that reason? No. |
|
I ended up figuring out my problem. There was a token for an Android app that was saved to my google account passwords, that was the long entry on the chrome exported file. |
|
I agree. Present an option for the user to either abort mission, or import passwords with valid length and skip the others. Or increase the 1000ch to support storing tokens, for instance from Microsoft APIs (RefreshToken for instance). |
|
@Gitoffthelawn <https://github.com/Gitoffthelawn> in my experience the
issue arises in two scenarios:
1. When migrating from LastPass their secure "notes" are migrated into
Bitwarden "passwords" and as such a very long note does not fit in a
Bitwarded password field.
This means that for any reasonable user of LastPass, migration to
BitWarden is not possible.
2. Adding ssh keys to Bitwarden is not possible.
Again I can store my ssh keys and ssl certs on LastPass, but not in
Bitwarden so migration is not an option for me :(
…On Tue, 28 Apr 2020 at 14:49, Olav Rønnestad Birkeland < ***@***.***> wrote:
@SergioVJr <https://github.com/SergioVJr>
I agree. Present an option for the user to either abort mission, or import
passwords with valid length and skip the others. Or increase the 1000ch to
support storing tokens, for instance from Microsoft APIs (RefreshToken for
instance).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#87 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABTNSVTO6YF7WN2AZRU4ADRO3GETANCNFSM4D5YFWUA>
.
|
|
@darrenpowers Is it currently possible to store an SSH key or SSL cert in BitWarden either in the Notes section of a login item, or as a Secure Note? |
|
This is starting to diverge into 3 different issues.
|
shatteredsword
changed the title
There is a feature request here from 2018 that I'd encourage users affected by this limit to go vote for. The use-case of storing long tokens (e.g. k8s dashboard) seems perfectly valid to me, and having to resort to file attachments for this purpose feels like a terrible hack for a purely arbitrary length limit that (as mentioned in this and numerous other issues) bites a lot of people. |
|
Adding insult to injury. The fields are being mapped incorrectly. I don't have a password field with 1000 characters and received the message. Could we have a way/option to confirm/map the columns with what is expected from the specific format(Keepass, 1pass, lastpass, etc...) Thank you for all your effort. |
|
See my previous comment on why (technically) the password limit is less than 1000 bytes. In short, the maximum database column size is 1000 bytes, but the password is encrypted and authenticated before it's stored in the column, incurring some overhead, meaning the maximum password size is 687 bytes. |
|
Not being able to store k8s tokens in Bitwarden is a huge pain to me. They used perfectly fit the "password" field in LastPass before I migrated, which caused cryptic errors during the data import. The pain is so significant that I created a StackOverflow question, hoping to find some workaround on the Kubernetes side: https://stackoverflow.com/q/64296300/1818285. If anyone has already come up with something please share your thoughts! Eventually, it’d be really great to see Bitwarden vault supporting slightly longer password fields than now – 1000 symbols (after encryption) is quite an unfortunate cap. Hope that the fix does not imply a change in the whole architecture and is a matter of changing a const and running some kind of DB migration at most. |
|
This limit appears to be completely arbitrary, according to the comment from @kspearrin and the reasoning appears to be based on an invalid assumption that legitimate content does not exceed this limit, and that it's in place to limit "abuse", whatever that might entail. Obviously, based on the many examples here and in other issues, that assumption is very wrong. Can we please just get the limit on password and note fields doubled, that should solve all use-cases that have been reported so far, and it's so trivial a fix, to remove significant pain for users, that I don't understand why this has been ignored for 3 years. |
|
Please bump the limit to double the value. Or at least make it configurable. It is quite a hassle to manage multiple Kubernetes clusters with this limitation. I have to store the token as a note and copy it manually every time. |
|
cannot migrate to bitwarden due to this limitation |
|
I had a large number of passwords saved in a Bitwarden account, lost the password, trying to start a new account with the passwords shared in Firefox, this error occurred. Passwords were all created or managed by Bitwarden before. No reason this error should occur. |
k8s tokens is definitely a good use case, where Bitwarden fails. cc: @kspearrin |
For 2. there is now #1148. |
|
I faced this error because of an entry for the following url. It had a very long JSON entry for the password field. I have no idea why was it but after removing the entry, my password imported successfully.
Such generic message for users is not acceptable. At least on this error, give a report on failed entries to the user so they can be sorted manually. However, the password length should be increased. |
|
I have the same error when trying to store a Kubernetes token, which happens to be 911 characters. |
|
There may be some movement on improving the handling of long passwords/tokens/keys in 1h of this year: https://community.bitwarden.com/t/remove-increase-1000-character-password-field-limit-length/1165/10 |
|
I've deleted all the Notes on the LastPass side after reading a few remarks here and I'm still getting this error message. How can I resolve this issue?
|
|
@wolvmarine What is the length of your password for that login? Encryption increases the length of the string, so if your password is more than about 650 characters, you are probably hitting the 1000 encrypted char limit. If not, then there might be something else going on. |
|
Is there an app I can use to find which passwords are too large that would
be most helpful
…On Sun, Mar 21, 2021, 6:38 PM Thomas Rittson ***@***.***> wrote:
@wolvmarine <https://github.com/wolvmarine> What is the length of your
password for that login? Encryption increases the length of the string, so
if your password is more than about 650 characters, you are probably
hitting the 1000 encrypted char limit. If not, then there might be
something else going on.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#87 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADHKAKCKONALFCRVY5SE343TEZYOBANCNFSM4D5YFWUA>
.
|
|
The error message is telling you that your password for login.xmarks.com is too long. You should have a look at that password, if it's longer than (approximately) 650 characters then you need to make it shorter. If it's not, then there might be some other problem. You can check our help documentation or contact our support team if you'd like someone to step you through it. If you scroll down in the error message prompt, there might be others as well. |
|
Can the limit be moved to 256 instead of 128? |
|
Hi @worldpe , the current limit for password fields is 1000 chars encrypted (approximately 650 chars unencrypted). Where are you hitting a 128 char limit? |
Since this issue was created, we have changed the error message to refer to the encrypted string length and provided more detailed error messages to help users debug their import files. I think this addresses the original bug report, so I'm closing this issue. Where to from here?
|
and others
The Error Message
The issue
This error can be triggered by attempting to save any password that is longer than 687 characters as far as I can tell
Example password that throws the error:
The text was updated successfully, but these errors were encountered: