Tag Archives: Security

Locking a Windows Laptop on Lid Close

Posted on by
Reply

Like many people I’m a Windows user not because I have any particular love for Microsoft’s OS, but rather because it is the best OS overall for what I need to do on a day-to-day basis. Given the resources Microsoft has to throw at Windows development, however, it is amazing how much you can’t do in Windows.

For example, here’s a pretty straightforward thing I’d like to do in Windows — I’d like to set it up so that when I close the lid on my laptop, Windows automatically locks itself. Based on a couple Google searches a lot of people would like to be able to do this.

And yet, as of 2012, there is no version of Windows in which this can be done. Microsoft will let you put a laptop to sleep automatically when you close the lid, and you can always hit the Windows key+L to lock the computer, but there’s no way to configure Windows to lock automatically when the laptop lid is closed.

That, my friends, is f***ing stupid. I did find a couple of people who had created programs that intercepted the lid state and would automatically lock the lid when closed, but none of these were currently available (the website of the most popular utility for doing this was hijacked by hackers a couple years ago and is still compromised).

So if you know of a decent utility for automatically locking a Windows laptop when the lid closes, I’d be glad to hear it. Or maybe Microsoft could actually follow up on a simple, obvious feature that many of its users have requested. Just don’t hold your breath on that.

My Credit Union Spent Two Weeks to Downgrade Security

Posted on by
Reply

A few weeks ago my credit union mentioned they were upgrading the systems that handle their online banking features and the system would be down this weekend.

When the system came back online, I tried to login, but they had wiped all the passwords so I had to create a new one. Since the one I had before was pretty secure and I had it memorized, I figured I’d just used the same password again. Oops, not so fast. The system rejected my password with the following message:

That’s right. Last week I could use a 12 character password. Now, after the upgrade the system can handle a maximum of 10.

Not to worry, though. In order to ensure my account doesn’t get hacked, the system asked me to set up three challenge questions, the answer to which — if I actually followed along — is easily discoverable on the Internet. I typically use another 12 character passphrase for the answers to the challenge questions, but really whoever signed off on this should be ashamed.

This is one of the few times maintaining such a small balance has actually made me feel better.

Hash It! for Android

Posted on by
Reply

Hash It! is an Android app that replicates — and is compatible with — the Password Hasher extensions for Google Chrome and Firefox. Create a master password key, and Hash It! generates a password for each site you visit based on the master password and the URL of the site.

An interesting approach to password management, though I’m sticking with Diceware plus KeePass.

The Amnesic Icognito Live System (Tails)

Posted on by
Reply

The Amnesic Icognito Live System is a Debian-based USB/CD-bootable system designed to preserve as much anonymity as possible. Tails does this first by routing all Internet communications through Tor and second by avoiding using any permanent data storage on the host machine.

Probably one of the more useful things — other than the distro itself — is Tail’s excellent warning page giving a nice overview of the limitations of Tails, Tor, and a lot of Internet security problems in general. For example, the warning page notes that Tails  “…doesn’t make your crappy passwords stronger” and that while Tor does a good job of providing anonymity for what it is, there are certain problems that it was never intended to solve (such as an attack by a global adversary able to monitor all computer traffic in the network).

Dropbox Lied. End of Story.

Posted on by
Reply

For the past couple years, I’ve paid for a 50gb Dropbox account and actively promoted the service among friends and colleagues. Drobpbox has been extremely useful in managing some freelance projects I’m involved in. So when potential security issues surrounding Dropbox emerged back in April, I was concerned about just how private and secure the files I was sharing were.

Since April, there seems to be two basic schools of thought on Dropbox. The first is that Dropbox’s problems are really no big deal. That fact that employees of Dropbox can potentially access files are inherent to any synced system. On the other side are folks who have shut down their Dropbox accounts and forsworn the service forever.

Here’s what I take away from the debacle: Dropbox lied, both to me and to the other folks to whom I recommended their system. When I signed up for Dropbox, the service promised that all of my files were encrypted and that,

Dropbox employees aren’t able to access user files, and when troubleshooting an account they only have access to file metadata (filenames, file sizes, etc., not the file contents).

When the security concerns emerged, Dropbox weaseled out of the above promise by clarifying that Dropbox employees are, in fact, able to access user files, but they are typically not granted access to do so. As Dropbox put it in a response to this issue,

