Security

5 easy ways to compromise your own security

Maybe you've effectively secured your IT resources against malicious security crackers, as much as reasonably possible. Perhaps it's even secured against "acts of God." There's always at least one more danger: that you'll accidentally compromise security yourself.

There's no way to compile a comprehensive list of all the ways you might let a well-protected system's security slip through your fingers, of course. The kind of mistakes you can make are innumerable. The following list offers just a few all too common examples of how security is accidentally compromised from within, by someone somewhere, every day in this world.

  1. Misplaced trust: Don't enter your online banking password on someone else's computer. Don't trust a brand. Don't trust security systems that don't trust you. Don't trust the government farther than you can throw it. Don't even trust yourselves too much -- because trusting in the infallibility of something you create can prove fatal to security.
  2. Security through ignorance: Most of us are probably aware that obscurity is not security. That doesn't mean we don't try to use obscurity for security, sometimes without even knowing we're doing it. A great example of this is the effects of Google and Yahoo! indexing Flash content. This indexing is showing that a lot of sensitive information is naively encoded in Flash objects, and has been available to people with the know-how to harvest it all along. Many of the people who created these security sieves never realized that they were essentially relying on obscurity for their security, though. The problem in many cases is that they didn't really understand the technology they were using, and as a result they never thought things through enough to realize that the only thing "protecting" such information was a veil of obscurity. Don't make that same mistake; understand the security implications of the technologies you use.
  3. Unsecured e-mail: Do you send business secrets through e-mail? Does your Web site offer a way to recover passwords via e-mail? If those e-mails aren't encrypted, you're basically handing the keys to the kingdom to anyone who cares to get them. A particularly egregious example of this kind of blunder was the case of unencrypted embassy emails sent through the Tor network.
  4. Unsecured encryption: Just like the anonymity provided by Tor, encryption itself is not a magical cure-all. In order for OpenPGP encryption to be usable and useful for protecting communications, you have to be able to decrypt any encrypted messages you receive. In order for it to be secure, you have to keep your private key private, as well as the passphrase you use to access it. If the computer on which you maintain your private key, and where you decrypt and read messages you receive, isn't properly secured, that means your encryption isn't properly secured either. Some systems are more prone to problems that compromise the security of your private key than others -- things like unauthorized access that might allow someone to copy your private key and launch an offline brute force attack on your passphrase, and keyloggers that can capture your passphrase as you type it in. It's even worse when you use encryption on someone else's computer, where you may have little idea what security measures have been taken by those who have administrative access, or even whether they themselves can be fully trusted. Ultimately, you may be better off communicating via plain text than encrypting messages, if the security of your encryption keys is too weak. At least if you communicate in plain text you know whether it's effectively protected against eavesdropping.
  5. Unwinnable battles: Choose your fights wisely. Don't focus a lot of energy trying to protect what can't be protected effectively. If securing the unsecurable is necessary to your business model, you may want to rethink that business model -- not only because of the inherent flaw in a business model like that, but also because all that effort put into securing the unsecurable is diverted from securing everything else. Don't take the easy way out, blaming everything on anyone except yourself when your business model is built to fail, giving yourself excuses to squander time and energy on a quixotic quest for the unattainable. It's not my fault your business model sucks.

Don't make these mistakes. Think about them, though, and if any of them are problems that hadn't occurred to you, think about what else you might be missing. Learn to think like a security professional, always looking for the way unintended consequences might arise from innocent actions.

About

Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.

23 comments
Sumjay
Sumjay

Another precaution one should take is when you get an email from a known friend inviting you to join 'Facebook' or 'My Space", check out the properties on your friend's name in the 'From' box. You will find that it is not your friend's email address. I just delete those solicitations from the Social networks.

BALTHOR
BALTHOR

I let somebody else captain my ship and have a navigator that knows where the enemy is.Then I cook pizzas on the bridge.Before melting their ships I beam over a bar of gold.We listen to heavy metal music and have subdued lighting.

shava
shava

So what you're saying is, the greatest compromise to security may well be users (who resist good security discipline) rather than administrators? This site is full of folks who'll take responsibility for their online hygiene, but for those of us who are site administrators, we can't get folks to learn how to secure their own activities, and very few companies back up any stated sanction (if any) to their staff negligence in areas of computer/network security. As a side note, thanks for implying that the embassy password issue was an administrator issue, not an issue with Tor. Tor doesn't encrypt end-to-end, it just passes the packets encrypted. If there isn't https: (or equiv) on the other end, the packets are in the clear as they approach their destination. One of the riskiest things I see folks doing all the time is putting passwords into http: (rather than https:) pages on unencrypted wifi in coffeeshops. Anyone can sniff these. I use Tor on public unencrypted wifi just for the benefit that the first hop of the Tor path (vs. the last hop) is always encrypted. Shava Nerad Tor volunteer (http://torproject.org)

