>>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.
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...)
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.
Edit: typo.
Well, it's not recommended:
>> 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.
Source: NIST (https://pages.nist.gov/800-63-3/sp800-63b.html)
The telco industry tells the banking industry not to consider SMS secure...
That said, many websites use a Twilio two-factor integration and don't support anything else. If that's the case, you should still use it.
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.
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.
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...
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 think we mostly agree here though :).
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 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.
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.
Call me paranoid, but I have a hard time seeing the push for 2FA as anything other than a plot to collect valuable user data. As with most any good lie, it's mostly true -- 2FA does improve security -- but what happens when a company goes bankrupt and sells off it's assets?
Moreover, I can't help but to question the actual necessity of this security feature. The OP's mess could have been avoided if he'd ... you know ... systematically chosen secure passwords.
>Turn on two-factor authentication. Right now.
I'll pass, thanks.
P.S.: thanks for Requests!
Exactly. Mostly when I see companies like Google, Facebook, etc constantly trying to trick me to activate it. And yes, I say trick: The option to ignore/skip is always hidden/disguised, totally ignoring the UX and accessibility needs.
This and the fact that the input text fields already have my phone number populated on them ...and are just waiting for my consent.. this does not inspire trust, no.
You make this sound like it's part of a conspiracy to force 2FA on the unsuspecting masses so that the Illuminati can sell your contact details to aliens from Mars, or something. That's a bit insulting to the original poster, who is sharing useful information learned through real world experience.
A lot of the time, though, it really is. I always prefer TOTP over SMS, but it's rare to be given the option.
In this exact scenario that is true but in general, not necessarily. He could of had a very secure password on his dns provider but through some other method that account could still have been compromised (social engineering, sql injection, poor brute force rate limiting, some other attack vector). And then once the dns account is compromised a password reset on github is trivial if there isn't 2FA on the github account - or any other account linked to that email account.
This isn't to say that 2FA doesn't add security. The point is rather twofold:
1. with a little extra attention, I can secure my system without 2FA and achieve comparable security
2. it's absolutely scandalous that the proverbial well has been poisoned and we are, by virtue of the fact that extra attention is required and that most people won't put in the work, in a less secure state. Again, this is due to the irresponsible data-policy of the overwhelming majority of service providers.
So again: 2FA is a valid security layer, but I'll pass. :/
Which leads me to another idea. If websites supported separate email accounts for messaging and authentiaction/resets and kept the second account name hidden from general public it would (somewhat) help in a lot of cases.
Also, I would be much more likely to do 2FA on more accounts if websites gave me the option to use printed lists of tokens instead of my phone number.
• Avoid using custom DNS emails (e.g. yourname@yourdomain.com) for any login purposes. It basically opens you up for these kind of attacks (where a hacker breaks into your domain name account and forwards your custom email to his own).
Read N's story at https://medium.com/@N/how-i-lost-my-50-000-twitter-username-...
I almost lost an old @gmail.com address when they asked me to verify a really old phone number for no reason. Never trusted them again.
The reason I disagree is that if you use something like gmail or outlook.com for logins/ password resets there Is a nasty potential problem which Is if the provider locks you out of your account you could be completely stuffed.
There have been cases of people losing access to their accounts because of ToS breaches in the past. If that account is your login account for other systems you could also lose access to those.
What am I supposed to use then?
That said: on account of size, targeting, procedures, and what I find are generally fairly diligent employees on the tech side (design, products, ads, and gov't rel'n are another story), you're probably as safe with Google as with any other large vendor.
That said, the basic problem here -- getting locked out of your account or profile, or allowing the wrong person in -- is a HYUUUGE problem. And the 2nd Amendment people can't do anything about it either, to continue the allusion....
I wrote of my own "I've been locked out of a Google account" account, well, twice. It's been pretty annoying (particularly as I'm paranoid and don't trust Google to know who I really am, because reasons). It's been resolved within a few days, though it leaves me scratching my head a bit.
As I noted the first time, and have adopted as a slogan for this type of event, "Who are you is the most expensive question in information technology. No matter how you get it wrong, you're fucked." See: https://redd.it/2w618r https://redd.it/3mo7l6
Unfortunately, that issue is paired with another, also sloganed and given to much use: Data are liability.
If you hold data about people, or state they consider important (e.g., a widely used codebase), or other elements, then you've got control point others may well find they wish to avail themselves of.
I don't have solutions to either of these problems (I'm paranoid, not narcissitically delusional). I can see the shapes of possible solutions, including reducing attack services and possibly having a more widely distributed and socially-integrated identity verification mechanism. Or offering far more services as stateless and without locally-maintained data, at least in cleartext.
Better notifications, recovery, and encryption methods for mail would also help -- capture of email accounts would matter far less if they were encrypted to keys held only by the user (and absolutely not on the control path involved in accessing or specifying them, such as MXs).
No guarantees this will pass whatever-service's arbitrary validation filters though.
We know from postmortems that the error-handling code tends to be among the least-tested parts of a codebase, which leads to cascading failure. I wonder if an even wilier attacker could have leveraged the analogous failure here.
Authentication aside: what does somebody do to talk to GitHub if you don't have a friend at GitHub that's willing to chat with you? Would Kenneth have been given the Source IP address of the attacker if he didn't know someone there?
Write a blog post on Medium with the perfect click-bait title to make it go viral. Hope a github engineer reads it and gets back to you.
The question isn't about how to authenticate yourself to the friend at the company, the issue is that the friend in the company shouldn't (and shouldn't be able to) perform privilege escalation. They can tell you what has/hasn't been done with your account, but then you have to login or reset password the normal way in any case.
Spoof an inside line's callerID and say "Hi, it's Dave. What's the root password?"
;-)
http://www.cisco.com/c/en/us/about/security-center/intellige...
"When Cisco ASA is configured for ESMTP inspection, the ASA is not able to examine the TLS session because it is encrypted. Therefore the ASA will prevent the establishment of the STARTTLS session and allow the SMTP endpoints to determine whether the SMTP session should continue in clear text (that is, with no privacy)."
(I once billed a client just over $30k to investigate/diagnose/resolve that problem - there was a piece of Cisco gear on the edge of their network that nobody ever admitted to even knowing existed which was stripping out the STARTTLS instruction between a webapp running inside their own datacenter and their own 3rd party mail service - and everybody was pointing their fingers at _me_ for the mail not coming through encrypted... Twitch. Twitch. Twitch...)
(edit: Oops, I guess I didn't realize the bold were hyperlinks in the article. Thanks for the pointer.)
Also is it possible to check if someone has 2-factor authentication?
No way to mandate 2FA yet though.
If you're a developer of a popular open-source project, this should serve as a warning to make sure you have multi-factor authentication on, yes, but it's even better to learn from this and come up with incident response plans with your core maintainer base. Ask among yourselves:
1. Do we have the ability to detect an overt breach like this one?
2. Do we have the ability to detect a covert breach (e.g. are our builds reproducible, auditable? Are our binaries signed? Do we know who our committers are?)
3. Do we have a consistent way to message users of the project of the compromise?
4. Do we have a way to deprecate/mark as tainted compromised versions of our module/package/application?
GitHub offers some technology to help in this regard. Sign your release tags, at a minimum [1]; sign your commits with developer keys if you're paranoid. [2]
As FOSS becomes more used in the enterprise, I suspect these attacks will become less of a rarity.
[1] https://news.ycombinator.com/item?id=11494997
[2] https://help.github.com/articles/signing-commits-using-gpg/
DNS is the foundation upon which everything else is built. And, it's been my experience that DNS and email attacks are very common.
If an attacker can compromise DNS and email, then they can compromise all the higher-level services that send password resets by email (twitter, github, facebook, whatever).
It doesn't look like the authors/contributors of requests are using Github signed commits either.
(Incidentally: I'm not familiar with what the Certifi bundle is, and some quick DDGing didn't turn it up.)
As a recent convo I'd had here on HN turned up, key management is a crucial element of PKI, which includes not only SSH and PGP, but the CA-based measures: SSL and TLS.
Your web link is only as secure as the least-paranoid developer's MX registrations in your entire development toolchain.
I mean if this doesn't happen, and if government don't take steps to improve the situation in the next 10 or 15 years, won't things get worse enough that politicians notice?
