Fight Back Against Pseudo-Security

09.11.2012 13:27 by kbeckman | Comments

At least some of your online personal and financial information is AT RISK RIGHT NOW. Some of your information might already be compromised… Even worse, some of the companies hosting your information may not even know that a breach has occurred. And worst of all, your personal information might be IS in the hands of companies with  bullshit security practices.  Online security breaches are an increasingly common occurrence… Back in June, LinkedIn was hacked and 6 million of its users’ passwords were posted online – mine was one that was stolen… A month or so later, Yahoo! was hacked and 400,000 user accounts were compromised. Today, well-known hosting service and DNS registrar – GoDaddy – was hacked and the number of affected sites is in the millions. Although a leak of passwords or personal information may or may not have been part of the breach… Folks, those are just the major instances this summer.

 

Amidst all the web chaos today, I became aware of the half-assed, don’t-give-a-shit security considerations of my former web hosting vendor – Arvixe. Here are the details…

 

Arvixe Billing Users Beware!!!

Until a couple of weeks ago, coding4streetcred.com was hosted through web hosting vendor, Arvixe.  The hosting arrangement was extremely vanilla – just a single server configuration sharing an IIS instance with who-knows-how-many other sites. Arvixe’s pricing was reasonable and the initial setup was incredibly easy. In the two years coding4streetcred.com resided on their servers, I only had a couple of issues with the IIS integration of Microsoft’s WebDeploy utility (probably only because WebDeploy wasn’t a mature product yet). Their support team was awesome and I always got a quick and relevant response. Despite my satisfaction with Arvixe, I recently decided to move my site to Amazon’s Elastic Compute Cloud for a couple of reasons: a) Amazon’s free usage tier; and b) I wanted more experience with Amazon’s Web Services platform for my current and upcoming development contracts.

 

All in all, my experience with Arvixe was good until today when I received the following email from their support team as I attempted to close out my account…

Hello Keith,
I am sorry to hear that you have moved your hosting services to another provider. I can close your account [account name removed] for you, effective immediately. I'll just need you to confirm your identity by providing the last 4 characters of your billing password. If you need to reset your password, please go to [link removed].

ARE YOU SHITTING ME?! PROVIDE THE LAST 4 CHARACTERS OF MY PASSWORD?! For the first time in the history of my Internet usage, a company has asked me to verify my identity by providing details of my actual account password… Unbelievable! After I politely replied via email and tweeted about my disgust with their plain text password storage, I got the following response via Twitter (full conversation is included).

image  image

I finally reset my password to finish the account termination only to find that Arvixe actually sends plain text reset passwords through email! This was another first for me – plain text passwords through email… If you use Arvixe, STOP USING THEM IMMEDIATELY.

 

Why Would This Be a Problem?

Any time you find that all or part of your password information is stored in plain text, IT IS A BIG PROBLEM. The cryptographic details are outside the scope of this post, but I’ll tell you this…

  • Passwords stored in plain text are accessible by anyone (in this case Arvixe employees) who has access to the system database.
  • Passwords stored in plain text are available in plain text to anyone who compromises or hacks that system.
  • Passwords stored in partial plain text can provide enough information to hackers to break the encryption cipher used encrypt the rest of your password. 
  • Passwords sent via email in plain text are only as secure as your email provider’s security. Passwords should never be sent via email – NEVER. An appropriate approach is to send a secure link that allows you to reset your password through some application utility.

It’s no joke… Even worse, this concerned Arvixe’s billing system – the same system that is capable of storing credit card information allowing you to automatically renew your hosting account as needed. Thank goodness they didn’t have any of my credit card information stored. At least not to my knowledge anyway.

 

The Minimum You Should Be Doing to Protect Yourself

