Security Assurance vs. Quality Assurance

7033818-3d-abbild-monster-mit-investigate-linseIt is often debated how Quality assurance relates to Security assurance. I have a slightly unconventional view of the relation between the two.

You see, when we talk about the security assurance in software, I view the whole process in my head end to end. And the process runs roughly like this:

  • The designer has an idea in his head
  • The software design is a translation of that into a document
  • Development translates the design into the code
  • The code is delivered
  • Software is installed, configured and run

Security, in my view, is the process of making sure that whatever the designer was thinking about in his head ends up actually running at the customer site. The software must run exactly the way the designer imagined, that is the task.

Now, the software has to run correctly both under the normal circumstances and under really weird conditions, i.e. under attack. So the Quality Assurance takes the part of verifying that it runs correctly under normal circumstances while Security Assurance takes care of the whole picture.

Thus Quality Assurance becomes an integral part of Security Assurance.

Security Breach at Unique Vintage

There is news that women’s clothing website Unique Vintage has sent notifications to the customers that the site has been breached and the customer information was exposed. What is interesting is that the website is fully PCI compliant, i.e. it follows all rules for security set forth by the credit card industry. And still, it appears, the credit card numbers, among other information, were stolen. And this went on for more than a year and a half before being detected.

There is no substitute for proper design and security diligence. Following the rules set in a book will only get you so far. The attackers do not follow any book strictly, so you should not.

User Data Manifesto

Having a confirmation that the governments spy on people on the Internet and have access to the private data they should not sparked some interesting initiatives. One of such interesting initiatives is the User Data Manifesto:

1. Own the data
The data that someone directly or indirectly creates belongs to the person who created it.

2. Know where the data is stored
Everybody should be able to know: where their personal data is physically stored, how long, on which server, in what country, and what laws apply.

3. Choose the storage location
Everybody should always be able to migrate their personal data to a different provider, server or their own machine at any time without being locked in to a specific vendor.

4. Control access
Everybody should be able to know, choose and control who has access to their own data to see or modify it.

5. Choose the conditions
If someone chooses to share their own data, then the owner of the data selects the sharing license and conditions.

6. Invulnerability of data
Everybody should be able to protect their own data against surveillance and to federate their own data for backups to prevent data loss or for any other reason.

7. Use it optimally
Everybody should be able to access and use their own data at all times with any device they choose and in the most convenient and easiest way for them.

8. Server software transparency
Server software should be free and open source software so that the source code of the software can be inspected to confirm that it works as specified.

In the news

I do not often want to comment the news so today is a special day.

The first piece is an article on the popular subject of NSA Web Surveillance quoting some well-known people starts off on a good direction but gets derailed somehow into recommending obscurity for security. Strange as it is we really should consider anonymizing our access to the Internet. The problem is though that we cannot anonymize the most important part of our Internet access where we real need our real identity and that is the part that delivers most information about us. Sorry, it is not going to work.

I was wondering earlier what the situation of Canada is in relation to the NSA scandal and the article on Canada’s part in NSA plan revealed that we cannot count on Canada to be impartial in the matter. They are in on it and quite likely Blackberry is no better choice than other U.S. controlled mobile phones.

I cannot remember when was the first time I heard that “passwords are dead”, it must have been years and years ago but this same mantra is repeated over and over again every year. Now the passwords are dead at Google. Well, tell you what, long live passwords!

And suddenly Vint Cerf, one of the guys at the beginnings of the Internet, is preaching for the devil. He is working for Google, of course, so his opinion that we all should “give up a degree of privacy in order to be protected” is likely Google’s, not his own. On the other hand, if you ask me I would say he should watch what he says, people believe him more or less unconditionally and his moral obligation is to not peddle the loss of privacy for all of us.

Here you go. I seem to disagree with nearly all of the news today. Which is good news!

Nokia is gone. So is mobile security.

The recent acquisition of Nokia by Microsoft stirred up investors and Nokia fans. But, the question goes, what does it have to do with security? (Not) Surprisingly, a lot.

Working in security makes people slightly paranoid over time, that is a fact. On the one hand, without being suspicious of everything and checking all strangeness you would not get far, so that makes you extra attentive to possible security issues. On the other hand, witnessing how everything around us turns from impenetrable walls into a Swiss cheese variety when poked makes you doubt every security statement on the planet. Looking at Microsoft buying Nokia, I cannot resist putting my security hat on.

