PhoneBoy’s Security Theater

When I was at the car dealer yesterday giving my car some service love, I hung out at the dealership while the repair was taking place. My dealer is pretty good--they give you a coupon (or two) for a free latte while you wait for your car to be serviced. They offer WiFi throughout their waiting area. They also have a "lounge" where you can either use one of the computers they have or use your own.

Despite the dealer having WiFi, I didn't use it. Why? Their system requires reauthenticating every two hours, which gets old when I know I am going to be there for at least twice that long. Instead, I decided to use my Sprint EVDO dongle.

Unfortunately, I spent a long time fighting with the Sprint Connection Manager software (version 1.10.0023.0) instead of working. When I tried to use it to connect, then started up my VPN to connect to the office, my EVDO connection would unceremoniously disconnect. I don't remember my Verizon card ever doing this.

I eventually figured out how to get this combination working. The hint is in the graphic here. Sprint's software--and presumably Verizon's software--are simply front ends for the standard Windows dial-up networking. Sprint's software also has this NDIS mode in it--make sure it's set to RAS before you do this trick.

In Check Point Secure Client (which us old-timers still call SecuRemote), I told it to use a Dial-up connection, which shows up in the Connection window. In my case, I ticked the Use Dial-up option and used the connection called CDMA. There was another one called 3G Connection that I didn't try. After this, Secure Client properly brought up the EVDO connection and started my VPN. The connection didn't drop once and worked reliably for the rest of the time I was at the dealer.

I left the Sprint Connection Manager software running, but I don't believe it was necessary. It continued to show me signal strength and the like, but I did not see any details about how much data I was sending and receiving. That's ok, just as long as my EVDO worked.

Sue Walsh over at IGotSpam (one of the CW blogs I occasionally write for) notes that another "worm" has hit Nokia phones. From the list, it appears she is talking about S60 2nd Edition handsets and not ones based on the more recent, more secure, S60 3rd Edition.

This is a problem for any highly successful device or computer manufacturer: people will continue to use the devices well past their expiration date. They may not know--or even care--about "flaws" like these worms. Even though Nokia has addressed the issue going forward, there's little that can be done for those legacy handsets other than replacement.  Hopefully that will happen over time.

I know that fingerprints are not exactly foolproof methods of authentication because they are fairly easy to spoof. 

Bottom line, folks: if you want to be safe, you need to rely on more than one factor of authentication.

If you do anything more than passively read web pages online, chances are, you've got an identity somewhere. You have an email address (or 10). You have a login on most every site you interact with (e.g. Google, eBay, Facebook). If you use IM tools, surely you've got a name on each of those services.

Even in the offline world, you have lots of identities, depending on whom you're talking with: an identification number, social security number, multiple phone numbers, and the list goes on.

Actually, let's be clear. These aren't identities per-se, they are tokens that uniquely identify you within a specific realm. Let's call them identity tokens for the sake of argument.

Ideally, I'd like to reduce the number of identity tokens I have to manage. I'll save Aswath the trouble of commenting on my post and just say what one solution to that would be: OpenID. It has potential to solve this problem, but it's not deployed widely enough.

But let's make this problem simpler. Let's talk about identity tokens within a single "realm," or multiple realms controlled by the same company, as it were. Best example of that? Jangl.

Jangl provides their "call anyone, anywhere" service through partnerships with a number of different social networks--including Facebook--not to mention their own web portal. Each one of these social networks is a separate realm under which Jangl operates. If Jangl's Facebook application is any indication of how it works in other social networks, Jangl makes it easy to call your buddies/friends within the social network.

Herein lies the rub. What if I am a member of multiple social networks that the Jangl service is using, or what if I want to use, say, Facebook and Jangl's own web portal? The two identities are treated as different. The main problem? I can't associate the same mobile number to both the Facebook and Jangl account. The main reason? The Facebook and Jangl portal "identities" are treated as different when, in fact, they point to the same person--me.

Federating these disparate identities within Jangl should be relatively straightforward, or you'd think anyway. I discussed this issue with their support folks and they have a solution to this problem. Essentially all the "accounts" have one thing in common: your mobile phone number. In theory, you should be able to use the same number across all these accounts provided you can provide the associated PIN.

