We are not who we are

In authentication, we generally talk about three “factors” for determining identity. A “factor” is a broad category for establishing that you are who you claim to be. The three types of authentication factor are:

  • Something you know (a password, a PIN, the answer to a “security question”, etc.)
  • Something you have (an ATM card, a smart card, a one-time-password token, etc.)
  • Something you are (your fingerprint, retinal pattern, DNA)

Historically, most people have used the first of these three forms most commonly. Whenever you’ve logged into Facebook, you’re entering something you know: your username and password. If you’ve ever used Google’s two-factor authentication to log in, you probably used a code stored on your smartphone to do so.

One of the less common, but growing, authentication methods are the biometrics. A couple years ago, a major PC manufacturer ran a number of television commercials advertising their laptop models with a fingerprint scanner. The claim was that it was easy and secure to unlock the machine with a swipe of a finger. Similarly, Google introduced a service to unlock an Android smart phone by using facial recognition with the built-in camera.

Pay attention folks, because I’m about to remove the scales from your eyes. Those three factors I listed above? I listed them in decreasing order of security. “But how can that be?” you may ask. “How can my unchangeable physical attributes be less secure than a password? Everyone knows passwords aren’t secure.”

The confusion here is due to subtle but important definitions in the meaning of “security”. Most common passwords these days are considered “insecure” because people tend to use short passwords which by definition have a limited entropy pool (meaning it takes a smaller amount of time to run through all the possible combinations in order to brute-force the password or run through a password dictionary). However, the pure computational complexity of the authentication mechanism is not the only contributor to security.

The second factor above, “something you have” (known as a token), is almost always of significantly higher entropy than anything you would ever use as a password. This is to eliminate the brute-force vulnerability of passwords. But it comes with a significant downside as well: something you have is also something that can be physically removed from you. Where a well-chosen password can only be removed from you by social engineering (tricking you into giving it to an inappropriate recipient), a token might be slipped off your desk while you are at lunch.

Both passwords and tokens have an important side-effect that most people never think about until an intrusion has been caught: remediation. When someone has successfully learned your password or stolen your token, you can call up your helpdesk and immediately ask them to reset the password or disable the cryptographic seed in the token. Your security is now restored and you can choose a new password and have a new token sent to you.

However, this is not the case with a biometric system. By its very nature, it is dependent upon something that you cannot change. Moreover, the nature of its supposed security derives from this very fact. The problem here is that it’s significantly easier to acquire a copy of someone’s fingerprint, retinal scan or even blood for a DNA test than it is to steal a password or token device and in many cases it can even be done without the victim knowing.

Many consumer retinal scanners can be fooled by a simple reasonably-high-resolution photograph of the person’s eye (which is extremely easy to accomplish with today’s cameras). Some of the more expensive models will also require a moving picture, but today’s high-resolution smartphone cameras and displays can defeat many of these mechanisms as well. It’s well-documented that Android’s face-unlock feature can be beaten by a simple photograph.

These are all technological limitations and as such it’s plausible that they can be overcome over time with more sensitive equipment. However, the real problem with biometric security lies with its inability to replace a compromised authentication device. Once someone has a copy of your ten fingerprints, or a drop of your blood from a stolen blood-sugar test or a close-up video of your eye from a scoped video camera, there is no way to change this data out. You can’t ask helpdesk to send you new fingers, an eyeball or DNA. Therefore, I contend that I lied to you above. There is no full third factor for authentication, because, given a sufficient amount of time, any use of biometrics will eventually degenerate into a non-factor.

Given this serious limitation, one should never under any circumstances use biometrics as the sole form of authentication for any purpose whatsoever.

One other thought: have you ever heard the argument that you should never use the same password on multiple websites because if it’s stolen on one, they have access to the others? Well, the same is true of your retina. If someone sticks malware on your cellphone to copy an image of your eye that you were using for “face unlock”, guess what? They can probably use that to get into your lab too.

The moral of the story is this: biometrics are minimally useful, since they are only viable until the first exposure across all sites where they are used. As a result, if you are considering initiating a biometric-based security model, I encourage you to save your money (those scanners are expensive!) and look into a two-factor solution involving passwords and a token of some kind.

Linus Torvalds shares the Millenium Technology Prize with Dr. Shinya Tamanaka

In a first for the Millenial Technology Prize, both Laureates were awarded the prize. Linus Torvalds was recognized for the creation of the Linux kernel and its continuing impact on enhancing scientific progress throughout the world. Dr. Shinya Yamanaka was recognized for his work in the development of induced pluripotent stem cells for medical research.

http://www.technologyacademy.fi/millennium-technology-prize/

SSSD Tips and Tricks Vol. 2 – LDAP

Multiple Search Bases

Starting with SSSD 1.7.0, the System Security Services Daemon now has the ability to search for users, groups and netgroups in multiple search bases. Some LDAP deployments divide groups into different trees so that individual clients can receive different “views” of a group. (This is especially useful for some application software that restricts access to hard-coded group names. In these cases, you can install the same application in different configurations by providing different views of that group).

In SSSD 1.7.0, we extended the ldap_search_base (and ldap_[user|group|netgroup]_search_base) options so that they will now take three pieces of information instead of one (the base itself). Search bases are specified by the pseudocode regular expression:

<base_dn>?<search_scope>?<search_filter>

The search filter can be either an empty string (indicating that no special filtering should be done) or it can be a valid LDAP search filter, which will be ANDed with the standard search filters SSSD uses internally.

“But that’s only one search base, you say!”. And you would be correct. You can add additional search bases by inserting another ‘?’ after the search filter of the preceding base.

For backwards-compatibility, a single search base can be specified simply by base_dn, which will be treated as

<base_dn>?subtree?

Paged lookups

For performance reasons, many LDAP servers limit the number of records that can be retrieved by an LDAP search at one time. Beginning with SSSD 1.6.0, the System Security Services Daemon can now perform paged searches to retrieve responses containing more entries than this limit. This is particularly useful for deployments with large group memberships or those with large numbers of users and groups with enumeration enabled.

SSSD now provides an option ldap_page_size that specifies how many records to request for each individual lookup. The default was set to 1000 records (chosen as it was the lowest common default value of OpenLDAP, 389 DS and Active Directory). However, if your LDAP server has been tuned to have a higher or lower value for this limit, you may wish to update this value to match.

As a general rule, you will want this page size to match the limit on the server, for maximum performance. A larger page size will mean fewer round-trips across the wire to LDAP.

Password Changes and Read-Only Replicas

Due to its use of the openldap client libraries, SSSD has a limitation when it comes to performing password changes. Normally, the way that a read-only replica will be set up is that it will be configured to return a referral to a read-write master LDAP server when a password-change attempt occurs. The client is expected to process this referral and then open a new connection to the read-write master.

Unfortunately, due to an open bug in the OpenLDAP client libraries (which SSSD uses internally for much of its LDAP communication), this referral is not processed correctly. As we’ve not had much traction with the OpenLDAP developers in fixing this bug, SSSD has implemented a workaround. We provide a new option ldap_chpass_uri (valid when using chpass_provider = ldap). It’s semantics are identical to that of ldap_uri, except that it will only be used when a password-change is implemented. This option allows the system administrator to specify a list of read-write servers against which the password-change should occur. The ldap_uri option can remain pointed at the read-only replicas for performance, without compromising the ability to perform password changes on the client.

Protected: The Truth About Passwords

This post is password protected. To view it please enter your password below:

SSSD Tips and Tricks vol. 1 – Kerberos

Automatic TGT Acquisition

You probably already know all about how the System Security Services Daemon can make your offline life easier by enabling cached-credential login to your system while you don’t have access to the central authentication servers.

What you might not know, however, is that when using SSSD to perform Kerberos auth, it’s also possible to configure it to automatically acquire your network credentials when you go online. By setting the ‘krb5_store_password_if_offline’ option to ‘True’ in the [domain/DOMAINNAME] sections of sssd.conf, you can configure SSSD to store a user’s password when they log in while offline (for example, working from home). Then later, if access to the network KDC is restored (for example, connecting to the VPN), SSSD will perform a kinit on your behalf to automatically acquire a TGT for single-sign-on with your network resources.

