Archive for the ‘Security’ Category

16 Bytes

Tuesday, May 8th, 2007

16 bytes seems like a pretty short number. That's only 128 bits. It doesn't take long to write them down. You could even memorize them if you try.

16 bytes is the length of a Globally Unique IDentifier (GUID). Here's one I just generated: "{37B317CC-6036-4037-8E26-0A239103BC2B}". This GUID has never been generated by any computer at any time in history, and will never be generated again.

I can use this arbitrary number to represent anything I want. I can say this is the ID of a new COM interface I design, or a new ActiveX control I author. I can use this as the primary key of a new row I add to a database table. Since it is globally unique, there is no chance of collision if I merge with another database.

There areĀ  3.4 x 10^38 possible 16 byte numbers. They are more rare that they originally seem.

Your social security number is 9 decimal digits. There are only 1 billion of those. It's a much shorter number.

16 bytes can be a trade secret.

I Fixed Security Now!

Wednesday, April 18th, 2007

I have edited the offending comment attached to Security Now! Episode 86. Even though the last half of the comment was hidden from view inside of a <script> tag, I discovered that I could extract the "edit" link from the page source.

For the full story, go back a couple of posts or listen to the Adventures in Software podcast, episode 22.

Again, my appologies to Steve and Leo for accidentally hacking their site. Fortunately, no permanent damage was done.

AiS 22: Website Attacks

Tuesday, April 17th, 2007

Listen Now

Cross site scripting and SQL injection attacks both take advantage of vulnerabilities in websites. In the case of a cross site scripting vulnerability, data can be rendered to the browser, causing it to run unintended code. In the case of a SQL injection attack, data is executed by the database as SQL code. In both cases, input that a malicious user provides is interpreted in a way that the designer did not intend.

Both of these vulnerabilities are software defects. In both cases, data in a natural language is rendered as if it were a programming language. Web developers and designers need to take extra precautions to prevent this from happening. But what are the right precautions?

One solution is to validate all inputs to ensure that no script or SQL code is included. Unfortunately, this approach is nearly impossible to implement correctly. Any inconsistencies between the way the validator parses the input and the way the browser or database interprets it can leave a hole for a hacker to slip through. Furthermore, it may be perfectly valid for the data to contain HTML or SQL code. What if you are running a blog about software? Shouldn't you be able to post code to the blog?

A better solution is to escape the data. If you are converting a natural language string into SQL, you have to be sure to escape the quotes. In HTML, you must escape the angle brackets. Several tools are already at your disposal to perform the escaping function. Please take full advantage of them.

http://www.bitlbee.org
http://toc2rta.com
http://jakarta.apache.org/commons/lang
http://jakarta.apache.org/commons/codec
http://www.unixwiz.net/techtips/sql-injection.html

Oops! I broke Security Now!

Friday, April 13th, 2007

I listen to Leo Leporte and Steve Gibson talk about Internet security on the weekly podcast Security Now. I just posted a comment on the show about cross-site scripting attacks. I didn't realize that I was attacking the site myself!

My comment was this:

Validating user input, while a good idea, is not the fix for CSS attacks. As Steve pointed out, it is nearly impossible to accurately detect script in the input.

The fact is, the CSS vulnerability is a defect in the output of a system, not the input. If I tell a web site that my name is "<script>", it should reply "Hello, <script>!". The way you say this in HTML is "Hello, &lt;script&gt;!".

If web developers simply escaped their output, the problem would be solved.

When the site served this comment back, it failed to escape the word "<script>". As a result, the remainder of this comment and all comments that followed were hidden.

I posted the comment a second time, this time escaping it myself on the way in. Hopefully someone can go back into the database and delete the first one.

Sorry Steve!

Is Gemalto’s NIM Secure?

Sunday, March 4th, 2007