This doesn't completely work in an ideal fashion, yet. Those of us who are early adopters are likely to have extra problems. As I write this, the Jangl support guys are trying to get my Facebook and Jangl.com accounts linked.

Given all the problems I'm having within the same company, now imagine having to do this between companies or between organizations. You can see it gets ugly fast.

OpenID would certainly be one solution to this problem: allow an account to be associated to an OpenID. Accounts that are associated to the same OpenID--with appropriate authentication, of course--could be linked somehow. Or simply use OpenID as the authorization mechanism and drop the realm-specific authentication schemes altogether.

That being said, there are times--and instances--where I don't necessarily want to be tied back to a single identity. Maybe I'm doing some testing or doing some "stealth" intelligence gathering. OpenID shouldn't be the only option.

What do you think about all this? How can we federate identities while maintaining the ability to have separate ones if you desire? Opinions are welcome.

There's an interesting thread over on Slashdot about parental controls on PCs. Obviously, the crowd on Slashdot is a bit more technical than your average parents. Good thing, as I am in that crowd.

Parental Controls are often seen as a substitute for good parenting. They aren't. Because the kids will eventually find a way to subvert it. That being said, you can do a few things to make it a bit more difficult.

Here's what I do on my family computers, which are all running Windows XP:

Computers In Public Rooms: The kids activities can easily be monitored by good old fashioned parental oversight--the most effective form of parental control.

Limited Accounts: The children use Limited Accounts in XP. This has all kinds of interesting benefits:

• Some Flash games require third-party add-ons, which only I (with full Admin rights) can install. Gives me a chance to check out the games before they play them
• Applications can't be installed. It doesn't prevent you from running a self-contained EXE, but those are rare.
• If any rogue software does run, the damage it can do is much more limited thanks to the limited permissions.

Windows Update: It runs in full automatic mode. The computers often get left on so they have a chance to download and install whatever patches Microsoft throws us.

AntiVirus: It's always a good idea to have AntiVirus loaded. I've settled on the free version of Avast.

Web Filtering: At the moment, the web filter is meant to prevent my young children (3 and 7) from accidentally stumbling onto something they shouldn't see. They may bump into it more and more as they get older. The one I'm using? K9 Web Protection from Blue Coat. It's free and relatively noninvasive. If you hit an objectionable site, your browser prevents you from accessing it but gives you the chance to provide the override password.

At some point in the future, I may start monitoring--but not restricting--other network activities. However, that's going to require some planning.

What things do to you do to protect your kids online?

A couple of people I know got signed up for Quechup. My address was apparently "harvested" from the address book of these folks and I've been invited--multiple times, even--to join this service.

I've looked through this service and I see absolutely no reason to join this place. It looks like a lame me-too service with no obvious value. The fact they want an address book is very irritating. Given the relative intelligence on the Internet with regard to these matters, I suspect I will see a lot of spam related to Quechup. Even people who do know better occasionally get sucked in.

Bottom line: avoid these twits like the plague.

As a guy who has made a living in the network security business, and is really unhappy with the state of security on the Internet, I like to see proper security in the hands of real people.

The PayPal Security Key is exactly that. This key adds a second factor to the authentication process for your PayPal account. Instead of just relying on a fixed password to log into your PayPal account, you append a constantly changing passcode to it provided by the PayPal Security Key.

The PayPal Security Key is actually an RSA SecurID token. SecurID tokens are used by corporations everywhere to provide strong authentication to end users. I have to use my SecurID token a couple of times a day to keep my VPN connection to the office alive.

SecurID uses a hardware token with a value that changes every minute or so. The card is synchronized with a server, which validates the authentication attempt. So long as you do not lose this card, your authentication will be secure.

SecurID tokens come in a number of different shapes and sizes. The PayPal Security Key actually fits on your keyring. The one I use for work is about the shape of a credit card. It also contains a keypad on which I enter my own PIN, which hashes the PIN to a different value. The great thing is that the people that maintain the SecurID server don't even need to know my PIN. It just works. ;)

What is a Cross-Site Request Forgery? Quoting from the Cross-Site Request Forgery FAQ:

Cross Site Request Forgery (also known as XSRF, CSRF, and Cross Site Reference Forgery) works by exploiting the trust that a site has for the user. Site tasks are usually linked to specific urls (Example: http://site/stocks?buy=100&stock=ebay) allowing specific actions to be performed when requested. If a user is logged into the site and an attacker tricks their browser into making a request to one of these task urls, then the task is performed and logged as the logged in user. Typically an attacker will embed malicious HTML or JavaScript code into an email or website to request a specific 'task url' which executes without the users knowledge, either directly or by utilizing a Cross-site Scripting Flaw. Injection via light markup languages such as BBCode is also entirely possible. These sorts of attacks are fairly difficult to detect potentially leaving a user debating with the website/company as to whether or not the stocks bought the day before was initiated by the user after the price plummeted.

The bottom line: if you visit a malicious web site and you are authenticated with a "trusted" web site, the malicious web site can essentially impersonate you, assuming you are already logged into the site or you are using an easily guessable password, for example the default password on your Linksys router. How does this happen? This attack stems from the fact that within a typical web browser program, any web session can easily access any other session or simply spawn a new one. For example, if in Firefox you were browsing a malicious site and also maintaining your MySpace page, the malicious site could perform actions on MySpace as if you did them.

Some more examples of things that Cross-Site Request Forgery can accomplish:

• Reconfigure your Linksys router to permit an attacker to reach your PC.
• Submit a bid on your behalf for an item on eBay.
• Post a message "as you" on a particular forum site, your MySpace page, or whatever.

The attacks go beyond just web sites, as I alluded to with the Linksys router comment. Just about every piece of residential or commercial networking gear has some kind of web interface associated with it. Accessing a carefully crafted malicious website in the right environment could lead to opening your entire network up to hackers. And they are coming in through a "trusted" service: HTTP.

There are steps web sites and web interfaces for networking equipment can do. Most of them relate to correcting cross-site scripting (XSS) issues in the web interface. The web browser may have its own XSS issues, further exacerbating the problem. While it's good to fix these issues, there's no promise those issues won't show up again later. There are a few other countermeasures, but these countermeasures can likely be defeated by other exploits. The end result is that, at least with the current browser architecture, there is little that can be done to eliminate these kinds of attacks.

There are several things you can do to reduce the risk from these attacks affecting you. They include, but are not limited to:

• Not caching your login passwords in the browser.
• If possible, set a 5 minute (or thereabouts) inactivity timer on your sensitive web sessions.
• Running the web interface for your device on a non-standard port.
• Explicitly logging out of the session on the web page in question.

The safest option is to use a completely different web browser program to administer your sensitive web pages and site than you use to browse the Internet. For example, if you use Internet Explorer to browse the Internet, use Firefox to administer your routers. Do not use Internet Explorer along with other Internet Explorer-based browsers as they may all share the same session information.

If you're a Firefox user, another thing you can download is a copy of NoScript.  NoScript disabled JavaScript for web sites you don't explicitly trust. In addition, NoScript has a number of XSS-related checks in it to thwart XSS-related attacks on well-known websites.

Here is the email from (ISC)2:

Candidate Id: xxxxxx

This is to advise you that your documents have been processed in the system as of today.

We are now printing certificates every day, therefore your certificate should be printed within a day following processing.

Your package will be mailed out within a couple days after the certificate is printed. Stateside delivery usually takes 10 days to 2 weeks; overseas delivery is 4-6 weeks.

Your official designation date will be the date your certificate is printed. You may NOT use the designation until your certificate is printed.

If you do not receive your package within your specified time frame, please contact [address deleted] as she handles the certificate printing and mailings.

(ISC)² Services

Do I have to wait until I receive my certificate or can I call myself a CISSP tomorrow or the next day? ;)

Today I got word that I passed my CISSP exam. The next phase in the process is getting endorsed by another CISSP. Currently, they also permit being endorsed by holders of other, related credentials, though on 1 October 2007, that will no longer be allowed. Since I'm in the Nokia office this week and one of my co-workers is a CISSP, getting him to fill out the endorsement form and email it along with my resume back to ISC2 was not a big deal.

In theory, I should be a CISSP in the next few weeks.