So what does the acquisition of Nokia by Microsoft bring us on a large scale of things? You remember, of course, that some governments, and in particular USA, listen to all our conversations on the Internet and collect all possible information about us, right? Okay, for those who forgot, I will remind that Microsoft, Google and Apple are on the list of companies sharing information with NSA. Just keep in mind it is likely not limited to NSA and USA, other governments are not likely to refuse the temptation.

lock-nokia-transpNokia was not on the list. And I will hazard a guess that the Finnish company refused cooperation with NSA. That means people who have the good old Nokia phones are probably more safe from surveillance compared to people with those Microsoft, Google and Apple phones. We can probably assume that it was not exciting for NSA and the like to know that (5 years ago) half of the people with mobile phones will not be under surveillance. I can imagine they were rather disappointed. I would not be surprised if they lent a hand to Microsoft in the plan to acquire Nokia or even orchestrated the whole thing.

Now, Nokia is Microsoft. What does it mean? There is no phone any longer that is not under surveillance. Think of any mobile phone, it is going to be Microsoft, Google or Apple, committed to collaborating with NSA on surveillance. There is no alternative.

We still can use our good old mobile phones, of course (and I do). Telephone networks change though, new protocols come into play, old ones are phased out. In time, the good old phones will simply stop working. And this process can be accelerated if desired. There will be no choice.

I really wonder about Blackberry now …

What are NFC cards and how are they protected?

Ever since I posted an initial article “Hack NFC Door Locks” I see a steady stream of people that come with queries like “what’s the protection of an NFC card” and “how do you hack a protected NFC card”. Obviously, there is something out there interesting enough for people to begin inquiring.

What is an “NFC card”? As opposed to an “NFC device”, an NFC card is simply a contactless smart card. The NFC protocol allows for a great flexibility in choosing what you may name an NFC card and nearly anything in the vicinity and proximity card world can be termed an NFC card.

Most of the time though you will be dealing with the good old Type A and Type B cards from the ISO 14443 standard. Unless you are in Asia and then the chances are high you will be facing a Sony FeliCa card. There is nothing NFC about any of them except the new name. They are all good old contactless smart cards.

Now, to the question that actually interests most of the people seeking enlightenment, the protection of those smart cards can vary. What kind of protection is used depends more on the system that specified what kind of a card will be used there. So if we are talking about door locks we are likely to see the cheapest MiFare cards that can actually be broken comparatively easily. When we are in some banking applications, we are likely to see high-end smart cards with seriously mean security features.

Since NFC cards are “just” smart cards, you must be looking for the information on how to deal with the smart cards and all of that will be applicable to the NFC cards. The low end is fairly simple, often the system does not use encryption, the cards may be read out and copied with very little effort. In more serious systems the cards usually do not let themselves to investigation erasing the content at the least suspicion of a break-in.

The protection mechanisms may include (and this is not an exhaustive list, just off the top of my head):

  • Constant time execution of all routines
  • Checks of the execution state at regular intervals and at critical operation beginning and end
  • Encryption of all of the memory content or sensitive areas like key storage
  • Encryption of input and output, sometimes double encryption
  • No debug and error output, just lock up in case of an error
  • Sensors for temperature, light, voltage, current
  • Protective mesh over and in between layers of the chip with cut sensors
  • Stabilizers of current consumption and noise generators
  • Scrambled and encrypted buses and memory content
  • Parallel execution to compare results against tampering
  • Randomized circuit layout

Basically, there are two things there: (1) protection of the hardware against tampering and side channel analysis and (2) protection of the software against induced faults and side channel analysis. Typically, the designers work hard to make sure you have to defeat both to get any meaningful results. So to get a go at the smart card security, you are better off to search for a security lab that does smart card security evaluations and ask them to work for you.

I always assumed there are tons of literature on the subject although right now a quick search on Amazon proved me wrong, there is only a handful of books. Maybe I should write more on smart card security?..

Password recovery mechanisms – Part 3

Passwords remain the main means of authentication on the internet. People often forget their passwords and then they have to recover their access to the website services through some kind of mechanism. We try to make that so-called “password recovery” simple and automated, of course. There are several ways to do it, all of them but one are wrong. Let’s see how it is done.

If you did not read Part 1 – Secret questions and Part 2 – Secondary channel, I recommend you do so before reading on.

Part 3 – Example procedure: put it all together

Security - any lock matters as much as any other.

Let’s assume we are putting together a website and we will have passwords stored in a salted hash form and we identify the users with their e-mail address. I will describe what I think a good strategy for password recovery then is and you are welcome to comment and improve upon.

Since we have the users’ e-mail addresses, that is the natural secondary authentication channel. So if a user needs password recovery, we will use their e-mail to authenticate them. Here is how.

The user will come to a login page and clicks the link for “forgot password” or similar. They have to provide then an e-mail address. The form for e-mail address submission has to have means of countering automated exhaustive searches to both lower the load onto the server in case of an attack and provide some small level of discouragement against such attacks. There are two ways that come to mind: using a CAPTCHA and slowing down the form submission with a random large (an order of seconds) delay. Let’s not go into the holy war on CAPTCHA, you are welcome to use any other means you can think of and, please, suggest them so that others can benefit from your thoughts here. You should also provide an additional hidden field that will be automatically filled in by an automated form scanning robot, so you can detect that too and discard the request. Anyway, the important part is: slow down the potential attacker. The person going through recovery will not mind if it takes a while.

As the next step, we will look up the user e-mail address in the database, create a random token, mail it out and provide the feedback to the user. The feedback should be done in constant time, so that an attacker does not use your recovery mechanism to collect valid e-mail addresses from your website. The process thus should take the same time whether you found the user or not. This is difficult to get right and the best solution is to store the request for off-line processing and return immediately. Another way is to use the user names instead and look up the e-mail address but a user is more likely to know their own e-mail address than remember their user name, so there is a caveat. If you cannot (or would not) do off-line processing of requests, you should at least measure your server and try to get the timing similar with delays. The timing of the server can be measured fairly precisely and this is difficult to get right, especially under fluctuating load but you must give it a try. Still, it’s best if you keep the submitted information and trigger an off-line processing while reporting to user something along the lines of “if your e-mail is correct, you will receive an automated e-mail with instructions within an hour”. The feedback should never say whether the e-mail is correct or not.

Now we generate a long, random, cryptographically strong token. It must be cryptographically strong because the user may actually be an attacker and if he can guess how we generate tokens and can do the same, he will be able to reset passwords for arbitrary users. We generate the token, format it in a way that can be e-mailed (base64 encoding, hex, whatever) and store it in a database together with a timestamp and the origin (e-mail address). The same token is then e-mailed to the e-mail address of the user.

The user receives the token, comes to the website and goes to the form for token verification. Here he has to enter his e-mail address again, of course, the token, and the new password. In principle, some measure against the automated searches is in order here too, to lower the load on the server in case of an attack. The tokens are verified against our database and then the e-mail is checked too. If we see a token, we remove it from the database anyway, then we check if the e-mail matches and we continue only if it does. This way, tokens are single use: once we see a token, it is removed from the database and cannot be used again.

Tokens also expire. We must have a policy at our server that sets the expiration period. Let’s say, that is 24 hours. Before we do any look up in our token database, we perform a query that removes all tokens with a creation timestamp older than 24 hours ago. That way, any token that expires is gone from the database when we start looking.

Well, now, if the token matches and e-mail is correct, we can look up the user in our passwords database and update the password hash to the new value. Then, flush the authentication tokens and session identifiers for the user, forcing logout of all preexisting sessions. Simple.

Password recovery mechanisms – Part 2

Passwords remain the main means of authentication on the internet. People often forget their passwords and then they have to recover their access to the website services through some kind of mechanism. We try to make that so-called “password recovery” simple and automated, of course. There are several ways to do it, all of them but one are wrong. Let’s see how it is done.

If you did not read Part 1 – Secret questions, I recommend you do so before reading on.

Part 2 – Secondary channel

A second way to do recovery is to use a secondary channel for authentication. Once authenticated on this secondary channel, the password for the primary channel can be changed. The secondary channel may be slower and more cumbersome but since it is used rarely it is not a problem.

You could ask the person to call user support. The user support would ask some questions for personal information and compare the answers with what they have on file. That would effectively reduce the system to the “secret questions” described in Part 1. There are better (and cheaper) ways to do it.

Historically, the server usually stores the e-mail address of the user provided at registration. That is what becomes the secondary channel. Although it is still over the Internet, but capturing the e-mails on their way to the intended recipient is not a trivial task unless you control one of the nodes through which the e-mail would be routed.

