I just got a rather interesting email in my inbox. It’s from a travel document service. The email was about an order I had just made regarding a lost passport. Which is a bit of a trick, seeing as I’ve never done business with this company, I know exactly where my passport is, and I am not traveling internationally in the immediate future. So, at first I thought it was spam; I get emails like that all the time for services I didn’t request. Usually the spam filter catches them, but one or two do get through.

But, you know, I’d never seen this one before. I had to read it to see what the scam was. And that made it far more interesting. There’s no scam. The company is perfectly legitimate, and they’re not trying to sell me anything. It’s a real order confirmation for a real order. Benjamin Hartley really did make this request.

Just, you know, not me. My name isn’t common, but there’s at least one other person with that name. And he’s not at all careful about email addresses. I’ve had email from him in the past – or, rather, from organizations to whom he’s given my email address. I feel as if I know him. I know where he went to school; I know who he works for. I know who he donates money to. I think I even saw his birthday in one of the emails. And now I know he lost his passport. I know when he’s leaving the country. Oh, and I have all the confirmation information to get his replacement passport sent wherever I please, so if I really wanted I could have, well, quite a bit more.

I’m not going to do this of course. But I obviously could. This is potentially very damaging information. And it was just emailed to me. Not even signed or encrypted – just emailed. I’ve not been stalking this guy; I’d be happier to not be receiving this information, but it keeps coming. And, ironically, the one piece of personal information I don’t have about him is his contact information. Actually, that’s not true. I called the company, and – even though I was entirely clear to them that I was not the person who made the order – they still gave me his phone number, which is a whole different security failure.

This is really rather disturbing for two reasons. First off, my nominative doppelganger needs to be far more careful with his information. I don’t know why he doesn’t worry that he never receives the emails he’s expecting; maybe he forgets about them, or checks his email so infrequently that it doesn’t matter. But he’s not getting information which he clearly should be receiving, including some potentially compromising information. Second, the travel document service needs to be far, far more careful. They should have asked me to confirm my identity before discussing the order – at minimum a birthday, but a passport number or social security number would have been better. Of course, given that I told them beforehand that I was not the person who made the order, confirmation is the least of the problems there.

In technology, we’re generally good about confirming the destination for data. Our medium may not be secure, but the technology usually knows if it has connected to the right destination. But that’s because computers do it for us. Out here in meatspace, we’re not so careful. Like this other Benjamin, we generally just assume that our data will go to the right place – or if we don’t get it, then it’s not a problem, it just got lost. And like the travel document service, we simply assume that anyone asking about specifics must be allowed to know about them, and we don’t confirm. And that’s really all that needs to be done here – get a little confirmation that data is going to the right source before sending sensitive information. If that had been the case here, I wouldn’t have been handed this man’s personal information this way. As it is, though, it makes you wonder what other information might have gone astray. The other Benjamin is lucky; his personal information went to someone without ill intent. Others may not be so fortunate.

Back in 2007 a group of American hackers went to Germany and toured this esoteric place known as a hacker space. They liked what they saw and quickly founded the first hacker spaces in the United States. The goal was to set up collective spaces where curious types could come in and work on personal and group projects, often involving equipment that isn’t feasible to have in your living room. Cut to the end of 2010 and hacker spaces are established all over the globe, with the United States completely obscured by red balloons on the hacker spaces map.

Since the beginning, hacker spaces has grown into a phenomenon in its own right. There are panels on hacker spaces at many of the major information security conference such as HOPE, and Defcon.Hackerspaces.org hosts inter hacker space events such as a synchronous hackathon and call-ins to find out what’s going on with hacker spaces around the globe.

In addition to being a facility to work hard on a big project, hacker spaces are also an excellent venue for some downtime. Come in and relax, meet new people, kick back, and talk about what you’ve been working on or even just a great book you read the other day. Being part of a hacker space can be a career boost from the social side as well. Getting to know other people in the field can only help on the quest for the holy grail of information security careers. There’s no better way to get where you are going than to get to know and learn from the people who are already there. Additionally if you are a bit shy about approaching that famous person in the corner, consider volunteering for hacker space leadership. Next time you see someone you idolize in the space you’ll be able to walk right up and say, “Hi, I work for . Thanks for coming to our event.”

Hacker spaces aren’t all about tinkering with cool toys either. For instance many hacker spaces have a strong artistic community as well. Open mic nights, reading groups, photography workshops, etc. are featured at many hacker spaces. Gumbo Labs, a hacker space I recently visited in New Orleans, Louisiana is a space of hackers and artists alike. They even share the building with groups that build floats and decorations for one of New Orleans’s annual Mardi Gras Krewes.

If you are a local reader check out Reverse Space a new hacker space that just opened its doors in Herndon, Virginia. Still in its early stages of development, members of this startup space will directly influence the direction the space takes. Currently in the works are a cyber warfare center for malware analysis, proof of concept development, and practicing penetration testing techniques. Additionally, Reverse Space has facilities for hardware hacking and rapid prototyping such as two Z corp 3D printers. Bring your passion for learning and your ideas for projects and events you would like to participate in, and join us at Reverse Space.

Hackerspaces.org has a list of all hacker spaces currently active as well as in the planning stages. Go here to find one in your area. If there is not an active hacker space in your community, the site also provides resources on starting up your own hacker space. All you need is a few people with a shared passion for learning and a little bit of motivation, and you are on your way.

Forget about everything that’s been made of password strength; it’s a red herring. True, you shouldn’t be using one common password across all sites, but that’s not a password selection issue. Should you pick good quality passwords that aren’t easily guessable? Absolutely. That being said, let’s forget about the rest of the rules, with perhaps the exception of length, and talk a bit about what actually happened with Gawker.

Read the rest of this entry »

How do you use a different strong password on every site without writing all of those passwords down or going mad – a password manager with randomly generated passwords.

I have several machines I use on a very regular basis – both for work and personal use: at least one desktop and one laptop in each case, and then occasional use on my iPhone. So any password manager for me would have to work among all of these machines. In my case, they’re all OS X, but these tools work on Windows as well if you’re stuck using it

I use 1Password syncing with Dropbox. Dropbox synchronizes files between computer systems – Windows and OS X, and even iPhone, Android and Blackberry. 1Password only works on Windows, OS X, iPhone, and Android so if you’re a Blackberry user, you’re out of luck at the moment. Dropbox runs “in the background” so things always appear to be in sync among your machines. Dropbox also claims that they encrypt your data with your login (AES256), but you’re trusting Amazon Web Services to keep that data secure otherwise.

1Password is a great all-in-one “secure storage” tool. It not only stores passwords, but you can also store passport information, credit card information, and secure notes. Everything is stored in an AES128 encrypted file with the master password as the key. It also provides secure password generation, and plug-ins for the major browsers to autofill information for you.

1Password supports Dropbox syncing, so all you have to do is tell it that your data file is in your dropbox folder, and it’s all set up for you.

At this point in time, I know my master password off the top of my head, but not too many more of my passwords. This is both convenient and frustrating. I know I’ve got strong passwords, but I have no clue what most of them are without one of my computers or my iPhone. Depending on your needs, this could be really annoying (like say logging into Netflix at a friend’s house), or you can just wear your tin foil hat proudly.

I’ve also had problems with the Firefox plugin and sites that require Windows basic authentication – it’ll prompt you for the login/password multiple times and never actually let you connect to the site. No clue what’s going on there, I just switch over to Safari when that happens (but if you know of a solution – I’m interested!).

I have not played with the 1PasswordAnywhere tool yet, but it looks good as an option to DropBox syncing if you’d rather not trust your file in the “cloud”.