The sad truth here is that there are droves of clever hackers out there that can and will break into a system where your account information is stored. The companies hosting your information won’t be able to stop them every time… Fortunately, there are a few things you can do to limit your attack surface… I’ve listed them below in order of what I think are most important.

  • Use a different password for every online account. This sounds a lot more difficult than it actually is… There are several good password management services out there for free or a small fee that can help you with this. I use LastPass. It integrates with every browser and they have mobile apps so you can use them on your Android or iOS devices. A different password for every account minimizes the effect on other accounts if one is ever breached.
  • Don’t store credit card details online. Most sites don’t require you to store credit card details. The exceptions would be those sites that require it for recurring charges… Only do it when or if you have to.
  • Max out your password strength. Every site has different rules regarding password strength (i.e. password length, upper/lower case character requirements, special characters, etc.). Use the longest password with the most numbers, special characters and combination of upper/lower case characters that the site will allow.
  • Be wary of passwords in plain text. If you ever find that your account provider stores passwords in plain text (or even part of your password), terminate your account immediately. The same goes for account providers that send passwords in plain text via email.
  • Make half-assed security practices public. Tweet it. Blog about it. Tell your friends. Other people need to know too… With a little exposure to bad press, companies might actually make it a priority to change their ways.
  • Always be vigilant about your personal details. Your financial stability, credit score, free time and countless other details of your life depend on it…

 

In Closing…

Cyber security is nothing to ignore. If your personal or financial information is online, it is at risk somewhere. There are countless ways your information can get into malicious hands. Unfortunately, it is just an ugly detail of Internet usage. Do everything you can to protect yourself… Stay safe out there.

Getting Up-to-Speed with WS-Federation and WS-Trust

09.04.2012 12:58 by kbeckman | Comments

As part of a recent client request, I’ve been asked to provide a list of resources that an organization can use to become familiar with the technologies and protocols behind enterprise Single Sign-On (SSO) and Federated Identity. Single Sign-On between enterprises is a difficult topic, especially when you get to scenarios beyond the initial user authentication. Trust me, there’s a lot more to think about organizationally than just accepting authenticated users from other security domains. The topic of Federated Identity forces organizations to think of users in terms of a global identity rather than a single account in some enterprise application. Users from the local security domain may or may not be treated differently than users from trusted partners. Application authorization rules may differ based on where your user actually authenticated…

 

The protocols at the core of enterprise SSO are WS-Federation and WS-Trust. At a high-level, WS-Federation defines the transport mechanism for security tokens and WS-Trust defines the procedures for signing, encrypting, validating and renewing authentication tokens. Another popular protocol is SAML 2.0 / SAML-P. [Sorry for the Wikipedia links… I have a better list of resources shortly.] Without getting into the details, there are a lot of functional similarities between WS-Fed and SAML-P… However, the differences are painful enough that we’re going to leave the SAML story for another day (or hopefully never).

 

Microsoft’s implementation of WS-Federation comes in the form of Windows Identity Foundation (WIF) – a subset of the .NET Framework that contains the types and classes for managing identity. Once a standalone extension to the .NET Framework, WIF is now included in the mscorlib. Below are some valuable resources to help you get started with WS-Federation, WS-Trust and WIF.

 

For Business Folks [and Developers Before They Start Developing]…

  • Understanding WS-Federation – This is an MSDN article from back in 2007 (pre-WIF) that describes WS-Federation and it’s sub-protocols (WS-Trust, WS-Security, WS-SecurityPolicy). Brace yourself… The article leads off with a copyright notice and never really recovers.
  • A Guide to Claims-Based Identity and Access Control, 2nd Edition – In my opinion, this is the best resource for explaining SSO and Federated Identity across enterprises. With each chapter, the authors setup an enterprise scenario and explain the interactions required by participating organizations to accomplish SSO. More importantly though, this book goes into detail to explain the business problems solved by SSO implementations. Developers will get a lot from this too as it touches on all of the Microsoft technology offerings that are either necessary or helpful in pulling off SSO – ASP.NET, WIF, Active Directory Federation Services 2.0, and Windows Azure Access Control Service.

For Developers…

 

For ‘Only the Lonely’

If you haven’t gotten your fill from the resources above, you can always take a look at the official OASIS protocol specs. Although I don’t advise this unless you’re working on your own framework or plug-in, etc.