In my two most recent security posts, I talked about USB key solutions to Internet security. A comment from Schlum led me to contact Gemalto about a USB product that they promise will make your on-line experience secure. Their YouTube video doesn't give enough information to make any sort of recommendation, so I sent them an email. I asked what differentiates their product from the True Crypt/Portable Firefox key that I carry. Here is their reply:

Hi,

Thank you for your email.
The TrueCrypt seems to be a portable Password wallet and is primarily aimed at user convenience and not security.

The NIM is for now a issuer deployed (by your bank, or stock trading portal or any issuer who needs to make sure that the users are securely logging into their portals and can mutually authenticate them).

There can be multiple issuers who could use the same device avoiding a necklace of devices effect.

The key difference between a password wallet and the NIM is that the NIM is not prone to man-in-the--middle or phishing attacks

I hope that they make a deal with my bank soon, so I can truly evaluate this product. But until then, I don't have any specific information to go by. So I can only make the following general precautionary statements.

Do not use your True Crypt or any other USB key on an untrusted computer. Any USB key that does not have its own processor is no more secure than a floppy disk. Any program on the host computer can read and write data on the USB key. If you mount an encrypted drive, then it becomes clearly visible to any program on that machine. And if you have to enter a password, like you do for True Crypt, then a key logger can steal the password. Just like Gemalto says, the True Crypt/Portable Firefox USB key is for convenience, not for security on unknown systems.

Any device that lacks a processor to perform encryption and decryption must share the key with the host. If the host is compromised, then the key can be stolen. Similarly, any device that lacks a keypad must collect the password from the host. If that host is compromised, the password can be lifted.

Just remember when using any USB solution: the computer sits between you and your key. A man-in-the-middle attack doesn't have to come from outside the system.

What’s Wrong with Passwords

Thursday, February 15th, 2007

We all have experienced the main problem with passwords on the net today: every site we visit demands that we create one. To be secure, we have to generate a different password for each site. To stay sane, we have to find some way to avoid memorizing them all. My last post provided a secure solution to that problem, but the password system is still flawed.

After the multiple password problem, the next big dilemma is phishing. A nice side-effect of using a secure password cache like a TrueCrypt/Portable Firefox key is that the cache is not fooled by phishing attacks. An attacker cannot fake an SSL URL, so Firefox will not enter your password for you. Since you have created a separate password for each site (you did, right?), and since you haven't memorized any of them, you can't enter your own password yourself. But most people don't go through the trouble of creating a secure portable password cache, so they might still fall for it.

The latest trend is to use SiteKeys to prove that the web site is who they say they are. When you sign up for your on-line banking account, you choose a picture from their list. An attacker wouldn't know which picture you chose, so they can't display the SiteKey to you during a phishing attack. So you only enter your password if you see the key.

That's the theory, anyway. According to one study, many people don't understand the SiteKey idea, and will enter passwords even without that visual verification. But even if people were well-behaved, SiteKey is vulnerable to a man-in-the-middle attack.

In order for the bank you know which SiteKey to show you, you musts first enter your username. So suppose a phisher duplicated this UI and collected your username first. They could then forward your username to the bank and scrape your SiteKey off of their login page. They display it to you, you enter your password, and they have access to your account.

The crux of the problem is that both SiteKeys and passwords are shared secrets. Both parties know the secrets fully. It's like the secret code phrases that fictional spys use to authenticate one another. But if both parties know the secrets, then a middle-man can listen in as they exchange them. The best solution is a private key system.

SSL is not vulnerable to man-in-the-middle attacks because the host site has a private key that it does not share with anyone else. To verify the correctness of the key, a visitor obtains the matching public key from a trusted third party. A random challenge is encrypted with the public key, and only the holder of the private key can decrypt it. So if there were a man-in-the-middle, he could not correctly respond to the challenge.

The only way this can work is to be able to prove that you have the private key without showing it. If we were to apply this to humans, that means that we would have to memorize a large number and do math in our heads in order to securely log into a website. Talk about loosing your sanity.

