[HN Gopher] 2FA or Not 2FA
___________________________________________________________________
2FA or Not 2FA
Author : sam_lowry_
Score : 57 points
Date : 2025-03-18 12:38 UTC (2 days ago)
(HTM) web link (mikhailian.mova.org)
(TXT) w3m dump (mikhailian.mova.org)
| Aardwolf wrote:
| Plus many want your phone number or some random app by them on
| your phone for their 2FA (instead of e.g. TOTP that you contol),
| less secure because they now can leak your phone number or do
| something with an update to the app
|
| BTW what's the sentiment on passkeys?
| account-5 wrote:
| In my opinion passkeys, whilst solving the password related
| issues, introduce their own. The risk of losing access to your
| accounts is greater if you tie everything to one device and
| that's lost or stolen, and the "solution" to use more than one
| device is not a solution, or feasible for everyone. There's
| also the risk of vendor lock-in, which is definitely an aim of
| the big providers like Apple, Google and Microsoft; which is a
| bigger risk to those less tech savvy.
| dcow wrote:
| FWIW no consumer implementation of passkeys is device bound
| for exactly this reason. The threat of a user losing a device
| is much bigger and pressing than getting phished. All
| passkeys are backed up in a sync fabric.
| gclawes wrote:
| You _can_ use a standalone YubiKey or similar dedicated
| hardware tokens as a passkey, but they have limited slots
| for discoverable credentials.
|
| But yeah, anything resembling a phone passkey seems to have
| a sync fabric behind it.
| jampekka wrote:
| Most consumer passkey implementations are lock-in.
| https://arstechnica.com/security/2024/12/passkey-
| technology-...
| reginald78 wrote:
| And one of the developers of passkeys threatened to use
| the specified attestation anti-feature to blackball
| Keepassxc's implementation when they made something not
| locked in enough.
|
| https://github.com/keepassxreboot/keepassxc/issues/10407
|
| There have been some discussions to create an export
| standard since then but I remain skeptical. Why was this
| not part of the original spec but the ban hammer was?
| Depending upon how this standard is implemented I can
| easily see it preventing export to anything but Google,
| Microsoft and Apple's implementations. And it still
| leaves the attestation badness in place.
| edent wrote:
| Password re-use is the bigger issue.
|
| No one can crack your super-strong multilingual password. But if
| a service accidentally leaks it, then it doesn't matter.
|
| Credential Stuffing is how 23andMe were hacked. People reused
| password, they were leaked from another service, attackers tried
| them on a variety of sites until they hit the jackpot.
|
| Unique passwords prevent that attack. Can't remember a thousand
| different passwords? Use a manager.
|
| Don't want to use a manager? Switch on 2FA. Weak passwords and
| password reuse ceases to be a problem.
|
| Yes, as the article points out, it slightly reduces ease of
| login. But that seems like a sensible trade off.
| benoliver999 wrote:
| I would advise against password re-use regardless of 2FA.
|
| - Lots of flaky 2FA implementations out there where it's easy
| to get in without it, if you have the password
|
| - If a service doesn't offer 2FA you are now unable to use it
| for fear of sharing your password (like this website)
|
| I suppose logically if your email is 2FA, then someone can't do
| 'forgot password', but man that feels super flaky.
| freeone3000 wrote:
| Gmail "magic link" login (which is the reset password flow,
| but without needing the password) is the same security
| profile as Google OAuth, while exposing less user data (name
| and profile are nonoptional) -- and also equivalent to an
| Android-managed passkey.
| 9dev wrote:
| With the price being an absolutely awful user experience.
| Did the email arrive yet? Or wasn't it sent in the first
| place? Oh wait, let's check spam. Send again, what do you
| mean _try again in five minutes_ , I want to sign in _now_!
| autoexec wrote:
| > Yes, as the article points out, it slightly reduces ease of
| login. But that seems like a sensible trade off.
|
| In addition to making the login process more complicated 2FA
| can also introduce privacy concerns. A third party
| authenticator app can collect all kinds of data for it's own
| reasons (For example MS's app will request location and camera
| permissions) and that 3rd party could also track which services
| you log into, when you access them, and how often you access
| them.
|
| 2FA can also cause you to be locked out of our accounts, either
| temporarily or forever.
| vel0city wrote:
| Having a TOTP app request camera permission isn't nefarious.
| In fact, I'd 100% expect it. Most of the time people import a
| TOTP secret from a QR code.
|
| Microsoft Authenticator can be configured by an admin to
| provide geo-blocking for attempts, so once again not just
| some arbitrary demand. It's a selling point of the product.
| autoexec wrote:
| It's not unreasonable for Microsoft Authenticator to
| request those permissions, but just because they can
| justify asking for them it doesn't nessesarily mean that
| you want Microsoft collecting that data, or any data, about
| what you're doing and when. One of the nice things about
| hardware tokens is that they keep third parties out of your
| business entirely.
| tracker1 wrote:
| Yeah, especially in that MS Authenticator is usually
| configured for Push mode as opposed to TOTP.
|
| That said, I prefer simple/general TOTP implementations
| that I can just use with my password manager for my own
| convenience. But the permissions being asked for are
| completely reasonable for the actual use of these
| applications.
| senectus1 wrote:
| lol
|
| >One of the passwords that I know by heart is a famous classic
| quote clumsily translated in a mix of French and Dutch. It is
| long, it can not be brute-forced because of its length and I am
| pretty sure it is not present in any of the rainbow tables. I
| never spell it out, let alone write it down, but it is in my
| muscle memory as I haven't changed it for years.
|
| One keylogger OR phishing attempt and his super complex and
| secure password is ruined. with no 2FA to protect him.
| akimbostrawman wrote:
| If a system used for logging in has a keylogger its game over
| anyways since it could just copy 2FA (excluding hardware token)
| or cookies.
| dharmab wrote:
| 2FA doesn't necessarily require entering a code. A lot of 2FA
| schemes use a push notification where the user confirms the
| login on a separate device.
|
| Session cookies are a problem, some services provide a way to
| invalidate all session cookies, but it's often buried deeply
| in settings and users aren't aware to find the button after a
| compromise.
| echoangle wrote:
| How would a keylogger steal cookies? There are hardware
| keyloggers that only record typed text.
| TeMPOraL wrote:
| For almost everyone on the planet, being spied on by a
| hardware keylogger is about as likely to happen as getting
| eaten by a shark.
|
| Security is important, but not the be-all, end-all. People
| really should get their priorities and threat models
| straight, and start counting in denial of service and data
| loss due to security system being incompatible with human
| beings as a cost.
| akimbostrawman wrote:
| Most modern malware are software suits with multiple data
| extraction feature. Getting a hardware keylogger is
| extraordinary unlikely and at that point why not also
| consider video surveillance or evil maid attacks.
| BlackFly wrote:
| Malware can sniff one password in a similar way that malware
| can read your password manager's vault. So yeah, one malware
| and all your unique website passwords might need to be rotated
| after a recovery anyways.
|
| If the 2fa was a yubikey or some other unique made-for-purpose
| device, the accounts wouldn't need to be recovered, but TFA is
| talking about microsoft authenticator so it could very well be
| on the compromised device.
|
| The most irritating thing about security is people treating it
| as one dimensional: more or less secure. 2FA changes security
| in a complex way.
| Y_Y wrote:
| I assumed everyone salts their memorised passwords. Like you
| add something that's a function of the thing you're logging
| into, in a way that's not atrociously obvious. I think (hope)
| that anything beyond "superpassword1+facebook" is going to be
| adequate to stop a successful phish cascading to other
| accounts.
| thaumasiotes wrote:
| > I assumed everyone salts their memorised passwords. Like
| you add something that's a function of the thing you're
| logging into, in a way that's not atrociously obvious.
|
| You're thinking of something other than salting. A salt isn't
| secret. The point is to make sure that the same password on
| two services, or on two users of the same service, doesn't
| have the same hash each time.
| Y_Y wrote:
| You're dead right. It was an improper use of a specific
| technical term and that sort of thing is very annoying.
| Thank you for your service.
| autoexec wrote:
| That only matters if you reuse a memorized password. If I
| have my hacker news password memorized but never use it for
| anything else there's no need to worry about it.
| _dain_ wrote:
| _> Now, my Github access depends on the second factor, which I
| have chosen to be Microsoft Authenticator running on my phone. I
| genuinely do not know what will happen if my phone breaks down,
| so I downloaded TOTP codes from Github and even tried one to see
| if it works, and so far it does, but now I have one less TOTP
| code to use in case something happens. Moreover, since Github is
| now a special case for my password management routine, I am
| afraid I may loose those TOTP codes and be totally locked out of
| my account._
|
| You don't need a phone for this. You can put the secret key into
| your password manager and it can generate the TOTP code whenever
| you need it. KeepassXC and 1Password support it.
|
| It stretches the definition of "two-factor" but I don't care;
| like the author I'm more concerned about phone theft and losing
| access to everything.
| dandersch wrote:
| >It stretches the definition of "two-factor"
|
| I always considered the time aspect to be the more important
| "factor" of TOTP in practice. E.g., if somebody managed to peek
| over your shoulder or film you while typing in your password.
| With TOTP, they have under a minute to capitalize on that
| information. I still have that base covered with my password
| manager handling the secret key, so I never saw the appeal of
| tying TOTP to a phone.
| foreigner wrote:
| This assumes that services are handling your password responsibly
| and not e.g. storing it in clear text in a public S3 bucket,
| which in practice happens _all the time_.
| BlackFly wrote:
| Actually, the author is assuming that you will generate a
| password like `Password123!` for an obviously fly-by-night
| company and use a password manager for other websites of medium
| trust, the author states as much. My reading of his suggestion
| is that the memorized passwords are used for things like ssh or
| possibly logins on laptops/pcs. Some people have a good
| instinct for such things.
|
| This is quite reasonable.
|
| - Useless passwords for useless websites that needlessly
| require accounts. - Autogenerated passwords for websites of
| infrequent use that you don't need to trust much. - Memorized
| passwords for logins of high importance that you need to trust.
|
| Since we only have so much capacity to memorize a password, the
| idea of reusing a password for the few high importance logins
| you have can be quite reasonable.
| wobfan wrote:
| I'm just asking myself, why not use the Password generator +
| manager _always_ if you have it installed either way. I 've
| also used some of my digit-only 8-char passwords for some
| websites where I'm just indifferent about people logging into
| my account, but usually I just use the PW manager. It take
| maybe 1-2 more clicks, but more importantly, it saves me from
| the website saying "ohhh noooo please add a special
| character", and then "ohhhh sorry but theres no upper case
| character", blah blah.
|
| By always using the PW manager I have a clear and standard
| route of registering accounts that is not a lot more work, is
| way more safe by default, and also can save time if at some
| point in 2 years you want to log in again, because of some
| random event. Sure, email reset would be possible, but that
| takes time again.
|
| Another counter-argument against the article in general, at
| least in my opinion: while 2FA adds a time consuming step to
| the login, it happens rarely. I use a lot of services and
| usually always enable 2FA if it has even a single bit of
| personal or critical data. But as soon as I'm logged in, the
| access tokens or refresh tokens are valid for such a long
| time that I rarely have to do the 2FA challenge again.
| bolobo wrote:
| I use a laptop, desktop PC, phone, and 2 tablets at home.
| Another PC and laptop and tablet when I visit my parents.
| Not all of them are mine, and it is _very_ annoying to have
| to login to a website on them. You have to go through the
| unlock flow on your own device (long and complicated
| password) to access the password, and then copy the site-
| specific password (usually long and complicated) to the new
| device.
|
| It is a giant pain. I can understand why people wouldn't
| want to go through it.
| TeMPOraL wrote:
| Also, which password manager I should use anyway?
|
| As far as I can tell, there are SaaS ones, broken ones,
| no longer maintained ones, and the ones that don't work
| on multiple platforms. There's not one password manager
| I've heard of that didn't exhibit one or more of the
| above "features".
|
| "Perfect is the enemy of good", but the effort around
| making informed choice makes not using password managers
| seem better.
| _dain_ wrote:
| KeepassXC is FOSS, runs locally, is actively maintained,
| and is multi-platform.
|
| https://keepassxc.org/
|
| I've used it for years with no complaints, it's
| wonderful.
| arkh wrote:
| > It take maybe 1-2 more clicks
|
| 1-2 clicks here, a couple there, and a click heavy UI.
| Welcome to the clickodrome, where your patience is tested
| to its limits.
|
| Why do people click on everything without reading? Because
| you trained them to.
| 9dev wrote:
| That makes the questionable assumption you'll always be
| accounting for all attack vectors someone might come up with
| on services that you don't think of as dangerous. It only
| takes a single, contrived way to daisy-chain a way into
| another system using that innocuous messaging platform you
| signed up for eight years ago that can now be coerced to send
| spoofed emails in your name.
|
| A password manager with randomly generated passwords and 2FA
| is the only sane response to millions of automated attacks.
| Tractor8626 wrote:
| Author doesn't understand problem space at all.
|
| 1) Weak passwords are not ok even on throw-away accounts. Just
| because you have no use for it, doesn't mean nobody has. Sending
| spam, or impersonating you or some other creative use.
|
| 2) Nobody is going to bruteforce your password. We don't use md5
| anymore. You password will get stolen. By phishing, malware,
| social engineering, password reuse etc.
| einr wrote:
| By your own argument, if no one is going to bruteforce your
| password, what then is the issue with a weak password?
| Jnr wrote:
| Password lists are full of weak passwords. You don't brute-
| force the password, you use a password list instead.
| notpushkin wrote:
| Potato, potato. Does anybody really say "bruteforce" _not_
| meaning a dictionary attack?
| janalsncm wrote:
| The author of the article, apparently.
| giantrobot wrote:
| Credentials stuffing. Attackers can spam a site with logins
| with common passwords. Too few sites implement good
| mitigations against this because it's easy to block/lock
| legitimate users that typoed a password.
| tracker1 wrote:
| This is why I isolate authentication to a separate
| application. I also implement max attempts per N minutes
| for IP and User. Most users once authenticated are good for
| the work day. Auth going down doesn't (generally) affect
| the work.
| arkh wrote:
| > Just because you have no use for it, doesn't mean nobody has.
|
| Lot of websites you'll visit once per decade (maybe) still ask
| for account. Or things like the software you get to manage your
| gaming peripherals which nowadays all ask for an account for no
| reason.
|
| Those accounts getting hacked? I don't care. So they all get a
| shitty birthday password if they accept it. If they prefer to
| use some stupid "X uppercase, Y lowercase, Z numbers, some
| special characters" I'll make a new account next time because
| I'm not using a real email. Or just stop there.
| wvh wrote:
| That is your perspective. Not that of the site owner, or the
| internet at large, victim to any abuse somebody unkind can
| unleash.
|
| Security is a bit like traffic. If you're alone in the world,
| you do you. But you are not alone, you have a responsibility
| to others, be it passers by, fellow travellers or those loved
| ones depending on you making it back alive.
| ss64 wrote:
| If a new account has that much power to abuse the system,
| then your problem is not the 2FA security. They don't need
| to crack your account, a bad actor could just create a new
| account for themselves.
| Macha wrote:
| > That is your perspective. Not that of the site owner, or
| the internet at large, victim to any abuse somebody unkind
| can unleash.
|
| Frankly, in a lot of these cases the site owner (e.g.
| Razer) has already decided to put their interest ahead of
| mine by requiring accounts to e.g. configure peripherals
| locally so they have can harvest sign ups for their
| marketing lists or tell investors they have XXX MAUs. I
| don't care if my password choice inconveniences them in
| turn.
| janalsncm wrote:
| Sounds like you're describing a situation where every user
| must have a secure account in order avoid a problem. In
| that case, it's not just the technically-minded folks here
| who need to have secure passwords. The site itself should
| enforce password security, not individuals.
| greatgib wrote:
| Same thing for example for public tv broadcast streams. Often
| they want you to create an account with an email to watch
| streams, for totally zero use for you but they hope to be
| able to target you with ad and co.
|
| Same thing, I create a random account with random creds each
| time I want to use it. And there will be zero impact for me
| if it leaks...
| TeMPOraL wrote:
| > _1) Weak passwords are not ok even on throw-away accounts.
| Just because you have no use for it, doesn 't mean nobody has.
| Sending spam, or impersonating you or some other creative use._
|
| Why should that be _my_ problem? It reeks of the same bait-and-
| switch that banks are doing, with calling failures of their lax
| KYC /security process "identity theft", calling themselves the
| victim, and making the actual victim responsible for it.
| croes wrote:
| Depends on the purpose of the account.
|
| For instance this requires an account
|
| https://news.ycombinator.com/item?id=43245361
| autoexec wrote:
| > Weak passwords are not ok even on throw-away accounts.
|
| They can be okay for throw-away accounts, it just depends on
| the circumstance.
|
| > Nobody is going to bruteforce your password.
|
| I can assure that there are still people brute forcing
| passwords. I see it happening all the time, especially for SSH
| accounts. While you are correct that phishing and password
| reuse are problems, they are also not totally solved by using
| 2FA.
| tigereyeTO wrote:
| Author also confuses backup codes with TOTPs.
| jve wrote:
| > Once I added 2FA to my Github account, it became less secure
| for me. Because security is not only about being protected from
| intrusion, but also about being able to securely access data at
| any time and in any circumstances.
|
| Why is he mixing stuff he shouldn't? I didn't find a reasonable
| explanation why 2FA makes things less secure. Not being able to
| access your account is more secure and not less secure.
|
| This article has to do with having a backup plan to access your
| account and not with security. Or maybe "security" as in "peace
| of mind".
|
| As for Microsoft Authenticator, the data is being backed up and
| can be restored. Except Microsoft accounts, they require
| reconfiguration and... is useless to have it backed up and gives
| false sense of "security" (peace of mind).
| onli wrote:
| The 2FA adds the risk factor of being locked out. Looking at it
| that way I'd say it is valid to call that an insecurity.
|
| You are right though that this isbabouy having a backup plan.
| For example, the TOTP app I use supports exporting the logins
| into a file, which van be saved elsewhere.
| TimJRobinson wrote:
| I thought he was going to mention the stupidity of sites like
| Twitter that when you add SMS as a 2FA option you can now use
| that to bypass the password and so are vulnerable to sim
| hijacking, which given how incompetent phone company employees
| are makes your security weaker.
|
| Always use an authenticator app or physical key, most sites that
| do SMS 2FA will then allow hackers to use it to bypass knowing
| your password.
| fmajid wrote:
| This is compounded by the fact most 2FA implementations are
| security theater not phishing-resistant, the sole exception being
| FIDO2/Webauthn (e.g. Yubikeys), and Passkeys, but passkeys are
| really single-factor authentication. Both FIDO and passkeys have
| serious usability challenges, though.
|
| What's worse, the most common scheme, SMS-based authentication
| can lead to denial of service, e.g. you are roaming and do not
| have access to texts, or have your account SIM-jacked as this
| seems to be very popular way to steal people's cryptocurrencies.
| _dain_ wrote:
| _> you are roaming and do not have access to texts_
|
| I truly despise this. It effectively disenfranchises people for
| living outside of areas with good mobile coverage. Banks or
| utility payments or parking meters(!) or whatever should not be
| gated behind cellphone reception. Nevermind people who can't
| use a phone at all ...
| bradley13 wrote:
| This. In theory, passkeys should be great. Sort of an SSH-for-
| the-masses.
|
| Unfortunately, the industry has mangled the implementation,
| making them basically useless.
| Spivak wrote:
| I mean they're not totally useless, in the current
| implementation they just can't replace passwords. I have a
| bunch of passkeys in my Bitwarden and they function as a "log
| in bypassing the 2FA screen" button. I get to skip the "we
| sent a code to your phone/email/butthole" flow.
| dcow wrote:
| Funny how that always happens. Passkeys were supposed to be
| great and what you ended up with is platform players abusing
| their position to push lock in to their own passkey solutions
| over fair access to arbitrary 3rd party providers.
|
| When they do work smoothly they aren't useless though.
| gclawes wrote:
| Android has been surprisingly awesome with cross-platform
| passkeys (i.e. google lets you use BitWarden/1Password/etc
| pretty transparently).
|
| Anything Apple related is another story...
|
| There's some good movement in the linux desktop space I'm
| excited about: https://github.com/linux-credentials/linux-
| webauthn-platform...
| ziml77 wrote:
| I'm using iOS and Passkeys from 1Password work there too.
| No problems with any browser on macOS either.
|
| On iOS I can even see a list of password & passkey
| providers, so I can ensure that the Apple one is toggled
| off (as well as MS Authenticator which can also provide
| those it seems)
| autoexec wrote:
| Passkeys can't always protect an account against phishing
| either (https://cyberpress.org/passkeys-with-aitm-phishing-
| attacks/) they just make it more difficult for scammers.
| vel0city wrote:
| The article agrees passkeys can't be phished. They
| acknowledge they just push users to go through an unnecessary
| account recovery and then phish those other credentials.
| echoangle wrote:
| > Because security is not only about being protected from
| intrusion, but also about being able to securely access data at
| any time and in any circumstances.
|
| Is it though? Wouldn't that be some kind of safety thing? I think
| having no way to access the data would be ultimate security,
| that's why there's always a tradeoff between security and
| usability.
| kalaksi wrote:
| It is. Confidentiality, integrity, and availability.
|
| Edit: see e.g.
| https://en.wikipedia.org/wiki/Information_security
| echoangle wrote:
| Interesting. Makes sense if you think about it though,
| otherwise protecting from ransomware wouldn't fall under
| security.
| karel-3d wrote:
| > Lately some services started requiring 2FA. One of them is
| Github. Once I added 2FA to my Github account, it became less
| secure for me. Because security is not only about being protected
| from intrusion, but also about being able to securely access data
| at any time and in any circumstances.
|
| >
|
| > Now, my Github access depends on the second factor, which I
| have chosen to be Microsoft Authenticator running on my phone. I
| genuinely do not know what will happen if my phone breaks down,
| so I downloaded TOTP codes from Github and even tried one to see
| if it works, and so far it does, but now I have one less TOTP
| code to use in case something happens. Moreover, since Github is
| now a special case for my password management routine, I am
| afraid I may loose those TOTP codes and be totally locked out of
| my account
|
| What? That's not what security means. Sure, you traded
| convenience for security.
|
| Why is this upvoted at all?
| TeMPOraL wrote:
| Because the current obsession with security is making systems
| _unsafe_ and unreliable for users, all while trying to get
| those users more dependent on said systems in their daily
| lives.
|
| What is the biggest risk factor with Google account _for me_?
| Is it an attacker guessing my password, impersonating me,
| stealing my photos? No. It 's _me breaking my phone_ , and no
| longer being able to pass 2FA[0][1]. The second biggest risk?
| Me typing a wrong comment or YouTube, or doing any other minor
| transgression against ToS of some Google service, and losing
| access to everything in one go, with no recourse[2].
|
| Note that literally _nothing_ in meatspace ever requires as
| careful management over years to decades, as 2FA does. There is
| _always_ a recovery procedure. You may need to stop by the
| court or a notary, but no matter the fuckup, you can _always_
| recover access - to everything _except_ modern Internet
| services.
|
| --
|
| [0] - Yes, I have the security codes I generated _15+ years
| ago_ ; I have them on paper, _somewhere_. Like most people, I
| suck at keeping small paper documents accessible and available
| over years.
|
| [1] - Also yes, I did break my phone, and I survived this
| without data loss only _because_ I had a complex setup around
| Pebble and Tasker, that allowed me to operate the phone with
| non-functioning screen remotely to the point I could mirror the
| display to the computer and continue from then. Most people in
| most situations can 't do that.
|
| [2] - Other than complaining on HN and hoping some Googler will
| advocate internally for me - which, as far as I know, they're
| _explicitly not allowed to do_ , and it's a career-risking
| move.
| ozim wrote:
| Well OP is kind of correct because in security importance is
| given to CIA Triad: Confidentiality, Integrity, Availability.
|
| Availability is important part of any system, if you lock out
| people, system will be secure but it stops serving its purpose.
|
| Where OP fails is he seems not to understand password leaks and
| how much password+e-mail+phone number+other info lists are out
| there.
|
| There is credential stuffing and password spraying running
| around from leaked passwords, so you can try dozen users on FB
| and just hit jackpot with one or couple, you don't have to
| brute force each one of them as there are countermeasures for
| that.
|
| Even if you have weak password with a trick it is trivial to
| find out your trick when your password leaked from 5-10
| services where you used the same e-mail.
| _dain_ wrote:
| _> What? That's not what security means. Sure, you traded
| convenience for security._
|
| Your Google/Microsoft/FB/etc accounts are used to sign in or
| access information about other extremely important things in
| your life, like your bank, payroll, travel companies, health
| records, taxes, insurance, everything really. If you get locked
| out of those SSO "identity providers", you get transitively
| locked out of everything else. Which means you could end up
| without access to money, unable to pay rent, unable to travel,
| contact friends for help, etc.
|
| In other words, your _physical_ security would be threatened,
| as in you might literally become homeless and die of exposure.
| megous wrote:
| Handling recovery codes is part of security. There are many
| gotchas even with a typical recommendation to print them and
| store them physically.
| latexr wrote:
| > Because security is not only about being protected from
| intrusion, but also about being able to securely access data at
| any time and in any circumstances.
|
| This felt like the author bending over backwards to justify their
| choice. They find 2FA _less convenient_ and conflate it with
| being less secure. It's not the same thing.
|
| It's OK to say "not all my accounts are equally important and I
| need to access some of them in situations where 2FA and complex
| passwords aren't worth it". It's not OK to sell the idea that 2FA
| does not generally offer security.
|
| This reminded me of the "SEO expert" a few years back which was
| trying to convince everyone, with wrong information, to not use
| HTTPS (which, I realise only after writing this, the author's
| website also doesn't use).
| guappa wrote:
| If we define data that can't be accessed by anyone as secure,
| throwing disks in a furnace is how you achieve security.
|
| I don't think this definition is very helpful though. So I
| prefer the one where the entities that need to have access
| still can access.
| latexr wrote:
| > I don't think this definition is very helpful though.
|
| Because it's a straw man, and straw men aren't helpful for
| discussion. No one is suggesting making data wholly
| inaccessible.
|
| Data that you cannot access "at any time and in any
| circumstances" (author's words) can still be secure. A fairer
| analogy would have been storing disks in a locked safe in
| your home. It's not as _convenient_ to access it, but it is
| secure. Should you do that for all your data? No, but neither
| have I advocated for that. I very clearly stated that I think
| it's OK to have different levels of protection for different
| types of data.
| mouse_ wrote:
| If I can't access money that I secured, I didn't secure it
| properly.
| latexr wrote:
| Which has nothing to do with my argument. See the reply to
| the other user, which expands.
|
| https://news.ycombinator.com/item?id=43421721
| Spooky23 wrote:
| Security is about risk management. If the value of what you're
| protecting is low, or the consequences of not accessing
| something is high, than the MFA control may not add value.
|
| The problem is in general people are really bad at assessing
| risk. You tend to see extremes.
| seethishat wrote:
| For the author... you may export/backup the TOTP secret from the
| TOTP app (MS Authenticator in this example) and save that
| someplace secure. You may use any TOTP app with that secret to
| generate codes to log in.
|
| I typically do this as a safe guard in case the device that is
| running the TOTP app breaks or fails in some way.
|
| I'm old enough and my passwords are random enough that I don't
| worry about them being guessed. However, I do worry about web
| security in general and the fact that companies are basically
| black boxes with loads of young inexperienced developers. They
| may be storing our passwords as plaintext strings and have them
| in a public S3 bucket. But, if you want one of my YubiKeys, you'd
| have to find me and physically steal it from me and hope I don't
| notice.
|
| So there are some useful things with regard to 2FA.
| bradley13 wrote:
| He's not wrong. I use a password manager that stores passwords
| only locally, not in the cloud. I can generate arbitrarily
| complex passwords and never have to worry about how hard they are
| to type or remember.
|
| 2FA makes my workflow significantly more difficult. As a result,
| for non-critical sites, I have started allowing the browser to
| store my passwords, thus relying on the 2FA-authenticator for
| security. This result is likely _less_ secure overall, since the
| browser 's password storage could realistically be compromised.
|
| That said, I do have to acknowledge the point in another comment
| that phishing may be the bigger threat. Log into a fake site with
| a password but no 2FA, and you are toast.
| postalrat wrote:
| What is the difference between a secure password synced with a
| password manager and a cookie that doesn't expire synced with a
| browser or extension? I don't see much difference so why bother
| even having a password?
| megous wrote:
| The difference is that cookies are not even encrypted and you
| can get all of them by `sqlite3 .dump` on `cookies.sqlite`
| file, while password manager likely offers more protection,
| since that's the point of it. :D
|
| Also SID are ephemeral and expire, while passwords are not
| supposed to be.
|
| Session IDs may be tied by the backend to a client IP
| address, or some such, but likely that's not done very often,
| and may not be that useful.
| 9dev wrote:
| What if your cookie is compromised and you want to ensure the
| attacker cannot log into your account anymore?
| apples_oranges wrote:
| Off topic: This is a website without HTTPS
| red369 wrote:
| Interested in your thoughts (and anyone else's) - is this OK
| for a website just serving content for consumption only,
| without logins, forms, etc?
|
| Would people rather that no-one can MITM and see which articles
| they read on the site? Or is it about conditioning people do
| demand HTTPS so that it's there when they need it?
|
| BTW: I feel I might be missing the real issues or
| unintentionally straw-manned them.
| jesprenj wrote:
| I think that 2FA is widely required not to protect users of
| online services but to protect the services themselves and/or
| their administrators from a burden of annoying work. Users that
| create accounts with weak passwords because they don't care about
| their accounts present a problem for the company behind the
| service, because their accounts will eventually become used as
| puppets of spammers etc. By requiring a very complicated login
| procedure, spammers won't try to hack those unused accounts and
| exploit them, resulting in less email being sent to abuse@.
|
| And I think that's the most probable reason 2FA is _required_
| today on most online services.
| dcow wrote:
| Nailed it. 2FA is about businesses doing risk management.
| donohoe wrote:
| It's hard to take this advice from someone who's site doesn't
| even support HTTPS.
| jampekka wrote:
| HTTPS isn't very critical for a static site. Only the Sith, and
| security zealots, deal in absolutes.
| SahAssar wrote:
| HTTPS protects the integrity and confidentiality (to a
| certain point, see ESNI) of what you visit. Those are
| important even if you don't submit any additional data to the
| server.
|
| Disclaimer: I'm not a sith or a security zealot.
| xpil wrote:
| I've noticed another issue: 2FA software fragmentation. Over the
| past 30 years, I've accumulated more than 600 online accounts
| (many of them dormant), with about 25-30% offering 2FA. As a
| result, I now have three separate apps for generating codes. I
| could consolidate them into one, but, frankly, I'm too lazy. So
| instead, I often find myself scrambling between different 2FA
| apps and devices just to locate the right account.
| perlgeek wrote:
| There are really two aspects two 2FA:
|
| 1: you as a user might want to protect your account
|
| 2: A website provider wants to secure their own business
|
| If it's about 1, then the argument "I don't reuse passwords" hold
| some water. It doesn't protect you from somebody getting access
| to a plaintext copy of your requests (for example on the load
| balancer that terminates the TLS), but that's only a small part
| of potential attack surfaces.
|
| But from the perspective the website owner, they might suspect
| that many of their users reuse passwords between sites. 2FA is a
| great defense against that, and also against brute force
| attempts.
| PinguTS wrote:
| There is another issue with all those growing 2FA/MFA protected
| accounts: managing your unexpected death.
|
| How do you teach your beloved ones to access your accounts. And
| they need to remember what to do. For some accounts may it
| doesn't matter. For others that means to be able to end the
| subscription. Because not all subscriptions are associated with a
| credit card, which just expires.
|
| But if you allow to contact a company by a third party to cancel
| and or change things then this becomes the go to for social
| engineering.
| croes wrote:
| Isn't the device to access the password manager mostly the same
| device used for 2FA?
|
| I hope most people use a password manager.
| dewey wrote:
| Most people are just storing them in the browser but that's
| not stopping people from coming up with easy to guess
| passwords.
| pests wrote:
| Services like FB have the concept of a legacy contact, an
| account that can manage your page after death. Also the concept
| of your profile switching to a memorial page, with your legacy
| contact doing moderation of posts.
|
| I did the math years ago and even back then, thousands of users
| would pass daily and now with most of the world population on
| FB it probably comes in handy.
| bobbiechen wrote:
| In the US, you have a legal right to access accounts of the
| deceased through RUFADAA. It's not as simple as logging in
| (usually requires a court order) but it's possible. I wrote
| about it and related issues here:
| https://digitalseams.com/blog/what-happens-to-your-online-ac...
|
| (and recently discussed on HN:
| https://news.ycombinator.com/item?id=42991112)
| 1970-01-01 wrote:
| OLD NEWS:
|
| Something you have.
|
| Something you know.
|
| Something you are.
|
| Pick two.
|
| NEW: Dismiss anything that is a hybridization. That is 1.5FA
|
| It's 2025. 0-days are rampant. If you're not at 2.0FA, you're at
| a high risk of getting popped.
| alwayslikethis wrote:
| I wish sites offered a way to opt out of 2FA if your password has
| enough entropy (128 bit random string). These are not getting
| cracked anytime soon. I store my TOTPs in keepassxc with the
| other passwords anyway. The keepassxc database is the "something
| you have" and its password is "something you know", and the
| random string is a testament to that. Also stop forcing SMS 2FA
| please. I don't want to need to have a phone.
| evolve2k wrote:
| > I never spell it out, let alone write it down, but it is in my
| muscle memory as I haven't changed it for years. There is no way
| someone on the internet can break into my ssh account or gmail
| account protected by such a password.
|
| Oh dear. The issue isn't the brute force, it's that the online
| services leak and get cracked. And in an instant a single script
| takes the newly discovered username password combo and starts
| hammering it into the top 10000 websites, all within moments of
| the leak data becoming available.
|
| Your super secret favourite phrase is worth crap once leaked
| alongside your email address.
|
| Further don't choose Microsoft for your Auth app, Go with an open
| source option, maybe one that encrypts and syncs so you have
| multiple devices just in case.
| ajd555 wrote:
| I could not agree more with this comment. OP entirely misses
| the point of 2FA. I sleep so much better at night knowing that
| I have different passwords for every account, and 2FA where
| possible. One should not write about 2FA when one uses the same
| "uncrackable" password everywhere...
| autoexec wrote:
| Maybe I missed it (it's early and I haven't even had coffee
| yet) but where did the author say they resued the same
| password over multiple sites?
| femtozer wrote:
| Not sure I understand -- passwords are generally hashed in
| databases. Even if leaked, an attacker would still need to
| brute-force the hash to retrieve the actual password, wouldn't
| they?
| evolve2k wrote:
| You'd think so. But over and over plain text leaks of
| passwords is the practical reality of the modern internet. A
| disgruntled staff member, poor tech practices or someone
| working out a way to get in and get access.
|
| The https://haveibeenpwned.com/ project regularly shares new
| breached datasets. Reusing passwords across websites without
| MFA is just not not not recommended in 2025.
| parliament32 wrote:
| "Generally", sure. How do you guarantee every service you've
| ever signed up for uses proper salting and hashing though?
| All it takes is one for your entire security model to go down
| the drain.
| autoexec wrote:
| > Oh dear. The issue isn't the brute force, it's that the
| online services leak and get cracked. And in an instant a
| single script takes the newly discovered username password
| combo and starts hammering it into the top 10000 websites, all
| within moments of the leak data becoming available.
|
| This is only ever a problem if your password is reused. Don't
| reuse passwords and if some website is hacked and they were
| storing your password in plaintext you just have to reset your
| password (the same way everyone else does, 2FA or not)
| c22 wrote:
| Also don't re-use email addresses.
| robertlagrant wrote:
| > This is only ever a problem if your password is reused
|
| That is the context of the reply, although I think they
| misread the article.
| Justsignedup wrote:
| the weird thing is:
|
| - if you use 1password (an example), then you're generating a
| bunch of random and unique passwords for every site - questions
| to verify you as a 2fa tends to be less secure since you tend
| to make simple answers for those. And they're not convenient to
| enter into 2fa apps. - 2fa apps are typically great ways to
| guarantee one bit of randomness into the process
| tracker1 wrote:
| I use the same app for most 2fa and the passwords themselves
| (Bitwarden). It makes the 2FA slightly weaker being in the
| same app, but infinitely more useful. It does bug me that
| they (Bitwarden) as a service want me to use 2FA for first
| logins, which makes it harder to access. My master passphrase
| is long, unique and only on their app/site.
| tracker1 wrote:
| While true... this is less of an issue if the breached database
| includes strongly encrypted passwords with individual salts. At
| least half of them are going to be part of existing breaches,
| but you aren't going to bother with the rest as it can/will
| take an exponential amount of time if they are treated
| properly, leaving top's password safe(ish).
| tomjakubowski wrote:
| Passwords can leak in many ways other than database breaches.
| Malicious front-end code and accidental logging that goes to
| a public place like an S3 bucket are two examples.
| 9dev wrote:
| So I am supposed to trust that the random forum I have to
| sign up for to view the solution of a question securely
| hashes the password I send them?
|
| That's pretty much like handing you car keys to a random
| person on the street and be confident they will take it to
| the bank and put it in a locker.
| megous wrote:
| > I never spell it out, let alone write it down, but it is in my
| muscle memory as I haven't changed it for years. There is no way
| someone on the internet can break into my ssh account or gmail
| account protected by such a password.
|
| SSH... no, they can't.
|
| Gmail... yes, you're basically giving your password in plaintext
| to someone on the internet.
|
| I dislike 2FA for similar reasons, but I would rigorously
| segregate remembered passwords between those shared with some
| service, and those used locally.
| gibibit wrote:
| I agree with the article. Maybe businesses are trying to protect
| themselves, but as a user, mandatory 2FA reduces the level of
| security I can achieve for myself.
|
| Because security is not just confidentiality, it's also
| availability: the "Security CIA Triad" is Confidentiality,
| Integrity, and Availability.
|
| If I can lose access (availability) to my online account by
| losing some physical item (e.g. lost cell phone), or if some
| third party can prevent me from accessing my 2FA (e.g. banned
| from my email provider by DMCA takedown request), then I have my
| availability, and hence overall security is at risk.
|
| Additionally, requiring a phone number for online services means
| that the confidentiality of my identity is reduced. It becomes
| impossible to be anonymous. For instance, you can't use Signal
| messenger without a phone number, so there's a chance your
| identity can be leaked.
| gpi wrote:
| Can't seem to access the site over https.
___________________________________________________________________
(page generated 2025-03-20 23:01 UTC)