apotheon
apotheon

Have you ever compromised your own security in one of these ways? How about in some other way that, looking back now, you realize was a tremendous mistake? What are some other ways people might compromise their own security?

Lovs2look
Lovs2look

I want some of what he's smokin'.

apotheon
apotheon

"[i]As a side note, thanks for implying that the embassy password issue was an administrator issue, not an issue with Tor. Tor doesn't encrypt end-to-end, it just passes the packets encrypted. If there isn't https: (or equiv) on the other end, the packets are in the clear as they approach their destination.[/i]" Tor is an anonymization system -- [b]not[/b] an encryption system. If you use it as though it protects your data from eavesdropping, you're going to be woefully disappointed, because [b]that's not what it's for[/b]. The people sending sensitive data through Tor gravely misunderstood its purpose, and they paid the price for their ignorance. Such is life.

Mond0
Mond0

The single biggest source of malware has got to be the users that can't resist clicking on everything that comes their way. These buffoons put us all at risk!

Mond0
Mond0

I've never heard of Tor, so after reading this I checked it out and found this: [i]To create a private network pathway with Tor, the user's software or client incrementally builds a circuit of [b]encrypted[/b] connections through relays on the network.[/i] https://www.torproject.org/overview.html.en Nice pie you got there...

Timbo Zimbabwe
Timbo Zimbabwe

"The single biggest source of malware has got to be the users that can't resist clicking on everything that comes their way." Such as links from an email that they recieved from "hackyourbox@donottrustme.duh" and websites that "just happen to pop up on their own." Then they have the nerve to claim that they can't understand why their PC has been infected 16 times this month....

Neon Samurai
Neon Samurai

I realize that this whole thread is probably due to my assumption that an "encryption system" uses encryption and that your statement that Tor was not an encryption system meant something that it did not. As such, could you please enlighten me (briefly for the sake of others) if there's more than a semantic difference here. Feel free to send me links via email if you have the time or inclination. This may be more for my benefit as around here I?m likely to be corrected pretty quick if I?m wrong. Tor is an anonymization system or a system that makes use of encryption. It?s purpose is to scramble the source address of the client and encryption is part of how it acomplishes that goal. Encryption also helps blow through filtering between client and Tor network since firewalls can not simply look at the packet and determin that it is a blocked protocol. While Tor uses encryption, it is a program making use of an encryption system for part of it?s process. It is like an email client that allows you to sign or encrypt your mail before sending it; the overall process is sending/writing/receiving email but Thunderbird/Outlook make use of encryption in part of what they do. OpenSSH is more in the grey area since it?s focus is very much on encryption though technically, it is making use of encryption systems within it?s greater functions as a replacement for ftp, telnet, remote copy, remote command or proxy service. Ssh is providing the telnet remote command line functions but it is using end to end encryption when making the connection between local and remote computers. It is providing file transfer functions but does so over an end to end encrypted connection. Proxying again is providing a local port number and remote port number connected through end to end encryption. (ssh through Tor would be slow as anything but would sure earn one a Paranoia badge of honor) These are ?systems that use encryption? rather than ?encryption systems?. In contrast, an ?encryption system? would be the frameworks that Tor and OpenSSH make use of. The encryption system is contained in one of the libraries that the programs load along with other required libraries referenced by the overall program. To simplify, consider Pretty Good Privacy/Gnu Privacy Guard or OpenSSL encryption systems. PGP/GPG is for encrypting files or storage or unencrypting them. Want to sign an email or encrypt a file for storage or before sending to someone; GPG does that. When your email client signs or encrypts your message; GPG was probably the plugin used. OpenSSL?s reason for existing is to encrypt connections; it is the ?S? in ?https?. It is the encryption system that your browser and the webserver connect to each other with as ?systems that make use of encryption?. I?m not sure how clear that is and I?m more curious to test my own understanding but hopefully that clarifies for others also.

Mond0
Mond0

Apotheon, I realize that this whole thread is probably due to my assumption that an "encryption system" uses encryption and that your statement that Tor was not an encryption system meant something that it did not. As such, could you please enlighten me (briefly for the sake of others) if there's more than a semantic difference here. Feel free to send me links via email if you have the time or inclination. Neon Samurai, Of course there's no encryption at the end point unless you're using HTTPS or some other end-to-end secure connection. I think that we all understand that and the last paragraph should have made that clear. Shava, Thanks for chiming in. I don't think I need any help with my "literalism" but if you could send over some "anti-assumption" that would be great ;)