The next best thing is to have a device that stores the private key AND performs the calculations on your behalf. If the device just stores the key, then an attacker could get in between the calculator and the device in order to steal the key. That is the weakness of the TrueCrypt/Portable Firefox solution: if you put your thumb drive into an untrusted computer, it could be using a key logger to get your TrueCrypt password. Or it could be reading the encrypted volume after it has been mounted.

Here's my solution
I want a USB device with three things: memory to store private keys, a processor to run encryption algorithms, and a key pad to capture my (one and only) password. If I had this device, I would be confident that no one could get in the middle to steal my identity. It could establish SSL connections to all of my websites so that nothing running on the host computer could spy on sensitive data. Of course, the host computer has to be able to render the web page, but a well-designed page is not going to expose private information.

Put your Passwords in your Pocket

Thursday, February 8th, 2007

If you sign on to a new website at work, you can ask your browser to remember the password. But that doesn't do you any good when you get home. And, that password is available and visible to anyone else who logs on to your work machine. Fortunately, you can secure your password cache and take it with you.

First you will need to get a USB thumb drive. You don't need a "secure key", since you will be adding the security software yourself. A large drive is not necessary either. I use a 32 MB drive that I got from the impulse lane of the grocery store, though it is a tight fit.

Second, download TrueCrypt. You don't even need to install the software on your PC. Just open the zip file and run TrueCrypt.exe from the "Setup Files" folder. Click "Create Volume", "Create a standard TrueCrypt volume", Next. Assuming your USB drive is "D:", enter "D:\portable.tc" and click "Next". Choose your encryption and hashing algorithms (I like AES and SHA-1) and hit "Next". Enter a volume size saving at least 1 MB for TrueCrypt (so my 32 MB jump drive has a 31 MB volume on it) and hit "Next". Now enter and confirm a password and hit "Next". (Do not use keyfiles for this procedure, and do not click "display password".) Now move your mouse over the dialog a few times to seed the random pool and hit "Format". When it's done, hit "Exit".

Third, install TrueCrypt on the USB drive. You should be back to the TrueCrypt window, so open the "Tools" menu and choose "Traveler Disk Setup". Again assuming your jump drive is on "D:", enter the root drive "D:". Uncheck "Include TrueCrypt Volume Creation Wizard" to keep TrueCrypt under 1 MB. Choose the option "Auto-mount TrueCrypt volume (specified below)". Then enter "portable.tc" without the drive letter or slash. Then click "Create", click "OK" on the popup, then click "Cancel" to close the traveler disk setup wizard.

Fourth, mount the encrypted volume. The easiest way to do this is to safely remove the USB drive (first using the "Safely Remove Hardware" icon in the system tray) and reinsert it. Alternatively, you can open "My Computer", right click on the drive, and select "TrueCrypt Mount". You will be prompted for your password.

Fifth, install Portable Firefox on the encrypted volume. Download the installer to your hard drive, run it, and enter the drive letter of the mounted encrypted volume (for example "E:").

For convenience, you may want to create a batch file on the root of your encrypted volume. Create a file called "Firefox.bat" containing the line "FirefoxPortable\FirefoxPortable.exe". Since you don't know what drive letter will be assigned, you have to use a batch file instead of a shortcut. This will allow you to double-click the batch file once you mount the drive, instead of drilling into the folder to double-click the exe.

To unmount the drive, right-click on the USB drive in My Computer ("D:" in this example, not "E:") and select "TrueCrypt Dismount All". Then use the system icon to safely remove the drive.

Now launch Firefox and start browsing. Go ahead and tell Firefox to remember all your passwords, safe in the knowledge that they are being cached to an encrypted volume. Take it with you to log in from any machine. You will leave no traces behind, and if your USB drive is lost or stolen no one can use it to get to your passwords.

Alternative to Role-Based Security

Thursday, November 2nd, 2006

The ideas of users and roles are pervasive. Just about every OS includes the idea of a user who logs in and is a member of some role. And many types of web sites -- blogs, message boards, and wikis for example -- organize their registered users into roles like administrator, editor, author, and guest.