DropBox offers free accounts, but 1Password will set you back a bit. I have a “family” license mostly to myself (my husband has the last license out of 5) that set us back $70.

There are other password managers out there, like KeePass and LastPass.  What do you use and why?

The discussion around the usual suspects of web application security (XSS, CSRF, injections, etc) hasn’t changed much in the last decade. Even high-profile website security incidents that get media attention often boil down to a clever application of one or more of these “basic” vulnerabilities. Part of the reason these techniques don’t seem to go out of style is a result of the speed at which the underlying technologies emerge.

In other words, as technology changes, the vulnerabilities enabled by that technology also change. With the quick rise (and rapid acceptance) of HTML5 as the next generation markup language, we are sure to see some interesting new ways that web apps can be bent and broken or otherwise convinced to do things they were not originally designed or developed to do. Indeed, HTML5 seems to be somewhat of a new frontier when it comes to web security. Like its predecessor, each browser rendering engine has its own way of interpreting and displaying HTML5 data. Developers seeking to fully secure their applications would need to account for users that may have HTML5-enabled browsers. Lack of familiarity on the developer’s part can result in unexpected vulnerabilities that are easily overlooked or difficult to detect.

The HTML5 Security Cheatsheet is a resource that shows some things to watch out for when you’re working with HTML5, and should be useful to both developers and regular users.

Also, it’s important to point out that not all unintended uses of a new technology are malicious in nature. Who knows– maybe some HTML5 hack will push future web innovation to new heights. At the very least, it could add some variety to the global discussion on web application security.

Many information security blogs, including this one, have discussed the recent data breach of gossip site Gawker and problems associated with leaked passwords. The story has demonstrated some of the risks associated with password storage. Gawker did store passwords using a form of encryption, but it was a weak algorithm and thus the encrypted data could be cracked. It’s important to remember that you should never simply rely on “encryption” to protect information – that’s sort of like say a bicycle is protected with a combination lock. Some locks are easier to open than others, and if the lock is attached to a weak cable or not properly looped through the frame of the bike, its strength doesn’t even matter.

With passwords, though, another option is available: one-way hashes. A hash function takes an input of data, such as a password, and outputs a value that’s always the same length and format. The algorithm is designed so that it’s easy to calculate a hash, but essentially impossible to reverse the process. Also, slight adjustments to the input drastically change the output value, and the chances of two values leading to the same hash are extremely unlikely. To use another analogy, think of a person’s fingerprint. It’s easy to capture a fingerprint using an ink pad and paper. But if you start with a fingerprint and want to identify the person it came from, you’re at a loss without a database of records to check. And once again, finding two identical fingerprints from two different people would probably never happen.

If an application stores the hash of a password instead of the actual password or a value generated by reversible encryption, then theoretically, the password would remain safe if the database were ever breached. When a user tries to log in, the application simply generates a hash of the supplied password (remember, generating hashes is easy) and compares it against the stored hash. If they match, the user has given the right password. If not, the password is wrong.

Just as people have built databases of human fingerprints, however, databases of hashes exist for common values, so only using a hash would not protect users with simple passwords. Weaknesses have also been found in older hash algorithms, such as MD5. Better options include SHA-1 and the various versions of SHA-2, but they are still not sufficient on their own. Extra protection comes from adding “salt.”

In this context, salt refers to an extra string of random information that’s unique for each saved record. This salt is then concatenated with the password and a hash is generated for the entire new string. The salt needs to be saved along with the hash in the database so that login passwords can still be verified, but it should still be kept secret as much as possible. When a user logs in, their supplied password is concatenated with the salt, hashed, then checked against the stored hash.

With this system, an attacker who manages to break in to the database will only recover salted hashes instead of actual passwords. The nature of hash algorithms means that even if a user had a simple password, the salt helps ensure that their hash won’t match any found in common hash databases. To figure out each password, an attacker would have to compute all possible values with each individual salt, vastly multiplying the amount of computation required.

