Security the MS way: Protecting you from yourself!

I have always maintained that Microsoft's security policy is essentially to stop you from doing anything stupid. The concept in itself is fairly sound, but the implementation is not. In the classic Operating System debate of Windows versus Linux, the biggest point Linux users make is that they can modify any part of the operating system to suit their needs and desires. When I used Windows XP, I had found all the little secrets to get my machine to do what I wanted it to do. But, I digress.

Microsoft basically adopted the "protect the users from themselves" approach in earnest in Windows Vista. There are several reason why I (and others) am not too fond of Vista, but that aside. The idea is sound in theory, but the implemenatation of it left so much to be desired. In hiding all the knifes from the kids, they also hid all the forks and spoons. Yes, I agree that some of the functionalities should not be available to normal users, but it should be available to admin users.

A whole plethora of useful features were hidden, but we shan't go into that now. The main thing is this article. Now I know I'm a bit late to jump onto this, but I have been a tad lazy. Moving on. So it seems that Hotmail will ban common and quite frankly shit passwords. This is a good and a bad thing.

As I have pointed out before, passwords can be tricky things. For something iek your e-mail account, you need a decent password. So now if Hotmail will reject your password because it's shit, that good right? Well, yes and no. It does stop dictionary attacks, however it drastically changes the search space.

Previously, an attacker would run dictionary attacks in the hope that somebody was a fool. Now that cannot happen then the system is foolproof right? Yes, but to quote Douglas Adams "A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools." It may sound a touch misanthropic, but people are stupid. 


Eventually what is going to happen is that people will find that people will find the least complex passwords that pass through the Hotmail filter and then use those passwords repeatedly. Now dictionary based attacks kick in again, just with a new dictionary. The dictionaries may be larger than previously, but it may not be a significant amount.


So, it is a good idea and I am very much in favour of this, but it could also backfire. Only time will tell, we shall wait and see.

Password Lockers Part 2

So, this is becoming a trend, well two trends: follow-up posts and data breaches. As you may or may not know, there was a MASSIVE breach involving Sony Entertainment, specifically the Playstation, but more on that later. More the the point you may recall my previous post on password lockers etc. Well, this post is about what can go wrong with a password locker.