Now, some of you will be saying to yourselves: “Wait, doesn’t this mean that my password is being stored on the system in a readable way?”. This is true but not the whole story. Yes, the password is stored on the system in such a way that SSSD (and theoretically the root user on the system, with some effort) can read the password. Without doing so, there would be no way for us to acquire the ticket granting ticket on your behalf. However, we do store the password in the most secure way possible: in the kernel keyring. This makes it very difficult for root to gain access to this password and essentially impossible for any non-root process. The risk factor is not zero, which explains why this is an optional feature, disabled by default. However, in the common laptop case (where it’s assumed that the owner of the laptop is likely to be its only user), this security/convenience trade-off is probably worthwhile.

Automatic Ticket Renewal

The second advanced Kerberos feature I’d like to discuss today is automatic ticket renewal. User processes sometimes need access to the user’s Kerberos credentials, even when the user is no longer logged in. An example might be a regular cron job that the user wants to run every day a few hours after leaving work. With traditional Kerberos configurations, this user would be forced to remember to manually renew his Kerberos credentials before leaving for the day, to ensure that the expiration time on his TGT did not expire before his cron job completed.

With SSSD 1.5.0 and later, it can be configured to automatically renew Kerberos tickets for the full renewable life of the TGT. This is different from the automatic TGT acquisition above, as we do not need to store the user’s Kerberos password to accomplish this. It does require some additional configuration on the KDC server, however.

If the KDC permits users to request “renewable” TGT tickets, then what it is allowing the user to do is to use their current TGT in place of their password in order to acquire an updated TGT (with a later expiration).

SSSD 1.5.0 and later can set two options to enable it to automatically renew the user’s TGT for as long as the KDC permits.

The first option is krb5_renewable_lifetime. When set, it specifies the maximum renewable duration that the SSSD will attempt to request from the KDC. Note that this is only a request, and the KDC itself may choose to return a much shorter duration, or disallow renewals entirely.

Assuming that a renewable ticket was granted, the second option is krb5_renew_interval. This option specifies how often the SSSD should poll to see if any of the user TGTs have gone beyond 50% of their current lifetime. If they have, SSSD will perform a TGT renewal on the user’s behalf, extending the lifetime of the TGT.

Code reviews, collaboration and the SSSD 1.5.0 release

Yesterday, the SSSD team hit a major milestone: we released SSSD 1.5.0. This is probably the largest release we’ve done since 1.0, with over 150 commits. With several new features, particularly related to access-control, we’ve worked closely with our users to ensure that 1.5.0 is the most attuned project to their real-world needs. As I’ve mentioned in the past, SSSD relies on a very stringent code-review process for its development. Nothing makes it into the codebase without the close inspection and testing of one of the other developers. Simo Sorce, one of the original designers and developers of the System Security Services Daemon wrote an excellent blog post on how this review policy has enabled us to write very secure code.

One of the major changes we made to our process in SSSD 1.5.0 is that we started using the Coverity Integrity Manager as part of our continuous-integration environment. By running these scans on the full codebase regularly (twice a day), we were able to keep ahead of common coding mistakes such as resource leaks or missing NULL checks. While this scanning did reveal several legitimate bugs in the SSSD, it also revealed that we had been doing an exceptional job of avoiding serious bugs in the code. For a detailed analysis of our Coverity results, see Simo’s blog post.

So, what have we learned from the SSSD 1.5.0 cycle? First, there is no substitute for feedback from real-world users of your project. By maintaining our relationship with our most vocal users, I think we’ve achieved some truly great things. Secondly, when developing a security product, there’s no such thing as too many eyes on the code, be they other developers, users or automated scanning technologies.

 Continue reading 

Net Neutrality and you

By now, you’ve probably heard the term “Net Neutrality” banded about on the Internet. Perhaps you wonder what it means. Perhaps you’ve been watching certain biased news networks and have a warped understanding of the term. In either case, I’d like to try and provide a human-readable explanation of what the positions are on Net Neutrality.

