You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 22, 2021. It is now read-only.
I recently tried to use Firefox Send to help a customer send us files securely. Because we are careful people, we used a password manager to generate a highly random password with a 64-character length. This password worked great when testing and upload and download of the file through the ffsend web UI. However, when trying to download the file using the CLI tool in an Ubuntu environment, we couldn't get the password to work.
I naively assumed it might be because we included special characters in the password, so we had to ask the client to re-upload the file without special chars in the password. This also did not work.
Then, on a hunch, I looked at the JS code for the front end app and saw this:
The password input field's maxlength attribute is set to 32. However, we were able to paste a 64-char password in just fine without the UI throwing a client-side validation error at us. I suspect the code responsible for password-protecting the file simply throws away any chars after 32. This seems to indeed be the case, because I manually truncated our previously 64 char password down to the first 32 chars, and we were able to download the file as expected.
I think there should be JavaScript-based client-side validation added to this application to tell users in no uncertain terms that 32 characters is the max length on passwords. We were quite obviously not prevented from using a longer password, much to our confusion.
Side note: why only 32 chars? Presumably, the password is being hashed, so wouldn't it be reasonable to expect that the hash of a password would appear be valid to the hash verification library during comparison to user input regardless of the length of the original password? bcrypt seems to support 50-74 bytes, for example. I'm not an expert with crypto libraries, but I suspect it's not unusual these days for users to be generating passwords of all sorts of lengths, and it's really the responsibility of the web UI to communicate what those limitations are.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I recently tried to use Firefox Send to help a customer send us files securely. Because we are careful people, we used a password manager to generate a highly random password with a 64-character length. This password worked great when testing and upload and download of the file through the ffsend web UI. However, when trying to download the file using the CLI tool in an Ubuntu environment, we couldn't get the password to work.
I naively assumed it might be because we included special characters in the password, so we had to ask the client to re-upload the file without special chars in the password. This also did not work.
Then, on a hunch, I looked at the JS code for the front end app and saw this:
https://github.com/mozilla/send/blob/master/app/ui/downloadPassword.js#L35
The password input field's
maxlength
attribute is set to 32. However, we were able to paste a 64-char password in just fine without the UI throwing a client-side validation error at us. I suspect the code responsible for password-protecting the file simply throws away any chars after 32. This seems to indeed be the case, because I manually truncated our previously 64 char password down to the first 32 chars, and we were able to download the file as expected.I think there should be JavaScript-based client-side validation added to this application to tell users in no uncertain terms that 32 characters is the max length on passwords. We were quite obviously not prevented from using a longer password, much to our confusion.
Side note: why only 32 chars? Presumably, the password is being hashed, so wouldn't it be reasonable to expect that the hash of a password would appear be valid to the hash verification library during comparison to user input regardless of the length of the original password? bcrypt seems to support 50-74 bytes, for example. I'm not an expert with crypto libraries, but I suspect it's not unusual these days for users to be generating passwords of all sorts of lengths, and it's really the responsibility of the web UI to communicate what those limitations are.
The text was updated successfully, but these errors were encountered: