Patch-tag is now https safe, so you can access your projects with cryptographic security. Just use https style urls when interacting with patch-tag.
By the way — for you code shops with mission critical, high-value, national security endangering repos hosted at patch-tag — https isn’t completely safe.
You could, for instance, get your password sniffed by a man in the middle attack with arp poisoning, if you are in a public network like an internet cafe, or on a trusted network with a coworker who enjoys hanky panky.
There is a simple thing you can do to foil the terrorists though — just click outside the text fields and type some gibberish when you are entering your password.
Ha! Take that script kiddies!
Please enjoy secure repos at patch tag, and as always…
Happy tagging.
************************
UPDATE: Please note the comments which contradict some of my claims. I think I may be wrong about some of this stuff, and am taking a backtrack to make sure my understanding is solid. Watch this space.
Yay! Good work! I’ve been waiting for this.
Are your last few paragraphs are a joke?
HTTPS is designed to protect against man-in-the-middle attacks (among others). Whether they are implemented with ARP injection, DNS injection, or even physically compromising the network, MITM attacks will not compromise HTTPS. Attempts at MITM will cause the browser (assuming it’s not NS 3 or something) to display an error message and refuse to continue.
Typing gibberish outside the text area does *absolutely nothing* against MITM. Nada, zip, zilch. Your browser will still send the same HTTP commands, and if the connection’s not encrypted (or is encrypted, but somehow broken), anybody with a packet sniffer can see your password.
Besides, even simple keyloggers like those kids install at school to steal Neopets passwords won’t be defeated by typing random text. Consider that an alpha-numeric password with 10 characters has (36^10) combinations. If an attacker is presented with a username followed by some random text, all they have to do is test every subsequence.
Thanks for pointing these things out.
So if I may ask, what DOES the gibberish defense help with, or do you just think it’s nonsense? Oh… as Joe says, it’s for keyloggers. ok.
IIRC, the author of this suggestion conceded that it’s not foolproof, but more a case of “I don’t need to outrun the bear, I just need to outrun YOU But… I guess that would be outrunning the wrong animal in this case.
Gibberish could help defend against attacks that rely on interpreting the user’s stream of keypresses. Like a hardware keylogging device that the attacker discreetly plugs in series with the keyboard. Or a simple TEMPEST attack.
That said, IANS either.
tl;dr: Using gibberish might have helped a few decades ago, when nobody (either attacker or defender) really understood security. But today, it does nothing.
A successful MITM attack against HTTPS requires the victim to be *really stupid*. Their browser will present them with an error page (such as ), and they’d have to click through any safeguards. For example, Firefox makes users click through 3-4 screens full of ominous warnings before allowing access to a site with invalid identification.
Regarding keyloggers: lets say I want to break into your patch-tag account. Assuming I can gain access to your computer for a few minutes, there are a few basic approaches:
1. Install a hardware keylogger. This is a small device, inserted between the keyboard’s USB or PS/2 terminus and the tower. It records all keystrokes as they happen, storing them in an internal buffer. Later, the attacker retrieves it and looks through for likely username / password combinations.
Occasionally seen in public places, such as libraries or cyber cafés, where they are easy to install and retrieve. They’re relatively easy to defeat — to type an alphanumeric password, the user can type out the entire character set (a-z, A-Z, 0-9) and then copy-paste individual characters into the password box using the mouse. In real life, you’ll probably never encounter one.
2. Install a software keylogger. This is similar to #1, but uses a hook into the graphical environment’s event handling to intercept and record events. Basic examples are no more effective than a hardware keylogger, but more advanced software can record mouse movements, non-input events, the clipboard buffer, and more. In some cases, they take screenshots on particular events (mouse clicks and the “enter” key). Recordings are sent to the attacker automatically via the internet, or stored as a hidden file somewhere.
Hugely popular in schools, libraries, and cyber cafés. They are “fire and forget”; once installed, no maintenance is required. I live under the assumption that every single computer not under my direct control has at least one software keylogger installed; experience suggests this is probably more correct than not.
These can’t really be “defeated”, since the attacker has a complete record of everything that the user does. Typing gibberish makes it slightly more difficult to find the correct password in the recording, but not in any significant way.
3. Install a traffic sniffer / rootkit. Generally reserved for more experienced attackers, though there are pre-configured packages available for sale. These hook into web browsers and the OS’s network stack, and log HTTP and HTTPS sessions for later analysis by the attacker. No amount of gibberish or cleverness will help against a rootkit, because it sees what the server sees — your raw password. HTTPS does not help, because your browser itself is compromised — the requests will be intercepted *before* they’re encrypted. All the attacker has to do is search for HTTP requests that look like logins.
The primary downside to rootkits is that they require superuser privileges to install. This means guessing the local administrative password or exploiting an unpatched vulnerability in the OS or other privileged process.
Congrats on adding https support to patch-tag!
Not sure how much of this post is serious and how much is joking. Sometimes my sarcasm detector is defective.
But, taking it all seriously, here’s some feedback:
- The video you linked to doesn’t show ARP poisoning. Perhaps you meant this one?
http://www.youtube.com/watch?v=aADs2ukNwKw
- The “typing gibberish” technique doesn’t work on ARP poisoning attacks; that’s for keyloggers — especially hardware keyloggers. Personally, I try to avoid keyloggers by using hardware+software I trust (my own laptop).
- As far as I know, all man-in-the-middle https attacks require the victim to explicitly accept the bogus SSL certificate sent by the man in the middle. So the simplest defense here is to look at the URL (better yet, type it in yourself, starting with “https://”) and don’t blindly click OK if your browser tells you the SSL certificate looks fishy.
1) It was serious — my last name is not schneier.
2) Actually I can’t find the video I meant. But thanks for posting this one.
3) Although my last name is not schneier, I take security seriously, and will do my damnedest by my users. Thanks for not assuming sarcasm and pointing these things out.