I think the first thing I need to describe is a little bit of how the Internet actually works. When you type in an address in your web browser, you are not connecting directly to that web server. Instead, what happens is that your request travels through intermediaries. First it goes to your Internet service provider that you bought your connection from (e.g. Comcast, Verizon, AT&T, NetZero, etc.). From there, it’s transmitted through several high-bandwidth providers, sometimes owned by the same company, sometimes another company, until it arrives finally at the server you wanted to talk to. We’ll call these middle hops (including your ISP, and the backbones that they talk to) “intermediaries”. I will use several of these companies as examples below, however they are only hypothetical examples and should not be misconstrued as an endorsement or accusation of misconduct by any particular entity.

Next, lets describe bandwidth a little bit. The classic example is to compare it to modern running-water plumbing. Bandwidth in this case could be described by the diameter of the water pipe. The wider the pipe, the more water than can flow through it each minute. Similar to pipes as well, you have a problem when the amount of water (data) you try to send through the pipe (Internet connection) is greater than its ability to pass it through.

Let’s try and define the term “Net Neutrality”. What does it mean, and how does it affect you?

Net Neutrality is a proposal that the Internet needs to be legislated to guarantee that the intermediaries between you and the server you’re trying to talk to cannot make deals to disallow access to certain services. For example, lets say that your Internet service provider is Comcast. Comcast owns NBC/Universal, which provides a website for streaming the latest episodes of its television programs. They have other competitors in the television market, so they decide that anyone using their communication lines can only connect at full speed to nbc.com, and that sites like hulu.com, cw.com and cbs.com are going to be limited to 10% speed so that they don’t use up the available bandwidth that Comcast wants to be used for nbc.com. As mentioned above, Comcast has a certain amount of bandwidth that it can take advantage of. As more and more people get on the Internet with an assortment of devices (computers, smartphones, Internet-enabled televisions, etc.), there is an increased demand on Comcast’s bandwidth.

From Comcast’s perspective, it would now have two choices:

  1. Increase its bandwidth. This is very expensive, as it involves expending millions of dollars on new equipment
  2. Find ways to divide the bandwidth it already has

The second option is where we start to get into Net Neutrality territory. In the example above, I provided the example that, in situations where the available bandwidth is at its limit, Comcast might choose to restrict the passage of data destined for one of its competitors, so that it could reserve a larger part of its available bandwidth for its own services. This is not necessarily a particularly good example, because situations like this might lead to antitrust lawsuits.

There is, however, another case that is the crux of the Net Neutrality argument. It is essentially this: Should Comcast be allowed to sell different tiers of service to different customers. For example, can hulu.com come to Comcast and offer to pay double the going rate for traffic through its network, and be granted a larger percentage of the available pipe? This is the source of the largest piece of confusion in the Net Neutrality debate. Those who do not understand the technologies behind the Internet see this discussion as a free market situation. In other words, if a customer of Comcast can afford to pay more for higher quality of service, then they should be allowed to do so.

However, think back to the plumbing explanation. Comcast is not building brand-new infrastructure to support these new higher-paying clients. They are merely guaranteeing them a higher percentage of the available bandwidth pass-through. This cannot happen without lowering the available bandwidth for those services that cannot afford the higher tier. Furthermore, if large numbers of clients with deep pockets pay for the privilege of higher bandwidth, they are further reducing the available bandwidth for the lower-paying customers.

In other words, no real product is gained by paying for the new service. It is merely redistributed (and how’s that for socialism, guys?). At the same time, it reduces the ability of smaller players from being able to deliver new, disruptive technologies and products.

Where would the world be if companies like Google and Apple had not been able to do business on the Internet because Yahoo and Microsoft were the big players and owned all of the bandwidth? Without a guarantee of Net Neutrality, the next great invention may never see the light of day because there will be no way to deliver it into the hands of customers.

The guarantee of Net Neutrality is that all bandwidth through an intermediary must be treated with the same priority as any other. There should be no artificial slowing of any customer’s data simply because another customer has deeper pockets.

Many of the larger telecommunications providers argue that it’s their right as the owner and maintainer of the communication lines to do with them as they please. There is certainly a point to be made from this, but at this point, the economy of the United States and the world is at stake if the fundamental operation of the Internet changes.

I hope I’ve explained this issue in a way that is easy to understand. If so, please write your local legislators and tell them that you support Net Neutrality for the rights of consumers and small business.