Of course, just as toothpaste manufacturers remind buyers that their products are only one component of good dental health, salted hashes are only one part of a secure application. In fact, with technologies such as OpenID, OAuth, and Facebook Connect, many sites really don’t even need to handle user passwords any more. But if your application does require its own authentication, a robust implementation of salted hashes ought to be a baseline for password security.

As Peter touched on when relating his story about the Gawker password database compromise (in addition to numerous other mentions on this blog), maintaining secure passwords for all of your various online identities is not something to take lightly.  In addition to secure passwords, you should also use passwords unique to each site you are visiting.  You may not care if someone compromises the account you use to comment on Gizmodo, but if you also use that password for e-mail, banking, Facebook, or other sites you may value, you leave yourself open to a painful security breach.

In a perfect world, websites would just use OpenID or other roaming credential, so that everyone would only have one secure password to manage, and we wouldn’t have to rely on bad home-grown authentication management from each web site.  However, this isn’t likely to happen anytime soon.  In the meantime, here are a few tips on password security that should help keep your accounts a little bit safer:

1) Do not use words, phrases, dates, or numbers that are of any significance to you, such as birthdays, your home address, or pets’ names.  (I think the law requires every password article to include this tip.)

2) Use mixtures of upper case, lower case, numbers, and special characters.  The longer, the better.  (This one, too)

3) If you can’t remember your passwords, don’t write them down – use a password management tool that you can store on a USB token to take with you on the go.  Make sure it’s a secure tool that uses high quality encryption.  (Readers and SM Bloggers, any products you’d recommend?)

4) Never re-use passwords for multiple locations.  If you absolutely, positively refuse to use completely unique passwords for each site, consider appending your password with something you can easily remember about the site.  For example, if you want to use Password123 for several low priority sites, instead use Password123papajohns.com, Password123gawker.com, etc.  This isn’t truly secure, as the pattern is easily figured out by a human looking at it, but it should at least stop automated scripts from successfully using a compromised password elsewhere.

5) Beware the password reset “security questions”!  Things like your mother’s maiden name, the street you grew up on, pet’s names, etc, are trivial to figure out, especially if you like filling out “which vegetable are you?”-type questionnaires on Facebook.  You don’t actually have to answer the security question with an answer that makes sense – for a question such as “What is your mother’s maiden name?”, the system will not care if you say “pamplemousse”…just make sure you can remember the answer as well!

Anyone have any other password tips to share?

I received the following email on Monday morning:

You don’t know me.  I’m nobody.  My name is Steve.  I came across a database dump from Gawker.com earlier this evening.  It’s making its rounds around the internet.  Besides just the code dump from gawker.com among other sites, it also contains email addresses and passwords for over 1.3 million accounts.  I’m sending this email to the 200,000 or so people who’s passwords were included, in plain text, in this archive.  I have your password.  However, I have 0 interest in it.  Obviously i’m anonymous so how can you trust me – you can’t.  But trust me, if I had interest in your password, I wouldn’t be emailing you saying I have it. That’s just dumb.  The reason I’m telling you this is because people all over the world, who aren’t like me, who won’t notify you, have it.  They will use and abuse it.  Change your gawker.com credentials. Now.  MORE IMPORTANTLY, change passwords on other sites you visit that use the same one as your gawker.com/lifehacker.com/gizmodo.com login.

Well, it was believable enough… then, I read an article on Forbes and knew it wasn’t a scam. Argh. To their credit, Gawker has some informative posts on their breach and how to audit and update passwords.

As background: I use a password manager to manage my passwords, and it helps me use secure passwords wherever possible. However, I have a number of passwords which predate my use of a password manager, and for many sites I used the same password. Yes, it’s a bad security practice that we’ve talked about before, and even XKCD has weighed in.  The use of this same password didn’t bother me – it was my password for using on sites that I considered “low impact”. In other words, I didn’t feel like it was a big deal if that password was compromised.

