Showing posts with label security. Show all posts
Showing posts with label security. Show all posts

Friday, 2 April 2010

Hiding from the Stasi

I find it seriously depressing to think that the free and wild internet of my youth has become so spied upon that projects to protect your privacy are now so common.

It's very difficult to surf anonymously any more, with endless cookies and logs being kept by ISPs to allow the state to spy on your surfing habits. If this bothers you, have a look at TOR. It's rough and ready, and it's not a one-stop anonymiser, but because of the way things work, I doubt they'd ever be able to achieve a one-stop anonymiser.

In a nutshell, all you have to do is go to http://tor.eff.org and leech a binary, run it, and config everything for socks A proxy on port 9050, but that wouldn't be much of a article would it?


More here.

Thursday, 1 April 2010

Length matters

I don't want to bore non-techies with this one, but I do want you to think about your passwords for just a few minutes.

The first thing is this: even if your password isn't something obvious like "password" or "obo", then hackers don't have to guess them. There is free, readily available software out there to do brute-force password hacking. So they can fire it up, go out for a cup of coffee, do the groceries, have a good night out and come back to find your password ready and waiting for them.

The second thing is this: the longer your password is, the longer it takes to crack.

The third thing is this: the more types of characters you use, the longer it takes to crack.

Let me give you a for instance: if I choose the password "obo", a brute-force cracker will take an average of 0.02 seconds to crack. So, "immediately". If I choose a slightly longer password, like "obnoxio", that will take two and a quarter hours. Much better, but still not really secure. However, if I simply change the password to include numbers and special characters, e.g. "Obnox1o$", it will take 210 years to crack.

And "Obnox1o$ Cl0wn" could take 154,640,721,434,000 years to crack using brute force.

So, put a bit of effort in, mix it up a little and make it just a little bit longer. Because it's worth it.

More info here.

Tuesday, 17 November 2009

Twitter, SSL and security

This story got me thinking:

A Turkish grad student has devised a serious, real-world attack on Twitter that targeted a recently discovered vulnerability in the secure sockets layer protocol.

The exploit by Anil Kurmus is significant because it successfully targeted the so-called SSL renegotiation bug to steal Twitter login credentials that passed through encrypted data streams. When the flaw surfaced last week, many researchers dismissed it as an esoteric curiosity with little practical effect.

For one thing, the critics said, the protocol bug was hard to exploit. And for another, they said, even when it could be targeted, it achieved extremely limited results. The skepticism was understandable: While attackers could inject a small amount of text at the beginning of an authenticated SSL session, they were unable to read encrypted data that flowed between the two parties.

Despite those limitations, Kurmus was able to exploit the bug to steal Twitter usernames and passwords as they passed between client applications and Twitter's servers, even though they were encrypted.


The reason he went after Twitter was:

Twitter proved an ideal platform to carry out the attack for several reasons. First, every request sent over the microblogging site includes the account holder's username and password. Second, the site's API made it easy to post the contents of the intercepted data stream into a message that an attacker could then retrieve.

Finally, many Twitter users send and receive messages using third-party applications. Many of those programs ignore error pages like those that would have resulted from Kurmus's attack, preventing victims from knowing anything was amiss.


So, here's my thinking on this: even though Twitter have fixed the bug on their side, you can rest assured that there are others. Twitter's implementation and "oauth" external authorisation model mean that it's always going to be a popular target.

The first thing you have to do is make sure you don't have a similar login/password combination on any other site. Always make sure Twitter has a different password to any other site that has the same login.

The second thing you have to do is to change your Twitter password fairly regularly. This means that even if your account is compromised, it won't be for too long.

Thirdly, always keep your eyes open for weird messages or behaviour. If something odd happens, it's probably worth changing your password immediately.

Security is a pain in the arse, but it's a price you have to pay.

Wednesday, 16 September 2009

Fisking Dominic Grieve

Over at the future-prediciting ConHome, Dominic Grieve will apparently say later today how he intends to reverse state surveillance:

1. Scrapping the National Identity Register and ContactPoint database.


Well, that's off to a good start. But what about all the other snooping databases, Dominic?

2. Establishing clear principles for the use and retention of DNA on the National DNA Database, including ending the permanent or prolonged retention of innocent people's DNA.


Well, there are already clear principles here, they're just shit principles. But getting rid of innocent people's DNA is another good step forward.

3. Restricting and restraining local council access to personal communications data.


It sounds good, but how much restraining are they actually going to do? I would be happier if he said: "councils can go fuck themselves and get a court order if they want to spy on someone". This sounds like bullet point fodder, words that say nothing but sound vaguely good.

4. Reviewing protection of personal privacy from the surveillance state as part of a British Bill of Rights.


Ugh. This is a horribly statist thing to say: "the state will give you these rights and freedoms". What I'd far rather the "British Bill of Rights" said was "the state is entitled to manage those things enshrined by law, you can do whatever you like outside that. And equally, outside that, the state can go fuck itself." Which is, in effect, the bill of rights you have today.

5. Strengthening the audit powers and independence of the Information Commissioner.


