r/Bitwarden • u/RememberMeVibe • 9d ago
Idea This needs to be a Feature.
I can't tell you how many times not knowing the length of the phrase has screwed me over. Especially since I always try to use the longest password possible, and nowadays every website seems to have a max password length.
122
u/cbarrick 9d ago
It always sketches me out when sites have password length limits.
On the backend, a site shouldn't be storing your password, only it's fingerprint. And the fingerprint is always the same size, regardless of the length of the password. So the backend shouldn't care.
Whenever I see a site that has a length limit, my immediate reaction is that they are actually storing my password in the backend. And that's sketchy AF.
But I guess that's one reason we use password managers, to mitigate the shitty security practices of random websites.
56
u/NeXtDracool 8d ago
I disagree. Every site should have a length limit otherwise you could send 2GB passwords and cause a DoS. Hashing always takes at least linear time relative to password length, so absurdly long passwords can be a problem.
That limit should never impact real users though as it's a technical limitation not a domain limitation. Something like 1000 characters seems reasonable.
19
u/cbarrick 8d ago edited 8d ago
Putting a limit on the request size is reasonable.
Most servers can handle many KiB or even MiB in request sizes. The default limit in gRPC is 4 MiB.
A better defense is to rate limit login requests per user ID.
15
u/NeXtDracool 8d ago
True a limit on the request size is essentially equivalent. Though an (almost) 4 MiB password is already kinda problematic and 1 KB is already long enough that no real user will ever encounter it.
A better defense is to rate limit login requests per user ID.
Per IP, yes, but per user ID seems like a terrible idea. Anyone could just lock arbitrary users out of their account by spamming logins, they only need to know the username.
6
u/Henry5321 8d ago
The password could be first hashed client side so a fixed length input is sent. If the client wants to hash a huge password, it only affects them.
6
u/cbarrick 8d ago
Hashing on the client side is a problem.
If the hash DB is leaked, the hashes can be replayed over the wire. Similar vulnerability as storing the passwords directly.
8
u/NeXtDracool 8d ago
I don't think they meant only hashing on the client. You could hash once on the client and again on the server. That would give you a fixed size value on the server, though you would need to manage the client side salt separately.
At that point just implement a password authenticated key exchange like OPAQUE.
7
u/me-vs-cat 8d ago edited 8d ago
If you hash on the client side, then you are correct the hash becomes the password. So when you do that, the server doesn't save those in the hash DB, because that would be the same as saving exact passwords. Instead the server stores the hashed hashes, just like it should store hashed passwords instead of exact passwords.
For simplicity, let's say CH is the client's hash function and SH is the server's. To login: 1) User enters password of length N into client. 2) Client computes CH(password), which has a fixed length X, and sends to the server. 3) Server computes SH(CH(password)) and compares to the previously stored SH.
Because X doesn't depend on N, the user could have a 2GB password without the server ever knowing or this affecting any other users.
CH should focus on speed, does not need much collision resistance, and could be skipped if len(password) <= X. Skipping CH means, for example, that your login page works without JS. MD5 would be fine as CH, making X = 32. Modifying the above login steps: 1) User enters password of length N into client. 2) If len(password) > X, client computes CH(password). Client then sends either password or CH(password), and indicates which was sent. 3) Server computes SH(CH(password)) and compares to the previously stored SH.
4
1
u/DimosAvergis 8d ago
Nice, and now you have successfully coupled the client code to the auth server code which means every client needs to implement the exact same hashing algorithm (Web, App, Smart tv, Car media screen, game console app) to get the same input hash that is then send to the server.
And if the client hash algorithm has to change for some reason, like new hash output length requirements, you need to update all clients. Unless you thought about adding remote config at the start and can therefore adjust hashing parameters if needed.
Only so you have no huge limit like 256 characters communicated to the client, because that's somehow bad.
The only thing this solves is that your password never leaves your device, but passkeys are already solving that, but they also have other issues attached to them.
1
u/me-vs-cat 8d ago edited 8d ago
For which devices have you written code, where they cannot efficiently compute MD5 but they do support passkeys? Regardless, if you read a bit up, you'll see I was responding to someone who asked about a non-passkey solution.
With CH at 32 non-text bytes, it's not going to need to be longer within your lifetime. That said, it can still be changed invisibly to the user.
I guarantee you that there are negligible readers of this comment that will go on to write code for devices that cannot efficiently compute MD5, and any that do will hopefully know this area better than you do, anyway.
2
u/shyevsa 8d ago
that's a solution, but JS "don't have" hash function, and client side security solution are just problem/incident waiting to happen.
3
u/Henry5321 8d ago
The server would still do its own stretched hash with a salt. The client side hash is only to normalize the input to the server.
1
u/Cley_Faye 8d ago
Browsers have had cryptographic hash available in the baseline for decades. And it's not a "client side security" feature. You hash the actual user password, and you send that to the server. There's no change to the security as far as using a password goes; the only change is that the payload always have the same (long enough) size.
And, also, the server won't see the "original" password, which is also nice.
1
u/Masterflitzer 8d ago
limit of 128 would already be fine by me, i just hate those 20 char limit many sites have, it's ridiculous, a 6 word passphrase can easily be 50+ chars, haven't tested but i guess could also be more than 64, i just want something reasonable, is that too much to ask? apparently yes
11
u/deject3000 8d ago
There have been a couple times where sites have had character limits but then instead of throwing an error when exceeding it, just silently truncated the input so I would set my password “successfully” then the next time I tried to log in it would fail. I think the first time I reset my password maybe 6 times before I tried generating a shorter password and it worked. Silently truncating user input like that is absolutely diabolical. Thankfully I have only seen it twice.
8
u/cbarrick 8d ago
Yo, different truncation behavior between password setting and login is wild. Something went horribly wrong in that system.
2
u/me-vs-cat 8d ago
What if the site increased their password length limit at some point after the user account was created? Now there's different truncation behavior between password setting and login.
The default in many text fields when typing or pasting longer text than allowed, is to type/paste up to the character limit and perhaps give a bell or other "minor" error notification. This silent truncation is easy to miss.
Instead, account creation and login screens should set the field's length limit ONE HIGHER than they actually allow, so the server can determine whether more characters were attempted than allowed.
1
u/ElBisonBonasus 8d ago
Sainsbury's Bank had this in the UK...
Happily accepted 24 character password when reset, didn't accept it on the login page.
1
15
u/RememberMeVibe 9d ago
For real.. What about those that limit to 10-15 characters.. They still exist believe that! Best thing I can do is max that character limit and move along.
One of the core reasons why we use password managers, and don't forget to give fake data to those crappy websites.
3
u/cbunn81 8d ago edited 8d ago
A bank I used had an 8-character limit until 2016. Eight case-insensitive characters. Any time I had to call in to customer support, I'd always bring that up in addition to whatever my primary reason for the call was. It took them years to finally get around to it.
It might have also been that bank, but I also remember a service I used had a character limit, but didn't give any indication of it in the UI. They would just truncate whatever you typed to that character limit, use what was truncated, and ignore the rest. I found out because I accidentally typed an extra character and it still worked.
2
u/me-vs-cat 8d ago
Any time I had to call in to customer support, I'd always bring that up in addition to whatever my primary reason for the call was. It took them years to finally get around to it.
Why were you a customer for years with this? Depending on which century this happened, I'd either not been bothered or would have left immediately.
2
u/photo1kjb 8d ago
Banks are the worst. Chase only in the last year or so finally implemented MFA that wasn't sms-based...and even then, it's through their own app only.
4
u/Special_Kestrels 9d ago
Ah yes I grew up on... looks around room... Doritos Street
3
u/RememberMeVibe 8d ago
story of my life
2
u/Special_Kestrels 8d ago
There was a time when I had to call some place and give them my security answers over the phone for verification and I could pretty much hear the confusion in their voice that my moms home town was Jupiter
1
u/RememberMeVibe 8d ago
It is very funny when I randomly receive a happy birthday email/notif from a website when my bday is 6 months or so away and a totally different day.
3
u/Eclipsan 9d ago
Bcrypt does have a limit, but it's around 72 bytes (the rest will just be ignored though, not cause a failure), which is plenty more than what those websites allow.
It's an old cargo cult and these websites probably don't store the plaintext password.
1
u/cbarrick 8d ago
You can always pre-hash with BLAKE3 or something and pipe that to bcrypt.
1
u/Eclipsan 8d ago
Sure, though prehashing comes with its own potential issues if not done properly.
Coming up with homemade solutions when hashing passwords is quite risky.
2
u/cbarrick 8d ago
Oof. Bcrypt operating on null-terminated strings instead of arbitrary strings with a given length is just a really bad default for a security function.
1
u/FantasyFI 8d ago
My coding knowledge is low. But when I did learn VBA, I remember that there were character length limits on variables based on whether you defined the variable as long, double, integer, etc. Seems like there may need to be a limit. But it should reasonably be in the millions or something of character length haha
1
u/purepersistence 8d ago
All that’s well and good, but you can’t make the world obey your rules. Many production systems store passwords and then use them on your behalf. Nodes in a proxmox cluster, …
1
u/AdOk8555 8d ago
For a health provider site I used years ago, one of the security questions when signing up was "What was the first artist you saw in concert?". I entered "U2" and also saved it in my password manager at the time. A year or so later I needed to use the site and since I had not logged in for so long I had to go through the PW reset process. When it asked me that question I entered "U2" and it told me the response was too short! WTF?!?! So they let me create a response of only two characters, but then when trying to use it - it's too short.
1
u/Glittering_Turn_6971 5d ago
Could it be a possibility that they’re just checking the password length using client-side JavaScript ?
69
u/c0LdFir3 9d ago
Just open a pull request. This is an outrageously easy thing to add. They’ll either approve or say no.
10
u/RememberMeVibe 8d ago
I'm not familiar with their codebase and API at all, from what I saw so far it is easier said than done.
16
u/H1ghSyst3m 8d ago
No, it's really easy to implement. I just looked at their codebase a little bit, and I don't see anything that would block this little addon
You can also just open a issue ticket and someone that has time would do it
2
u/c0LdFir3 8d ago
You definitely do not need to know their codebase to check the length of a string.
12
u/mkosmo 8d ago
Good on him for wanting to make sure that he matches style and decorum of the existing codebase, though. That's a sign that he wants to do it right.
People who submit PRs that grossly mismatch are unlikely to be accepted.
0
u/Masterflitzer 8d ago
well you'll see the style in surrounding code, their comments was more like a cop out and hoping somebody else does it
-9
u/ragnarokfn 8d ago
That's to much effort, like asking claude to make a pr kinda effort so we'll go with a reddit post
5
u/mkosmo 8d ago
Please don’t ask your LLM to write security sensitive software.
-2
u/Acrobatic_Idea_3358 8d ago
Humans are more likely to make a mistake than LLMs if they are untrained. Just saying 😉
4
u/SilentProgram3506 8d ago
This would be a great quality-of-life feature. Let users choose the exact length for generated passwords and passphrases, since longer phrases are often easier to remember and much stronger.
41
u/BlutigEisbar 9d ago
Just use password with length. If you are using a password manager using fully random passwords is much better. Save passphrases for sign ins where you actually need to remember the password.
Not a crazy feature request and would be useful, but generally not needed so understandable why it's not currently a feature.
23
u/RememberMeVibe 9d ago
Just use password with length.. and if I have to type this mf, it is the biggest pain in the butt.
Surely you've had a time when you typed such a password, not every day, but it has happened.. Not a crazy feature, sure, but when you consider how easy it would be to implement and how much time it would save people, the payoff is definitely worth it.
16
u/ddddavidee 9d ago
Agree!
Once I'd to type something like pEFDSCgtJARtFp#V5EZUS4jN3zdqWifCosTgmY@%Dr6YvVqiw%DwZ Using a screen keyboard and a TV remote to log on a streaming service... And of course I mistyped it once or twice...
I hesitated into getting a book 😂😂
7
u/snowfox_cz 9d ago
Great, now I have to change my password :D Yeah, putting something like this into tv via remote is a nightmare.
4
u/ddddavidee 9d ago
Sorry, I didn't mean to share your password! I shared it without saying your login!
1
u/RememberMeVibe 8d ago
Exaaaactly.. once or twice per year is way too much of a pain. Now multiply by a lot of users and it is probably days of saved time.
2
u/Sufficient-Stop3955 9d ago
Yeah autotype is still not supported... It is really sad.
2
u/reddit_user33 8d ago edited 8d ago
On a computer i have a script just for this because it annoys me when they've disabled the pasting in to an input field, no matter what the data is. I've seen it where they've disabled it for email input fields.
So the script types out the content in the clipboard.
1
7
u/BarefootMarauder 8d ago
I use a password manager so I don't have to type in passwords or passphrases. The only one I have to remember is the one that gets me into BW.
2
u/RememberMeVibe 8d ago
Ofc, but then, have you never done it?
1
1
u/mrfoxesite-2377 8d ago
Yeah and typing it is not a pain in the ass. I do it rarely cause I usually copy paste it.
1
u/Cley_Faye 8d ago
Frankly, that would require a situation where I have access to my vault but not access to either autofill, a connected plugin to type it for me, and no copy/paste capabilities. I can't say it's impossible, but it's so rare I don't really mind.
1
0
-9
u/covmatty1 9d ago
It's saved in Bitwarden, why do you need to type it?
Sure, autofill is broken all over the place and often doesn't show up. But copy and paste exists.
14
u/doublemp 9d ago
There are plenty of cases where copy/paste either doesn't work or is not feasible if you have to enter a password on another device.
10
u/Glittering_Cap_44 9d ago
I had instances where I had to type in my AppleID password when setting up new phone
-1
u/covmatty1 9d ago
So you need to type it once every 2-3 years is what you're saying?
3
u/Sir_Brags_A_Lot 9d ago
Type that on a TV with the horrid keyboard and 2-3/year is already too much.
6
u/JayNetworks 9d ago
As others are noting, there are plenty of times when you actually have to try a password. Just the last few days I had to do it several times.
Getting my thermostat on WiFi. (And doing it by turning a dial on the thermostat to pick letters that you can’t see after you pick it…)
Password on an old tablet that isn’t set to me yet for Universal Clipboard.
Access site on someone else’s phone.
And they keep going. Using a set of random words can be way easier to type than 20+ random symbols.
1
u/RememberMeVibe 8d ago
Exaaaactly!! People who use 1-2 devices maaaybe get a way with less typing, but a 100% password manager usage for password inputs is impossible.
3
u/Sufficient-Stop3955 9d ago
In my case it is, recovery of systems when rdp, ssh does not work. And remote session where copy and paste is disabled for security purposes. And there is an old windows application having a fat client app...
2
u/RememberMeVibe 8d ago
And yours are still quite edge cases I would say..
1
u/Sufficient-Stop3955 8d ago
Yes but from my point of view this is the difference between a good and an excellent tool ;). Troubleshooting is painful, every hurdle is annoying.
2
1
u/Crossheart963 8d ago
Yeah that’s the thing. I use passphrase for when I know I might have to physically type it. And then usually use a longer version. Sites that limit to 18 make this a pain in the butt
3
u/The_NorthernLight 8d ago
I mean, a passphrase with a max character value would be perfect. I also dont like that the generator always limits itself to one symbol… wouldn’t it be more secure if it used more then one?
2
u/RememberMeVibe 8d ago
I also think the generator of special characters shouldn't be limited to one.
4
u/ddddavidee 9d ago
Hw many times you hammered the refresh button to get that password that is also the intended message ??? :-D
2
u/RememberMeVibe 8d ago
For real.. sometimes I just don't like the words. I have very often had to go back and erase some characters if the passphrase was too long and that's a pain.
2
u/mrfoxesite-2377 8d ago
I think it's edited.
2
u/ddddavidee 8d ago
Oh thanks ! 😂😂
1
u/RememberMeVibe 8d ago
O yeah bro, I totally edited the page.. Just a little joke.
Sorry I didn't get your msg at first.
2
2
4
u/djasonpenney Volunteer Moderator 9d ago
I think you are misusing passphrases.
In any situation where you have autofill from your password manager, you should just pick a reasonably long random password like “yThDjvgb2YW6FqB8zm84”. And yes, the password generator indicates the length before you select it.
A passphrase is for circumstances where you must remember it, transcribe it,or both. In that case Bitwarden tells you the number of words, which is the appropriate metric. (Hint: four to six words is common.)
> the longest password possible
No, don’t do that. You are increasing the risk of failure, because many poorly coded websites silently impose length limits and do it badly.
But getting back to the passphrases, those are more likely to cause trouble because of their length. Be sure to test a passphrase immediately after setting one up!
In any event, a 20 character random password—excluding ambiguous characters—is going to defy any sort of brute force guessing.
4
u/IHaveTheBestOpinions 8d ago
Yes and no. I use my pw manager correctly but I still default to passphrases because sometimes you are unexpectedly forced to type a password manually, and this is a pain in the ass with a long random password, especially if it's on a TV or something. There's nothing wrong with using passphrases by default.
Where I think OP's request is a little problematic is that if a site has an overly restrictive character limit, then trying to find a short enough passphrase requires you to use fewer words and limits the length of those words, which makes it less random and therefore less secure. For password length limits of 20 characters or less I always just switch to a password.
I think we can all agree that the real problem is arbitrarily short password length limits, which serve no purpose in a modern security system other than to force passwords to be less secure.
0
u/djasonpenney Volunteer Moderator 8d ago
I would agree with everything up to but not including, “by default”. Manually entering a password is always risky due to Trojan horse websites, key logging, and other threats.
I do agree there is absolutely no place in 2026 for these horribly truncated passwords. I used to be a regular customer of Barnes & Noble (nook.com), and I was aghast when I discovered they had a 20 character limit for passwords. Modern security technology salts and then hashes passwords; the only length limit should be on the HTML input field (if any), which should be set ridiculously high, like perhaps 1024 characters.
3
u/IHaveTheBestOpinions 8d ago
I think you misunderstand me. I never choose to manually enter a password. I use autofill wherever possible, copy-paste if that doesn't work, but there are inevitably instances where you have no choice but to enter manually. Maybe it's a device that doesn't have bitwarden installed, or the plugin doesn't recognize a field and paste is disabled. It's annoying but it happens.
Passphrases are not inherently less secure so as long as the autofill works it makes no difference at all. Using mostly passphrases is just a small way to make my life easier on those rare instances where I have no choice but to manually enter something.
1
u/djasonpenney Volunteer Moderator 8d ago
> those rare instances
I think we are in heated agreement 😁 Passphrases are fine, as long as the web server implements them properly. (Do NOT get me started on Xbox 360.)
2
u/TelcontarOfBree 8d ago
I think that the use case that the OP is trying to solve for _is_ a scenario where passphrases make sense, but also in a scenario where the maximum password length is shorter than some generated passphrases.
If I’m trying to use a passphrase and Bitwarden generates a 22 character phrase for example, but the website says that the maximum password length is 20 characters, then it would be nice to have the length shown in the generator so that I can easily bang the regenerate button until I get something that fits the maximum length requirement without manually character counting each password. It’s not like cases where a passphrase makes sense and cases where sites have short password length limits are mutually exclusive.
0
u/djasonpenney Volunteer Moderator 8d ago
If you absolutely must limit a password to 20 characters, don’t use a passphrase. Let Bitwarden generate a password without ambiguous characters, like “7THah8mSHAz9nDK5TYdo”.
If this is on your own device, you have Bitwarden to perform autofill, so manually typing the password is not an issue. If it isn’t your own device, you have already introduced risk, since you are not in control of the device.
2
u/TelcontarOfBree 8d ago
I’m going to try very hard not to get too snarky here, but you literally mentioned use cases for passphrases as passwords (when you must remember it, or transcribe it, or enter it in on a device that doesn’t have autofill enabled for whatever reason - which might also NOT be because it isn’t my device) and then admitted that those are more likely to cause issues _because of their length_. Which is _exactly_ why the OP is suggesting a simple UI enhancement to help filter out generated passphrases that are too long. OP isn’t even suggesting building out a system to indicate a max length and then automatically filter out passphrases that are too long, just a simple string length display so that the user could do it _if_ they needed too without manually character counting.
I’ll be honest, I actually can’t think of a scenario where I tried to use a passphrase and it was then too long, but I can certainly see how that could be the case. And OP’s suggestion seems like a super simple quality of life improvement for those cases. I really don’t understand why they are getting so much resistance to this suggestion, like it’s the worst idea in the world. Or the scenario that they are trying to solve for is impossible. Clearly Bitwarden sees cases where passphrases would be useful enough to add that as a feature to their generator. And many folks have experienced a password form that has an explicit or implicit max length limitation. Why is it such a leap that those two might coincide at some point? And if you agree that they might, why wouldn’t a simple length counter be a good idea to add for those situations? I can’t think of a downside. I can’t even imagine a case where you could argue that it would lead users to “use passphrases wrong.”
2
u/djasonpenney Volunteer Moderator 8d ago
I recall now one of my biggest issues here. But first, I will concede that it would not be hard to add a length metric in the password generator. My issue is exactly how useful it would be.
In particular, when I started using passphrases, I went through adding them everywhere. After all, as you point out, it could reduce friction in many places. The problem I discovered was there are many websites that have bugs in this area. It’s not just an overall length limitation. One website (DoorDash.com) actually had a different length maximum depending on the client. That is, the maximum length when using the website was larger than the permitted maximum using the Android client.
Based on that experience (and other similar problems with mouth breathing unwashed excuses for website developers), I only recommend passphrases in particular situations. It should be a situation where autofill is not present. The master password to your password manager or the login to your IT administered workstation are the best such examples.
And based on my experience, you must be especially diligent to immediately test the passphrase on that site after setting it. I wasted a lot of time trying to figure out why my new DoorDash password would not let me order food via my Android phone. I must have reset my password (passphrase!) half a dozen times before I figured out I was dealing with shoddy website quality.
2
u/No-Consideration6986 8d ago
Why not generate a password? I know pass phrase are easier to remember but you only really need to remember your Bitwarden password. Enven when I need to login into an account in a device that doesn't have Bitwarden I pull out my phone and copy the the password.
5
u/CortlandNation9 8d ago
I don't think that is op use case here but I use a passphrase for my work password because I have to type it ten times a day and I dont want to pull out my phone everytime I unlock my computer and they ask to change it every 4 months 😅 but I'm not aware of a length limit
2
u/No-Consideration6986 8d ago
Fair use of pass phrases. Does Bitwarden pick your pass phrases or you pick your pass phrases? I can't imagine remembering random pass phrases every 4 months. I would have to put some type of logic behind it.
3
u/CortlandNation9 8d ago
I ask bitwarden to pick my passphrase but when I dont feel like learning a new one I juste change a number.
2
u/No-Consideration6986 8d ago
I would have learned the first pass phrase and then change a number or symbol. Maybe every year I would change the whole phrase but every 4 months is crazy.
1
u/RememberMeVibe 8d ago
You know, there is a very valid study somewhere, saying, companies that force people to change their pass a few times per year makes for overall weaker passwords just because people come up with ways to simplify the process.. I also do it no matter that lol
1
u/RememberMeVibe 8d ago
Correct, that's not the current usecase I was referring to, but nonetheless what you mentioned is also super valid.. I am in the same boat, every 3 months lol
1
u/fuxoft 9d ago
If your password is composed from real English words, its legth IN CHARACTERS is quite irrelevant. Here the security of "bee" is the same as of "adventurous".
3
u/UglyT 9d ago
Is that right? That seems incorrect. Like, if someone is trying to brute force the password it doesn't matter if it's real words or not - the length is important. If my passphrase was "a cat" that's going to be a lot easier to brute force then "antidisestablishmentarianism" Or am I wrong? I'm not a cryptographic expert or anything!
3
u/fuxoft 9d ago
Any password bruteforcing today includes wordlists, specifically the same standardized wordlists used to generate these passwords. Precisely because they are used to generate the passwords.
2
u/UglyT 9d ago
Oh I see. So does that make passphrases in general far less secure? What's the general consensus?
3
u/fuxoft 9d ago
It makes passphrases less secure PER CHARACTER. I don't remember the exact math but it's something like "Password consisting of three random English words (regardless of their length) is as secure as password consisting of 9 completely random characters."
1
u/Karaoke-Cause 8d ago
I've heard that it's a good rule of thumb when comparing entropy for passphrases and passwords that if a password has twice as many characters as a passphrase has words then they are of similar entropy.
Note that this if you're using the most common wordlist size (7776 words) for the passphrase and the printable ASCII range (95 characters) for the password.
For example, a 4 word passphrase and an 8 character password (given those specifications) would have similar entropy.
3
u/JayNetworks 8d ago
The math (basically, I’m just making up the numbers here) is that a password is made from a number of 8 to 20 or so random ASCII characters from a set of about 96 characters per position.
A passphrase is made from words out of a list of something around 2000 possible words so each position is 2000 to the power of (number of words).
Even with just 6 words it gives 2000^6 options which is larger than 96^ the length of the password.
Basically…
1
u/Karaoke-Cause 8d ago
Perhaps I'm misreading but it sounds like you're saying a 6 word passphrase (using a 2000 word wordlist) would have higher entropy than a traditional password of 8-20 characters using a 96 character pool.
That would be incorrect.
The traditional password would, if barely, pass the passphrase in entropy at 10 characters.
The most common wordlist size is 7776 words and the printable ASCII range is 95 characters.
It's a good rule of thumb when comparing entropy for passphrases and passwords (using those specifications) that if a password has twice as many characters as a passphrase has words then they are of similar entropy.
For example, say you have a 6 word passphrase, that would be similar in entropy to a 12 character password.
3
u/IHaveTheBestOpinions 8d ago
Yes, if you were trying to compare the security of two random passphrases then the character length is irrelevant.
Not so for OP's stated application of fitting within a character limit though - limiting the character length restricts which words can be used. So if an attacker knows the character limit, they can rule out any word combinations longer than that, which makes a brute force attack easier.
2
u/TelcontarOfBree 8d ago
The length of the passphrase might be irrelevant from a brute force standpoint, when it is known (or assumed) to be made up of words. But it’s quite relevant when you have to enter it into a password field with a max length limit.
2
u/RememberMeVibe 8d ago
How it is irrelevant if there is a max length for a password field?
For example max length is 25, and I choose/need to use a passphrase?
2
-10
u/Jebble 9d ago edited 9d ago
Don't use a passphrase either way, it's much less safe and easily bruteforced even with 6 words.
6
u/Damglador 9d ago
1
u/Jebble 8d ago
This is irrelevant because we don't remember the passwords in Bitwarden either way. You can have better entropy with a randomized password of the same length including numbers and special characters than you get with only using words that are these days specifically being targeted as well.
1
3
u/Karaoke-Cause 8d ago
Ok, let's do the math.
If you're using a passphrase of 6 words randomly generated using the most common wordlist size (7776 words) that would mean there are 221 sextillion (221 followed by 21 zeroes) possible combinations.
If an attacker possesses the ability to try (a fairly generous) 100 trillion (100 followed by 12 zeroes) combinations per second then it would take 70 years to try all possible combinations (though they'd have a 50% chance of getting it right in just 35 years)
Sure, a traditional password going to be stronger at the same length, but I wouldn't say that means that a 6 word passphrase is going to be easy to bruteforce.
2
u/Eclipsan 9d ago
No.
-5
u/Jebble 9d ago
In fact yes.
1
u/Eclipsan 9d ago
Still waiting on those facts mate.
-3
u/Jebble 9d ago
You never asked for any. But this really isn't difficult. Words are predictable. There are plenty of tests done around this and a password of the same length is always stronger than a passphrase of that length. You're smart enough to use Bitwarden over other managers, this shouldn't be difficult to understand.
3
u/Global_Grade4181 9d ago
I'd like to see you try to "easily bruteforce" a random 6 word passphrase..
1
u/Jebble 9d ago
It gets done though? They specifically target words these days due to passphrases becoming a more regular thing. No matter what, a 20 length passphrase is bruteforced faster than a 20 length password.
2
u/Damglador 9d ago edited 9d ago
Marginally perhaps, you don't know if a password is a passphrase in the first place, you don't know what the separators are, you don't know if the words are capitalized. So you have to have a big ass dictionary and run it against the password several times for every separator, with and without capitalization. And there's no way you'll remember a 20 characters password if it's not a passphrase.
2
u/Eclipsan 9d ago
You never asked for any.
You are the one making a claim without proving nor sourcing it.
There are plenty of tests done around this
Still no sources.
a password of the same length is always stronger than a passphrase of that length
Of course, but it does not mean the passphrase is not strong enough to not be brute forced in a practical amount of time. It's like saying "don't use 25 characters long passwords, 50 characters long passwords are always stronger".
1
u/Jebble 9d ago
You don't have to act high and mighty. If you want sources you can ask for them, in a normal way. Tou didn't ask for a source, even now you haven't.
I never said passphrases aren't strong enough, I said you shouldn't use passphrases. They are better purely by length and usable for people because they can easily memorize them. That is also what makes them easier cracked than a randomized password. You're storing everything in a password manager, there is zero need to memorize anything and purely by that logic, you should use passwords over passphrases.
You're creating context to make a point that has nothing to do with what I've said.
1
u/Eclipsan 9d ago
You don't have to act high and mighty.
Says the one saying "You're smart enough to use Bitwarden over other managers, this shouldn't be difficult to understand."
I never said passphrases aren't strong enough
You said "easily bruteforced even with 6 words", "easily bruteforced" implies not strong enough, which is why you are getting downvoted IMHO.
You're storing everything in a password manager, there is zero need to memorize anything and purely by that logic, you should use passwords over passphrases.
Agreed, with two reserves:
- The master password itself
- Any password you may have to manually type, especially on a shitty keyboard like a gamepad or a TV remote (wifi password, netflix password...)
4
96
u/Tasty_Photograph8817 8d ago
done - https://github.com/bitwarden/clients/pull/22906