6 ms·

Is it a bug or a feature? Depending on the exact wording, I completely expect the browser to suggest the same password for the same website in the same session

Is it a bug or a feature? 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.

hoseja 4y ago
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.
- zwirbl 4y ago
  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.
  - acdha 4y ago
    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.
    - ThePowerOfFuet 4y ago
      Password truncated at [login|reset] but not vice versa.
      - acdha 4y ago
        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.
- lalopalota 4y ago
  The security implication I see is that the password generation is deterministic. My assumption when using a password generator is that it is random.
  - acdha 4y ago
    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.
  - tesseract 4y ago
    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.
  - pontilanda 4y ago
    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.
- deleted 4y ago
  [deleted]
ilyt 4y ago
It's resolved and closed as "it works as designed" so dunno why someone even linked it in the first place
- riskable 4y ago
  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.
  - meitham 4y ago
    Perhaps the higher ranking is driven by the many positive comments here supporting the argument that firefox is doing the right thing
iam-TJ 4y ago
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.
- meitham 4y ago
  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.
  - Boltgolt 4y ago
    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
    - meitham 4y ago
      >>> 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.

hoseja 4y ago

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.

zwirbl 4y ago
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.
- acdha 4y ago
  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.
  - ThePowerOfFuet 4y ago
    Password truncated at [login|reset] but not vice versa.
    - acdha 4y ago
      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.
lalopalota 4y ago
The security implication I see is that the password generation is deterministic. My assumption when using a password generator is that it is random.
- acdha 4y ago
  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.
- tesseract 4y ago
  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.
- pontilanda 4y ago
  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.
deleted 4y ago
[deleted]

ilyt 4y ago

It's resolved and closed as "it works as designed" so dunno why someone even linked it in the first place

riskable 4y ago
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.
- meitham 4y ago
  Perhaps the higher ranking is driven by the many positive comments here supporting the argument that firefox is doing the right thing

iam-TJ 4y ago

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.

meitham 4y ago
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.
- Boltgolt 4y ago
  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
  - meitham 4y ago
    >>> 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.