JCitizen
JCitizen

I had a data privacy feature in PC-cillin that prevented such password/ect. transfers by blocking outgoint data on non SSH/SSL connections. It looks like Comodo's iVault does the same thing; at any rate, this feature illustrates the facts about your statement.

shava
shava

First, although I am formerly the executive director of the Tor Project, I don't speak for them, and I'm only a volunteer on the project these days, just to be clear. But if you go to the DOWNLOAD page, there's a bunch of text you have to scroll through (can't make you read it...). Under number 4 of the points made under the bit where it warns you that installing Tor isn't enough to protect you -- that you have to change your habits -- it says: "Tor anonymizes the origin of your traffic, and it encrypts everything inside the Tor network, but it can't encrypt your traffic between the Tor network and its final destination. If you are communicating sensitive information, you should use as much care as you would on the normal scary Internet ? use HTTPS or other end-to-end encryption and authentication." If that isn't clear enough for anyone who downloads the software...well, as I said, we can present them with text but we can't make them read it. Mond0, it should be clear that every application that *uses* encryption doesn't use it end-to-end. For example, your browser may keep your username/passwords on your hard disk encrypted, but they are sent in clear text across any page that is http: vs. https: If this isn't clear enough to you, I can not help with your literalism, but I could advise you gently that if you insist that if the word encryption appears anywhere in a process that the process *is* encrypted, you are going to have a lot of compromises to your security. Which I suppose is the point of the article, yes? Shava

Neon Samurai
Neon Samurai

.. rather than looking at the information and what answer it's analysis results in. So, yes, we can agree that encryption is used within the Tor network; no one has yet to claim otherwise. Here's what I think you are missing or ignoring to try and make the evidence fit your hypothisis; the encryptiong is not end too end. Between you and the Tor "in" node, the connection is or can be encrypted. Your Firefox with Tor plugin makes an SSL connection (I think it actually uses a local proxy but tunnel or https is the same result) to the Tor server. Between Client (you) and Tor "in" server; your encrypted. Between the Tor "in" server and Tor "out" server, connections are also encrypted. What happens here is the packets (what your sending/recieving) go from Tor server to Tor server down the various onion layers to the middle and then back up the onion layers to the "out" server on the other side. This is also why it's called an "onion" network. The Tor servers keep no logs so anyone tracing packets back to there source loose the trail in the forest of Tor servers. Between Tor "in" and Tor "out"; encrypted still If your keeping score, we're not encrypted from the client (you) through Tor to the "out" server on the other side. Anyone on your side of the Tor network get's your encrypted packets but can see where they come from. Anyone within the Tor network, get's the encrypted packet but can't see where it comes from. Now, here's the part you have to keep in mind. Between the Tor "out" server and the recipient server (youtube.com, google.com, bigboobs.com,..) depends on the protocol used by the recipient server. If you connect to http://google.com; the packets between Tor "out" server and Google.com are not encrypted. If you connect to pop or smtp; pain text between "out" and your mail server. If you connect to ftp://ftp.mysite.com you've got plain text between "out" and recipient server. Basically, either all servers on the internet have to move allowing only encrypted protocols (https, pops, smtps, ssh) which won't happen at current Certificate Authority pricing. The other option is every server on the internet installs some sort of Tor server side client so that all connections between Tor and the recipient servers are encrypted by default; this won't happen because it means any possible server which a user may randomly hit while browsing with a Tor plugin. The connection between Tor "out" node and recipient server is not encrypted unless you are using an encrypted protocol and then, only if it's a true end to end encryption; some encryption authenticates in plain text before starting the encrypted tunnel. So, using encryptiong within a service that you have available to you for free is different from providing you with end to end encryption for all your packet exchange needs. "Individuals use Tor to keep websites from tracking them and their family members, or to connect to news sites, instant messaging services, or the like when these are blocked by their local Internet providers." Glad you braught that up though. 'to keep websites from tracking users or there family members or to use services blocked by there ISP' That's the key point paraphrased badly. If the server you are connecting to tries to figure out where you come from, they can only get as far as the Tor "out" server. Traceroute will go no further and going through server logs for each node step back to the Tor "in" server is not possible since logs are not kept. The server will still have a log of your connection and login if you had to provide uname/passwd; it can't trace where you connected from though. Because traffice between you and the Tor network is encrypted; you get past the firewall rules set by your ISP (or Chinese government; human rights is a big motivator for the Tor project). So: 1. "keep websites from tracking them" as in where they connect from - True. 2. "connect to sites blocked by the local ISP" - True. Am I missing something? Are you really this upset that Tor is not able to force an encrypted connection between "out" server and where you are connecting too? Are you erally raging against some feeling of false advertising here? I honestly may not be understanding the point we differ over.

