I applaud the fast response, especially contacting a security engineer to be removed from the GitHub organization. One particular bit stuck out to me.
>>In this instance, though, the attack vector was DNS. My account at the not-so-incredibly-common DNSimple.com did not use a highly secure password. I didn’t think it was necessary, as in my mind, the only reason that the security of an account like that would be at risk would be if I was the explicit target of an attack. Once again, I thought to myself “That’s something that only happens to other people”.
Kenneth used a randomly generated password and two-factor authentication on his GitHub account, which is great! But on DNSimple he made the decision to forego better security because it seemed unlikely to be a target.
It is not enough to use some strong passwords for the things you think are sensitive. Every weak password is a weak link in your total identity chain.
The best way to use a password manager is to never give yourself authority to make passwords unless they are randomly generated. Even if the site or account in question appears innocuous or insignificant, even if it does not allow you to make a password of your manager's default strength, commit yourself to going through this process 100% of the time.
Yes, it's a usability pain to constantly use a browser extension to log in. But that pain is nothing compared to the stress of a compromise or targeted attack.
Until password management or authentication are substantially overhauled on the web, the most optimal solution for protecting yourself is constant, militant vigilance with passwords. I don't know any of my passwords at all, and what's more, I even have randomly generated answers to security questions.
Also, where possible, use two-factor authentication. You can use SMS, Authy, Google Authenticator, a Yubikey, whatever. Just turn the damn thing on and use it if it's available to you.
Some people forget that email almost always works as a way to reset passwords, and the also forget that dns registrars and dns hosts control where your email goes (if you're using your own domain).
Your email domain is a link in the authentication security chain for everything that'll let you send a "reset password" email. If someone can subvert your domain's MX records (by breaching your registrar account or your dns hosting, or by subverting the dns of the outgoing mail servers of the service they're trying to attack) then you've lost. If _any_ of those parts have weak authentication, your whole auth chain is weak.
(How much would you bet against me being able to change your cellphone account password and get your sms 2FA redirected if I can subvert the email account associated with your cellphone account? The OP is only lucky that his attacker wasn't quite sophisticated enough to attempt to take control of his cellphone account before firing off the Github 2FA SMS...)
> Some people forget that email almost always works as a way to reset passwords
I recently switched distros on my work laptop and went on holiday. I didn't take the backup drive from the old install with me. I use KeePass. My company uses LastPass.
I had to log-in to LastPass, so grabbed my username and password from KeePass, and tried to log-in to their website. I was then greeted by a request to give the "Sesame" code. For those who don't use LastPass on Linux (maybe other platforms as well), Sesame is an OTP generator, installed on the user's computer.
I was stumped. I hadn't copied the Sesame install to the new distribution. Luckily, LastPass provided me with a helpful link "Disable Sesame for this account". They sent me an email to confirm that I really wanted to disable Sesame, I clicked the helpful link, and upon next log-in, just my username/password were sufficient.
The LastPass enterprise administrators (people in the company with admin access to our LastPass account) did get an email saying that I had requested the deactivation of Sesame on my account. They were... "surprised" to hear that I did it myself.
That's a LastPass bug; if your 2FA can be disabled with nothing more than an email challenge-response, your second factor is just email.
For comparison, when I had trouble with Linode's 2FA - I set up a new phone and wiped the old one before realizing that Google Authenticator doesn't include TOTP secrets in iPhone backups, in effect destroying my 2FA token - and my scratch codes failed to work, I had to provide government ID matching my account information before their support department would disable 2FA on the account. I'm not overjoyed by the fact that an implementation error prevented my scratch codes from working, but I was pleased by the nature of the verification required to disable 2FA so I could log in again and re-enable it. Linode may have had some security problems in the last few years, but this at least they got exactly right.
Keep in mind too that this argument chains - if your 2FA can be disabled with access to your phone/SMS, and your phone account can be updated with an email challenge response (or just a confident voice-call to your carrier's customer service), it's just one extra level of hoop-jumping for your attacker.
>> Due to the risk that SMS messages may be intercepted or redirected, implementers of new systems SHOULD carefully consider alternative authenticators. If the out of band verification is to be made using a SMS message on a public mobile telephone network, the verifier SHALL verify that the pre-registered telephone number being used is actually associated with a mobile network and not with a VoIP (or other software-based) service. It then sends the SMS message to the pre-registered telephone number. Changing the pre-registered telephone number SHALL NOT be possible without two-factor authentication at the time of the change. OOB using SMS is deprecated, and may no longer be allowed in future releases of this guidance.
So they are finally admitting that SS7 is a huge security problem to the point they have to recommend everyone not to use it for 2FA anymore....but they are not going to try and fix SS7.
It's not just the technical problems with SS7 - it's a business issue.
The Telco's prime motivations are to make it easy for their customers to make more calls and send more text messages - that's what make them money. Making it difficult to port phone numbers away from competitors, or making it difficult for customers to redirect phone calls or text messages is bad for business, and will lose them customers and/or increase customer support costs.
There's absolutely no upside to a Telco for doing any of that - they don't really care if that makes their product less secure for use-cases other 3rd parties who aren't paying the Telco - the Telco's never signed up to provide a secure channel for your bank to send secrets to you - and the banks aren't offering to pay them for it. The Telco's customers are paying, and to an overwhelming degree they demonstrate that they prefer convenience over security - you get pissed off and potentially change carriers very quickly if you cant call them up from a friend's phone when yours get broken/stolen and get your calls/texts redirected to another number immediately. The fact that that same ability give access to social engineers to get hold of banking pins and internet service 2fa secrets is a vanishingly small concern for the people paying the Telco's.
So they just don't care. Not their problem. Sucks to be a bank.
My idea is get rid of minutes and text and simply have data on your phone. Then you can use the call/sms service of your choice to provide those features over https. Basically unbundle the whole deal. The carriers would never go for it but I think it would work.
I've got a nephew who sort-of does that with an iPod touch. It doesn't even have a cellular data connection - he relies on glomming on to free wifi at school/home/friend's houses/the library/the shopping mall/wherever, and gets iMessage and Skype only when he's got wifi - which is "good enough" for him to not even bother upgrading to a phone with a pre-paid account... (He's even managed to convince his Mom to leave the wifi hotspot on her phone running all the time, so he can make/receive calls in the car...)
SS7 attacks get a lot of news coverage but they still aren't practical for most non-government attackers. What generally happens is that they trick the phone provider into issuing them a new SIM card for the account or redirecting the number to one they control.
Also, TOTP is kind of secure if you never log into the website from the device that has the authenticator. Otherwise, it is pretty vulnerable to attacks that target the client.
IMO the real issue here is that almost all websites consider that email is a good way to verify the identity of someone when they want to reset their password, while in reality email is a terrible medium. Attacks on the DNS work, and a lot of SMTP traffic is still plaintext. The way to secure email is to encrypt and sign at endpoints but of course websites don't do this in the reset password flow.
A long time ago I used "rings" of passwords, where the least secure sites shared one, medium secure sites shared another, and most secure sites shared a third.
This has some disadvantages, one because I was not always good at predicting which sites would end up security critical. (I probably signed up for 10 random web forums in 2009 and nothing at the time made news.ycombinator.com the obviously-important-to-me one.)
These days, though, password managers. Use them 100% of the time. Turn 2FA on everywhere; mandate it administratively (ideally in can't-be-ignored settings) for company systems.
One case although, is to keep a simple password you'll remember to access your client-side encrypted cloud backups of your password manager db. Otherwise you could end up in a case where you've lost all of your passwords and your shit out of luck when you lose your computer and your local backup.
> One case although, is to keep a simple password you'll remember to access your client-side encrypted cloud backups of your password manager db. Otherwise you could end up in a case where you've lost all of your passwords and your shit out of luck when you lose your computer and your local backup.
The problem is that if you can remember a password, then a computer can guess it, and if you store something in the cloud then a computer can perform offline attacks all day long. And as time goes by, those offline attacks only get faster. This is one of the reasons that Mozilla's new Firefox accounts & sync system are insecure and unsuitable for storing passwords or other private data.
Sure, if it's an epic passphrase run through PBKDF2, bcrypt, scrypt or argon with a truly evil work factor (like, on the order of hours), then _maybe_ it's suitable for securing a backup of the keys to one's kingdom. Maybe.
Better, I think, is to encrypt the backup with a secure key, then encrypt the secure key with a memorable password, then use k-of-n secret sharing to give shares of the encrypted key to some number of trusted people. Up to k-1 of those people may disclose his share without endangering the encrypted secret, and if k do disclose it then it is still protected by the memorable password.
The problem is that in a world of cloud backups, a mistake tomorrow can endanger yesterday's backups.
>The problem is that in a world of cloud backups, a mistake tomorrow can endanger yesterday's backups.
This. This is the big problem with password managers. If your master password ever get compromised, you can't effectively change it in all backups and replicas, new and old, local and cloud, on various media supporting reliable wiping or not. You either can't track or can't control them. Even periodic rotation of master password is almost pointless.
I keep a note in the safe at work providing me with sufficient hints about my password manager password to be able to recreate it - without it being something that helps anybody else (think something along the lines of "every third word of the first two stanzas of that poem my second girlfriend loved").
I have the encrypted file synced across two phones, an iPad, a work machine (including it's on-site and off-site backups) two home machines (including a Dropbox account, a Time Machine networked backup drive, and a weekly rsync of the Time Machine backup to off-site storage).
I did once leave a bag containing my laptop, and my 60G iPod containing my laptop's only backup (including my only copy of my password manager file and a fair bit of confidential work-related source code) under an outside table at a cafe right before closing time. I spent a sleepless night worried as hell about it, but a friendly and familiar waitress who kind-of knew me had found it and stashed it behind the counter with a note to her manager describing me, so I got it back the next morning. That made me a) very happy, and b) somewhat more careful and paranoid about my backup and password storage habits...
Keep it simple but long, see famous relevant xkcd "correct horse battery staple" . My randomly generated passwords are usually 16 characters, but my password manager master is 40+ chars, and much easier to remember.
> It is not enough to use some strong passwords for the things you think are sensitive. Every weak password is a weak link in your total identity chain.
I get what you're saying here, but this is patently false. My HN account is not a weak link in my "total identity chain" in any way that matters.
Yes, obviously defaulting to strong passwords everywhere is a better default because you can make mistakes when judging how important a specific site is, but that doesn't mean that every site is critical.
I believe parent's thinking is that a total identity chain comprises all human-influencing bits of identity. Most of these social engineering attacks fuzz boundaries in human-arbitrated authentication systems. And I wouldn't categorically rule out any portion of my identity as never being useful to an attacker.
You're right that not every website is critically important, but that also wasn't my point. My real point is that it is important to treat every website as though it were, because having that decision making ability is dangerous.
Yet with access to your HN account, a malicious person could damage your reputation and career, and I can imagine different kinds of social engineering that makes "weak link" seem plausible.
> Until password management or authentication are substantially overhauled on the web, the most optimal solution for protecting yourself is constant, militant vigilance with passwords. I don't know any of my passwords at all, and what's more, I even have randomly generated answers to security questions.
This is a good point. Those "On what street did you grow up" security questions do not increase security. If answered with real answers, they decrease security, since a lot of this stuff can be looked up online. It boggles the mind why a company would go to the trouble of encouraging users come up with a strong password, then turn around and deliberately provide a softer attack vector.
I recently had to do some security questions with my bank to verify myself- the trick was, they were all multiple choice, and they actually said "we pulled these from public record". Furthermore, I saw earlier someone mentioned the same thing, but they had filled their questions with gibberish, so when support gave the options the gibberish stood out significantly.
> Also, where possible, use two-factor authentication.
I have turned on two-factor wherever possible, but I am thinking about turning it off again for PayPal. It sends an SMS every time I log in, even in their app or on a PC I have logged in on before. I wish they would keep a device authenticated at least a month or so, only asking for the password on each login.
Unfortunately, I had to disable SMS 2FA on Paypal. I got locked out multiple times for days because their system had issues and it wouldn't send me the SMS code. Eventually I had to call service support and get them to disable it so I can enter the account again. And I left it disabled.
Paypal is one of those services where it's very dumb not to have 2FA, but until they overhaul their 2FA system, or support something like a Yubikey/Nitrokey/U2F and Google Auth, I won't risk using it again.
>>In this instance, though, the attack vector was DNS. My account at the not-so-incredibly-common DNSimple.com did not use a highly secure password. I didn’t think it was necessary, as in my mind, the only reason that the security of an account like that would be at risk would be if I was the explicit target of an attack. Once again, I thought to myself “That’s something that only happens to other people”.
Kenneth used a randomly generated password and two-factor authentication on his GitHub account, which is great! But on DNSimple he made the decision to forego better security because it seemed unlikely to be a target.
It is not enough to use some strong passwords for the things you think are sensitive. Every weak password is a weak link in your total identity chain.
The best way to use a password manager is to never give yourself authority to make passwords unless they are randomly generated. Even if the site or account in question appears innocuous or insignificant, even if it does not allow you to make a password of your manager's default strength, commit yourself to going through this process 100% of the time.
Yes, it's a usability pain to constantly use a browser extension to log in. But that pain is nothing compared to the stress of a compromise or targeted attack.
Until password management or authentication are substantially overhauled on the web, the most optimal solution for protecting yourself is constant, militant vigilance with passwords. I don't know any of my passwords at all, and what's more, I even have randomly generated answers to security questions.
Also, where possible, use two-factor authentication. You can use SMS, Authy, Google Authenticator, a Yubikey, whatever. Just turn the damn thing on and use it if it's available to you.