This is absolutely getting unwieldy to the point of being fucking ridiculous and unusable.
I've been in tech for 25+ years. I'm very familiar with security, and I have the internal endurance to sit patiently and work through IT-related issues.
However, at this point, there are just too many broken ways and I'm at the point of giving up. I use LastPass and if that somehow gets hacked or phished, I lose absolutely everything. I'm waiting for the next virus or phishing attempt to steal my LastPass password.
I use multi-factor authentication on some accounts, but if they use SMS like many sites do, I can get my phone number stolen from me and then I lose access.
I use Gmail and Google Authenticator, but if I somehow do something to piss off Google, I can lose my gmail account and access to Google Authenticator and then I'm really fucked. I've lost some gmail accounts because they will ask me for security questions when I log in with the correct password, and I don't remember them so my account gets locked, so they're gone forever.
What we need is a single way to do login, MFA and security across every single site. We can't have every company incorporating their own methods. We need standardized customer support, where Tier 1 customer support can't give you access to things like credit card numbers, last 4 digits of SSN, or change passwords. Changing passwords needs to be a higher level, better trained customer support.
There needs to be an ISO standard that is well thought out and implemented by all the vendors, or at least all the big vendors. If there's a standard way of doing security but also a standard way of doing customer support and what data is exposed to various levels of customer support, then social hackers can't take partial info from sites A and B, and use that to social engineer site C.
This has to be simplified because it's absolutely unwieldy even for a veteran like me. There are too many ways I can get hacked and we are all just sitting ducks. The only thing protecting us is that we aren't high-value targets.
I have lost the ability to log in to my original gmail account, so I advise planning for that to happen some day.
What happened to me is that I went to reset my password one day, and they required I confirm my backup email which I no longer had access to.
Even though I had access to read messages sent to the gmail account itself, and I had access to the phone number connected to my gmail account, without my backup email as well, I could not get anywhere. The recovery procedure that asks you questions didn't get me anywhere either, because I couldn't possibly answer things like exactly when I started using gmail due to using it for too long. And I even had an archive of a few years of my email, that ought to have enabled me to answer the other questions, but it didn't work and there is no feedback nor escalation procedure.
I may well still be logged in due to a certain buggy/obsolete device I have; I think it's probably been five years, but I don't believe I will ever be able to log in or reset my password again.
It didn't have a great deal of impact on my life in the sense that I was able to simply switch to a new email account, but I feel a certain sense of loss at not being able to use the one and only address that was my full name. More significantly, it indelibly engraved in my mind, the kafkaesque, diabolical nature of Google, the ingrained lack of customer service, the way in which, while they may mostly be geniuses, when they screw up, they won't admit it and there's no appeal.
The thing that I object to on an emotional and logical level, is that adding a backup authentication method removed the ability to use the primary authentication methods. If I just never added the backup email I'd be fine! I can't accept that makes sense, that it adds security. Something the user does to make them safer should not make them less safe.
My big mistake was to use 2FA - more precisely authenticator.
Around the same time my old phone broke and i had to change the password.
I must have mistyped the password while changing it in both fields and since then have never managed to re-access the account. I have old passwords, backup email, previous contacts, phone, ... But i cant restore the password because i hadnt yet set up authenticator on my new phone.
My fault? Probably. But that there's no way out, no option beyond the horrible restore wizard - that's Google's irresponsibility. How many millions must have lost access to their gmail accounts by now?
How is this any different from what you have on your phone?
If someone hacks your phone they have access to all your email, whether you have 2fa set up or not. If someone hacks your computer in this case then they also get access to all your email.
The thing that 2fa is good at is preventing hackers from logging in if they guess or find out your password. If your device is compromised then everything you do on it is vulnerable, no matter how many factors you have.
I mean, it's game over in pretty much any situation that your endpoints are compromised.
It's incorrect to take these measures as giving perfect security. They're efforts to greatly increase the cost for attackers. It's a pretty good improvement to increase effort from "having a password" to "having remote access to your computer."
Alternatively if you dont want your keys stored in Authys cloud, you can replace Authy with AndOTP and export your keys in to an encrypted file which can be imported later back in to your phone when needed.
This happened to me ages ago and I was also unable to recover my accounts but recently I tried again, and I was able to recover 1 of my 2 lost accounts. The second one is pending. It seems Google has changed the process and after a semi-failed attempt to recover they actually pass it to a human. All my previous attempts ended in a stone walled error "We are unable to verify it is you", even when I was able to provide things like old numbers, old passwords or verification codes from backup emails.
Maybe try again. :)
One thing to note is that I was unable to access an old account for so long that it no longer has any old email in it.
Do you have ~15 year old emails available in gmail?
I don't think my earliest emails are available at all, I may well have deleted them, but even if they were, the device that remained logged in is over a decade old, uses POP or IMAP or something and barely functions. Not the gmail web interface, that's out of reach.
I wonder if signing up for Google One, which apparently comes with support, would possibly get access to a real person who could resolve the issue?
IMAP might do it via the "All Mail" folder? (Just a guess.)
Also, anyone who still can should print out Google backup codes and store them somewhere safe. Google Authenticator is not enough, because phones break eventually. A Yubikey is not enough, because they can break too.
> Also, anyone who still can should print out Google backup codes and store them somewhere safe.
The 2fa set up process for many websites (and iirc Google too) do not make this a priority. They should clearly emphasize the importance of saving the backup codes, and make you check a box that says you printed them. The 2fa should not be enabled until that is done.
I remember within the past few years when I was talking to someone who seemed to be unfamiliar with the idea of storing all your really important papers in a safe deposit box. I'm not sure if that's the times have changed, or the particular person I was talking to, or that it never was that standard.
Some of the arguments often seen on HN against "solving" identity:
- The inconsistent, chaotic patchwork of ID systems is more resilient than a monoculture, and definitely more resilient than a centralized solution.
- The gaps provide necessary cover for people who need to hide.
- Doubt usually plays in the little guy's favor. The bank eats the loss when it can't prove the debt is yours. Copyright lawsuit fails when it could have been anyone at that IP address.
- The difficulty of strong ID verification is what keeps it from being used gratuitously. A PKI or SSO provider that's too good will soon be required for every little thing.
- Customer identity is something a business should own, not rent.
> The inconsistent, chaotic patchwork of ID systems is more resilient than a monoculture, and definitely more resilient than a centralized solution.
This can be done in a decentralized manner where people host their identity. For example, for email you can buy a domain name and set the DNS MX record to point to whichever email server you want to receive email at. For identity you could have a DNS record with a public key, and then use your private key to generate random signed identities for every website. Obviously that's a bit out of reach of normal people, but it can be implimented without too much complexity. And inevitably it'll get pretty centralized for 90% of people, just like 90% of people use a @gmail.com email address, but the option will still be there for those who need it.
You laugh, but in China, your national ID card is used for nearly everything important, and then your WeChat account or phone number is used for everything else. Almost all logins are done through SMS verification or WeChat login (no passwords in many cases), and your WeChat and phone numbers chain back up to your national ID card.
It turns out that you can completely centralize ID and authentication, provided you have a government which is mercilessly willing to violate your privacy...
Nice in a way. Just don't ever say or think anything the Government doesn't approve of, because it can all be traced right back to you, and they have a million ways to make your life miserable if they get the slightest hint that you aren't toeing the line.
Re: Google Authenticator, I've started grabbing the TOTP secrets and storing those in backups. Download the QR code and decode it to get a string like the following:
That "secret" field is the only thing that TOTP actually cares about, and any app that supports TOTP will happily ingest the secret and provide 2FA codes.
Agreed. They live in BitWarden right next to the passwords. I lose some security, since compromising my password manager now also compromises my 2FA, but the password manager is itself behind 2FA, a Yubikey, and its backup codes are on paper in my safe.
Laziness, old Yubikey hardware that doesn't do TOTP natively, logging in to websites on my phone. I probably should upgrade, it's just pretty far down my to-do list.
Correct. So putting your TOTP codes in your password manager is no less safe than using the password manager in isolation, and likely substantially more safe, because it requires attackers to compromise your password manager in totality (which should be itself behind 2FA) rather than just phishing an individual password.
AndOTP supports exporting TOTP secrets in to an encrypted file which can be reimported if you need to restore your keys.
You can have the file stored in Keepass or an encrypted container for storage.
Additionally it has support for Steam and Blizzard TOTP secrets. Though they aren't straightforward to use, its nice having them on one app.
I've used this to cover me when traveling overseas. I print them on paper and snail mail a copy to several different family members. They don't have my passwords, so pretty secure from that angle.
This also helps if you want to use YubiKey TOTP support. Grab the keys, and then set them up on multiple sticks. If you lose a stick, you need to rotate, but if you say accidently snap one in half (yes, I've don't this).
Fido2 is better, but for sites that don't support it, I use this to make TOTP sites almost as secure.
Right-click in firefox and "save image". Drop it in /tmp so it gets nuked on next reboot (tmpfs yay). Pick your favorite barcode reader tool; I ended up deciding on `zbar-tools` based on... not honestly that much research. Invoke `zbarimg /tmp/qr.png`. It'll spit out the TOTP URI.
Verifying that I did it right: I manually enter the secret into a tool that can produce TOTP codes and verify that Google Authenticator and my backup are producing the same one-time passwords.
Yep - it's really useful to know that structure for services who don't bother properly identifying themselves with the issuer parameter in their QR codes so they end up in apps like Authenticator without enough descriptive context to be easily found (I'm looking at you Dropbox and Github!)
"This is absolutely getting unwieldy to the point of being fucking ridiculous and unusable."
Agreed. The worst part, in my opinion, is the penchant of sites/providers to demand a phone number any phone number as an identity mechanism.
Which is to say, there is no way to tie this number I have just entered to my personal identity in any way, or to verify that it has any relationship with me ... but as long as I successfully enter any mobile number I pass with flying colors.
You are really only complaining about the newest iteration of the identity treadmill.
In the beginning it was just a password. Then it was a username + password. Then an email address was tacked on to support "forgot my password". Then phone number was added to support SMS-based 2FA (or, hopefully, out of band contact).
The problem is that only government IDs have a high enough assurance to reduce fraud, and our {companies, employees, consumers} seem to avoid wanting the government to be involved in internet-based identity/authentication. Having a chip used to sign encrypted messages in our government ID cards would both assure authentication and reduce all of the frictions added after the fact.
The sad part is that USA government institutions are woefully underprepared to support internet scale of adoption and the legacy services (like DMV and county/state government offices) aren't exactly known for their swift customer service (which would be required if you lose access to your government ID).
> The problem is that only government IDs have a high enough assurance to reduce fraud
That type of "assurance" is really quite irrelevant to most authentication. Google doesn't need to know the name on your driver's license or your street address, only that you're the owner of this gmail account.
> Having a chip used to sign encrypted messages in our government ID cards would both assure authentication and reduce all of the frictions added after the fact.
Or you could have the same chip in a YubiKey and get the same result without the centralization or the privacy violation of having everything tied to the same identity without your consent.
> The sad part is that USA government institutions are woefully underprepared to support internet scale of adoption and the legacy services (like DMV and county/state government offices) aren't exactly known for their swift customer service (which would be required if you lose access to your government ID).
This is just more reason why it makes no sense to have the government involved.
It's not actually that hard to get a state-issued ID in someone else's name, especially for criminals who are willing to do things like pay off government employees, but even just for someone willing to forge documents.
The government can't use good cryptographic solutions to authenticate you in order to give you the card with the good cryptographic solutions because it's chicken and egg. But without that the security will always be weak.
Starting with a card which isn't associated with any "identity" to begin with and making the service you're using it to authenticate against your "identity" doesn't have that problem, because it isn't necessary to prove "identity" when you're opening the account to begin with (the account is then empty and contains nothing to compromise) and thereafter you can use the authentication method(s) configured when you opened your account.
But then the government wouldn't be doing anything but selling blank cards you could use to create identities with various services, and any private business could do that as well.
The value of asking for an arbitrary phone number is as a challenge of last resort. Let's say that you have given the provider no useful second factor, so the account is potentially quite vulnerable to credential stuffing The phone number acts as a mechanism for rate limiting and imposing an economic cost on attackers.
To hijack accounts at bulk, you also need to procure phone numbers in similar quantities. The cost of a phone number is low, but so is the value of the average hijacked account.
If you go post something on craigslist and show your phone number as a contact method, I guarantee you that you will soon get spammed by google 2FA notifications. Around me they seem to be primarily set to a Vietnamese language.
I live in the same city as the AT&T headquarters.
AT&T and Google could also have systems to help prevent these scams, for instance I could specify the languages I speak and if SMS messages arrive in a different language, they could allow me an SMS command to flag a sender as the trigger-er of the phishing attempt.
However, AT&T could also make a phone app for billing that loads menus in less than 30 seconds to a minute, and considering they've done neither I suppose I'll take the billing app first since it gets more use than craigslist does. After all, we only pay them 60 dollars a month for a phone and another 60-100 dollars a month for DSL for quite literally decades, so I wouldn't want to strain them by requesting too much in the way of a basic level of service.
This is called FIDO2 and can be used for passwordless authentication as well as two-factor. It’s compatible with Windows Hello or Touch ID (in Chrome, not Safari), and there are a number of dedicated USB tokens available if you want a second factor beyond your device authenticating itself.
It’s just not well-known enough on enough sites and services yet, but it exists and WebAuthN makes it easy.
Outside of the browser, it has OpenSSH support but not git or pgp/gpg support. GPG (and by extension git) don’t support very many security technologies... Windows Hello and CryptoKit are solutions but rarely implemented yet. Perhaps this will change over the next decade as hardware-based security authentication supplements or replaces soft- or password-based authentication....
While I agree that FIDO2 is great, especially far more secure than SMS based 2fA, people will still lose their FIDO2 sticks, they will still get stolen. And there will still be stories of people getting into accounts by pretending to be you to support.
You should always register more than one, and services should accept or require more than one, ideally. Google Advanced Protection shows how it could be done for extra security-conscious users though it does not, itself, use FIDO2 yet, I believe it’s still on an older iteration, U2F?
They don't, but that's a non-compliance. The WebAuthn (WebAuthn is the standard way to support FIDO in a browser) specification explicitly tells Relying Parties (which is what AWS are here) that they need to allow users to enrol more than one key.
The whole API design incorporates this thinking. The API call to tell a browser "Hey I want to enrol a Security Key" navigator.credentials.create() takes an array as a parameter with IDs for keys you don't want to enrol because they enrolled already.
The call for "Hey, prove you still have that second factor" navigator.credentials.get() needs among many things an array again, this time for IDs for keys that you'd accept, and one reason that's needed is that other keys needn't bother doing anything as they can't help.
Yeah, but AWS is a bit, uhh... just because AWS screws it up doesn't mean everyone else will.
That probably came across like speculation based on AWS's reputation, but it's also my actual experience after going on a U2F spree. Out of maybe 7 or 8 accounts, AWS was the only one that didn't support a backup key. Point is: I don't think it spells doom for U2F. Wasn't it just a few days ago that AWS was allowing password resets that couldn't be used for login because of validation? I don't remember the service, just that I saw it on HN.
You can make it work by creating multiple IAM users, for different keys. Just make sure they have billing and full admin access. Still doesn't help for root 2fa, but just give that a random 32 char password and stick that in a safe deposit box or something.
It hit a huge maturity milestone last year when the last major browser/OS combination got support for USB keys by default. Now the user story is "insert key, boop button." It's intuitive enough for my parents to understand, it's easy enough to habitually use, and the security is a big step up.
It's worse than you're even alluding to. I recently purchased a Yubikey with the intention of securing as many accounts as I could with FIDO2 and U2F. Literally the only service I could secure fully with the key was Google.
Google was the ONLY service that supports FIDO2 on both the desktop and mobile (using the Yubikey 5Ci with the lightning connector). Everything else was a hodgepodge mess of two factor options:
Twitter: FIDO2 on desktop only, needs TOTP fallback for mobile. Recovery keys for backup.
Facebook: FIDO2 on desktop only, need TOTP fallback for mobile. Recovery keys for backup.
LastPass: TOTP or YubiOTP only, email to recover.
ProtonMail: TOTP only, recovery keys as backup.
US Bank 1: TOTP via their app only, email and SMS as backup. Recovery by customer service
US Bank 2: Email only, recovery by customer service.
DE Bank: PhotoTAN only, recovery by customer service & postal mail.
US Investment Firm 1: Symantec VIP only, email as backup
US Investment Firm 2: Email only
Reddit: TOTP only, recovery codes as backup.
Amazon: TOTP only, SMS as backup
Duo: FIDO2 on desktop and mobile, but lack of support for embedded browsers means I need to have HTOP or push as a fallback for some applications on both platforms.
For the services that have recovery keys, I have them in an envelope I keep in my gun safe as well as a PGP-encrypted text file on my computer. I didn't store the TOTP secrets separately, although I probably will next time I re-enroll everything because my Yubikey physically fell apart a month after using it (a common thing with the first batch of 5Cis from what I gather) and I had to move everything back over to TOTP codes.
It's not just the standard for 2FA, it's everything from the bottom up. The 2FA tool, how backups work, how recovery works. It's a complete hodge-podge mess and and, like you mentioned, if it's this big of a pain in the ass for an experienced tech guy, how am I supposed to, in good conscience, recommend this stuff to my non-techie friends?
FWIW, Facebook, Dropbox and Github use Fido2 just fine on mobile (Chrome browser).
You don't need the TOTP fallback for Facebook on mobile browser (though annoyingly they'll still always send you the code via SMS, if you haven't disabled). I suppose it's possible that their app has issues with FIDO2, and maybe that's why you had to fallback to TOTP.
But yeah, 4 services (including Google), out of all the ones that I use... The track record for supporting FIDO2 is underwhelming. It's especially annoying that you cannot set up backup FIDO2 keys in AWS, which means that I won't rely on it.
Inversely, though, many apps like $authenticatorApp are tied to the specific phone (possibly storing a necessary data in the phone's secret enclave), not the account. For example when I upgraded to the newest $smartphone, all of my accounts with only $OTPApp2FA were unable to 2FA. I had to request 2FA resets from my account rep and configure the accounts to work with the new phone.
I'm much happier doing this than risking having a phone number hijack due to a $cellCarrier employee maliciously or negligently transferring my phone number to a malicious user, but it's not easy for me to remember to do all of these security steps, let alone someone who doesn't work in the cybersecurity industry. There's no way in hell my parents could do this.
Replace your Google Authenticator TOTP with a pair of YubiKeys and the Yubikey Authenticator app. New YK models have U2F so use that when available on whatever service you're logging on. Disable all SMS auth where possible. Look into Bitwarden.
I doubt a 'standard' how to do it can be independently developed and implemented. I use a non web-based password manager, a backup strategy that makes sense, and have a secure setup with regard to my threat level.
And with regards to your fear from Google: Short from full-on identify theft I have a controversial solution: E-Mail is something one should pay for.
E-Mail is essential ; the one thing you can use to pretty much sign up for everything, the one thing to use to reset passwords ; the one form of communication which is open, readily accessible to almost everyone, crosses borders, doesn't ask for fees, doesn't need a specific app, et cetera
I once lost my complete password database (if you sense irony here, it was a long time ago, and I was being stupid), including my E-Mail password, no 2FA set up, nothing. I was completely locked out, but: since I paid for the service: I could open a ticket, I could get a human(!) within a short time frame who actively assisted and I could proof my identify via easy means.
I was greeted with empathy, we could work with whatever I knew about the account and related information. There was no ridiculous meaningless questionnaire, no support ticket answered by some volunteer moderators. I was dealing with someone from staff who knew what they were doing, and we worked it out quickly.
Not saying it would have been impossible to restore access to a Gmail Account, but at the very least it would have been incredibly more painful, I am sure of that much.
> lose my gmail account and access to Google Authenticator
Google Authenticator is not tied to your account. Unless you lose your phone at the same time (or have remote wipe enabled and someone who gets your Google account wipes it), your Gmail account is not tied to access to Authenticator.
You should also backup authenticator codes on paper in a safe place.
> What we need is a single way to do login, MFA and security across every single site.
This. U2F could be it, but even the vendors that implement it often implement it poorly (e.g. not allowing multiple tokens).
It is interesting to me that we do not see the same complaints regarding a single way to do login for every single site for administration. Every site has to be administered, most of them are probably capable of being administered remotely and I would bet almost every single one uses SSH in some capacity to do that. Comparing that to the clusterfxxx of security theatre on the user side, it is quite an interesting contrast. I can login to a server as an administrator via SSH without disclosing any personal details but if I try to login to a server as a user, I am asked to disclose all manner of personal information and yet at the same time the requesting party takes no legal responsibility for what might happen as a result of complying with their requests. (They only try to instill fear of what might happen if we do not comply.)
> What we need is a single way to do login, MFA and security across every single site.
The way to do that is to use a client-side certificate in combination with a username/password for authentication.
When I create an account on a website, these are the steps I should have to follow:
1. Choose a username and password
2. Upload a CSR
3. Get the client-side certificate
4. Add it to my local certificate store
When I log in, I should have to follow these steps
1. My client automatically chooses the correct client certificate to send based on the server certificate
2. If I need a passphrase to decrypt my private key, I enter it at a prompt
3. The server verifies the certificate the client sent against whatever CA they use
4. I enter my username/password
5. My credentials are verified and I'm logged in.
I shouldn't have to provide my phone number or email address as a second factor because those factors aren't under my control. The private key associated with the client certificate is under my control.
How do you distinguish an attacker who has compromised your username and password from a hard drive failure on your laptop that made you lose the client certificate? In both cases you (or the attacker) have the username and password, but not the client certificate. They can upload a new CSR just as well as you, but at that point it's theater.
This is the main problem any such solution has to solve (IMO) to be better than the hodgepodge of 2FA methods that we currently have. Humans are fallible and will likely not maintain proper backups and such.
After creating the account, you should be able to get more client certificates associated with your account (while logged in on the first device) by sending more CSRs generated from other devices and then add them to the respective device's certificate store.
If you don't do that and lose the certificate and private key, then you lose access to the account. You should not be able to log into the account without both the client certificate and the username/password.
The procedure I described earlier would be for accounts like HN or reddit. If this was an account with a government agency, bank, or credit card company, then the part where you generate a CSR and get a certificate would be done at an office where they verify your identity (drivers license, passport, etc). In the latter case, if you lose your certificate, then you need to go back and repeat the procedure to get a new one.
> Humans are fallible and will likely not maintain proper backups and such.
While that's true, we really ought to sacrifice some convenience for better security. If a user fails to maintain proper backups or register multiple devices for an account, then the inconvenience of losing their account and going to the arduous process of creating a new one is on them. They shouldn't put the lack of security burden on us by having companies engage in security theater like MFA (i.e., SMS or email based second factor) because they want convenience over actual security.
That said, those users could opt out of MFA and just rely on their username/password for authentication. Those of us who want MFA could use the client-side TLS certificate in combination with the username/password and keep our account secure.
The way I see it, people who are careless with security have put people who are technically able to deal with things like client-side TLS certificates in a compromised position where they have to deal with SMS or email based MFA for important services like their bank, credit cards, taxes, etc.
I would rather have the ability to use real security with the MFA scheme I described above (and in my other post [1]) rather than the security theater we have with email/SMS MFA. If some people aren't able to deal with that and lose access to their account, then the burden is on them. On the other hand, by using email/SMS based MFA and account recovery, the burden is on all of us for the lack of security for everyone. If someone wanted to get into the important accounts, they don't necessarily need to target the user's bank. They could target their cell phone provider or email provider and get access not only to their bank account, but any account using those as factors for authentication.
With a client side TLS certificate, they would actually have to get physical access to the device and brute-force the private key passphrase in addition to the username and password for the account.
On the contrary, people like me do need it. The status-quo right now is that companies are forcing us to use security theater measures to further secure our accounts. But since those measures are actually weaker than the original password, it actually reduces the actual security around our accounts.
And I never use the remember password feature in my browser because I don't want to inadvertently give someone access to my account if they manage to access my machine.
I don't know about it having to be an ISO standard but certainly it MUST be the industry equivalent of "don't roll your own crypto" but for user level authentication. This is indeed ridiculous.
This sounds like something your ID card would be suited for, German ones already support NFC and can used to authenticate against government websites.
Of course that would eliminate anonymity, which would be horrible, but maybe ok for Gmail where people use their real names anyway.
But in the event of loss of ID card or identity theft, there is a trusted instance (the government) that can block old ones and issue new ones. This could be used as a reliable way to rotate a 2FA key, because some unique number attached to a citizen won’t change.
The worry is that if systems like this become widespread enough then they'll simply be required just like phone numbers are. The website will pinky promise you that they won't sell your data. Not to mention that now the government can just request access to all of your accounts on all of these services, because they know you had to use your ID.
Paper trails is my biggest concern. Far too much PII data gets slung around emails and is sitting in 'Sent' folders waiting for the pillaging. I'm concerned because I can't do anything about this with regards to doctors/employers/gov.
I mean how many times have you been left alone in a doctors office with a computer just sitting there with connections/inputs exposed. I am 0% shocked at the large scale retail data theft that gained steam a few years ago.
KeepassXC supports TOTP and with a nice compatible app for mobile, that is one way to do MFA in a way that is more resilient to data loss as opposed to Google Authenticator which might get shutdown without too much notice. Plus, Keepass let’s you choose how to distribute your vault whether you want to do it manually via email or something or via cloud storage. Even if you do cloud storage, it is very easy to backup in case something happens with the cloud storage.
Account recovery is a completely underserved problem today and many companies don't have a well thought through solution. Many rely on Knowledge Based Authentication questions that can be found easily by an attacker who has access to your email. To solve for cases where someone has lost all factors (forgot password, lost access to email, lost phone number), we need a brand new way of thinking about solutions. Hit me up if anyone's interested in brainstorming on the same!
> I've lost some gmail accounts because they will ask me for security questions when I log in with the correct password, and I don't remember them so my account gets locked, so they're gone forever.
Oddly for me it seemed like as time went by I had a better chance of recovering old gmail accounts with spurious remembered information, like the algorithm thinks the longer nobody's in it the more likely you're the owner trying to get in. This was ~10 years ago though.
I generally agree, but I do see cause to believe there is the possibility of light at the end of the tunnel.
Microsoft is starting to push passwordless features for Windows and online accounts.
YubiKeys and OTP apps are pretty common (hopefully there will be more standardization and less fracturing of those features).
OAUTH2 is mature and Google/Facebook/GitHub/etc all work decently as providers.
Although I wish a single government entity would replace those OAUTH providers. I can't get banned by my state like I can get banned by Google for ToS violations, so I'm wary of creating a federated auth account unless I'm certain I can't lose access to the root account without necessarily losing access to the subservient accounts. The obvious downside is that dissidents and criminals are easily identified, but that's an offline problem as well as an online.
I've had YubiKeys + OTP software apps for years, but the industry of web apps is still too fractured and not enough devices + browsers + websites support it.
>“During this period, we started realizing that his bank account was being drawn down through purchases of games from Xbox and [Electronic Arts],” Dayman the elder recalled.
You should never trust any of these companies with your actual bank account. All of them have garbage customer service with hoops upon hoops to get real help if your account is somehow compromised.
Use a credit card, prepaid card (in the US Amex gift cards you get at grocery stores will work just fine) or buy codes from Amazon and redeem them.
Agreed. By extension, you also should not use a debit card as a credit card, for largely the same reasons. Credit cards have excellent fraud protections enshrined in law that are not extended to bank accounts or debit cards. Your individual banking experience may vary, however. For example, my credit union has a $0 liability guarantee for fraud on my debit card, but they are not required to offer that.
Personally, the only companies that have direct access to my bank account are those that either won't accept credit cards, or make it excessively difficult to do so. Chief among them would be the service that processes my rent payments, and PG&E.
> For example, my credit union has a $0 liability guarantee for fraud on my debit card
Even with that, I'd still prefer a credit card. If there's fraud on my CC, I haven't lost anything. If there's fraud on my debit card, there will be a period of time where that money will be gone before the bank investigates and decides to give it back to me. Even if they are 100% reliable at giving it back to me, the money is still inaccessible for some non-zero period of time.
> Personally, the only companies that have direct access to my bank account are those that either won't accept credit cards, or make it excessively difficult to do so. Chief among them would be the service that processes my rent payments, and PG&E.
At banks that make it easy to have multiple checking accounts tied to one online account, create accounts just for these debits. Don't keep funds in them until close to the transfer date. "The Paypal Maneuver".
...and if you can't turn off "overdraft protection" then you should find a new bank. Especially if they charge a fee for overdrafting: it's just a fee for being poor.
Does that not defeat the purpose of separating the accounts in the first place? If the airlock account info fell into malicious hands, the pristine account funds are now at risk.
It’s a fair point. Banks with this feature usually allow you to set dollar limits. Hard to provide generic advice due to how different fintech offerings are. My apologies.
The only company with any access to my primary account is my brokerage. I have given access to a secondary account for Venmo which I only use to pay my child's music instructor since lessons are remote right now and I can't hand him a check. The secondary account nver has more than $400 in it and usually far less.
Every other bill gets paid by credit card or gets pushed to the biller through online banking that I approve. No one gets to pull money from my primary bank account.
Is that how it works in the US? In the UK, your debit card is effectively your bank account. Maxing it would imply your account is empty, and overdrawn to the point where the bank will not lend you more. No lag.
That's the difference between a credit card and debit card. If a scammer drains your credit card, you won't be able to buy anything on that card, but the money is still in your bank account. You also have a grace period of around 2-3 weeks to pay it back, so you don't even accrue interest. If a scammer drains your debit card (aka bank card), then you've essentially lost access to all the money in the account. Resolving that could take days/weeks, which will be a problem if you need to pay bills or buy food/gas.
They were talking about using a credit card which is based on a credit limit not a debit card which here in the states is also based on your bank account. The argument being that if you expose a debit card which is basically like a digital checkbook to your bank account then you have 0 protections. If you use a credit card then you have plenty of legal recourse against fraud.
I have something called "Bill Pay" from my credit union where they send the checks for payment (Rather than the company drawing from your account). That's how I pay PG&E. You might want to investigate if your bank has the option (unless you already have, in which case never mind :)
Sending checks isn't really any different, since the checks contain the same information that you would provide the company to draw from the account. Even the one additional safeguard checks used to have, that they have to clear through the banking system so there's a paper trail, often doesn't apply any more since many companies will now process the check as an ACH transaction instead of a paper check transaction, the same as they would if they were drawing directly from your account.
AFAIK, most bill pay services move the money from your account into an account owned by the bank, and then send out a bank check. But verify this for yourself before trusting it.
When I was using my credit union's billpay, sometimes they would do that, and sometimes they would write a check against my account; it wasn't apparent why (as I recall, some scheduled checks were issued with both methods over time)
Well, this is different in the sense that I have to initiate a payment (or schedule a payment if the amount is fixed). The other side cannot just access my account to withdraw money.
They actually can. That's all a check is -- giving them the info they need (account number) to just access my account to withdraw money.
The only difference is legal in case of later dispute: the check is evidence of how much you authorized them to take, and vendor autopay usually has fine print saying you agree to whatever.
But in case of unauthorized theft, there is no difference.
The check has the account and routing numbers printed on it (near the bottom usually?). These uniquely identify your account, and via ACH they allow you to deposit or withdraw money electronically without the account owner's prior approval.
I've never had a problem with fraudulent debit charges being covered by a bank even though it's not required. The detection is the same as used for CCs and the card gets shut down immediately in most cases, even for legitimate charges outside your consumer profile.
Obligatory privacy.com mention. Them or any other virtual card service is better than giving your actual card, especially with the Visa/MC "card update service" that gives companies your new card number if it's changed. I've only encountered a few instances where using a virtual card is blocked, such as for pay-as-you-go services (GCP and Azure, for instance).
My bank in France has this service built in. You set the amount and the expiration date and you get a virtual card. It's tied to the first commerce that uses it. That one commerce can use it multiple times as long as there are funds left.
It works on Google Cloud Compute I used it last year. Then there is an option to completely block any transaction of my actual card for any online purchases. When I go on a trip I generate a few virtual numbers and write them down in case I need to make an online purchase from abroad.
I have 2FA turned on for Github. Since they refuse to recover accounts that have 2FA enabled if you lose your second factor, I have many alternative ways configured: TOTP, U2F, recovery codes, recovery phone number.
I have the recovery codes stored in a secure location, and several U2F tokens enrolled (one of them is also off-site at a different location).
But I didn't back up my TOTP seed. I still have the old phone with Google Authenticator, but it's too old to accept the version that lets me export my keys.
Getting a new TOTP seed requires me to re-setup 2FA, which will invalidate the recovery codes and possibly unenroll my security keys (it says "This will invalidate your current two-factor devices and recovery codes.")
It's also apparently impossible to set up Github 2FA with "only" a set of security keys + recovery methods - you have to first set up an authenticator app or SMS 2FA as a primary method.
So now my options are:
- Leave the dead TOTP on the account, and don't have a working TOTP setup
- Re-setup from scratch, invalidating the recovery codes and possibly U2F tokens, requiring me to visit two distinct off-site locations to re-setup everything, one of which is currently locked down and inaccessible due to Coronavirus.
And Github is one of the better sites when it comes to 2FA!
I had to get the seeds out of Google Authenticator several years ago. The seeds were stored in an SQLite database file in the app directory. I think I used another app to read the DB file and export the seeds to plain text, but you could also conceivably copy the file to a computer and work from there, though you might need root access either way.
Yes, all of this requires a rooted phone or otherwise subverting the Android security model.
A potential alternative could be finding an ancient APK that didn't have the 'prevent backup' bit set, downgrading via adb install, and pulling an adb backup. Still, massive PITA.
Yeah, it's very painful to use foreign services, the 2FA solutions are just so annoying. SMS and TOTP? Legit stone-age garbage just like paper signatures.
I have none of these problems with local important services because I can use my goverment-issued ID for those things.
Two-factor authentication is largely an annoying band-aid over an easily-solvable problem. It either relies on devices and protocols like smartphones and SMS (which are fundamentally insecure to begin with) or requires expensive proprietary solutions like Duo.
It's like an anti-password manager. Doesn't depend on any specific device.
Essentially it's a sane implementation of what others have already discussed below, in the other child comments -- using the name of the site to derive a secure, non-reusable password.
I used to do this in the distant past, but gave it up because it didn't cope well with:
- Sites that have different password requirements (some require special characters, some don't allow them, for example).
- Changing my password on a site.
I took a peek at masterpassword.app, but couldn't see that it solved these. Does it?
Barely. In order with your requirements, Master Password offers:
- A choice between a few different password types (numerical, short, long, complex, phrase) for picky sites. It relies on you to remember which password type you used for which site.
- A counter you can increment arbitrarily to generate new passwords for a given site. Again, relies on you to remember that you're on password #3 for site X, password #5 for site Y, ...
I haven't reached a point where I've had to make heavy use of these features (yet) but if you use lots of picky sites, or change passwords very often, certain limitations will become apparent.
If it's any consolation, passwords generated by Master Password tend to have a unique phonetic cadence -- that is to say, once you're familiar with the first or second syllable of your password for a given site, you'll know pretty much instantly if you're looking at the right one, despite not being able to reproduce the entire string from memory.
This might make it easier to increment the counter several times in quick succession while being able to conclusively discard passwords that don't "sound right".
YMMV of course. If this sounds like something you'd hate to do, Master Password may not be a viable solution.
The Java-based desktop app somewhat solves these issues by (optionally) caching encrypted data about your passwords (site names, password types, and counters) on disk. However this could possibly end up defeating the point of "doesn't rely on any specific device", if the user grows to become reliant on the cached data.
Use a mnemonic that includes the name of the service or website in an algorithm.
With that you never reuse passwords. Someone with other passwords of yours is likely just trying these automatically, people who would target you usually don't have your passwords from a breach elsewhere and can't figure out your password rule.
It is not easy though and I find myself having to reset my passwords occasionally...
>Use a mnemonic that includes the name of the service or website in an algorithm.
I'm not sure what the point of this when there are password managers available. Sure, it prevents simple credential stuffing attacks, but you're still open to sophisticated attackers deducing your passwords based on a leak. For instance, if your bank password is "correct horse battery staple chase", an sophisticated attacker might try "correct horse battery staple paypal" for your paypal account. Attackers already bruteforce common variations of passwords (eg. password -> (Password, password1, etc.), so this isn't too far fetched. Password managers with randomly generated passwords have none of these issues, and you still only need to remember one password.
I'm not advocating for or against, but one big difference is that with a mnemonic you don't need access to your password manager to be able to log in somewhere.
Of course, that's a major weakness; if the password trick is simple to remember it is likely simple to figure out for a motivated attacker! But when there are millions of password leaked and your mnemonic-password doesn't contain "chase" or "paypal" but "chicken5" and "pony6" and has otherwise enough entropy, will the attackers stand around a whiteboard and crack your code or just run their scripts and take what they can get automatically?
A password manager is probably very good, but it's a single point of failure and a huge target for the black hats; it's a program on a computer or on a smartphone that (potentially) sends data back and forth as it pleases.
So maybe the idea is to use a password manager for single-use entropy and then add some mnemonic manually before submitting the password. Then it's down to keyloggers and other sophisticated attack vectors?
>A password manager is probably very good, but it's a single point of failure and a huge target for the black hats; it's a program on a computer or on a smartphone that (potentially) sends data back and forth as it pleases.
What's the threat model here? If it's downloading a malicious password manager, that can be mitigated by using an open source/audited one (eg. keepass or bitwarden). If it's your browser/computer being compromised, that really isn't fixed with manually entered passwords either. If there's malware on your machine, you can assume that all your keystrokes and form submissions are logged. The only advantage is that rather than getting all your passwords, the attacker only have whatever passwords you've entered prior to detection.
You'll want better mnemonics than this, but for a start:
correct horse apple stable eat (c.h.a.s.e) is, I suspect, closer to the spirit of the original suggestion. Just tacking the name of the company onto the end instead of weaving it in is, as you say, pretty weak.
>correct horse apple stable eat (c.h.a.s.e) is, I suspect, closer to the spirit of the original suggestion.
The nice thing about password breaches is that they're all from the same source, so you can come up with a few variations and they'll be valid for all the passwords in the breach.
This is a very valid question, and I'm not sure why people downvoted.
The answer is that services like LastPass and OnePassword have recovery codes that you're supposed to download and save somewhere (possibly even on paper). These codes can get you into your account if you are somehow locked out of your account.
You're wrong that two-factor authentication is a band-aid or that it's trying to solve an easily solvable problem. Not reusing password doesn't provide any protection against phishing, which is as big of a threat as the server-side leaks, and for high-value targets, it's even a bigger threat.
That said, 2nd factor that's not U2F are not worth it at this point with lots of issues, so indeed U2F is about the only no-compromise (security wise) 2nd factor. All other 2nd factor have serious security or availability downsides.
Mitigating password reuse is far from the only purpose of MFA. If you are using any sort of SSO or account that signs in to multiple services (I think Xbox falls into this category as a Microsoft account), then it can also protect you from an attacker who steals the login info from one place and uses it to sign in to a different service. In the case of a Microsoft account, all it would take is one decent enough phish, one app storing your email credentials improperly and accidentally leaking them, or a quickly blocked malware infection that nevertheless manages to steal your password manager’s contents, and without MFA the attacker can then log in to email, Xbox, and so on.
The downside is not touched upon, however: losing access to an mfa account because the mfa is lost. This can happen in a multitude of ways. Losing a phone, wiping a phone, changing phone number, losing a hardware access key, losing recovery keys (if they're even provided, many times they are not), etc. It's inconvenient too, especially for sites that require it on every log in and whose sessions were short lived (aws). Or refreshing everything when the mfa changes including codes. I have almost 500 logins in my password manager. That's 500 potential mfa code generators and 500 sets of restoration keys. All I'd have to manage manually (pw manager can help with the keys but it's all manual).
How do you keep all of that safe though? Unless you use a password manager that backs up into to cloud you can still be in trouble. If your house burns down then there's a good chance your codes went with it.
Living in South Africa, I actually turn off 2FA wherever I can. I use a strong random password per site stored in a password manager, but my phone number is controlled by a drone at a telco helpdesk which can easily be convinced to port my SIM to another.
SIM-swap fraud is super common here, so turning on 2FA actually reduces the security of my account.
A soon to be released patch offers world of Warcraft players an in game upgrade (additional bag slots) for players with MFA setup. I would have thought this would be supported by a community.
Instead, the feedback I'm seeing everywhere us "it's just a scam to make you setup the authenticator, don't fall for it". I cannot fathom why people think this, when it's a free offering and protects you more than them.
It just shows how differing some community views are from the security community.
They used to give you a Core Hound Pup pet (Core Hounds were huge dogs seemingly made of molten rock in what was once an end-game raid fight, but these days you can probably go pet one with a relatively low-level character)
Bag slots do seem like a more concrete reward for using authenticators.
I'm actually toying with what sort of trivial reward would be appropriate for using WebAuthn to sign into an archaic PHP-based web site we built last century, I wrote a PHP WebAuthn implementation for it and it'd be fun to give people some silly reward for turning it on.
The article mentions the father having recovery codes in a safe. For those of you who do use MFA with recovery code access if the MFA device is lost, how do you store your recovery codes?
Say I have MFA enabled to send me an SMS when I log into my email.
I am abroad, and my phone gets stolen. I need to log in to my email on some other device and re-access my boarding passes, maybe communicate about my upcoming radio silence. But I can't access my account without the code sent to my phone...
I print them on paper and snail mail them to my sister and parents. I lose my yubikeys (I store TOTP secrets here, not my phone), I can call them internationally and have them ready me the seeds (or send me a picture, at which point I roll them all over).
I've also done it where I sent them a YubiKey with my secrets, then set it up so I can access a computer remotely (via ssh, rdp, etc...). I have to call them to insert the key into the machine, so if the machine gets compromised, there's not much risk, as it's only plugged in if I call them to do so (and tell them to unplug it X minutes later).
Interesting! I think I read about a person who had a "only turn on this machine if I ask you to" situation, where that computer would boot, automatically connect to a network and allow for connections to the secrets store, in a situation like you describe.
Of course, that requires maintenance and checks it would work in a real life situation, that network configurations haven't changed, the parents are present and compos mentis, etc.
I have my backup codes in a file that's encrypted using a key derived from a passphrase that's over 50 characters long (not the same passphrase used for my password manager), that I've memorized. It's stored in cloud storage, on an account created just for that purpose. The account is protected with a (different) password that I've also memorized, and that account doesn't have any kind of MFA on it.
Since access only requires 1) internet access, 2) a common, publicly-available decryption program, and 3) stuff in my brain, I can gain access to it under pretty much any situation where I'd need access to it.
A potential downside is that if I ever had to access and decrypt the file on hardware I don't trust, I'd have to revoke and re-issue all my backup codes, and come up with a new long passphrase to protect the new file, which is a huge pain to do.
This is of course not perfect security, but I think it's fine for my purposes and threat model.
Aren't you afraid that you are going to forget a passphrase that you don't regularly use? That's my main concern with your approach (I have thought about it and didn't do it because of this fear)
I do regularly use it, just for something else that has a similar security level. I know it's generally bad to reuse passwords, but I do this specifically for the reason you've brought up: it'd be a disaster if I forgot the passphrase.
This is obviously not perfect security for that reason and a few others, but it's good enough for me.
Every now and I then I get a password reset email from spotify. Someone somewhere keeps trying to login to my account (not sure what the point is to try and go through the password reset process, since the email gets sent to my email, and they likely won't know which email it gets sent to). Would be brutal if they find out my password is 64 random characters.
What's annoying is that a lot of these attempts would stop if spotify simple started forcing MFA. Even if through their mobile app.
After reading a lot and especially watching recent programs on Russian TV with witnesses comming out I am strongly convinced of human action.
They were lined in front of tent and told to leave external layer of clothes and shoes in the tent. Otherwise it would be to easy to escape in the darkness. Walked down the slope, some resisting had been beaten (Kolmogorova, Slobodin) and under the tree some were undressed and tortured with fire (Krivonischenko).
This TV show is a mess of but there are some interesting witnesses who came forward.
Both are definitely mysterious, it's a bit difficult to tell by reading English translations but as far as I can tell Zolotaryov's body had a tattoo (I've seen it described as military related, crime related and unknown) that people who knew Zolotaryov said he didn't have, Had a fifth camera that was unknown to the rest, had different tooth caps and didn't match a DNA test after a recent exhumation, though later testing matched.
Also on the subject of the rib fractures, they've been described as consistent with a bomb or car accident, a snow mobile like a B7 seems like a possibility. Maybe Krivonischenko was suspected of leaking information and Zolotaryov was there to keep an eye on him, and the rest got caught up in the mess. And when things got out of hand, Zolotaryov sided with the group.
Fortunately I can still understand Russian that I had to learn at school..
Krivonischenko was no ordinary guy. His father was in rank General Major and in charge of constructing Soviet nuclear plants. Krivonischenko himself worked on liquidating Mayak (Kyshtym disaster - https://en.wikipedia.org/wiki/Kyshtym_disaster) then he suddenly quit his job and ignored letter denying him release. From what he saw at Mayak and from informal talks with his father he could have had troves of valuable information.
Suprisingly there is another member of the group - Kolevatov - that from analysis of his biography looks like career officer involved with nuclear industry. At 19-year-old Kolevatov graduated from the Mining and Metallurgical College in Sverdlovsk and was sent to Moscow to work at 9th Directorate of the NKVD of the USSR laboratory "B", focused on creating protection against ionizing radiation. And then sent back to Sverdlovsk (which does not make sense as voluntary career move but makes sense as some sort of assignment).
And Zolotaryov - there are witnesses of him beeing seen at different places at the same time. We know that he had zek brother (kept in Gulag for beeing traitor after WW2). He was leading tourist expeditions often close to the borders of USSR (in 1950s it was difficult to achive permits for such expeditions - there were people trying to escape and in some still active ant-Soviet partisans).
He claimed that after Dyatlov expedition he will achive fame. He was simple PE instructor but working in secret city.
On the TV show the daughter of Zolotaryov life partner and a person who have taken bath with him on previous expedtion does not remember Zolotaryov tattoos. No one else does and Zolotaryov was handsome man and well remembered. It was also at times hard to imagine for a normal member of Soviet society to have tattoos. Especially for PE instructor who has been leading PE classes with students in short sleeve shirt.
Zolotaryov young son disappeared without a trace. He was apparently given into foster care but boy's mother (Zolotaryov's life partner) had been actively looking for him for long years in vain. So it looks like the paper trail of the boy vanished or have been erased.
Tumanov - pathologist on the TV show - claims that Krivonischenko's burns are a sign of prolonged exposure to fire - not an accident casue even semi-conscious person will react to contact with fire. So either Krivonischenko climbed the tree and fire was used to force him to get down or it was plain torture to extract some information.
Slobodin (amateur boxer), Kolmogorova and Dyatlov all had died of hypothermia but also all have signs of blunt force trauma. So hypothermia might have been result of being left unconscious in the cold after receiving serious blows (back of skull for Slobodin, batton on a hip and bleeding nose of for Kolmogorova and Dyatlov had frozen with his both hands in protective gesture). Especially in case of Slobodin the snow evidently melted under his warm body and frozen later.
All three of them especially Kolmogorova have been really well dresed so hypothermia is unlikely explanation (they were all tough tourists, familiar with camping in the snow without all the equipment that we have now (polartec, gore-tex, down parkas and down sleeping bags, mats etc.) - all of them perishing from hypothermia within few hours is absurd).
The ravine four might have been just finished off with broken necks. Their bodies had autopsy after long time in snow.
There are less credible sources saying that Dyatlov group had been followed by another group of people. On the Rusdian TV show there is a guy who tells that his father was hunting in the area, saw the fire, came closer and have seen people being beaten. He did not came forward cause hunting without permit was criminal offense.
---
Now this is all armchair theorizing, grasping at straws and nothing more and it probably belongs in https://dyatlovpass.com/ forum rather then here. ;-)
But let's hope that as Russia's attorney opened the investigation we may learn what has happened some day.
MFA is great if it is something like Google Authenticator, with recovery codes.
And yes, store your recovery codes in your safe. Or print them, I guess, but it isn't that big a deal.
My problem is with most banks that make me use some MFA that I can't reasonably recover with codes, or those that can be recovered so easily that MFA is a joke.
Is there a simple site or a table somewhere with services/products saying whether they support MFA or not? Kind of like https://pyreadiness.org for MFA.
Some password managers (1password, for example) suggest adding MFA for services that you have records for and if it knows that these services have MFA. Not sure where they get that info.
The lesson learned is that allowing MFA but not making it mandatory poses a security risk. Arguably, that practice can be even worse than not offering MFA at all if it gives hackers even better control over your account once they get in: they can lock you out even more effectively.
I try to have strong discipline of erasing and closing my digital footprint, and not relying on freebies like gmail to support my digital identity. News like these remind me how important that is...
An interesting piece (as Krebs' typically are). There are a number of takeaways here for both users and implementors. The headline one of course is that poor implementations of MFA can themselves become a risk factor in a variety of ways. Ideally if a company is going to implement one at all, they need to be really careful about what they're rooting the trust in. If it's required for everybody when the account is created originally, than it can be assumed by definition that the same human who created the account setup the MFA as well. But if it's something that can be added on later, is there any thought to how that fact is established and what recovery procedures are available if it isn't? That's particularly the case when money is involved, and it's also curious in that subcase that the money trail itself isn't more often used as a recovery identifier. Ie., when linking financial accounts a fairly common verification procedure is that a couple of <$1 deposits are made and must be entered. This is a pretty core way to verify that at the least the money is also controlled by the same person, and financial accounts usually have a lot more identity tied to them. It's almost surprising entities the size and sophistication of Microsoft or Google don't do that, because it'd also help reduce the potential financial return for attackers. Want to make core account changes when money is involved? You need to verify you control the money. Attackers could change to their own funding source, but that'd reduce the value of the attack.
Of course it also is a reminder to be careful about what money you tie to online accounts at all:
>Nevertheless, the thieves began abusing their access to purchase games on Xbox and third-party sites. “During this period, we started realizing that his bank account was being drawn down through purchases of games from Xbox and [Electronic Arts],” Dayman the elder recalled.
I would never, ever tie a checking/savings account to basically anywhere online. When the money is pulled out of those it's a huge pain to get back if it's possible at all. Credit cards, even ultra basic low cap starter types for people with no credit history yet, are another layer of protection and intermediation. Virtual card numbers with unique cards per account may sometimes be useful. Even better is to take the convenience hit and leave no stored financial payment at all. Just reenter each time, or get $10/25/50 gift cards and use those to fund a game account as needed for new purchases.
>“I pulled the recovery codes for his Xbox account out of the safe, but because the hacker came in and turned on multi-factor, those codes were useless to us.”
I think this is bad design by Microsoft. Why should turning on MFA, or adding a new MFA factor, obviate one-time use recovery codes which are to some extent a weak form of MFA themselves and explicitly should serve as a final emergency recovery thing people have in a physical safe? A decent recovery code system itself is typically a requirement for good MFA, as a final resort in case the factors are all lost/damaged. They could also be used as another way to try to meet the issue of verifying the person who created/owns the account is indeed the one turning on MFA.
> Why should turning on MFA, or adding a new MFA factor, obviate one-time use recovery codes which are to some extent a weak form of MFA themselves and explicitly should serve as a final emergency recovery thing people have in a physical safe?
I have no idea if Microsoft works this way, but I believe that many places generate new recovery codes when you enabled 2FA. If Microsoft is such a place, then the thieves would have been given the new recovery codes when they turned on 2FA, and any prior codes would be invalidated.
Or it may be even simpler. I don't have an XBox account, but I do have a Microsoft account. Not sure if they are the same or not. Anyway, once you are logged in you can simply go to the security settings and ask for a recovery code. It gives you one, and notes that any prior codes are now invalid.
Recovery codes are really generally just for dealing with forgotten or inaccessible credentials. An example would be someone who forgot their password and they also no longer have access to the email address that would be used for password recovery. Another example would be someone who enabled 2FA and has lost their 2FA device.
Honestly, I think the authentication method used by the credit bureaus is pretty good, and I think that other companies can license it or something. They ask you multiple choice questions that require you to know elements of your credit report. They have the data to make plausible false options. It certainly seems to work better than Google's recovery process for gmail.
Protecting your identity with a 1 in 5 guess is absurdly unsecure.
Let's say I was a bad guy and I looked at my target's social media. I see he was in the military, and I see USAA (a bank that caters to the military) is an answer choice, I'll try that one. Or if I know approximately where my victim lives, I'll look at an online map and see what banks are close by. Chances are the victim would get a loan at a bank they are already a member of, and would be a member of a nearby bank so they could deposit/withdraw easily.
Anecdote: I was once asked what type of car I got a loan for. First of all, just because the dealer pulled my credit doesn't mean I bought it (I never took out a loan for the vehicle). Second, just go on Google Street View to see what car is in my driveway, or check social media because people like to post pictures of their cars. So again, more incorrect data they used to verify me, and if it was correct, it wouldn't be secure!
Many years ago, before MFA was really a thing, I changed my email address to get away from the spam list I'd built up in my youth. Still, I had used the account for some personal communications and was concerned some people wouldn't catch immediately update their address books, so I set up a forwarding rule to my new address for anything that got through the spam filters.
The old account has been silent for years, to the point that if I'd forgotten whether I'd even deleted it or not. So imagine my surprise when in the span of a minute, I get several forwarded emails from Google stating that the account was recovered, a new device has signed in, password was changed, secret question changed, and recovery email changed.
Now, as far as I'm concerned, the account is dead and hasn't been linked to anything I've signed into for years. But that doesn't mean it was never linked to anything important and who knows what's still sitting in the archive or who's still in the contact list. So as soon as I saw the messages I jumped to figure out what happened.
But it turns out that all these security alerts from Google are just to "let you know about important changes to your Google Account and services" and if there's a problem just tell you to click a button to login and "Check activity"...which is difficult to do when all your security information has been changed before you have time to respond.
There are options to try old passwords and linked email addresses, but after several attempts all I got was "Unfortunately Google couldn't verify that <the account> belongs to you." and a link to "Recover your account"[1] that just tells you to try the recover options that have already been prompted for, and if all else fails "consider creating a replacement Google Account."
There is no contact information, no option to let anyone know you have a problem. The emails alerts are sent from the uncaring "no-reply" address while Googles "Contact Us" only gives a physical mailing address and directs you to the same help articles.
Now, again, the account is--has been--dead as far as I'm concerned. But considering the forwarding rule was still in place Google probably thinks differently. So now the account, and everything in it, belongs to someone else.
The moral of the story is not only do you need to practice good security now, you need to have done it your whole life, and go back to do it better when new security practices are adopted--before crooks do it for you.
I've been in tech for 25+ years. I'm very familiar with security, and I have the internal endurance to sit patiently and work through IT-related issues.
However, at this point, there are just too many broken ways and I'm at the point of giving up. I use LastPass and if that somehow gets hacked or phished, I lose absolutely everything. I'm waiting for the next virus or phishing attempt to steal my LastPass password.
I use multi-factor authentication on some accounts, but if they use SMS like many sites do, I can get my phone number stolen from me and then I lose access.
I use Gmail and Google Authenticator, but if I somehow do something to piss off Google, I can lose my gmail account and access to Google Authenticator and then I'm really fucked. I've lost some gmail accounts because they will ask me for security questions when I log in with the correct password, and I don't remember them so my account gets locked, so they're gone forever.
What we need is a single way to do login, MFA and security across every single site. We can't have every company incorporating their own methods. We need standardized customer support, where Tier 1 customer support can't give you access to things like credit card numbers, last 4 digits of SSN, or change passwords. Changing passwords needs to be a higher level, better trained customer support.
There needs to be an ISO standard that is well thought out and implemented by all the vendors, or at least all the big vendors. If there's a standard way of doing security but also a standard way of doing customer support and what data is exposed to various levels of customer support, then social hackers can't take partial info from sites A and B, and use that to social engineer site C.
This has to be simplified because it's absolutely unwieldy even for a veteran like me. There are too many ways I can get hacked and we are all just sitting ducks. The only thing protecting us is that we aren't high-value targets.