Random Password Generator Tool

Sure, there are lots of random password generators out there, but how many of them are integrated with our very feature-rich open source code repository of tools that will help you to code against Active Directory, while also standing alone as a simple quick to use tool for a helpdesk?

Yeah, that's right, only 1 random password generator tool does that.  Get it and its open source code now: https://github.com/Securology/ActiveDirectoryServices/tree/master/PasswordGenerator

Coding for Active Directory: Quickly import Exchange Rooms or Resources

Do you have a copy of Visual Studio, a very rudimentary knowledge of C# .NET, and a need to import a list of Exchange Rooms or Resources into your Active Directory?

If so, check out a couple very simple example apps that can import .CSV files to knock out this frequent task:

https://github.com/Securology/ActiveDirectoryServices

Coding for Active Directory: Programmatically Get or Set Obscure Attribute Data in C#

If you are an organization of any size, chances are you have an Active Directory instance sitting around, and maybe some level of additional investment in Microsoft products beyond Windows on client machines and a couple servers.  And the more investment you have, the more value you will get from having relevant data in your Active Directory.  You may even have some developers on staff that write applications in C# or VB .NET.  Chances are, though, your developers won't understand or even want to understand Active Directory.

They may, however, be able and willing to code to a few random source code examples that float around on the web, but most examples are not very feature complete.  So it requires developers digging into the musty underbelly layers of Active Directory to learn how to get what they need.  Few will dig.

You could purchase an API, but the licenses may be expensive, and you may only want to read or set a couple of attributes on a user or group object that nobody else seems to have documented how to do well enough to satisfy your developers.

Or you could just send your developers to the new Securology GitHub repository to pull down a fully-functional, open source, non-restrictively licensed API to include in their projects to get up and going.

Maybe you just dealt with a large scale AD migration and you need to peel back the layers and extract user or group SIDs (Security Identifiers) or validate that SIDs from previous domains on imported objects are properly stored in the SID History?

Maybe you have a basic interface with your HR system, but don't want to shell out tons of cash to purchase a metadirectory tool like Identity Lifecycle Manager to move HR data like manager/reporting relationships around, but could really benefit from having that data in your Exchange, SharePoint or other application environments.

Maybe you need to set the user's employee number from your HR system on each AD user to identify the authoritative data source to satisfy an Active Directory Audit.

Maybe you just want to read or write the AD user's address, telephone, or even IP Phone number.

Maybe you have a mixed environment that also contains Unix servers and you need to set Unix attributes on the IT Unix Admin user accounts for a Unix SSO to AD product that you're using.

Maybe you'd like to programmatically setup Microsoft Exchange or Lync (Office Communicator) attributes?

Maybe you'd like a safer way to programmatically move or delete Active Directory objects?

Maybe you'd like an easier way to programmatically add or remove a user from an AD group?  Or maybe check if they already are in that group?

Maybe you'd like to populate your AD with Contact objects for business partners who don't need user accounts in your domain or forest, but so that they'll still show up in the Global Address List (GAL)?

Maybe you need a way to programmatically create an Organizational Unit (OU)?

Maybe you'd like to toggle an AD group from "Security" to "Distribution" and back again?  Or "domain local" to "universal"?  Or dump all of its members?  Or check if the AD group has no members?  Or set the "owner" of the group for audit/management purposes?

Maybe you'd like to prune back old computer objects?  Or build a report to show what Operating Systems are in your directory?  Or safely move or delete computer objects?

Maybe you'd like a way to expose the True Last Logon time of a user account without manually checking each Domain Controller and comparing times?  Or maybe you'd like a nice multi-threaded (and fast!) way of checking all Domain Controllers simultaneously?

If any of those are even remotely interesting to you, check out our extended version of Microsoft's System.DirectoryServices.AccountManagement namespace that we provide on GitHub.

Coding for Active Directory: Proxying Users into an AD-LDS Application Directory

In another IT Pro tip related to Active Directory, suppose an organization has an internal AD forest, but has a company policy that only paid personnel are to have accounts in that directory.  That's a fairly rational policy:

• If we pay you directly, then you're an employee, so you get an account
• If we pay you indirectly, then you're a contractor that we've hired, so you can also get an account
• If you pay us, whether directly as a consumer, retailer, or reseller, or indirectly as a consumer through a retailer or reseller, then you're a customer, so you probably should not have an account in our internal AD forest.

But suppose you have an application that needs to be built that will allow both employees/contractors, AND customers to access it, and you don't want to setup yet-another-provisioning process for granting and revoking access for employees and contractors?

Enter a common solution: Active Directory - Lightweight Directory Services (previously known as ADAM, AD Application Mode, a.k.a. an "application" directory).  This is a lightweight, LDAP only directory with less bells and whistles than AD has, but many Microsoft-centric applications can plumb right into it.

But to achieve a true Single Sign On for the internal AD users, the IT Admin must create either a UserProxy or a UserProxyFull object in the AD-LDS.  Both function nearly the same, but a UserProxyFull has additional schema data elements for storing additional contact data fields, which are generally handy for today's applications.

Under the hood, when an internal AD user connects to the application, an authentication request is passed to the AD-LDS, which looks up the UserID of the internal user, finds the User Proxy object, and then performs Kerberos authentication against the internal AD.  All other attributes, though, from contact data fields, to the group memberships that the UserProxy has, are separate from the internal AD forest.  In essence, nothing is automatically the same and it's yet-another-directory-to-manage.

Wouldn't it be nice if there was a way to build a service or application in C# .NET so that a configurable subsection of your organization's internal AD user community could automatically be provisioned and deprovisioned, complete with metadata updates, and maybe even rudimentary AD-LDS group memberships based on your AD data?  Why yes, yes that would be very nice.  

Wouldn't it be even nicer if the code was open source so we can take it, borrow it, and use it internally without a restrictive license?  Why yes, yes that would be very nice, too.

Wouldn't be even nicer still if this article linked straight to that source code?

Why yes, yes it sure would be nice.

Good thing we just did! 

Start synchronizing your Active Directory forest with your Lightweight Directory Services (AD-LDS) instance with this example solution in C#.

Active Directory Tip: Hitting Snooze on the Password Expiration Policy

The Active Directory Password Expiration Snooze Button

IT Administrators have certainly been in the tough scenario where a security policy mandates that passwords expire in X days, but there are constraints that make it really hard for the user account passwords to actually change.  For example:

• Dealing with service, application, or generic accounts and a strict constraint to not mark them as non-expiring (forever) passwords
• Dealing with rarely active human users who suddenly need to (on-demand) authenticate against an application, such as HR benefits open enrollment for employees who are not "information workers" (don't access computers).

There are a couple tricks for dealing with this without causing interruption.  Take note that these "tricks" may completely circumvent the letter and perhaps even the intent of the "policy".  But even with astute auditors, the intent of using these tricks will likely never get noticed. 

Or perhaps you are an auditor, and reading the details of these tricks will open up your mind to look for new events that signify lack of compliance.

Administrative Password Resets

If you know the password for the account in question, then simply perform a password reset with that password.  If you have never thought to do this before, this may at first seem counter-intuitive: after all, resetting a password with a password history rule turned on by policy will cause the password to change, right?

Wrong.  There are two ways an Active Directory password can change: 

1. The user initiates a password change event, in which they are required to supply the current password in addition to a new password.
2. The administrator with permissions on the UserAccountControl attribute of the AD user object can perform an administrative reset.

A reset by an administrator must support changing the password when the user is locked out and does not know the password, therefore, the administrator is not required to know the current password.

Also, a reset by an administrator does not enforce password history.  If it did, a rogue administrator could inadvertently learn the current password if the new password supplied by the administrator failed to reset due to password history requirements.  Sure, they just reset the password and could impersonate the user anyway, but that may not be the point: that user's password might be the same on a different (non-Active Directory integrated) application.

So, if you know the current password, perform a RESET and the password last set date attribute on the user account in the directory will update, effectively hitting the snooze button.

A More Clever Trick

But what if you don't know the current password for the account?  

In the scenario of a mostly-inactive end user community that suddenly need to hit an application (e.g. your company's HR system for annual benefits enrollment):

• there may be too many users to learn their passwords
• asking the user for their password is likely faux pas
• the user may not even know the password anyway (since it's been a year), and 
• resetting a large collection of users passwords to a standard/default that everyone shares is insecure
• and resetting individually unique passwords for an infrequent, on-demand access presents communication problems all of its own

So, what to do? 

You could disable or extend password expiration.  In Windows 2003 AD and earlier, this meant changing the policy for everybody, which may not be the intent at all.  This is especially true if there are both active and inactive users in the directory, since active users will not get the normal "your password is about to expire" warning X days before it's too late.  Reverting your password expiration policy setting back to the original value could result in a portion of your active users suddenly being locked out and calling for help.  In Windows 2008 and later, you can have multiple expiration policies within a domain, but your user objects may not be grouped to distinguish the inactive users of concern.  You could identify them and move them (and even script that step), but then you may have to move them back to many different OUs (Organizational Units) which could be just as much of a pain as the original problem.

Or you could follow this set of steps (which are scriptable!):

1. In Active Directory Users and Computers, locate the user with the expiring or expired password
2. Check the "force password change at next logon" box.
3. Click Apply.
4. Uncheck the "force password change at next logon" box.
5. Click Apply.

And VOILA!  That user's password expiration has just been snoozed-- effectively reset for another iteration, and with zero knowledge of the current password.  The password last set date will appear to be the moment you hit step 5.

How does this work?

Under the hood, the user attribute which stores the date/time when the password was last set is also dual purposed for the password must change flag.  The value is a really large integer which contains the number of ticks of seconds as a representation of time.  But when the force password change button is checked, the value of seconds of time is wiped out.  "Empty" is how the flag is stored.  The last date/time is wiped out.  So, when the administrator unchecks the force password change checkbox, AD Users & Computers has to put SOMETHING in that attribute, because NOTHING appears like it is flagged for change.  But the original value is gone forever!  So what does it store there?  The current date/time.  Hence, the user appears to have had its password reset without any actual (visible) changes to the user.

This can all be scripted out using the dsquery and dsmod commands the Microsoft ships with Active Directory.  PowerShell could also be used.  Or, an astute C# (or VB) .Net developer could simply take a look at the Securology GitHub repository, to see the example Password Snooze Button console app, to incorporate it into your organization's existing user management applications and services.

For the Auditor

To detect if an organization that you are auditing has been using the first option (administrative password resets to snooze the expiration), look for:

• Event log data for password resets of multiple accounts at roughly the same time, since this would likely be done "in mass" by the IT administrator
• Service accounts that all have roughly the same password last set date and time.  Manually resetting multiple passwords would have a period of time between each reset event, but a script would cause them all to be within a few seconds of each other
• User accounts that have been in existence for longer than the password expiration policy's time out, but that have one or few historical passwords stored in the directory (requires a very low level AD editing tool to discover), while still being active (lots of log on events)

To detect if an organization has been using the second option (password must change flag), look for:

• Lots of user accounts with nearly the same date/time value for the password last set attribute.
• Lots of user accounts that have not logged in since their password was last set.
• If event log data is available, look for lots events denoting the must change password flag was set or unset.

Even if long term historical event log data is available, the determined IT administrator could spread out these events to appear sporadic, random, or intentionally related to a user's call to a help desk.  A determined administrator could both keep the lights on and keep auditors at arms' length without detection of a policy violation.

Securology's Open Source Repository on GitHub

Securology now has open source code on GitHub!
https://github.com/Securology

This is something we have wanted to do for some time and finally are now able!  As our contributors find the time and freedom to contribute some of our intellectual property back to the greater community at large, we will add more repositories and content there.

Our first offering is a C# .NET wrapper that can do more to manage Microsoft Active Directory instances (including Active Directory Lightweight Directory Services, formerly known as ADAM, or Active Directory Application Mode) than any other open source project can do (which is why we wrote it in the first place).  Our open source Active Directory Services repo is available here:
https://github.com/Securology/ActiveDirectoryServices

In addition to shipping a core library that extends Microsoft's out-of-the-box functionality that ships with the .NET runtime (System.DirectoryServices.AccountManagement), we also have fully working example applications that are consumers of the library, so you can see how to use all of the features we have built.

Here's a list of just some of the features our consumer applications can do:

• Create, Edit, Update, and Delete Active Directory objects Users, Groups, Organizational Units (OUs), Contacts, etc.
• Create, Edit, Update, and Delete AD-LDS (ADAM) UserProxy and UserProxyFull objects.
• Sync AD Users into an AD-LDS (ADAM) instance as UserProxy or UserProxyFull objects.
• Create, Update, Delete, and generally manage/sync dynamic AD security/distribution groups based upon reporting relationships (if those are defined within Active Directory).
• Enable, set, and maintain Microsoft Exchange attributes to enable objects to become visible in the GAL (Global Address List), which also works for Microsoft's Exchange Online hosted service via DirSync.
• Import various rooms and resources from a .CSV file into Active Directory and enable their visibility in the Exchange GAL.
• Enable and Manage Office Communicator/Lync attributes to turn on/off access to your company's Lync/OCS server, setup default policies, including access to any internet-facing proxy servers as well as archive/logging per user.
• Generate random passwords for users.
• A nifty way of "snoozing" when a AD user's password expires while keeping the same password.
• And much more...

Eventually, we will share a working Provisioning Web Service that will be a great solution for limited budget organizations that want some of the functionality Microsoft's Identity Lifecycle Manager (ILM) includes, without the heftier license cost and infrastructure requirements.

More follow-up posts will follow.

How To Send Digital Messages using HAM Radio

This is a bit of a stretch from the normal topics, but in a severe disaster scenario (think Hurricane Katrina or third world country), it may be desired to send real time digital text communication when there is no communication infrastructure in place any longer (i.e. telephone lines are down and the Internet "tubes" were all clogged up).

Here is a clever, low budget way to accomplish digital text communication over significant distances with very inexpensive components, namely a HAM radio, a netbook, an open source software application called FLDIGI, and a low tech way of connecting them together.

A clever improvement to this might be to encrypt the text data before its transmitted, which should be possible using a variety of tools, possibly even GnuPG (if the transmission medium is reliable enough to send the complete block of encrypted text without drops).

Brute Forcing Credit Card Numbers

PCI Regulations allow merchants to store the first 6 digits plus the last 4 digits of a customer's credit card number. Ever wonder just how secure that is?

Well, without knowing anything else, if a credit card is stored as 1234-56xx-xxxx-1234, the possible missing middle digits range from 00-0000 to 99-9999, roughly one million (1,000,000) possible combinations. That seems very tough to guess (without being detected).

However, credit card numbers all implement Luhn's Algorithm, which is a special mathematical formula that uses the last digit in the number as a check digit. Not all of the 1,000,000 middle combinations will pass Luhn's check. Turns out (since modulus 10 math is involved), the quantity of missing middle number combinations is at most 100,000 possibilities, not a million. Luhn's reduces the complexity by an order of magnitude.

So, what if an attacker can get just one more digit somehow? Well, it's only 10^4 combinations then: 10,000 possibilities. What if they can get two more digits? The math follows this formula: 10 ^ (n-1). Here's the table:

6 digits	10 ^5 = 100,000
5 digits	10^4 = 10,000
4 digits	10^3 = 1,000
3 digits	10^2 = 100
2 digits	10^1 = 10
1 digit*	10^0 = 1

* It makes sense, if you're missing a single digit, Luhn's will help you recover it. That is the purpose of that algorithm originally.

Now, as far as practical applications for abusing the knowledge of Luhn's Algorithm on a PCI acceptably-formatted credit card number are concerned ... 100,000 attempted transactions to brute force a card number by a single merchant will certainly be detected and the merchant's ability to process any transaction will be in jeopardy. So, an attacker with access to a merchant account is probably not a valid threat to model.

For an attacker to attempt to make purchases at varying merchants with this brute force scheme and everything but the middle 6 digits, the attacker will also have to have the billing address and potentially the CVV code. That makes the problem significantly harder. But as the attacker can discover missing digits from the middle six, the problem becomes easier. If the victim is well chosen, and the attacker can do something like shoulder surf at a point of sale machine to visually see and remember a digit or two or three, then the problem gets noticeably easier. If the attacker can do that, the attacker can probably also guess the billing address and name. There's still that pesky CVV code, though (that's another 3 digits which compounds things).

Realistically, though, for an attacker to get that much information on a victim, the victim would probably have to be oblivious or have an extremely large line of credit to make it worthwhile.

For the rest of us, we're fairly safe with the PCI rules of first 6 plus last 4 digits being public knowledge.

Check this out for yourself. Here's the source code for a very simple C# console application that will take whatever first 6 plus last 4 digits you provide it, and churn out all of the possible middle combinations. Here is the inspiration for the C# Luhn's implementation. [Sorry about the code formatting.]

using System;
using System.Linq;

namespace Luhn
{
public class Luhn
{
private static int _middle = -1;
private static int _counter;
private static int _places;

public static void Main(string[] args)
{
if (!args.Any())
{
PrintUsage();
return;
}

var cc = args[0].Replace("-", "").Replace(" ", "").Replace("x", "X");

if (cc.Length != 16)
{
Console.WriteLine("input is not correct length.");
PrintUsage();
return;
}

_places = cc.Length - cc.Replace("X", "").Length;
var limit = Math.Pow(10, _places);

Console.WriteLine("Places: {0}", _places);
Console.WriteLine("Limit: {0}", limit);

while (_middle < limit)
{
var s = FindNext(cc);
if (!PassesLuhnCheck(s)) continue;
Console.WriteLine("Valid: {0}", s);
_counter++;
}

Console.WriteLine("\r\nFound {0} potential matches for {1}", _counter, args[0]);
}

private static void PrintUsage()
{
Console.Write("Usage: luhn.exe [credit card number]\r\n"
+ " in format like 1234-56xx-xxxx-1234\r\n"
+ " or like 1234-5678-xxxx-1234, etc.\r\n\r\n");
}

private static string FindNext(string number)
{
_middle++;
var middle = _middle.ToString();
while (middle.Length < _places)
{
middle = "0" + middle;
}
return (number.Replace(GetPlaceHolder(), middle));
}

private static string GetPlaceHolder()
{
var s = "";
for (var i = 0; i < _places; i++)
{
s += "X";
}
return s;
}

private static bool PassesLuhnCheck(string number)
{
var deltas = new[] { 0, 1, 2, 3, 4, -4, -3, -2, -1, 0 };
var checksum = 0;
var chars = number.ToCharArray();
for (var i = chars.Length - 1; i > -1; i--)
{
var j = chars[i] - 48;
checksum += j;
if (((i - chars.Length) % 2) == 0)
checksum += deltas[j];
}

return ((checksum % 10) == 0);
}
}
}

DNSCrypt

This is a very premature response to what I believe is the single best solution to dangers like SOPA, PIPA, and ACTA: DNSCrypt.

To be fair, I don't think DNSCrypt in and of itself would be a solution to draconian "take the free out of internet" laws; however, it's going to be a very necessary component to maximize liberty in the 21st century. It's amazing the web has lasted this long without end-to-end crypto for DNS.

As stated in the link above, DNSCrypt is no replacement for DNSSEC. In fact, the ideal solution would be to rebuild DNS from the ground up using more of a web-of-trust model and completely end-to-end confidential and authenticated channels everywhere, with the ability to determine which "authority" you subscribe to for DNS and with resources listing themselves with as many authorities as they wish to be associated, ending the centralized (yet distributed for availability) control of the web. There's probably no reason to put that much power in the hands of a single entity anyway, and as governments continue on the path they appear to be on, locking down the web, isolated technical solutions will essentially create black markets for essential services like DNS.

For maximum persistence, an ideally liberated DNS solution would also need to float through filters, learning what it can from protocols designed to do so, like bittorrent, IRC, and basically any "cloud service" an enterprise IT Security team would want to block (those online drive storage services always seem to find a way through!).

And ultimately, wide-scale adoption is very necessary. It's excellent to see the inklings of that plan in DNSCrypt. Look at the choice to use ECC to preserve confidentiality. ECC requires low CPU overhead compared to other public key schemes, like RSA encryption, making it perfect for small devices like phones, wireless routers, and other embedded platforms to natively support DNSCrypt. Also important is for large scale providers like OpenDNS to support it. But like so many great technical solutions to problems, market penetration has been the deciding factor what wins out and what doesn't.

Even if DNSCrypt isn't perfect, it's a step in the right direction.

Linux SSO to AD

This is a break from the traditional types of posts. It's more of an instructional howto, but I hope that it is valuable nonetheless.
...

Ah, the holy grail of Identity Management: Single Sign On. And in today's enterprise, that likely means Microsoft's Active Directory at the back end. While directions for bringing unix/linux boxes into the AD forest have been out there, they have been sticky at least, requiring random config changes to PAM, Kerberos, Samba, LDAP(S), etc.

Enter likewise-open, which is a great way to package all those up. It's a free software package that also comes with optional enterprise support, which anti-free-and-open-source companies tend to like.

Sure, there are tons of great examples out there that will tell you how to get likewise-open installed (which is a dream compared to the old days of manually configuring Kerberos, PAM, etc.). BUT, they leave you high and dry with any user in the whole domain (possibly the forest) being able to log into the computer, since they focus on "authentication" and not "authorization". Since when is that better than less passwords? They also don't properly show how to manage privileged access once logged in. So the following are some subtle configuration details and nuggets for which I have had to comb the web and anyone who really does enterprise SSO will appreciate.

This will assume you have likewise-open installed, which if you don't, on Ubuntu it's as simple as: sudo apt-get install likewise-open.

For that matter, this entire thing assumes Ubuntu, but would work elsewhere (paths may vary).

Joining to the domain is very easy, too: sudo domainjoin-cli join fully.qualified.domain.name UserID

Now, you probably want to limit who can log on to the shell to just admins. After all, it's Unix; it's not a toy. Use your favorite text editor (as root or sudo) and edit /etc/security/pam_lwidentity.conf. Uncomment this line require_membership_of and add an AD group containing those admins in the Domain\Group format.

Next you'll want to make sure those admins can use sudo otherwise you'll have a root password management problem (the whole point of SSO is to reduce the number of passwords to manage, right?). Edit the /etc/sudoers file by typing sudo visudo and add a line in this format: %DOMAIN\\Group ALL=(ALL) ALL (if you want to allow everything-- follow normal sudo permissions rules to restrict further).

Last, but not least, you'll probably want to get a psychological acceptance from administrators as a security design principle, right? In order to do that, let's get rid of that pesky Domain\UserID format and just use the UserID format. After all, who wants to type in ssh 'domain\userid'@computername when they can just type in ssh computername? This is the coup de grâce in favor of less passwords. Again, as root or sudo, edit /etc/samba/lwiauthd.conf and add winbind use default domain = yes to the end of the file. If you're in a multi-domain forest, you're up a creek (not to mention you probably have a less than simple environment anyway), and at a minimum your users in other domains will have to specify the domain\userid format. But users in the same domain can log in without the domain\ prefix.

One recipe for quick SSO to AD on Unix/Linux in a mere few minutes. Enjoy.

Open Source Trustworthy Computing

There is a pretty good article over at LWN.net about the state of Trustworthy Computing in Linux, detailing the current and planned support for TPMs in Linux. Prof Sean Smith at Dartmouth created similar applications for Linux back in 2003, when the TPM spec was not yet finalized.

Of the TPM capabilities discussed, "remote attestation" was highlighted significantly in the article. But, keep in mind that Linux, being a monolithic kernel, has more components that would need integrity checking than there are available PCRs in the TPMs. The suggested applications (e.g. checking the integrity of an "email garden" terminal by the remote email server) are a stretch of capabilities.

Also keep in mind that unless coupled with trust at the foundational levels of memory architecture, integrity-sensitive objects could be replaced in memory by any device that has access via DMA. IOMMUs or similar will be required to deliver the solution fully.

And on that note, Cornell's academic OS - Nexus has a much better chance of success, because of the limited number of components that live in kernel space. The fewer the items that need "remote attestation", the more likely the attestation will be meaningful at all. At this point, modern operating systems need to simplify more than they need to accessorize, at least if security is important.

On Open Source and Security

Recently, I noted that it's not important whether source code is open or not for security, it's important to have well-qualified analysts reviewing the code. As a result, I received the following comment: "If you are paranoid, pay some guys you trust to do a review. With [closed source] you can't do that." The following is my response.

...


Well, say I trust Bruce Schneier (I generally do professionally speaking, but not necessarily personally-- and I'll pick on him since he's almost universally accepted as the patron saint of security). Let's say I trust Bruce's analysis of a particular company's products. If Bruce is reviewing the source code and the code is closed to the public but made available to him as an escrow, I would likely be OK with that. Trust is more complicated than just availability of source code. There are not too many people in the world that are qualified to security reviews of security product's code. So, I couldn't trust just anyone's analysis of it. To be honest, if it came down to a computationally-intensive implementation of cryptographic code, I wouldn't even trust my own analysis of it. My point is: Trust is a social-psychological phenomenon, not a technical one.

"Open source" means so many different things to different people. To some it means "free to use, modify, or distribute". To some, it means anyone can review the code. To others, it might just mean the vendor will provide source code escrow services at your request. It might be possible to have a closed source (in the common sense) product opened up to a specific customer (potentially any customer asks the right question the right way).

How many "joe users" that have a one seat install of a product actually review the code? Not many. How many of those one seat installs are actually qualified code reviewers? Fewer still.

Open Source != Security

It (open source) is an unrelated variable. It's like how automobile insurance providers in the US inaccurately categorize all male drivers under 18 years of age as high risk. Not all of them (caricatures and jokes aside) will get tickets, cause wrecks, or otherwise require the insurance agency to pay out. However, the actuarial data presented to the insurers suggests that is a reasonable category of customers for which they should increase premiums. If it was legal and ethical (and affordable) to put all under 25 year old drivers through a *magic* test (I say magic because it may or may not exist) that could differentiate with a higher level of certainty whether the customer had the "x factor" that caused a higher tendency to cause wrecks ... well, that's where the insurance companies would go.

Open Source is like that broad, mis-categorization. There are many open source projects that are never reviewed for potential threats by qualified people. In fact, since "open source" is so "open", there are likely projects that have never even been reviewed by anyone outside of the sole contributor. "Open Source" strikes up a connotation of community and collaboration, but it does not guarantee community and collaboration. Likewise, there's no guarantee that the people reviewing the code aren't adding security problems deliberately.

Trust is a binary action. You either choose to trust someone or something, or you choose not to trust. You might opt to choose to trust someone conditionally, such as I might trust a carpenter to build my house but not to work on my car. Trustworthiness, however, is a totally different equation. People estimate trustworthiness (which is exactly as it reads: calculating how worthy of trust something or someone is) using a combination of perceived reputation (track records) or trusted third parties' estimated trust (e.g. my friend Joe knows a lot about cars, so I trust his mechanic, since Joe would know how to differentiate between a good and bad mechanic).

A product has opened its source code for review. So what? You should be asking the following questions:

• Why? Why did you open your source?
• Who has reviewed your source? What's (not) in it for them?
• What was in the review? Was it just a stamp of approval or were there comments as well?