Depending on the exact wording, I completely expect the browser to suggest the same password for the same website in the same session for the same user.
Websites are crap and sometimes you need to enter the same password twice before the browser has gotten the notice to actually save the first one.
One use-case I hit recently is when having multiple Private Windows. Assuming visiting a site, B, and wanting to use two different username+password combinations.
If Window A->Site A needs to remain open but Window B->Site B is closed, and a new Private Window (opened using File > New Private Window) that we'll call Window C visits Site B the expectation is this is a 'clean' session.
But Window C->Site B then presents the same auto-generated password as was created in Window B->Site B even when using a different username.
ALL Private Windows have to be closed for the 'session' to be removed so that new passwords are generated.
I would expect two private windows to be using two separate isolated containers and according to the bug report, different containers won't generate the very same password.
All private tabs share the same container and it is only thrown away when you close them all. Otherwise you would not be able to move tabs between private windows for instance
>>> Otherwise you would not be able to move tabs between private windows for instance
I am not sure how this is related, but I can have multiple containers running within the same Windows and I can drg and drop these tabs between Windows without them changing their containers.
Even though it's resolved I do find it very interesting. The reason why it still exists on the home page is evidence that others agree with this sentiment.
Yes, with autogenerated passwords you want to be extra-sure the machine has actually remembered them and the process breaks down sometimes. This is a good (if unexpected, should be advertised) feature and I can't see security implications.
When using 1Password this bit me once when I was signing up to my countries online finance and tax management. I managed to sign up and store the wrong password, without being able to look up the previously generated one. For extra "learned my lessons annoyance" I needed to get a new signup-code via snail mail to change the password.
That's impressive for 1Password with the history feature but I wouldn't put anything past financial systems. One of our utilities broke their bill payment system in some manner that I was able to save my new password, have it be rejected on login, and then when I followed the password reset flow and tried to use that password it was rejected because it was the same as the current password.
I’ve definitely seen that kind of before (app had max length in the HTML different than the max enforced by the validator). It’s amazing how much bad UX is tolerated in the name of security.
I think in this case the behavior is that the initial generation of the password is random, but subsequently it is, shall we say, "trivially deterministic": it (intentionally) always spits out a cached copy of the initial randomly generated password.
I think security implications here would mostly apply to cases where you wanted to create multiple accounts on the same website within a short period.
Deterministic doesn't mean predictable by an attacker who can't read system memory but consider also that this could be implemented as simply as a cache: store the generated password for that hostname for n minutes and reuse it for autofill when present. There are a number of hokey things web developers do around security and this would seem like a good hedge against, for example, the ones who split the password and confirmation into separate forms or make you login to their related services because they haven't setup SSO properly.
That’s why I mentioned “depending on copy” (or more broadly “UI”).
If I’m clicking a “Generate password” button I expected a new password every time. But here it’s an autocomplete-like dropdown rather than an action. By your definition, such dropdown would show different passwords for different fields, even if the second field is a “confirm password” field.
As the comment suggests: you are an admin and you need to create a few new accounts. If you do need to create hundreds you will probably use a batch script or something, but for just a couple using a web ui seems more convenient, and using an autogenerated password helps you.
In that case, if you are not paying attention all the new accounts will have the same password, which is a privacy issue.
Smart! But such an edge-case, I don't find this bug as ridiculous..
On another note, admin shouldn't be sending entering other peoples passwords anymore, they should be sending invites links that let's the user insert their own.
"The admin never knows the user's password" is a pretty simple security step for any setup. What way would someone want to use a web service where the admin knowing their password is a requirement?
> What way would someone want to use a web service where the admin knowing their password
Unfortunately the people who have to use software are often not the people responsible choosing it!
> where the admin knowing their password is a requirement
For creating fresh accounts this is less of an issue than once the account has access to real data that has already been entered, so all the admin can get by knowing the password at this point is the information they already had to create the profile and account with. While still not good design it is at least mitigated somewhat in practise. The main issue this behaviour-as-designed introduces is one new user being able to guess another new user's password. The danger this poses can be reduced by forcing the user to choose a new password on first login, before any information is entered, but it still isn't good design to even need this mitigation. If the software is badly arranged enough that the admin knows the password instead of it being generated and sent to the target user without the admin being any the wiser, then it may be that the “force change on first login” option is missing too.
You log out of a site (manually or it logs you out after a period of inactivity) but don't properly lock your machine when walking away, or put your phone down unlocked, etc.: someone can now access that site as you even though you were logged out. Worse, that can take the password away and use it at a later time on an entirely different device.
It could be argued that if you don't logout/lock devices properly then you are unlikely to log out of sites, but the principal of security in depth requires accounting for partial use of best practise not all-or-nothing.
Also as described in the bug, you could accidentally create multiple accounts with the same password if you are creating or resetting accounts for multiple people (i.e. you are performing some sort of admin role in relation to local users of the site in question).
I can see the usability argument for the feature “behaving as designed” because often when a password cycle is required you have to enter it two or three times (once to set, once to confirm you didn't mistype that first one, then some password reset procedures don't leave you with a valid session so you need to immediately log in again with the new password), but it does strike me as one of those places where paranoia should trump usability.
> you can do the same with any password manager. If you don't lock your "vault" any of your passwords are exposed
True, but:
1. People are aware of that, it is an expected threat vector so at least a little less likely to be an issue. The behaviour of the FF password generator function is unexpected (to many) so is a hidden potential problem.
2. Good password managers have the option to auto-logout after inactivity which can mitigate an attack if not performed quickly.
3. Other similar attack vectors existing does not mean this one shouldn't be considered for closure, or if not closing by changing the behaviour perhaps instead adding a warning.
I'm very thankful this is the current design. When I noticed it, I needed it to do exactly what it does, and was honestly quite pleasantly surprised it worked this way.
You see, I'd just tried to create an account on a website with a slow network link. The website then failed to load. I wasn't sure if my account had been created or not. I always wait for the account creation step to succeed before I save a password, so I hadn't yet saved this random password.
I was a bit worried I'd have to go through a lengthy password reset process, on my slow internet link. Fortunately for me, going back to the account creation page simply popped up the same password, so I just hit the "Sign Up" button again, without worry of losing my password again.
- I didn't know this is the expected behavior of FF
- I'm paranoid about getting locked out of certain accounts by stupid accidents (particularly on badly designed web sites). I temporarily copy old password too, when changing to a new one.
- I do wish Firefox's password manager maintained a history of previous passwords like LastPass does.
Clipboard history can also be helpful in this context (I use Unclutter on macOS, YMMV), tho it has its pros and cons.
But I have a use case where I really do not want this: when I sign up for multiple accounts in the same browser session, I expect a different password when I've logged out. I use Bitwarden and a text file in this use-case though; not Firefox. Because Bitwarden allows password sentence and I'm supposed to hand over the account to someone else.
I also do this, and I double check it in Safari before closing any windows. It's become a good habit, especially with things like Disney Plus but logged in via Hulu credentials. Example, for some reason sometimes www.hulu.com works but auth.hulu.com doesn't know that I changed my password, so I can easily paste the new one into the appropriate field and everything works.
EDIT 2022-12-20: There are at least 3 cases where this is desirable within a short period of time:
Filling password confirmation fields on the same page if we were not able to automatically do so.
Filling the same password on the next page
The password didn’t save on the change form so you need to fill it on the log in page.
Bug 1551723 will give the user the option to choose a new password.
This is pretty absurd and goes against every expectation I'd have of a password generator. The only reason I can think of it being useful is if the site has a separate screen for a confirm password field, but even then the password should be saved in the password manager the first time it is submitted.
Except the confirm password field is in the same form so hasn't been submitted.
This very well could be the expected behavior to allow for the potential states of form entry and submission and the immense number of issues related to networking.
Whether this could be changed by a preference perhaps is definitely a possible avenue here, but if they want to have it this way so people are less likely to lose their password during sign-up then so be it.
Pick another password manager if you don't like it, but for the common user it's probably the best experience out of the box (even if I don't want it that way either)
Only thing I can think is that sign up forms make you enter a password twice to prevent you from making a typo in the password. So with this you can right click and generate a password in both password fields and it will be the same password in both
Also the fact that it isn't uncommon that you need to actually log in on site for browser to actually try to remember password or prompt the storage to right associated url.
LastPass, 1password and bitwarden are happily filling out both fields with the same generated password without preventing new password generation. Seems like a solved problem.
They happily try. But there are so many poorly coded websites they can't handle all possibilities. This seems like a useful feature, although I prefer the way 1password solves it.
(They handle multiple accounts on the same site, so their UI is a list rather than a single item. "Generate a random password" is just a special list item, so they can show you both.)
I get the spirit - but this is way more convoluted than just letting 1Password generate and save everything for me in 1-2 clicks without ever leaving the browser. And as a bonus I don’t have to copy+paste it, care about where it’s stored, and it will auto-fill for me. Not to mention they just magically appear on all my devices without some home brewed syncing scheme :)
It copies passwords like `Uncertain-Postbox-Cannot5` to your clipboard. Much easier to remember/type, and just as secure. I've assigned that to a hotkey, so whenever I need a password I press Super+G, Ctrl+V, and that's it.
In that case, [:print:] instead of [:alnum:] will include all printable characters.
Although I'm pretty sure I've met websites that require brackets and ampersands but will reject, say, periods and underscores, because web developers are sociopaths.
I've never had a website outright reject certain special characters, but I've had some passwords silently accepted at signup and then rejected at login. So I usually randomize the password until it doesn't include any backslashes or asterisks...
I've had this happen on pure length. I believe KeePass defaults to 20 characters. I've seen websites accept 20 characters on sign up, but internally, the log in only accepts 12 characters, but it doesn't truncate the input either. I had to enter the first 12 characters and submit the form, and it worked.
I was completely baffled on why it was designed that way - if you're going to truncate the password, the login field should do the same.
Omg you must have incredible luck when filling out sign in forms. There must be some sort of sadistic instinct on the types of people who design password forms. I’ve had passwords rejected for being too long (over 15 characters), including the “wrong” kind of special characters, having the same character repeated twice in a row, not having enough numbers, just to name ones I can remember off the top of my head. Oh the best ones don’t tell you the rules until after you’ve been rejected.
A special place in hell is reserved for those websites that consider themselves too cool for a password manager. They actively block auto fill or cut & paste in the password field. I don’t envy the 1password devs for having to put up and work around this stuff.
Don’t get me wrong I appreciate the hacks. But I can’t exactly walk my father in law through that process when he hardly understands what a password manager is and why it’s important in the first place. Plus this doesn’t help at all on mobile.
> I've never had a website outright reject certain special characters,
This is exceedingly common for US Banks. You'll find, usually only after pasting in the newly generated random password and clicking submit, that the "your password must include at least one number and two special characters" description up front failed to also include: "oh, also, we do not allow use of the character % in your password" (or some other character).
When I created an account to take out a mortgage with a UK bank, I found they allowed up to 12 ASCII alphanumeric chars for a password. I forget if there was a min length.
This was around October 2019, so it's not like they shouldn't have know better.
This creates one password of 32 characters of reasonable classes. There are options to adjust character classes if the site enforces something like that.
`/dev/urandom` isn't a real file / stream. It's part of the 'everything is a a file' *nix mantra. Even if two users are reading from /dev/urandom simultaneously, they'll each get unique values. The CSPRNG keeps track of a sequence number and so you'll end up with something like [process 0 requests sequence 0, process 1 requests sequence 1, process 1 requests sequence 2, proceess 0 requests sequence 3...].
Is that strictly true? I know urandom doesn't block if it lacked entropy, but if it had entropy I was under the impression urandom's output was derived from that instead.
Well, a lot changed since the article. For one the test tool now eats more CPU than RNG.
From my dumb tests (run DD in one, then many threads), the 4 thread run have 4x the performance of single thread one (I have 4 core CPU), while 16 thread one have predictably same-ish total throughput, so if there are any serialization still there it is not noticeable much.
IMO they should just remove the password generator feature. It's barely usable, and with this behavior it's just dangerous.
Why barely usable? Some really simple features are missing. I miss the ability to specify password requirements - for annoying sites which specify length, require so and so many these and those types of characters, or even forbid some types. And another one is that it's not possible to manually generate a password, not even in the password storage UI, when manually adding a new entry. So, if a site did not correctly declare a password field, which happens, you must generate a password yourself somehow.
If you read the page you would see it is functioning by design and the bug was closed 3 years ago. Not saying that is the proper behavior, but that would explain why you can reproduce it.
It is a hit or miss, as some password fields don't get this. However, I personally fund it useful and use it about 100/% of the time in new signups/resets when available.
Yeah that's the problem though: A lot of websites don't set the password field to "type=password" or they don't set the second (verify) password field like that. Why do they do this? Either the web developer didn't really know what they were doing or they were given some very unique requirements (e.g. need to work with a legacy framework).
Wrong. There's random generation, and each randomly generated password is pinned to the site where it was generated. When you navigate to a different site, Firefox will generate a new password. There's no cross-site leaking.
Password is leaked and you want to change it all in the same browser session/tab since you created it for the 1st time? I mean, technically you could be living with the same tab opened for months but...
Has anyone the time to do a code review on that: I would not be surprised if there's even less entropy in Firefox generated passwords than the bug report might indicate (e.g. just uses time and domain as random seed).
If that's the case it would make a new "named" vulnerability (FOXHOLE, FIREBLEED, whatever).
It uses a PRNG with no site-specific seed, it just stores that result temporarily so it can be filled it password confirmation fields or login forms during the same session to ensure the user can complete their password change process.
Code: https://searchfox.org/mozilla-central/rev/abcee8d2c97a5c8a1f...
Seems they saw the submission and edited their response, appending the following:
EDIT 2022-12-20: There are at least 3 cases where this is desirable within a short period of time:
1. Filling password confirmation fields on the same page if we were not able to automatically do so.
2. Filling the same password on the next page
3. The password didn’t save on the change form so you need to fill it on the log in page.
Bug 1551723 will give the user the option to choose a new password.
It only generates the same password if the browser session is also the same, i.e. it generates a different password for the same domain if the browser was closed in the meantime.
Depending on the exact wording, I completely expect the browser to suggest the same password for the same website in the same session for the same user.
Websites are crap and sometimes you need to enter the same password twice before the browser has gotten the notice to actually save the first one.