Originally the passwords were stored in plaintext at the server and the user could request the password to be e-mailed. Some services still operate like that. The notorious Mailman list server e-mails you your plaintext password once a month in case you forgot it. That is a convenient way but has a bit of a security problem, of course. Should the password database be recovered by an attacker, all passwords to all accounts are immediately known. On the other hand, it has the advantage that user passwords are not really changed, so if someone requests a password reminder, the original subscriber will receive an e-mail and that’s all.

The inventive thought then went to the idea of hashing the passwords for storage, which is a great idea in itself and protects the passwords in case the database gets stolen. It has a side effect that suddenly the password is not known to the server anymore. Only the hash is. That is sufficient for the authentication but isn’t very helpful if you want to mail out a password reminder. So, someone had a bright idea that the password reminder should become a password reset. And what they did is: when a user requests, the server generates a new password, sends it to the user, and changes the hash in the database to the new password’s hash. All secure and … very prone to the denial of service attacks. Basically, anyone may now request a password reset for any users at will and that user’s password will get changed. Very annoying.

So we went further and decided that changing the password is not such a good idea. What we do then is make a separate database of single-use tokens. When a user requests a password change, we generate a unique random token, keep the token in the database and send it out to the user. If user did not request a token, the user need not react, the password was not changed and the token will harmlessly expire some time later. When the user needs a password change, he provides the token back to the service in a password change form (or through a clicked URL) and that allows us to perform this secondary authentication and then change the primary password. And that’s the way to do it.

There are variations where the secondary channel can be an SMS, an automated telephone call, or even an actual letter from the bank. But the important thing is that those messages only provide a token that verifies your identity on the secondary channel before allowing a security relevant operation on the primary channel.

Next, we will look at an example procedure for a website in Part 3.

Password recovery mechanisms – Part 1

Passwords remain the main means of authentication on the internet. People often forget their passwords and then they have to recover their access to the website services through some kind of mechanism. We try to make that so-called “password recovery” simple and automated, of course. There are several ways to do it, all of them but one are wrong. Let’s see how it is done.

Part 1 – Secret questions

A widespread mechanism is to use so-called “secret questions”. This probably originates with the banks and their telephone service where they ask you several questions to compare your knowledge of personal information with what they have on file. In the times before the internet this was a fair mechanism since coming up with all the personal information was a tough task that often required physically going there and rummaging through the garbage cans to find out things. Still, some determined attackers would do precisely that – dumpster diving – and could gain access to the bank accounts even in those times.

Right now this mechanism is, of course, total fallacy. The internet possesses so much information about you … It is hard to imagine that questions about your private life would remain a mystery to an attacker for long. Your birthday, your dog, your school and schoolmates, your spouse and your doctor – they are all there. It is hard to come up with a generic question that would be suitable to everyone and at the same time would not have the answer printed on your favorite social network page.

And even if it is not. Imagine that the secret question is “what’s your dog’s name?” How many dog names are there? Not as many as letter combinations in a password. And the most common dog names are probably only a handful. So it is by far much easier to brute force a security question than a password.

This mechanism of secret questions and answers is antiquated and should not be used.

There is a variation where you have to provide your own question and your own answer. This is not better. Most people will anyway tend to pick up the obvious questions. The attacker will see the question and can dig for information. The answer will usually be that one word that is easy to brute force. So, no good.

And, by the way, what should you do when you are presented with this folly on a website you use? Provide a strong password instead of the answer. Store that password in whichever way you store all the other recovery passwords. All other rules for password management apply.

So much for secret questions. In the next part, we will see how to do password recovery with a secondary channel.

Coverity reports on Open Source

Coverity is running a source code scan project started by U.S. Department of Homeland Security in 2006, a Net Security article reports. They published their report on quality defects recently pointing out some interesting facts.

Coverity is a lot into code quality but they also report security problems. On the other hand, any quality problem is easily a security problem under the right (or, rather, wrong) circumstances. So the report is interesting for its security implications.

The Open Source is notably better at handling quality than corporations. Apparently, the corporation can achieve the same level of quality as Open Source by going with Coverity tools. An interesting marketing twist, but, although the subject of Open Source superiority has been beaten to death, this deals the issue another blow.

Another interesting finding is that the corporations only get better at code quality after the size of the project goes beyond 1 million of lines of code. This is not so surprising and it is good to have some data backing up the idea that corporate coders are either not motivated or not professional to write good code without some formalization of the code production, testing and sign-off.

This is the necessary evil that hinders productivity at first but ensures an acceptable level of quality later.

Posts navigation

1 2 3 4 5 6 7 8 9