Mond0
Mond0

I've read through the [b]Tor Protocol Specification[/b] and here is some of what is there. First note that: PK -- a public key. SK -- a private key. K -- a key for a symmetric cypher. a|b -- concatenation of 'a' and 'b'. [A0 B1 C2] -- a three-byte sequence, containing the bytes with hexadecimal values A0, B1, and C2, in that order. All numeric values are encoded in network (big-endian) order. H(m) -- a cryptographic hash of m. [b][i]For a stream cipher, we use 128-bit AES in counter mode, with an IV of all 0 bytes. For a public-key cipher, we use RSA with 1024-bit keys and a fixed exponent of 65537. We use OAEP-MGF1 padding, with SHA-1 as its digest function. For Diffie-Hellman, we use a generator (g) of 2. For the modulus (p), we use the 1024-bit safe prime For a hash function, we use SHA-1. KEY_LEN=16. DH_LEN=128; DH_SEC_LEN=40. PK_ENC_LEN=128; PK_PAD_LEN=42. HASH_LEN=20. When we refer to "the hash of a public key", we mean the SHA-1 hash of the DER encoding of an ASN.1 RSA public key (as specified in PKCS.1).[/i][/b] Are you telling me that this isn't encrypting? Then there's this: [b][i]Connections between two Tor servers, or between a client and a server, use TLS/SSLv3 for link authentication and encryption. All implementations MUST support the SSLv3 ciphersuite "SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA"[/i][/b] That says encryption STARTS at the client. Let's not lose sight of Tor's stated purpose: [b]Individuals use Tor to keep websites from tracking them and their family members, or to connect to news sites, instant messaging services, or the like when these are blocked by their local Internet providers.[/b] Now if your dealings are such that someone would be willing to trace your packets to the bitter end in order to capture them when they are "unwrapped" and handed to the target system, then you have much more to worry about than whether or not Tor is good enough to cover your tracks!

Tony K
Tony K

You have to dig a little deeper into the documentation before using something like Tor. BTW, apotheon, I have one more for you: Hanging out with gay people won't make you gay, anymore than hanging out with tall people won't make you tall. :)

apotheon
apotheon

As Neon Samurai already noted, using encryption is not the same as being an encryption system -- just as hanging around in a church doesn't make you a Christian and hanging around in a garage doesn't make you a car.

Neon Samurai
Neon Samurai

I think if you continue to read the documentation, you'll find that Tor makes no secret about being an anonymizer not a point to point encrypted tunneling service. It will mention that the link among Tor servers within the onion are encrypted. It will probably also mention that you can setup an encrypted tunnel between your client and the tor network; FF with Tor comes preconfigured this way. The data coming out the other side of the Tor onion still has to hit the server in the same protocol your asking for it. The Tor network can't be making encrypted tunnels out to every server you may browse any more than you can jump on the server and setup tunneling. If you connect to a pop, telnet, ftp, smtp, http, gopher or any other plain text protocol; your going to be sending something in plain text. If you connect to pops, ssh, https, smtps, imaps or any other encrypted protocol; your going to have end to end encryption as specified by that protocol. Since you've "never heard of Tor", you may find it beneficial to read more than the first cherry picking point you pass before stating your limited knowledge as factual. How's that piece of pie, would you like another?

Neon Samurai
Neon Samurai

The up side is that he can pretty much take care of his own machines and while I leave an updated liveCD he remains trapped in the old mindset that keeps him locked in to Windows platforms (not all bad, his new notebook was how I got a proper look at Vista). Now, where I get called in is the heavy lifting like cleaning his primary machine after week long guests did go clicking everywhere a poppup asked for a reverse connection. Keeping a dirty install of win2k running on failing hardware falls under my umbrella also. No daily calls for what links are ok to click on or what email are valid though. :)

Mond0
Mond0

My father was just the opposite. I spent many weekends at my parents home re-loading Windows. :(

Locrian_Lyric
Locrian_Lyric

I grumble a bit when he calls me over every little thing, but that's better than the big things, right? He never clicks on ANYTHING if he doesn't know who it's from *and* what it is about.

Editor's Picks