[HN Gopher] Password generator doesn't generate new password in ...
___________________________________________________________________
Password generator doesn't generate new password in the same
session
Author : makepanic
Score : 101 points
Date : 2022-12-20 09:44 UTC (13 hours ago)
(HTM) web link (bugzilla.mozilla.org)
(TXT) w3m dump (bugzilla.mozilla.org)
| sys42590 wrote:
| 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).
| mnoorenberghe wrote:
| 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...
| sys42590 wrote:
| thanks for the link, much appreciated
| haasted wrote:
| It generates the same password when on the same domain. There's
| probably a usability explanation for this behaviour, rather
| than lack of entropy.
|
| Wish the responder would have spend some time elaborating on
| "why" rather than just stating that it's "by design".
| sys42590 wrote:
| Lack of entropy when generating keys and passwords leads to
| things like the infamous Debian weak SSH keys vulnerability
| from 2008: https://cve.mitre.org/cgi-
| bin/cvename.cgi?name=CVE-2008-0166
|
| So I'd prefer secure passwords instead of convenient
| passwords...
| forgotpwd16 wrote:
| 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.
|
| #1551723 tracked @
| https://bugzilla.mozilla.org/show_bug.cgi?id=1551723
| nebalee wrote:
| 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.
| turtleman1338 wrote:
| >This is currently by design
|
| What?
| chrisallenlane wrote:
| I'd be incredibly interested to hear the rationale for this
| decision. Seems like an obviously disastrous idea.
| thatguy0900 wrote:
| 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
| enedil wrote:
| I would claim that this is much more common than the
| scenario described in the bug report.
| viraptor wrote:
| 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.
| iudqnolq wrote:
| 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.)
| Ekaros wrote:
| 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.
| [deleted]
| dncornholio wrote:
| Can someone explain me what the issue is with this? Not a
| hypothetical reason, but a real life example?
| TrianguloY wrote:
| 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.
| dncornholio wrote:
| 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.
| hackmiester wrote:
| That is a narrow view of all the different ways people
| might use a Web service.
| Xelynega wrote:
| "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?
| ekianjo wrote:
| not so much a privacy issue than a security one
| TrianguloY wrote:
| oops, you are right. Can't edit now :(
| dspillett wrote:
| 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.
| maxpro wrote:
| But you can do the same with any password manager. If you
| don't lock your "vault" any of your passwords are exposed.
|
| I think it would make sense to create a "regenerate" button
| or something like that.
| dspillett wrote:
| _> 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.
| [deleted]
| pontilanda wrote:
| 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.
| iam-TJ wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| >>> 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.
| ilyt wrote:
| It's resolved and closed as "it works as designed" so dunno why
| someone even linked it in the first place
| riskable wrote:
| 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 wrote:
| Perhaps the higher ranking is driven by the many positive
| comments here supporting the argument that firefox is doing
| the right thing
| hoseja wrote:
| 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.
| [deleted]
| zwirbl wrote:
| 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 wrote:
| 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 wrote:
| Password truncated at [login|reset] but not vice versa.
| lalopalota wrote:
| The security implication I see is that the password
| generation is deterministic. My assumption when using a
| password generator is that it is random.
| pontilanda wrote:
| 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.
| tesseract wrote:
| 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.
| acdha wrote:
| 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.
| dbttdft wrote:
| makepanic wrote:
| Most recent issue that tracks this is
| https://bugzilla.mozilla.org/show_bug.cgi?id=1551723
| jmclnx wrote:
| If you are on a UN*X Type system, you can create your own random
| passwords very easily.
|
| tr -cd "[:alnum:]" < /dev/urandom | fold -w 20 | sed 10q
|
| So I have no need for these fancy password generators :)
| usr1106 wrote:
| The are unlimited ways of writing such oneliners. Only allowing
| alphanumeric characters seems wrong to me and will be rejected
| by many sites.
| BrotherBisquick wrote:
| 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.
| TechBro8615 wrote:
| 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...
| ThunderSizzle wrote:
| 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.
| pwg wrote:
| > 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).
| TechBro8615 wrote:
| It's even worse for UK banks, which ask you to (for
| example) "enter the 4th, 5th and 11th character of your
| password."
| onei wrote:
| 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.
| ipython wrote:
| 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.
| pwg wrote:
| > They actively block auto fill or cut & paste
|
| Firefox -- set the "dom.event.clipboardevents.enabled"
| setting in about:config to 'false'. No more "actively
| blocking paste" by websites.
| somehnguy wrote:
| 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 :)
| e1g wrote:
| OpenSSL is commonly available and can guarantee at least one
| "special symbol": openssl rand -base64 20
| pimlottc wrote:
| Hah! At first I was surprised they thought to guarantee at
| least one symbol, and then I realized you meant the base64
| padding!
| stavros wrote:
| This is much better: echo -n "$(diceware -d
| '-' -n 3)"$(( RANDOM % 10 )) | xsel -b
|
| 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.
| fabrixxm wrote:
| I usually go with echo 4
| Semaphor wrote:
| For anyone confused: https://xkcd.com/221/
| febeling wrote:
| I like pwgen: pwgen 32 1
|
| This creates one password of 32 characters of reasonable
| classes. There are options to adjust character classes if the
| site enforces something like that.
| forgotpwd16 wrote:
| >So I have no need for these fancy password generators :)
|
| There's nothing fancy here. On password fields browsers have an
| auto-fill. Your method requires more effort compared to it.
| amelius wrote:
| Question: how does /dev/urandom ensure that two different
| users, both reading from the stream, don't get the same output?
|
| (ignoring that they could get the same output by chance)
| [deleted]
| colanderman wrote:
| There is (or at least was, in 2014) a spinlock to serialize
| access: https://damonsnyder.com/2014/04/16/linux-dev-urandom-
| and-con...
| onei wrote:
| 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.
| colanderman wrote:
| Edited my post to include a link with code references and
| discussion by kernel devs. The RNG state is protected by
| a spinlock.
| ilyt wrote:
| 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.
| codefined wrote:
| `/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...].
| haasted wrote:
| The actual challenge for browsers is to create a system that is
| usable by our grandmothers, though.
| TrianguloY wrote:
| Could be "fixed" by showing two entries: "previous password" and
| "new password".
|
| This will change the ui a bit though.
| GloriousKoji wrote:
| I can't remember the last time Firefox changed an UI element
| that made things better... when they combined the Refresh and
| Stop button?
| jonnycomputer wrote:
| And here
|
| https://bugzilla.mozilla.org/show_bug.cgi?id=1786712
|
| This is sort of a ridiculous bug, tbh. What rationale could this
| be "currently by design"?
| [deleted]
| pritambaral wrote:
| 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.
| jonnycomputer wrote:
| I always paste into a text file until ive confirmed
| everything works as expected
| forgotpwd16 wrote:
| Having to take such steps sounds like what you're using
| isn't working right. Fortunately Firefox doesn't need you
| to do this.
| jonnycomputer wrote:
| - 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.
| pmontra wrote:
| More or less it's what I do except that I generate the
| password with a password manager (one of the Keepass
| family) and store it there.
|
| Rationale:
|
| 1. I'm not tied to a browser, even if it is Firefox.
|
| 2. I can use the password with any other browser on the
| same or any other device.
| Fnoord wrote:
| 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.
| jrnichols wrote:
| 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.
| ekianjo wrote:
| "will not fix" is now called "duh! its by design!"
|
| then the actual design is probably just badly thought through.
| Karellen wrote:
| The bug has been updated with a rationale:
| 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.
| SahAssar wrote:
| 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.
| bakhy wrote:
| This is quite easy to reproduce. Wow.
|
| 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.
| amelius wrote:
| I use the feature all the time, and I'm happy with it. Please
| don't remove it.
| weird-eye-issue wrote:
| > This is quite easy to reproduce. Wow.
|
| 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.
| haasted wrote:
| Why do you find the feature "barely usable"?
| Ayesh wrote:
| 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.
| mnoorenberghe wrote:
| I believe you can right click in any type=password field to
| bring it up with the heuristics didn't detect it as a new
| password field.
| riskable wrote:
| 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).
| richardwhiuk wrote:
| Password is leaked. Firefox continues to suggest the same
| password, because there's no random generation.
| darkwater wrote:
| 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...
| kijin wrote:
| 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.
| haasted wrote:
| I meant in addition to the issue being discussed.
|
| > It's barely usable, and with this behavior it's just
| dangerous.
___________________________________________________________________
(page generated 2022-12-20 23:02 UTC)