In this type of system, resource permissions are usually doled out not to individual users, but to all users in a role. All members of a role tend to perform the same types of actions to several resources. Authors create articles, editors modify them, and guests read them. Role-based security is a simple metaphor for permitting people to do the jobs that they want to do.

As pervasive as this metaphor is, we often forget that it is not the only option. Indeed, it is not even the best option. Role-based security has several flaws that make it inconvenient, and ultimately insecure.

The first weakness of role-based security is the root, or administrator. Someone has to define the roles, assign them permissions, and populate them with users. Even if this person doesn't have direct access to all resources in the system, he can easily create another user account for himself that does. It is impossible to keep secrets from Root.

The second weakness is coarse granularity. When a permission for a resource is granted to a role, all users in that role inherit that permission. But you might want to subdivide your editors and authors into teams, giving each team's editors permission to modify articles created by their own team's authors. You could create finer roles to account for this, but doing so requires administrator intervention.

Which brings us to the third weakness: the admin bottleneck. Any significant change requires an administrator. Administrators are busy people, and work should not stop while we wait for them to create new roles and assign new permissions. The people doing the work should be able to organize themselves and their resources on their own, independent of other groups.

The fourth weakness is centralization. The administrator represents one authority. All users and all roles are derived from this authority. It is difficult to merge two organizations that have different roots, as all users, roles, and resources must be merged into one of the two central authorities. LDAP directory services perform this operation, but they are difficult to set up and administer.

The fifth flaw is that the administrator controls identity. In order to gain access to the system, a person needs to go to the administrator to obtain a user account. The admin assigns them to a role and issues a name and password. For that brief period, both the user and root know the password. Furthermore, root has the authority to change the user's password or revoke the account at any time.

These flaws add up to a system that is inconvenient and insecure. The lack of convenience comes from the bottleneck of administration and the difficulty of merging. The insecurity comes from the all-powerful root, who has access to data and identities that he does not own.

Here's my solution

The alternative is so simple and powerful that I'm surprised to see how infrequently it is implemented. Just put the power in the hands of the users who create the resources. When people control their own identity and their own resources, the omnipotent root becomes obsolete.

The scenario is as follows. A person -- call him Jim -- approaches a system for the first time and creates his own user account. Jim only shares his password with the system, not with an admin. This new user account only has permissions to create new resources. No one has access to these new resources other than Jim. No one.

Then another person -- Helen -- establishes a user account in the same way. She and Jim want to work together, so she identifies herself to Jim both in-band (by giving him her user name) and out-of-band (by verifying that user name on the phone or face-to-face). Jim then assigns Helen permission to access the resource he created.

Now suppose Daniel and John want to join the team. Either Jim or Helen can give them access to the resource. But instead they decide to create a group. John creates the group and invites the others to join (again both in-band and out-of-band). Then Helen gives that group access to the resource. They can now create more resources under the umbrella of that group.

If Jim leaves the team, any remaining member can remove him from the group. Now he no longer has access to the resources controlled by the group, including the one that he started the whole project with. The team can organize themselves, authenticate their members, and control their resources without giving up any control to an administrator.

The solution in practice

Multi-user blog sites go part of the way toward this solution. You can go to blogspot.com and create an account without contacting an administrator. Then you create your own blog to which you alone can post. But everyone has read access to your resource. After all, it is a blog.

Google Docs and Spreadsheets goes a little further by allowing you to grant other users access to your resources. But you still can't create groups to manage permissions for entire teams.

By far the best implementation of this idea is Groove, a peer-to-peer collaborative workspace acquired by Microsoft. Anyone can create a new space, invite anyone they want into that space, and maintain control over the resources therein. The space itself acts like a group, associating individual users with the resources that they control. Any member can invite others to the space, though last I looked you cannot revoke someone else's membership.

But there is nothing special about peer-to-peer. You can implement this idea on the web. Think about it next time you are setting up a collaborative site.