On Cybersecurity and Being Targeted
kennethreitz.org
kennethreitz.org
>>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.
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.
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...
Not that I think we'll be rid of SS7 even a decade from now, but there is a reasonable path to take, yes ?
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.
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.
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.
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...
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.
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.
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.
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.
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.
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.
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/
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.
Spoof an inside line's callerID and say "Hi, it's Dave. What's the root password?"
;-)
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.
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!
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. :/
How? Lets play devils advocate here and pretend your email is compromised (account takeover or redirect). What have you done on any of the services you use that has given you comparable security to enabling 2FA on them that now prevents the attacker from resetting your password?
By hardening your email server. Yes, assuming the email server is compromised implies a compromised system in this scenario, but that is tautological and therefore uninteresting.
The extra attention should go towards hardening the weak link, in this case the email server that, de facto, provides authentication services.
Server hardening is a vast topic, so I leave it as an exercise for the reader to research what can be done. Surely you don't deny that "a little extra attention" to server configuration can provide additional security without necessarily resorting to 2FA?
But again, 2FA is valid security, so why not host it yourself? I have nothing against 2FA in principle, but I don't trust Google, Github, Facebook et al with my phone number.
While we're on the subject, the inherent insecurity of the SMS protocol should also be weighed in any serious endorsement of phone-based 2FA: http://www.itnews.com.au/news/telcos-declare-sms-unsafe-for-...
> but I don't trust Google, Github, Facebook et al with my phone number
Github doesn't require a phone number to use 2FA. And if you don't trust Google or Facebook with your phone number then that means you don't use either of them at all? Because otherwise holding back your phone number from them is a rather pointless exercise as they already know everything about you [1]
>And if you don't trust Google or Facebook with your phone number then that means you don't use either of them at all?
More or less. Email I can handle, and there's stuff I stupidly gave up in the past, but I see no reason to provide them with additional info.
>Github doesn't require a phone number to use 2FA
Are you referring to the application? That might be a fair compromise depending on what kinds of permissions the application requires.
>A hardened email server doesn't prevent a targeted attacker from just redirecting your mx records (as happened to OP).
What on earth are you on about? Of course it does. The OP had a crappy password, which is about as fundamental as it gets with regards to server hardening...
"The application" is an open standard called TOTP, which doesn't require any specific application. I just set up 2FA for my personal GitHub account using a TOTP app on my Pebble watch. The actual crypto for the 2FA is done locally on the watch, no other device can spoof it, and GitHub get exactly zero feedback or information from this - other than the 2FA code that I type, of course.
There's other ways to do 2FA - U2F is an upcoming standard and people have been using dongle-generated codes from RSA for years.
Before making pronouncements that go against current best practices for end users, you really need to get a much better understanding of what you're talking about. Saying nonsense in a confidence voice is enough to convince people that your terrible advice is worth following, and could result in them having worse information security as a result.
You can have the most secure/hardened email server on the planet but if I can change your mx record at your dns provider it will do you no good. And there are multiple attacks against DNS that don't require me to target your provider even (e.g. https://en.wikipedia.org/wiki/DNS_spoofing)
And once all your emails are being sent to me, I can own every account you've signed up for using that email (through reset password). And currently the only reliable defence against that is 2FA.
* Your DNS Records - MX records point to your email server, the attacker just changes the record to point to their email server, taking your hardened email server out of the loop.
* Your Domain Registrar - the attacker can just change your DNS records to point to their own DNS servers (with their own MX records pointing to their own email server).
Do you trust your DNS provider is completely secure from hacking and social engineering?
Do you trust your Domain registrar to adequately secure their systems from hacking and social engineering? Remember, you only pay them ~$10/year for your domain.
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.
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.
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.
• 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-...
What am I supposed to use then?
No guarantees this will pass whatever-service's arbitrary validation filters though.
@[IP address] is a really bad idea.
I'm not convinced this is a property of domain names. It seems like as long as you pay your bills, your provider stays in business, and no governments get involved, both these identifiers are effectively permanent. Your IP is likely provided by the same people who own or co-locate your physical server anyway. In any case, you're likely to get enough advance notice of ip changes to update your various accounts.
Are you sure your POP3 mailbox is using encryption for the password? The original port 110 POP3 protocol sends it in cleartext unless there's an STLS command sent (which is MITM-able) - POP3S over port 995 (or 997?) will be encrypted (but then you need to consider whether all the software in the chain is actually checking SSL certs and their chains...)
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).
Could you share a way to resolve it? I've been in such situation recently. I was forced to change VPN I used for long time to access my Gmail account. And I haven't 2FA enabled because I didn't want to give out my phone number.
In another, fallback/recovery ultimately worked, but I needed to try from several devices.
The "security questions" proved worse than useless. Unless exercised periodically, I think people forget or lose the answers (or even questions). Worsee, vendors change their strategies.
Seveeral of my Google IDs started from entirely different services, with different rules. And privacy guidelines. E.g., YouTube's old "never use your real name" advice.
How quaint!
Identity is weird.
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.
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).
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...)
It doesn't look like the authors/contributors of requests are using Github signed commits either.
> figurative language
I read the Wikipedia article. It indicates our friend rcthompson expected his question to be interpreted literally, not figuratively. He did not use a simile, nor metaphor, nor any of the other techniques Wikipedia lists.
Perhaps you're suggesting that "comprehensive" should be interpreted as "many" or "a large variety" when the proper meaning is implausible. In that case, what use is the word "comprehensive"?
I should point out that I've seen lots of comments lately that actually are absurd. Forgive me for the mistake?
(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.
(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.
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?