2FA or Not 2FA(mikhailian.mova.org)
mikhailian.mova.org
2FA or Not 2FA
http://mikhailian.mova.org/node/295
152 comments
> 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)
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)
> 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.
That is the context of the reply, although I think they misread the article.
Also don't re-use email addresses.
The larger problem is when your password gets hacked for whatever reason that the MFA protects your account.
Anyone else here had friends have their say Instagram account hacked, none ever have MFA on and it causes great distress.
MFA IS a good idea for multiple reasons.
Anyone else here had friends have their say Instagram account hacked, none ever have MFA on and it causes great distress.
MFA IS a good idea for multiple reasons.
MFA is bad idea for as many reasons if not more: complexity of implementation, variety, digital sovereignty... to name a few.
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
- 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
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.
Master password that you share with a third party?
I probably do not understand how Bitwarden works, but this feels wrong anyway.
I probably do not understand how Bitwarden works, but this feels wrong anyway.
If trust issues and paranoia are sufficient, you can definitely self-host the server portion of the application, and many do. ;-)
Bitwarden is open-source enough to where all functionality can be self-hosted and run on one's own and reviewed. IIRC, there are a couple of non-floss modules for the commercial release in different directories under source control iirc... Some are more purist than others.
Bitwarden is open-source enough to where all functionality can be self-hosted and run on one's own and reviewed. IIRC, there are a couple of non-floss modules for the commercial release in different directories under source control iirc... Some are more purist than others.
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).
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.
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.
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.
It's also less of an issue if the passwords never get leaked at all. The question is how much of a bet you're willing to make on the security practices of all of the sites where you have an account following this practice, and at least to me it doesn't seem like a smart.
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...
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?
[deleted]
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?
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.
The https://haveibeenpwned.com/ project regularly shares new breached datasets. Reusing passwords across websites without MFA is just not not not recommended in 2025.
"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.
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.
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.
> 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.
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.
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 zéro 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...
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...
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.
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.
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.
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.
> 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.
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.
> 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.
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.
I love this, yes the crime of getting a loan with stolen or fake credentials used to be called "bank fraud" and it was the bank's problem.
Now it's called "identity theft" and they've convinced many of us it's our problem. So much that people pay the banks to buy "identity theft protection"!
Now it's called "identity theft" and they've convinced many of us it's our problem. So much that people pay the banks to buy "identity theft protection"!
Depends on the purpose of the account.
For instance this requires an account
https://news.ycombinator.com/item?id=43245361
For instance this requires an account
https://news.ycombinator.com/item?id=43245361
> 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.
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.
[deleted]
Author also confuses backup codes with TOTPs.
OP here. It's a typo and should read OTP.
This accidental confusion between TOTP and OTP is by itself an argument against complex alternatives to login+password.
This accidental confusion between TOTP and OTP is by itself an argument against complex alternatives to login+password.
By your own argument, if no one is going to bruteforce your password, what then is the issue with a weak password?
Password lists are full of weak passwords. You don't brute-force the password, you use a password list instead.
Potato, potato. Does anybody really say “bruteforce” not meaning a dictionary attack?
Yes, plenty. It's not great for passwords, (but sometimes it still is! Sometimes sites using MD5 still get popped) but there's plenty of other problem spaces where brute forcing still means brute forcing.
Sorry, forgot to clarify! Yeah, the context matters here: if you’re cracking something like a numeric PIN, or looking for something like a hash collision, you might want to iterate through all possible solutions, randomly or sequentially.
The author of the article, apparently.
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.
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.
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.
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.
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.
- 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.
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.
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!
It's good UX for websites with extremely long periods between logins. Like a service you access once a year, or even every two years. Or a service where you might never have to log in ever (I run such a thing at work).
I would not want this for my google account or the like.
I would not want this for my google account or the like.
If you pop a Google account, Reddit no longer has 2FA, just as an example. Plenty of examples of stupidity like that around.
(Logging into Reddit with a Google account bypasses any and all forms of 2FA auth.)
(Logging into Reddit with a Google account bypasses any and all forms of 2FA auth.)
> 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.
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.
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.
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.
For a few years now, there's also been the option on Android to avoid giving permanent permissions to most apps that request use of one; when an app requests a permission for the first time, I'm prompted to choose from the options "allow only this time", "allow only while using the app", or "allow always" (in addition to having the option to completely deny the permission of course, although in many cases an app might refuse to function if that's chosen). Scanning TOTP QR code seems like a really great use-case for the "allow only this time" option; presumably adding a new TOTP secret is a pretty infrequent reason for opening the app compared to getting a code from an existing one, so having to manually accept the request each time doesn't seem like it would be that much work.
I'm not familiar with with iOS to know if something similar to this exists for it, but I'd honestly be more surprised if there _isn't_.
I'm not familiar with with iOS to know if something similar to this exists for it, but I'd honestly be more surprised if there _isn't_.
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.
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.
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.
>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.
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.
>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.
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.
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.
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.
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.
Unfortunately, the industry has mangled the implementation, making them basically useless.
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.
When they do work smoothly they aren’t useless though.
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...
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...
Apple have been the best in my experience. On apple devices all 3rd party passkey providers are shown at the same time in the same UX where you’d choose iCloud (their native provider)
Google Android may be good, but Chrome is not doing right yet. Chrome still tries to get you to use itself i stead of delegating to the platform selection box.
Google Android may be good, but Chrome is not doing right yet. Chrome still tries to get you to use itself i stead of delegating to the platform selection box.
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)
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)
Why are they useless? I log into GitHub, Google and Discord using passkeys, and it's very convenient being a single mouse click.
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.
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.
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.
>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 ...
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 ...
I don’t have an international phone plan. When I travel overseas I cannot access my bank account and my primary credit card randomly asks for a phone number verification that I cannot update.
I tried buying an sms number from twilio so that I could receive 2fa while out of the country but my bank (PNC) would not accept any phone number unless it was from one of the 4 major carriers in the US!
My credit card (capital one) seems to have a phone number on file from Mastercard. If I change my phone number in capital one, whenever I get into the Mastercard extra verification, it does not use the updated number. I have no idea how to get Mastercard to update it. I just ended up using a different credit card!
I tried buying an sms number from twilio so that I could receive 2fa while out of the country but my bank (PNC) would not accept any phone number unless it was from one of the 4 major carriers in the US!
My credit card (capital one) seems to have a phone number on file from Mastercard. If I change my phone number in capital one, whenever I get into the Mastercard extra verification, it does not use the updated number. I have no idea how to get Mastercard to update it. I just ended up using a different credit card!
I moved from the US to the UK. I ported my US mobile number to Twilio, but that service is incredibly unreliable even for basic things like forwarding a call or a SMS. I had another number on Google Voice, and moved all my US accounts to it whenever possible.
The great thing about Google Voice is that since Google doesn't believe in humans providing customer service (or more generally in providing customer service, period), there are no gullible CSRs that can be conned or bribed into SIM-swapping you unlike the mobile carriers.
The great thing about Google Voice is that since Google doesn't believe in humans providing customer service (or more generally in providing customer service, period), there are no gullible CSRs that can be conned or bribed into SIM-swapping you unlike the mobile carriers.
The bad thing about Google Voice is if Google closes your account then you're screwed.
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.
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.
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.
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.
> 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).
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).
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.
The problem is in general people are really bad at assessing risk. You tend to see extremes.
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.
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.
> 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.
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.
If I can't access money that I secured, I didn't secure it properly.
Which has nothing to do with my argument. See the reply to the other user, which expands.
https://news.ycombinator.com/item?id=43421721
https://news.ycombinator.com/item?id=43421721
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?
BTW what's the sentiment on passkeys?
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.
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.
Most consumer passkey implementations are lock-in. https://arstechnica.com/security/2024/12/passkey-technology-...
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.
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.
I was referring to device bound discoverable credentials and saying all implementations that an average Joe will run across have a sync fabric deliberately. Platform lock-in is a different thing.
AFAIU the attestation referred to here won’t be signed so any implementation can say anything. It’s just supposed to be ise for things like showing the user a logo so they know where their passkey is stored.
AFAIU the attestation referred to here won’t be signed so any implementation can say anything. It’s just supposed to be ise for things like showing the user a logo so they know where their passkey is stored.
Platform/vendor lock-in != device bound
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.
But yeah, anything resembling a phone passkey seems to have a sync fabric behind it.
Something I don't see talked about often regarding passkeys, is that they seem to be useful in addition to other methods, not instead.
I've been thinking that they allow you to have long, non-memorisable unique passwords for an account (1), and then add passkeys on the devices you use often. The long, non-memorisable password isn't inconvenient because you don't need to use it, and the passkeys which are used day to day are resistant to phishing & keyloggers (as I understand).
However, I don't know if that is how they're being used or marketed.
1) Perhaps even 2FA too, which wouldn't be as inconvenient if it's only used rarely. Given the points raised in this article, I'm rethinking whether that is necessary.
I've been thinking that they allow you to have long, non-memorisable unique passwords for an account (1), and then add passkeys on the devices you use often. The long, non-memorisable password isn't inconvenient because you don't need to use it, and the passkeys which are used day to day are resistant to phishing & keyloggers (as I understand).
However, I don't know if that is how they're being used or marketed.
1) Perhaps even 2FA too, which wouldn't be as inconvenient if it's only used rarely. Given the points raised in this article, I'm rethinking whether that is necessary.
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.
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.
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.
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.
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.
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.
It is a giant pain. I can understand why people wouldn't want to go through it.
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.
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.
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.
https://keepassxc.org/
I've used it for years with no complaints, it's wonderful.
I use proton pass (SAAS). I just figure I should be paying for core internet services like email, storage, passwords, calendars, etc. so that ideally my interests are aligned with my provider. I use the services on windows, android and linux regularly. So I can confirm that proton pass, email and vpn all work on those three operating systems. I cannot imagine they wouldn't work on MacOS.
Yes, you pay, but I see that as acceptable and expected for the service offered.
Yes, you pay, but I see that as acceptable and expected for the service offered.
> 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.
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.
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.
A password manager with randomly generated passwords and 2FA is the only sane response to millions of automated attacks.
You aren't going to use a password manager to access your password manager is basically the point I was getting at. So you are always going to have some access managed via passwords or biometrics if that is available to you (finger print readers are instead unreliable for me). The fundamental access to password management isn't going to be managed by a password manager.
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.
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.
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?
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.
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.
In this case the cookie would be as permanent as a password. I was just thinking if convenience is a priority why even have a password when the cookie is just as secure.
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.
And I think that's the most probable reason 2FA is _required_ today on most online services.
Nailed it. 2FA is about businesses doing risk management.
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.
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.
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)
(and recently discussed on HN: https://news.ycombinator.com/item?id=42991112)
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.
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.
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.
>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.
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.
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.
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.
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.
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.
How would a keylogger steal cookies? There are hardware keyloggers that only record typed text.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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).
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).
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.
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.
1password for unique long passwords per account. I store OTP in 1password as well for the extreme convenience it offers on desktop & mobile.
Backup TOTP are put in .txt files for each service and in a folder encrypted by Cryptomator (using a unique pw not used by any other services, esp. 1password). This encrypted folder is put on flash drive on my keychain and synced into my google drive folder.
This feels to me like a pretty good balance between convenience and security. Not 100% of my eggs are in one basket, but it's true that my 1password account password needs to be long and well-guarded and never re-used for anything else. Also putting a lot of trust into 1password to not get breached...
Backup TOTP are put in .txt files for each service and in a folder encrypted by Cryptomator (using a unique pw not used by any other services, esp. 1password). This encrypted folder is put on flash drive on my keychain and synced into my google drive folder.
This feels to me like a pretty good balance between convenience and security. Not 100% of my eggs are in one basket, but it's true that my 1password account password needs to be long and well-guarded and never re-used for anything else. Also putting a lot of trust into 1password to not get breached...
> Backup TOTP are put in .txt files for each service and in a folder encrypted by Cryptomator
I do something similar but instead use KeePassXC to securely store copies of totp secrets.
I do something similar but instead use KeePassXC to securely store copies of totp secrets.
> 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.
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.
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.
> 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.
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.
It is. Confidentiality, integrity, and availability.
Edit: see e.g. https://en.wikipedia.org/wiki/Information_security
Edit: see e.g. https://en.wikipedia.org/wiki/Information_security
Interesting. Makes sense if you think about it though, otherwise protecting from ransomware wouldn’t fall under security.
I know lots of people who have been hacked with passwords... If you reuse it, it gets leaked, if you don't reuse it, it's very hard to remember all your 74653 different accounts.
And some of us don't have reliable muscle memory... Having our SSH password suddenly vanish would be undesirable.
And some of us don't have reliable muscle memory... Having our SSH password suddenly vanish would be undesirable.
It’s hard to take this advice from someone who’s site doesn’t even support HTTPS.
HTTPS isn't very critical for a static site. Only the Sith, and security zealots, deal in absolutes.
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.
Disclaimer: I'm not a sith or a security zealot.
HTTPS everywhere also makes internet less decentralized.
This is even more important.
This is even more important.
Can't seem to access the site over https.
Off topic: This is a website without HTTPS
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.
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.
It's not just about seeing, a man in the middle could also modify the content.
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.
I agree although sites still might concerned about password re-use they could just have an option to generate what is basically a key. Instead of a password and some sort 2fa "token" which is basicallly a key. Accept for that 2fa token only a low amount the entropy is capable of generating is used.
I also agree sms 2fa is just broken/garbage.
I also agree sms 2fa is just broken/garbage.
> 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?
>
> 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?
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.
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.
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.
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.
>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.
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.
Handling recovery codes is part of security. There are many gotchas even with a typical recommendation to print them and store them physically.
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.