I just tried to log in to IBKR and was presented with the annoying screen which asks you to fill in “the name of your pet dog” etc. for security.
I pressed ‘continue’ to go to the next step only to realise that the browser had prefilled my IBKR password into the field and this had accepted my IBKR login password as the answer.
Aside from the awful security paradigm of having these dumb guessable questions, this has now compromised my password on top due to my carelessness and the poor security design of the page itself.
I transferred sensitive data to an LLM by mistake. i’d meant to send to a local LLM, but the client refreshed and sent to cloud instead. lesson learned make sure default LLM is the local one.
Theoretically, well made and secure websites don’t store your password (it could be leaked or employees could read it).
They store the hash of the password (plus some random string called salt), so giving them the password in plain text is quite bad.
They do this because the hash is very hard to reverse (get the password from the hash), which means that even knowing the hash shouldn’t compromise your account (especially if salt was used).
Usually the provider does not know the password, only the hash of the password. As soon as you save the password in a field that is stored readably in the database (which is the case with a security question, the support must be able to read it), the password is compressed.
I see two possibilities here:
IBKR has marked the security question input field in the HTML as a password field, thus fooling the password manager and causing it to make an incorrect entry.
Or the password manager does its own magic and tries to recognize input fields and in this case has mistakenly interpreted the security question field as a password field.
This has also happened to me on other websites. My two cents: The automatic filling in of passwords should only happen after an action, i.e. with a key combination or with a confirmation. I personally always switch off automatic magic filling for precisely these reasons. This can be configured in most password managers. If not, I would change the password manager.
Yeah, except, rainbow tables. But the salt addresses this to some extent.
You missed to emphasize “theoretically”.
I’m not saying these are well made or secure websites, but here are some that actually did this:
Facebook (2019)
Twitter (2018)
GitHub (2018)
LinkedIn (2012)
Anyway, this is the eternal usability question weighing between enabling (somewhat automated) account recovery when users forget their password or making it really hard for attackers to breach an account but somewhat equally hard for the legitimate user to recover an account with the additional overall constraint of the provider not wanting to spend unlimited headcount on handholding the affected user.
I shaved my beard once and my phone took a while to recognise me, got scared for a bit until I remembered I can just stroll down to the bank, Ausweis + passport in hand and recover whatever’s needed to be recovered. Internet is only for pr0n, after all
No seriously, I hope you fix whatever needs fixing.
I like to use alias emails for each different login, which allows to track how much and what crap comes from what site being hacked/selling my data. Each should at a minimum have a different password.
Edit 29th of May 2025 - 7:30 pm: sorry, I just realized it was about using Chrome as a password manager, which this doesn’t apply to.
By reading and partipating to this forum, you confirm you have read and agree with the disclaimer presented on http://www.mustachianpost.com/
En lisant et participant à ce forum, tu confirmes avoir lu et être d'accord avec l'avis de dégagement de responsabilité présenté sur http://www.mustachianpost.com/fr/
Durch das Lesen und die Teilnahme an diesem Forum bestätigst du, dass du den auf http://www.mustachianpost.com/de/ dargestellten Haftungsausschluss gelesen hast und damit einverstanden bist.