Sounds nice, but really, so fucking what? He's done absolutely nothing so far, and we're practically living under the Stasi already. Increasing his audit powers is going to mean more jobs for the Information Commissioner. W00t. Just what we fucking need, more state. Yay. Go Dominic!

Cunt.

6. Requiring Privacy Impact Assessments on any proposals for new legislation or other measures that involve data collection or sharing at the earliest opportunity. Require government to consult the Information Commissioner on the PIA and publish his findings.


Or in other words, "more paper shuffling jobs for the state's boys". It's clear from this kind of crap that Grieve has no minarchist tendencies whatsoever.

7. Immediately submitting the Home Office's plans for the retention of, and access to, communications data to the Information Commissioner for pre-legislative scrutiny.


Woo. Well, given that the useless cunt is just another government-appointed stooge dependent on having at least some surveillance to justify his job, I can see this is going to be really, really useful.

Not.

8. Requiring new powers of data-sharing to be introduced into law by primary legislation, not by order.


Really? Why not just fucking make it illegal, Dominic? We got as far as 1997 without needing widespread data-sharing at all. But since Labour have created a bunch of made-up threats we now have state-created excuses for state sharing of data. How fucking convenient!

You don't need to share data with fucking councils, or the National Potato Board or OffFuck. So just don't fucking do it.

Idiot.

9. Appointing a Minister and senior civil servant (at Director General level) in each Government ministry with responsibility for departmental operational data security.


Ahhh, I love the smell of jobs for the boys in the morning. Tell me, Dominic, WHAT THE FUCKING FUCK DO YOU THINK THIS IS GOING TO ACHIEVE?

It just means you're going to have someone to sack or someone who is Teflonned enough to avoid it. It's not going to do a single fucking thing to actually improve security.

Here's how to actually prevent data loss by incompetent civil servants (and MPs!) -- you'll like this, Dominic, because it's a) cheap; b) easy to fucking do and c) absolutely foolproof:

DON'T COLLECT THE FUCKING DATA IN THE FIRST PLACE!!!!

10. Tasking the Information Commissioner to publish guidelines on best practice in data security in the public sector.


Ooh, "guidelines on best practice", that will make it all better. Listen, fuck features, I've actually done a bit of data security consulting in my life and "guidelines on best practice" don't mean fucking shit if you allow people to take the data out of the building. In fact, they don't mean fucking shit ever.

Proper security is bloody fucking difficult. It's a pain in the arse for every fucker concerned. The best security also means they worse usability. The best usability means the worst security. The easiest way to make sure that you have good data security is to drastically reduce the amount of sensitive data that you hold. Since no fucker has made the case for the reams of data that you do want to hold, just stop trying to keep it.

Some fucking "best practice guidelines" will be as much fucking use as Airmiles.

11. Tasking the Information Commissioner to carry out a consultation with the private sector, with a view to establishing guidance on data security, including examining the viability of introducing an industry-wide kite mark system of best practice.


A kite mark? You fucking idiot! You fucking, fucking imbecile! The fucking "industry" doesn't need a fucking kite mark, you fucking spazmong! We already have fucking Sox compliance, HIPAA compliance, any fucking number of PCI requirements along with whatever industry regulatory requirements there may be (and some of these are frighteningly onerous.)

So the absolute last fucking thing "industry" needs is another pile of of fucking requirements from a bunch of interfering fuckwits who really do need to "remove the beam from their own eye", as it were.

And there we have it: the Tories are going to reverse the surveillance state by doing a couple of half-hearted twiddlings around the edges, creating a whole bunch more "jobs for the boys" and having the sheer fucking gall to hector the private sector into doing more to protect our data.

Colour me unimpressed


Update: Carswell is also unconvinced.

Tuesday, 8 July 2008

Database Security -- WTF?

On my regular excursions as a faceless drone working for a faceless corporate providing technical and other help to other faceless drones working for other faceless corporates, I never fail to be astounded at how little people care about database security.

From banks to retailers, from telcos to corner shops, nobody gives a fucking shit. Even the most basic precautions appear to be too much trouble, let alone doing it seriously. I suppose with our glorious government leaving data all over the place, why should they care?

Apart from the fact that it's one rule for them and a different rule for us, of course!

Take half a day to sort out some basics:
  1. Can someone pick up your server and walk out the building with it? If so, make it someone else's problem to sort that out! Easy!
  2. Keep your version of your database server reasonably current. Security is often patched in at random times as vulnerabilities are discovered. This isn't an unreasonable thing to do.
  3. Deny write permissions for server binaries and key files, and see where you can trim read access.
  4. Have a password policy for root, informix, oracle, whatever. If your database has a bunch of default access passwords, change them!
  5. Try not to use /tmp for anything database-related.
  6. Only install from a trusted source. Take a checksum on binaries after the install, and check it every month or so.
  7. Encrypt communications between clients and servers or servers and other servers. Mostly, you can make this a sysadmin's problem. Try for SSL, because it's being maintained and enhanced continuously.
  8. Set DBCREATE_PERMISSION in your onconfig.
  9. Use NODEFDAC.
You're looking at about a half a day's work, apart from maybe scripting the checksum validation, which is hardly rocket salad either. In exchange for which, your database will be ten times more secure than the next guy's.

Come on, get off your arse!