In our help article we state that Dropbox employees aren’t able to access user files. This is not an intentionally misleading statement — it is enforced by technical access controls on our backend storage infrastructure as well as strict policy prohibitions. The contents of a file will never be accessed by a Dropbox employee without the user’s permission. We can see, however, why people may have misinterpreted “Dropbox employees aren’t able to access user files” as a statement about how Dropbox uses encryption, so we will change this article to use the clearer “Dropbox employees are prohibited from accessing user files.”

Whether they intended to or not (and it is hard not to see the original statement as intentionally misleading), Dropbox lied about its security model. I and others took those assurances seriously and assumed our files were being encrypted client side.

Regardless of whether this or that feature or security option is a good or bad idea, the fact remains that I simply don’t trust Dropbox anymore. I have better things to do than worry about when/if Dropbox is going to have to release another “sorry, we didn’t mean to mislead you, but …” statement.

I already set my account up so it reverts to the basic free version once the renewal date hits later this summer. I’m moving everything out of Dropbox except for my Keepass file and any other files which are already encrypted, and for working with clients who are going to continue to use the service despite the security risks. I’m currently testing SpiderOak — which is like Dropbox but uses a client-side encryption model — for all my cloud-based file syncing needs.

Colin Percival on Flaws in Jungle Disk’s Security

Posted on by
Reply

Colin Percival has an in-depth look at some security issues with Jungle Disk.

A lot of people, including me, have recommended Jungle Disk to people because the cloud-based backup system encrypts your files before it uploads them to Amazon’s S3 service (as opposed to something like Dropbox which encrypts them after the files are uploaded — meaning Dropbox has the key to unencrypt your files if it wants to or is ordered to by a legal authority).

The problem that Percival points out is that they way Jungle Disk handles that client-side encryption is weak to the point where there is a clear path for attackers to follow in either corrupting data stored on the system; replacing data stored on the system; or, ultimately, cracking your password and having free reign.

I used Jungle Disk for a couple years to as a cloud-based backup of my main data hard drive. I used a 20 character passphrase. As Percival notes in a handy chart he provides, a 10 character strong password would take about 95,000 years to crack using current techniques and a $1,000 off-the-shelf laptop. A $10,000 GPU-based password cracking box is going to reduce that to 95 years, and the CIA’s going to be able to put together a system that could rip through that in 2 years. Given that, why not emulate Alfred E. Neuman — what, me worry? But, as Percival writes,

Now, maybe you don’t have any data stored which Joe Cracker would be willing to spend 10 hours decrypting. Maybe you trust Amazon and Rackspace’s internal procedures and security measures to ensure that nobody — either breaking in from outside, or working for those companies — will have access to your “encrypted” data. Depending on who you are and what data you have stored (your credit card numbers? bank statements? how about last year’s income tax return, complete with your national tax ID number?) you might be justified in such trust. But I would say that this is profoundly missing the point: With good cryptography, you wouldn’t need to trust them.

Anyone who doubts the level of computing resources that an individual or small group of people would be willing to throw at a complex problem based entirely on speculation about the value of doing so need only take a look at some of the crazy rigs and setups being built to do nothing but mine Bitcoins. And, of course, the cost of cracking passwords is only declining with every day that passes.

Again, the best solution with cloud backup or sync in general is for the user to encrypt the files before uploading them. Unfortunately, this increases security but at the cost of convenience (and maximizing convenience is apparently why Jungle Disk has these potential issues in the first place).

MonkeySphere – Using OpenPGP to Route Around Broken Web Security Model

Posted on by
Reply

The Monkeysphere Project is a project to use OpenPGP to securely identify servers in web browsers and elsewhere that routes around the growing potential problems with certificate authentication. As The Monkeysphere website sums it up,

Everyone who has used a web browser has been interrupted by the “Are you sure you want to connect?” warning message, which occurs when the browser finds the site’s certificate unacceptable. But web browser vendors (e.g. Microsoft or Mozilla) should not be responsible for determining whom (or what) the user trusts to certify the authenticity of a website, or the identity of another user online. The user herself should have the final say, and designation of trust should be done on the basis of human interaction. The Monkeysphere project aims to make that possibility a reality.

. . .

When you direct the browser to an https site using the Monkeysphere plugin and validation agent, if the certificate presented by the site does not pass the default browser validation (using standard, hierarchical X.509), the certificate and site URL are passed to the validation agent. The agent then checks the public keyservers for keys with UIDs matching the site url (e.g. https://zimmermann.mayfirst.org). If there is a trust path to that key, according to your own OpenPGP trust designations, the certficate is considered valid, and a browser ‘security exception’ is put in place to allow connections to the site.