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.
Monday, 28 March 2011
Sunday, 27 March 2011
Location, Location, Location! What you don't know that they know!
Alrighty then folks, I have been away for about a month. Between my holiday, work and trying to write another post which I hope to publish some time soon, you have seen zero in terms of output from me. This is me correcting that. So, as I was browsing through the magical interwebz, I happened upon this article. This set of all kinds of crazy alarm bells in my mind. So, let's look at this issue in a bit more detail.
Historically, your mobile provided has always known where you are to some extent. With GSM (I believe there is a difference with CDMA, but I am not to familiar with it, so I will skip it) the service would know what the nearest base station to you was. With this information, they would that you were in a certain area. The reason they need to know this is so that when you make a phone call, they know which base station to forward the authentication information to.
One little point to make here is that one can tell approximately how far you are from a base station based on signal strength. If you can find out the distance from several base stations, you can use a method called multilateration to calculate an more accurate location. The more distances you know, the more accurate the location is. This is how location-based services, such as Google Maps, work on a handset with no GPS.
Now, it would be very very very easy for an service provider to obtain the location of any customer and store it, but it may be ILLEGAL!!! Under the European Data Protection Directive (and analogous legislation in other countries) no company may collect any personal data about you without your explicit consent. Now we need to clear up two points (in the simplest case):
1) Is your location personal data
2) Did the company have your consent
So, let's start with point 1. The defintion of personal data is as follows in Article 1 Clause 2 Sub-Clause a:
Historically, your mobile provided has always known where you are to some extent. With GSM (I believe there is a difference with CDMA, but I am not to familiar with it, so I will skip it) the service would know what the nearest base station to you was. With this information, they would that you were in a certain area. The reason they need to know this is so that when you make a phone call, they know which base station to forward the authentication information to.
One little point to make here is that one can tell approximately how far you are from a base station based on signal strength. If you can find out the distance from several base stations, you can use a method called multilateration to calculate an more accurate location. The more distances you know, the more accurate the location is. This is how location-based services, such as Google Maps, work on a handset with no GPS.
Now, it would be very very very easy for an service provider to obtain the location of any customer and store it, but it may be ILLEGAL!!! Under the European Data Protection Directive (and analogous legislation in other countries) no company may collect any personal data about you without your explicit consent. Now we need to clear up two points (in the simplest case):
1) Is your location personal data
2) Did the company have your consent
So, let's start with point 1. The defintion of personal data is as follows in Article 1 Clause 2 Sub-Clause a:
'personal data' shall mean any information relating to an identified or identifiable natural person ('data subject'); an identifiable person is one who can be identified, directly or indirectly, in particular by reference to an identification number or to one or more factors specific to his physical, physiological, mental, economic, cultural or social identity;
I think we can safely say that a person's location and their movements would definitely qualify. So that's one point out of the way.
Next, we need to know if this information was collected legally. I'm going to go out on a limb and say probably. Most companies have you agree to a Terms of Service, which nobody ever reads. This is because it tends to be dozens of pages written in legal parlance. It's enough to make any sane non-lawyer cry tears of sheer anguish. We all sign our consent to it having read the summary and hope we haven't signed away one of our kidneys.
In this case, it's not really the end of the world if our cellphone provider knows where we are. The problem arises when they decide to share that data. In the Terms of Service it may say that they can share this information with certain 3rd parties for any reason. This means that marketing companies could potentially track your every move and learn a lot about your preferences. This could be a problem.
This is an example of why privacy experts complain bitterly about the loss of privacy in the digital age. And they have every right to, with things like this, less and less information is becoming private. However, their constant and sometimes annoyingly repetitive rants tend to fall on deaf ears. Unfortunately, some people release this information themselves using applications such as Foursquare. It's a classic case of taking a horse to the river and the horse drowning itself scenario.
Although despite this, people such as Malte Spitz (link is in German) still have concerns about the privacy of their data. I would not recommend that anybody try and get their hands on what locational data they have, as it would probably not go down well. According to the article it took 6 months of legal wrangling for Herr Spitz to get this data. It would be at least as for you.
Now to sum up I would say "Big Brother is watching you!" but that is trite and cliché. And frankly a tad more alarmist than I would like to be at dark-and-scary-o'clock in the morning. So, I will go with the slightly milder "Be careful what you share on the Internet!"
Sunday, 20 February 2011
Just a litlle bit more on N vs. NP: Computational Complexity
So, after having a conversation with my friend Daniel (who will at some time help me redesign this blog), I realised that I had made one very big, and fairly erroneous, assumption with regards to P vs. NP: People know about computational complexity analysis. So, now I will correct that and explain computational complexity.
So, every computer program is basically a set of steps, which is called an algorithm. When designing any software, you first design the algorithm and then implement it. There are several reasons for this, the one of interest to us is complexity analysis. This is basically counting how many steps the program will take and how many CPU cycles are needed. The basic rule of thumb is that each addition, subtraction, multiplication, division, memory lookup and assignment take 1 CPU cycle.
Of course, this is just a heuristic measure and the actual time taken will depend on the actual hardware, but it gives us a fair idea. Another advantage is that it allows us to compare two algorithms for solving the same and find out which one is more efficient. Just to illustrate this, I will demonstrate one of the most classic examples: Adding up numbers from 1 to n.
The simplest way to do that is to have a counter and add each number to it in sequence. The pseudocode algorithm is below. Anything in green is a comment and is simply to explain what is happening.
counter += i; //Add i to the counter
next i //Increase the value of i by 1 and repeat above
output counter //Output the result
If we count the number of steps, we see we need 2 steps for initialisation (lines 1&2) and n additions and 1output. This gives a total of n+3 steps. Now we look at another way of doing this, by using this formula. In pseudocode, it would look like this:
output counter //Output the result
Now, if we count the steps, we get 1 for initialisation, 1addition, 1 multiplication, 1 division and 1 step for output. This gives us a grand total of 5 steps. Comparing that with the previous algorithm, we see that this is more efficient and does not depend on the actual input.
Most programs are more complex than this and have more complicated expressions for their running time. For these we use big-O notation. This gives us an approximate estimate of the effective running time. It also give us very nice and neat complexity classes. Looking at the example above, algorithm 1 has a running time linear in the input size, O(n), while algorithm 2 has constant running time, O(1). We also have logarithmic time O(log n), polynomial time O(n^c), exponentital time, O(c^n) and so on and so forth. Which, quite neatly brings us to the main problem: P vs. NP.
All problems in computing have a solution, but not all are efficient. Some solutions would takes minutes, others hours and some would take 100s of years to compute. Again, this all depends on your hardware, so actual time measures are not exactly useful. And, this is why we have P and NP.
All the problems that have a solution using an algorithm with time complexity that is polynomial, or less, are classed as P type problems. These can be solved in an acceptable amount of time, e.g. a couple of days. Any thing that takes more than polynomial time is classed as NP. The trick is that even though for small enough instances of NP problems, you can find a solution efficiently, it is the scaling that matters.
So, thus we can see how the above means this post makes a little bit more sense, I hope.
So, every computer program is basically a set of steps, which is called an algorithm. When designing any software, you first design the algorithm and then implement it. There are several reasons for this, the one of interest to us is complexity analysis. This is basically counting how many steps the program will take and how many CPU cycles are needed. The basic rule of thumb is that each addition, subtraction, multiplication, division, memory lookup and assignment take 1 CPU cycle.
Of course, this is just a heuristic measure and the actual time taken will depend on the actual hardware, but it gives us a fair idea. Another advantage is that it allows us to compare two algorithms for solving the same and find out which one is more efficient. Just to illustrate this, I will demonstrate one of the most classic examples: Adding up numbers from 1 to n.
The simplest way to do that is to have a counter and add each number to it in sequence. The pseudocode algorithm is below. Anything in green is a comment and is simply to explain what is happening.
int counter = 0; //Creates a counter, with an intial value of 0
int n = getUserInput(); //Asks the user to enter a number
for i = 1 to n //Repeat the following steps with i having a value from 1 to ncounter += i; //Add i to the counter
next i //Increase the value of i by 1 and repeat above
output counter //Output the result
If we count the number of steps, we see we need 2 steps for initialisation (lines 1&2) and n additions and 1output. This gives a total of n+3 steps. Now we look at another way of doing this, by using this formula. In pseudocode, it would look like this:
int n = getUserInput(); //Asks the user to enter a number
int counter = (n*(n+1))/2; //Creates a counter, and assigns it the value of the sumoutput counter //Output the result
Now, if we count the steps, we get 1 for initialisation, 1addition, 1 multiplication, 1 division and 1 step for output. This gives us a grand total of 5 steps. Comparing that with the previous algorithm, we see that this is more efficient and does not depend on the actual input.
Most programs are more complex than this and have more complicated expressions for their running time. For these we use big-O notation. This gives us an approximate estimate of the effective running time. It also give us very nice and neat complexity classes. Looking at the example above, algorithm 1 has a running time linear in the input size, O(n), while algorithm 2 has constant running time, O(1). We also have logarithmic time O(log n), polynomial time O(n^c), exponentital time, O(c^n) and so on and so forth. Which, quite neatly brings us to the main problem: P vs. NP.
All problems in computing have a solution, but not all are efficient. Some solutions would takes minutes, others hours and some would take 100s of years to compute. Again, this all depends on your hardware, so actual time measures are not exactly useful. And, this is why we have P and NP.
All the problems that have a solution using an algorithm with time complexity that is polynomial, or less, are classed as P type problems. These can be solved in an acceptable amount of time, e.g. a couple of days. Any thing that takes more than polynomial time is classed as NP. The trick is that even though for small enough instances of NP problems, you can find a solution efficiently, it is the scaling that matters.
So, thus we can see how the above means this post makes a little bit more sense, I hope.
Tuesday, 15 February 2011
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.
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.
Sunday, 13 February 2011
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.
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.
Saturday, 12 February 2011
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.
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.
Tuesday, 8 February 2011
Computer Security Experts; The Doctors of the Digital Age?
So, there's a lot going on and I really need time to compose my thoughts. And by that time, more will have happened. Loop infinitely. But until the end of time or death, whichever comes first, I will try and keep up. While I do that, I have a not so significant post on a random train of thought from my brain.
So, this idea struck me while watching an episode of House MD. If you are not familiar with it, I will give you the overview: Dr. Gregory House is a genius and an ass of the highest order. He diagnoses and cures patients with conditions that have baffled and/or escaped other physicians. They use a method know as "differential diagnosis" (DDx), which is basically saying "the patient has the following symptoms, therefore they must have the following condition." While watching one of these, I realised that there is only one kind of human body. Yes, there are differences from person to person, such as eye colour, height, weight, allergies, etc, but the basic abstract framework, if you will, is the same. Arguably there are two, one for each gender, but there really aren't more than that.
Then I thought if any parallels could be drawn between computer security and medicine. Here's where I drew a blank. There were some superficial comparisons, but those were a stretch of the imagination at best. It dawned on me that the level of complexities in the systems we deal with are so high, that the human body looks like a wind-up toy in comparison. In no way do I mean to trivialise medicine, which is a very complex field in its own, but all that complexity is constrained to at most two basic frameworks. In computer science in general, there are an near infinite number of potential frameworks.
If we begin at the most basic level and just examine the hardware. Right there you have so many components to consider and several of them with potential security issues. First off, the components have to compatible. Next we need to insure that none of these components, on their own or in combination, will cause a security threat. This is easier said than done, as components from different manufacturers can behave differently and have side-effects that others don't. At this point we have so many ways we can fail, and yet we only have a box that does nothing. Zilch! Without any software to run the hardware, you just have an expensive and oversized paperweight. Which takes us to the next point software.
Even in software, we have two basic groups: operating systems (OS's) and application software. Well first you need an OS to run your computer. There is a HUGE potential location for security holes here. Every OS available has security holes, every one of them. Yes, every single one, that especially includes MacOS. I am sick and tired of Mac users sanctimoniously claiming that there are no viruses from Macs! This is often swiftly followed by a comment on how Macs are more secure than Windows. I have one word for that:
I know you must be thinking, but when I installed my operating system it had all these programs installed already. I could play games, connect to the Internet, and so on. Yes, that is true, but the software that enabled you to do so was not part of your OS, generally speaking. It was bundled in and included with your installation media, but it is technically not part of the OS. Now we come on over to application programs. This anything you install on your computer, no matter how small or large, it all matters.
The thing with most software is it does a lot of stuff that you never see. Most of the time it's stuff you want it to do, but you really have no way of knowing. There are two scenarios here, where the software is doing what you asked, but as a side-effect has made you vulnerable to certain attacks and where the software is deliberately making you vulnerable. In either case you are vulnerable. This is assuming just one program, it gets even more fun with multiple programs. Some applications connect to each other, such as your PDF reader and your web browser. Here it becomes really fun!
It may turn out that on their own the programs pose no threat, but when combined they are potentially lethal. A sort of the reverse of salt, whose components are lethal, but the combination is not. I think you can see where this is leading to. If your head is spinning trying to imagine the countless possibilities of interaction between programs on your computer and/or that you know of, well then my job is done.
Now, I would like to point out that the same applies for smart phones. Have fun running over that one. Then consider when you connect your smart phone to your computer. This whole path leads you to a really messed up place where you are building a house of cards, using cards of different shapes and sizes. It's almost like you want it to fall down, just so you can stop building.
But enough gloom and doom, silver lining time. Here you go! Seriously, although there are a plethora of threats to your computer and its safety, if you are smart and keep your wits about you, then you should be fine.
So, this idea struck me while watching an episode of House MD. If you are not familiar with it, I will give you the overview: Dr. Gregory House is a genius and an ass of the highest order. He diagnoses and cures patients with conditions that have baffled and/or escaped other physicians. They use a method know as "differential diagnosis" (DDx), which is basically saying "the patient has the following symptoms, therefore they must have the following condition." While watching one of these, I realised that there is only one kind of human body. Yes, there are differences from person to person, such as eye colour, height, weight, allergies, etc, but the basic abstract framework, if you will, is the same. Arguably there are two, one for each gender, but there really aren't more than that.
Then I thought if any parallels could be drawn between computer security and medicine. Here's where I drew a blank. There were some superficial comparisons, but those were a stretch of the imagination at best. It dawned on me that the level of complexities in the systems we deal with are so high, that the human body looks like a wind-up toy in comparison. In no way do I mean to trivialise medicine, which is a very complex field in its own, but all that complexity is constrained to at most two basic frameworks. In computer science in general, there are an near infinite number of potential frameworks.
If we begin at the most basic level and just examine the hardware. Right there you have so many components to consider and several of them with potential security issues. First off, the components have to compatible. Next we need to insure that none of these components, on their own or in combination, will cause a security threat. This is easier said than done, as components from different manufacturers can behave differently and have side-effects that others don't. At this point we have so many ways we can fail, and yet we only have a box that does nothing. Zilch! Without any software to run the hardware, you just have an expensive and oversized paperweight. Which takes us to the next point software.
Even in software, we have two basic groups: operating systems (OS's) and application software. Well first you need an OS to run your computer. There is a HUGE potential location for security holes here. Every OS available has security holes, every one of them. Yes, every single one, that especially includes MacOS. I am sick and tired of Mac users sanctimoniously claiming that there are no viruses from Macs! This is often swiftly followed by a comment on how Macs are more secure than Windows. I have one word for that:
NONSENSE.
Seriously, every operating system has security issues. Some have more that others, some have more critical ones than others. Now another concern is which operating system are you using? Which version of it? Which patches and updates are installed? Is there any issue arising from the hardware/software combination? These are just some of the questions you have to ask. At this point we have a computer that can switch on and let you log on and not much more.I know you must be thinking, but when I installed my operating system it had all these programs installed already. I could play games, connect to the Internet, and so on. Yes, that is true, but the software that enabled you to do so was not part of your OS, generally speaking. It was bundled in and included with your installation media, but it is technically not part of the OS. Now we come on over to application programs. This anything you install on your computer, no matter how small or large, it all matters.
The thing with most software is it does a lot of stuff that you never see. Most of the time it's stuff you want it to do, but you really have no way of knowing. There are two scenarios here, where the software is doing what you asked, but as a side-effect has made you vulnerable to certain attacks and where the software is deliberately making you vulnerable. In either case you are vulnerable. This is assuming just one program, it gets even more fun with multiple programs. Some applications connect to each other, such as your PDF reader and your web browser. Here it becomes really fun!
It may turn out that on their own the programs pose no threat, but when combined they are potentially lethal. A sort of the reverse of salt, whose components are lethal, but the combination is not. I think you can see where this is leading to. If your head is spinning trying to imagine the countless possibilities of interaction between programs on your computer and/or that you know of, well then my job is done.
Now, I would like to point out that the same applies for smart phones. Have fun running over that one. Then consider when you connect your smart phone to your computer. This whole path leads you to a really messed up place where you are building a house of cards, using cards of different shapes and sizes. It's almost like you want it to fall down, just so you can stop building.
But enough gloom and doom, silver lining time. Here you go! Seriously, although there are a plethora of threats to your computer and its safety, if you are smart and keep your wits about you, then you should be fine.
Subscribe to:
Posts (Atom)
Subscribe To
Posts
All Comments