Receiving that email, along with a notification from Google that my account had been locked out, was a wakeup call. Suddenly, it became a big deal to me.

So, I spent this evening going through my password manager’s records. I have 507 saved passwords.  I had nearly 150 with the same password.  I changed every one of them to a randomly generated password.  It took me over three hours to go through that process.  A tremendous hassle. Let me suggest from experience: change those passwords you use on many sites.  If you try to do them all at the same time, it will be a tiring and painful process.

For a while, it looked like the crypto wars had been won. Strong encryption was available, and governments were even encouraging the development of better encryption standards like AES and 3DES. Implementation is – and will likely always remain – an issue. But it was there, it was possible, and there weren’t any legal barriers to using it. And it couldn’t have happened sooner: more and more business processes are moving online, from nigh-ubiquitous email, to rolling out VoIP to save on telephony costs, to increasing outsourcing to the cloud.

The victory in the crypto wars didn’t last long. Today, there are a slew of laws in place in various countries controlling the use of strong encryption. Some, like the UK’s “Regulation of Investigatory Powers” Act allows encryption but allows law enforcement to require that information be decrypted. Others, like France, require the use of trusted third parties in case law enforcement desires the keys. Still others, like the Communications Assistance for Law Enforcement Act (CALEA) in the US require other forms of encryption backdoors be in place. In a few places, certain forms of encryption are simply illegal.

There’s good news here, after a fashion. If ever we needed independent confirmation that the current level of cryptographic technology is pretty good, here it is. Governments, in the form of law enforcement, espionage, and military are all concluding that it’s not practical to break existing encryption. (Of course, this doesn’t mean they can’t, just that they either don’t think they can do so fast enough, or that it’s too costly). Still, this is a good sign for the quality of the encryption.

The bad news, however, is that complying with the law may make your data insecure. Notwithstanding how you feel about a given government reading your files and intercepting your communication, it’s a given that if a backdoor exists for one party, it exists for anyone sufficiently motivated to find it. So what are your options?

Well, pretty much the typical ones. First of all, learn the relevant laws about cryptography wherever you’re doing business. This is actually pretty hard, as there doesn’t seem to be any authoritative list, even just for the US, and it’s pretty hard to figure out who would even know. But once you do, it’s time for some hard decisions. You may decide that you can be sufficiently secure within the limits imposed on you. You may choose to keep truly sensitive information off the network, maybe keep something in-house that you’d rather outsource. In some cases, you might even decide you can’t do business, though that’s a pretty extreme measure.

A number of our employees are currently spending a fairly large amount of their time helping a customer with a task.  In a perfect world, this task would be completely unnecessary.  Suffice it to say that there is some maintenance that must be performed on a number of systems before the year is out, and they are having trouble getting responses from the system administrators who are responsible for the systems.

When we perform assessments, we often ask our customers about whether they have a configuration management database (CMDB) or something similar.  While CMDB systems may be useful for performing a physical inventory of your systems, that isn’t the real benefit. The real power of a CMDB comes in being able to track the current configuration, status, health, usage, and ownership of every system in the organization.  Let’s say a new patch is released; an up-to-date CMDB can help you understand what systems the patch applies to, whether they need to be patched and/or need prerequisite requirements fulfilled, what applications should be tested before and after the patch, and who the administrator(s) and owner(s) of the system are.

In this particular case, while there is a CMDB, it doesn’t do a good job of tracking the administrators and owners of their systems.  We are experiencing a huge gap in responsibility management.  While we may know of a system which needs maintenance, we don’t know who is responsible for its maintenance, and who is responsible for the information and applications which may be affected by the maintenance on that system.  In this organization, they are typically different people from different parts of the organization, who may not have even met.

Without understanding who is responsible for the system, the applications running on it, and the information stored within it, you are setting yourself up for problems. Well, you’re at least setting yourself up for many frantic emails and phone calls as deadlines draw near.