LastPass is a company that provides a password locker service. What you do is register and download their software. Your master password, which unlocks the locker is then stored there. Now it recently came to light that some of these passwords were compromised (or not). Well, LastPast, if you are reading this, have a gander over here for a sec, k? We assume, hypothetically, that the master passwords were compromised (mainly because I have already written out most of this post and I'm kinda lazy). LastPass issues a warning to all its users to change their master passwords and they all do. Their servers could not handle the load and so they had to restrict the number of users allowed to change their passwords. This actually happened before they announced they were not hacked.

Well, I would like to say that I am somewhat impressed by the expediency with which the users tried to change their passwords. I am also impressed by LastPass's inability to deal with the situation. Agreed, that they had issues dealing with the load but according to their blog they have put affected accounts in "lock-down" mode. Kudos to you.

After all of this, LastPass then claimed they were not hacked. It seems that they just broken their system. After users changed the master passwords, they were met with garbage characters, random images and occasionally the deep dark void of nothing. Somewhere somebody thought that implied a hack. And that brings us to today's lesson.

When you think you have been breached, DO NOT PANIC! Check, re-check, double-check and confirm that there has been a breach. Immediately put in place counter-measures and check for other possible backdoors opened by this breach. Take a deep breath. Notify the affected users as required by law and/or company policy. If you follow these steps properly, then there should be no need to ever retract a security warning. Issuing a security warning scares people, retracting it causes doubt. We are trying to bring digital security out of the realm of FUD (Fear, Uncertainty, Doubt)!

Why the movies are wrong (Surprise, Surprise)

On the lighter side of life, my friend @zarino tweeted this link, which got me thinking about hackers in popular culture. Think about your favorite movie and/or TV hacker. My vote goes to Alec Hardison, but that's irrelevant. In any "hacking sequence" you see the hacker typing away furiously on a keyboard and all sorts of random green text on a black background. The green on black dates way back to the old days and I have no clue as to why they used those colours, but everybody loves it.

Anyway, you see them typing away furiously at a console screen and all sorts of text just popping up.

IT'S ALL WRONG!

Sadly, hacking is really not that glamorous. It's mainly typing one or two commands or even just a button click. That is preceded by actually coding the tool you are using but nobody types that fast, especially not when programming. Just by the by, the text that appears in the link is a program of some sort. Haven't read all the code, so not sure what it does. All I can say is that it looks something from the C-family.
*****EDIT******
Turns out they last change the site a touch since I visited it. It appears the code is part of the Linux kernel.

Irony thou name is SQL injection

As I clicked on my slashdot bookmark, I for some reason said to my browser "Please give me something juicy" and it did not disappoint. It gave me this article. The sheer irony alone made me chuckle for 2-3 minutes. So, meine Damen und Herren, (I just had to throw a little German in there) let's talk about SQL injections. I promise this won't hurt (much)!


So, to understand a SQL injection, we need to understand SQL. To understand SQL, we need to know what a database is. And that's where we will start. This may be a bit round about, because to frank I find databases to be a dull and boring topic. We start at the bottom, with data elements. Now a data element is a single piece of data about an entity e.g. Name, Gender, Age, Favourite Star Wars Character and so on. A record is all the specific data elements about a specific entity e.g. {Saqib A Kakvi, Male, 23, Yoda} would be a record about me. If we have several such records stored as rows, we get a table. If we have more tables (generally related) we now have a database. In summary: A database is a collection of tables, which in turn is a collection of records, which in turn are a set of data elements.

Agreed, it's all fine and dandy having all this data nicely stored, but how do we access specific parts of it? The answer is Structured Query Language or SQL (sometimes pronounced 'sequel') for short. SQL is basically a language that allows us to get a section of a database based on some criteria e.g. all the records of people who are over the age of 30. Although SQL gives you quite a lot of lean room, it is strongly typed, which means that all SQL statements must have a very specific form, syntax and all the right symbols in all the right places.


And this brings us to SQL injection. A SQL injection exploits the srong-typing of SQL and issues malformed statements which cause the SQL interpreter to go a little bit bonkers and produce some crazy result. By taking very, for lack of a better phrase, well-formed malformed queries, an attacker can recover parts of (and even all of) the database. When implementing a database, one must ensure that any and all malformed queries are rejected, thus making SQL injections irrelevant. 


MySQL is a software that helps you implement, run and maintain a database (known as a Relation DataBase Management System {RDBMS}). The MySQL company seems to have forgotten about this vulnerability in a primary part of their system. As we have seen, MySQL (and apparently sun.com) have been so ironically compromised due to a SQL vulnerability. Well who would have thought it?


ME! ME! ME! Well, actually the thought had crossed my mind a few times and I thought it was funny, but sincerely hoped that it would never happen. Well done world, you continue to surprise me.

A note on passphrase guessing time calculations

Alrighty then, I had few thoughts about these figures that I mentioned here and decided to some math. It all falls apart very quickly. If we actually crunch the numbers, the titular hacker's computing power changes for every equation and produces some interesting values. I will assume there is some rounding off that is done and thus we lose accuracy in the answer explaining the fluctuations.

Now, don't just take my word for it, you can join in at home. Grab a pen, paper and a calculator because we are dealing with HUGE numbers. Before we can begin, we need to do some housekeeping and define some variables. If you recall from my last post, I stated the 3 characteristics a good password should have, but we only consider the two under attack here that is length and complexity.

We define the complexity by the size of the alphabet, a, that is possible characters the password contains. For lower case a = 26, lower and upper case a = 52. With symbols it depends on how many symbols are considered valid, but in general, we have a = 52 + number of valid symbols. The length is fairly straightforward and self-explanatory. We define the total complexity of our password as
c = a^l (where ^ denotes exponentiation.)

Now, to calculate the time it would take for a hacker to guess your password, we need to know how many guesses they can make per second (or other appropriate time unit), which we denote by g. We can see that the time required is
t = c/g (in the worst case)
You may want to consider the average case, which is obtained by dividing by 2g instead of g.

If you compute g for lower case passwords with length 6 and 7, you see that there is a discrepancy in the g value. However, if you take the g from length 6 and plug it into the equation, you get a t of 4.333.... hours, which is close enough to the 4 hours they have stated. This lends credence to my rounding theory, but does not prove it.

The rest is left as an exercise for the reader. So, go on and give it a whirl. Try this with different combinations and see how long it would take somebody to crack your password.

Passwords/phrases and client side storage

So, after we discussed this, we now move onto the promised post on where and how you should be storing your passwords. But before we get into that, we need to define the importance of passwords and password strength. But, we first need to discuss the term password, mainly the word part. People think, quite intuitively, that a password should be a single word, which is not the best idea. I prefer the term passphrase, implying multiple words and/or numbers and/or symbols. I will use the term passphrase from now on. With that out of the way, I think the next logical step is to discuss password strength.

Password strength is defined by 3 characteristics. The simplest is length, which is fairly obvious. The longer the password the harder it is to guess. I recently stumbled onto these figures, but take them with a grain of salt. They do not specify what kind of hardware was used to make these figures, so its all a bit iffy. Next is complexity, which is illustrated in the afore mentioned figures. (but just the general trend, the actually figures are still questionable). Simply put, if you have more complex passwords, with a combination of lower case, upper case, numbers and symbols, you increase the search space hugely. The third is memorability. There is no point of having "ASddeu43548&^&^ßß" as your password, because you will never remember it. A good password should be easily recalled.  The higher each of these characteristics are, the stringer the password.

Now we move on to the classification of passwords. People have varying opinions on what the exact classifications are, but I use a 4-tier system, detailed below. For each tier we define the suggested password strength wrt the 3 characteristics using the terms High(H), Medium(M), Low(L). We express these as a 3-tuple of the form {Length, Complexity, Memorability} e.g. High length, medium to high complexity and low memorability is written as{H,M-H,L}

TIER I: The big guns; these are passwords for your financial accounts. Online banking, online shopping, or any account which has you financial details, PIN numbers for your ATM/debit/credit cards. These must be very memorable, hard to guess and very strong. You lose one of these, you will lose all your money.
Strength: {H,H,H}

TIER II: These are next in line in terms of importance: Login credentials. This is your school/university/office login name and password. This is how you login to systems at work (wlog) either when you are on the premises or remotely. If you lose these, then you can kiss your professional life goodbye.
Strength: {H,M-H,H}

TIER III: The mid-level identity theft type passwords: email and asocial networking. So your Facebook, HI5, LinkedIn, MySpace, GMail, Y!Mail, Hotmail, thismail, thatmail, and so on and so forth. Depending on how many e-mail addresses you have and what kind of emails you receive on them, the effects of the loss vary. If you lose your primary account's password, then the likelihood of identity theft is significant.
Strength: {M-H,M-H,M}

TIER IV: The throwaways. This is all the stuff you couldn't care less about. Logins for sites that you created just so that you could read certain articles for example. These do carry some risk, but there is a very small risk involved. This depends on several factors, which we will get into in a moment.
Strength: {M,M,L-M}

Now, we need to lay down some ground rules. No passwords should be shared across tiers. This is based on the principle of least privilege. Secondly, passwords from one tier are never stored with passwords from a lower tier. Thirdly, realisability limits; Tier 1 passwords should be unique, tier 2 & 3 should be reused sparsely, Tier 4 can be reused infinitely. Finally, each tier's passwords should be of similar strengths, as explained above. These rules and system in general are a guideline, which I try to follow, but there are grey areas. When in doubt, go for the safest option.

Now that we know how to classify our passwords, we now move onto storage of said passphrases. For tier 1 passwords, we need a highly secure storage, i.e. a password locker. These are programs that will store all your passwords for you in an encrypted form. To decrypt these, you need a master passphrase, which you define when you setup the locker. This passphrase can be thought of as as a tier 0 passphrase, which a mild abuse of notation. This master passphrase has to live in your head and must be of high length, complexity and memorability.

Next we go onto tier 2. These can be stored in programs, but need to be encrypted or locked with another master pass phrase. These should not as a rule be stored with the tier 1 passwords, but that rule tends to be broken for practicality's sake. It is quite annoying having multiple password lockers and it wouldn't be the worst thing if your most important passwords were kept together. If we do have a second password locker, we should treat the master passphrase as tier 1 password.

Now for tier 3, it you can save them in your browser, BUT, they must be encrypted with a master passphrase under all circumstances. Also you should avoid the use of cookies storing the session, caused by checking the "Remember me" check box. This is a big no-no. It's convenient, but it's not really secure. Alternately you could have a third password locker and store them there, encrypted with a tier 2 passphrase (I'm sure you can see the general trend here). If you have your tier 1 and 2 passphrases in a single locker, then this would be a second locker.

And now, tier 4. We all have a billion passwords for a billion sites that we that we use once a month or even less frequently. Theoretically, you could create a new password for each, but you will never be able to remember them all. These you can have your browser remember for you. This way you can have a unique arbitrary password for every single account. There is no real need for a master passphrase encryption, but it is recommended. As you may have guessed, this master passphrase would be a tier 3 passphrase.

These rules are quite rigid, but they are designed from a security point of view rather than a usability point of view. What is an acceptable loss of usability is very much a personal preference and that is up to you. You are welcome to bend and even break some of the rules, to make life easier for yourself. But, remember, you sacrifice security for usability and only you can strike the right balance for yourself. (I avoided saying "you have the power" because it sounds really cheesy) And so, there you have my guidelines for password storage. If in any way this makes the web just that much more secure, then I will have done my job.

Passwords and server side storage.

OK, so some background reading here. I know it says I will post something about password lockers, but this is not it. Instead of considering where you store your password, we consider where they store you password. They being any website you have signed up for. 

Now, it's obvious that they need to store your password. If not, the whole exercise would be pointless. The initial idea was to store the password in plaintext in a file in the server. BAD IDEA! If an attacker were to somehow get a hold of that file, you are screwed. Royally! The attacker now knows all your users' login credentials and can run amok doing all sorts of bad things. So, there were 2 bright ideas to fix this: encryption and hashing.

We note that both work in a similar way at the high level, which we will abstract as a function f. With these, when a user registers, we get the plaintext input of the password, pass and compute f(pass). We then store f(pass) instead of pass. When a user attempts to login, we get the password they entered login_pass and compute f(login_pass). We then check to see if f(login_pass) == f(pass). If they are the same, we conclude the user has entered the right password and let them in. If not, then they get an annoying error message.

Now, we straight away notice a problem: Collisions! If person A and person B both have the same password, then the stored value f(pass) will be the same. This means that if the attacker knows person A's password, they know person B's password. There is a very very small possibility that f(passA) = f(passB) and passA != (not equal) passB, but we will ignore this possibility. So, now what?

Well, the answer is salt. Well not exactly that kind of salt, but what we call a "random salt." Basically, this is a random bit-string, which or may not have some structure. So, we now have the modified password storage protocol as follows: A user registers with password pass. We compute f(pass+salt) and store (f(pass+salt), salt). When a user attempts to login, we get the password they entered login_pass and the stored salt. We compute f(login_pass+salt). We then check to see if f(login_pass+salt) == f(pass+salt). Thus, even if 2 users have the same password, the collision is not apparent due the salt. Now, they are secure, right?

Not quite yet. This depends on your choice of the function f. Let's start by discussing the symmetric key crypto option. You need to use a secure crypto scheme, such as AES, with a large enough key size. Then, we need to consider the key storage. If we store the key with the passwords file, then there is no security. If the attacker can access the password file, its safe to assume he can access the encryption key. Once, he has the encryption key, it's game over! But if you store the key safely in another location, even if the attacker gets the password file, there is still some security.

Now, we look at hash functions. You would need to use a collision-resistant hash function, which is not broken. Since the hash functions are not really keyed, there is no concern about key storage, so that makes things a bit easier. However the trade-off is the due to the fact that hash functions are designed to be computed quickly, the attacker has quite an advantage as detailed here.

Of course, the increased computational power attacks can also make it faster to break the symmetric crypto algorithm. How quickly this is don depends on known attacks for the algorithm. So, there is still a threat if your encrypted password file is compromised. Ask Gawker, they will tell you. This particular attack revealed some interesting statistics about passwords, shown here. More about these later.

For now, I have but one humble request for all admins on all servers out there: please store my, and everybody else's passwords securely. Although a lot of them do it right, some don't. This needs to change.

Password Storage

As you may or may not know, I have previously had a few not so pleasant words for people's activities on Facebook (cf. this post). I'm sure most people will agree that some people post unbelievable things on Facebook. Granted some of it user error, some of it is the interesting phenomenon called "Facebook rape" or simply "frape", but most of it is intentional. This has lead to the development of two very similar sites lamebook and failbook. The content is not all about people posting inexplicable things, but that is the gist of it. These sites have provided me with many hours of entertainment.

Now, you may be wondering what this has to do with password storage. This post is the link. So Ally stored all her passwords in a file, which I will for the sake of argument call pwd.doc. Now at this point that's a really bad idea. But then Ally thought about securing this file so she password protected it. Of course the most brilliant part is putting the password into the file itself, which as stated in the comments is like locking a copy of the key into a treasure chest. The pointlessness of that aside, Ally has now forgotten the password for pwd.doc, which is a bad thing.

What Ally has done is essentially a quick and easy password locker. The security of it debatable as Word document passwords can be relativly easily cracked. That aside, it is an excellent solution for what is just a bad situation. A recent study has shown that people have about 25 accounts requiring passwords and an average of 8 passwords. Each of these accounts has varying specifications for length, characters used, frequency of change and so on. This leads to sheer overload for the human brain.

The instant response is for people to write down all these passwords (as shown in the comments on the posts) which then creates a security threat. So the natural solution the that is a password locker. Instead of writing it all down on a piece of paper, you store it digitally and encrypt it. Which is is a password locker. There are several of these available on the net, ranging from free to £15 to any amount somebody thinks they can get away with. There are several issues to consider when creating a password locker, but that is for a later post. So Ally has essentially got a DIY password locker, which is now locked.

However, this was posted on Facebook, so that means that either:
a) Ally's Facebook password is stored in the browser,
b) Ally has the "Remember me" option ticked,
c) Ally remembers the password.

Going through each option one at a time, first up we have browser storage. Most people use their browsers password storage system, which stores passwords and then fills them in automatically to forms in web pages. This is an issue because a browser exploit could find all your passwords and we all know where that leads to. So door 1 has a goat behind it (for those of you unfamiliar with that reference cf. The Monty Hall Problem)

Lets look at the next option, "Remember me" which was covered in a previous post, in the 6th paragraph. So another goat

Finally, we assume Ally remembers the password. Well then, we can safely say it is more memorable that the password for pwd.doc. If we assume both passwords are equally memorable, then we can rule out this option. So we have a car, sort of. Lets say a goat-pulled car.

I could go on and on at length about passwords and their implications, but let's be honest, you'd rather hear it from someone. Bruce Schneier has several posts about passwords on his blog. Have a read through there if you are interested.

---NOTE: I will still post something about password lockers---