Adaptive Code via C#. Agile coding with design patterns and SOLID principles (2014)

Chapter 8. Authentication and Key Exchange

At first glance, it may not be clear that authentication and key exchange are two topics that go together. But they do. This chapter is really all about secure connection establishment—everything the client and server need to do before they start talking. Generally, the server will need to authenticate the client; the client will need to make sure the server is the correct machine (not some attacker). Then the two parties will need to come to some agreement on how to communicate securely beyond that, also agreeing on an encryption key (or a set of keys).

Yes, authentication doesn't always happen over an insecure network connection—it is certainly possible to authenticate over a console or some other medium where network attacks pose little to no risk. In the real world, however, it's rare that one can assume a secure channel for authentication.

Nonetheless, many authentication mechanisms need some kind of secure channel, such as an authenticated SSL connection, before they can offer even reasonable security levels.

In this chapter, we'll sort through these technologies for connection establishment. Note that in these recipes we cover only standalone technologies for authentication and key exchange. In Chapter 9, we cover authentication with SSL/TLS, and in Chapter 10, we cover authentication in the context of public key infrastructures (PKI).

8.1. Choosing an Authentication Method

Problem

You need to perform authentication, and you need to choose an appropriate method.

Solution

The correct method depends on your needs. When a server needs to be authenticated, and the client does not, SSL/TLS is a popular solution. When mutual authentication is desirable, there are a whole bevy of options, such as tunneling a traditional protocol over SSL/TLS or using a dedicated protocol. The best dedicated protocols not only perform mutual authentication but also exchange keys that can then be used for encryption.

Discussion

An authentication factor is some thing that contributes to establishing an identity. For example, a password is an authentication factor, as is a driver's license. There are three major categories of authentication factors:

Things you know

This category generally refers to passwords, PIN numbers, or passphrases. However, there are systems that are at least partially based on the answers to personal questions (though such systems are low on the usability scale; they are primarily used to reset forgotten passwords without intervention from customer service people, in order to thwart social engineering attacks).

Things you have

ATM cards are common physical tokens that are often implicitly used for authentication. That is, when you go to an ATM, having the card is one factor in having the ATM accept who you are. Your PIN by itself is not going to allow someone to get money out in your name.

Things you are

This category generally refers to biometrics such as fingerprints or voice analysis. It includes things you have that you are not going to lose. Of course, an attacker could mimic your information in an attempt to impersonate you.

No common authentication factors are foolproof. Passwords tend to be easy to guess. While cryptography can help keep properly used physical tokens from being forged, they can still be lost or stolen. And biometric devices today have a significant false positive rate. In addition, it can be simple to fool biometric devices; see http://www.puttyworld.com/thinputdeffi.html.

In each of these major categories, there are many different technologies. In addition, it is easy to have a multifactor system in which multiple technologies are required to log in (supporting the common security principle of defense in depth). Similarly, you can have "either-or" authentication to improve usability, but that tends to decrease security by opening up new attack vectors.

Clearly, choosing the right technology requires a thorough analysis of requirements for an authentication system. In this chapter, we'll look at several common requirements, then examine common technologies in light of those requirements.

However, let us first point out that it is good to build software in such a way that authentication is implemented as a framework, where the exact requirements can be determined by an operational administrator instead of a programmer. PAM (Pluggable Authentication Modules) lets you do just that, at least on the server side, in a client-server system. SASL (Simple Authentication and Security Layer) is another such technology that tries to push the abstraction that provides plugability off the server and into the network. We find SASL a large mess and therefore do not cover it here. PAM is covered in Recipe 8.12.

There are several common and important requirements for authentication mechanisms. Some of these may be more or less important to you in your particular environment:

Practicality of deployment

This is the reason that password systems are so common even though there are so many problems with them. Biometrics and physical tokens both require physical hardware and cost money. When deploying Internet-enabled software, it is generally highly inconvenient to force users to adopt one of these solutions.

Usability

Usability is a very important consideration. Unfortunately, usability often trades off against good security. Passwords are a good example: more secure mechanism would require public keys to establish identity. Often, the user's private key will be password-protected for defense in depth, but that only protects against local attacks where an attacker might get access to steal the key—a well-designed public key-based protocol should not be vulnerable to password-guessing attacks.

Another common usability-related requirement is that the user should not have to bring any special bits with him to a computer to be able to log in. That is, many people want a user to be able to sit down at an arbitrary computer and be able to authenticate with data in his head (e.g., a password), even if it means weaker security. For others, it is not unreasonable to ask users to carry a public key around.

When passwords are used, there are many different mechanisms to improve security, but most of them decrease usability. You can, for example, expire passwords, but users hate that. Alternatively, you can enforce passwords that seem to have sufficient entropy in them (e.g., by checking against a dictionary of words), but again, users will often get upset with the system. In many cases, adding something like a public key mechanism adds more security and is less burdensome than such hacks turn out to be.

Use across applications

For some people, it is important to manage authentication centrally across a series of applications. In such a situation, authentication should involve a separate server that manages credentials. Kerberos is the popular technology for meeting this requirement, but a privately run public key infrastructure can be used to do the same thing.

Patents

Many people also want to avoid any algorithms that are likely to be covered by patent.

Efficiency

Other people may be concerned about efficiency, particularly on a server that might need to process many connections in a short period of time. In that situation, it could be important to avoid public key cryptography altogether, or to find some other way to minimize the impact on the server, to prevent against denial of service.

Common mechanism

It may also be a requirement to have authentication and key exchange be done by the same mechanism. This can improve ease of development if you pick the right solution.

Economy of expression

An authentication protocol should use a minimal number of messages to do work. Generally, three messages are considered the target to hit, even when authentication and key exchange are combined. This is usually not such a big deal, however. A few extra messages generally will not noticeably impact performance. Protocol designers like to strive to minimize the number of messages, because it makes their work more elegant and less ad hoc. Of course, simplicity should be a considered requirement, but then again, we have seen simple five-message protocols, and ridiculously complex three-message protocols!

Security

Security is an obvious requirement at the highest level, but there are many different security properties you might care about, as we'll describe in the rest of this section.

In terms of the security of your mechanism, you might require a mechanism that effectively provides its own secure channel, resisting sniffing attacks, man-in-the-middle attacks, and so on that might lead to password compromise, or even just the attacker's somehow masquerading as either the client or server without compromising the password. (This could happen, for example, if the attacker manages to get the server password database.)

On the other hand, you might want to require something that does not build its own secure channel. For example, if you are writing something that will be used only on the console, you will already be assuming a trusted path from the user to your code, so why bother building a secure channel? Similarly, you might already be able to establish an authenticated remote connection to a server through something like SSL, in which case you get a secure channel over which you can do a simpler authentication protocol. (Mutual authentication versus one-sided authentication is therefore another potentially interesting requirement.) Of course, that works only if the server really is authenticated, which people often fail to do properly.

Whether or not you have a secure channel, you will probably want to make sure that you avoid capture replay attacks. In addition, you should consider which possible masquerading scenarios worry you. Obviously, it is bad if an arbitrary person can masquerade as either the client or the server just from watching network traffic. What if an attacker manages to break into a server, however? Should the attacker then be able to masquerade as the user to that server? To other servers where the user has the same credentials (e.g., the same password)?

In addition, when a user shares authentication credentials across multiple servers, should he be able to distinguish those servers? Such a requirement can demand significant trade-offs, because to meet it, you will need either a public key infrastructure or some other secure secret that users need to carry around that authenticates each server. If you are willing to assume that the server is not compromised at account creation time but may be compromised at some later point, you can meet the requirement more easily.

We have already mentioned no susceptibility to password guessing attacks as a possible requirement. When that is too strict, there are other requirements we can impose that are actually reasonable:

§ When an attacker steals the authentication database on the server, an offline cracking job should be incredibly difficult—with luck, infeasible, even if the password being attacked is fairly predictable.

§ Guessing attacks should be possible only by attempting to authenticate directly with the server, and the login attempt should not reveal any information about the actual password beyond whether or not the guess was correct.

§ There should not be large windows of vulnerability where the server has the password. That is, the server should need to see the password only at account initialization time, or not at all. It should always be unacceptable for a server to store the actual password.

No doubt there are other interesting requirements for password systems.

For authentication systems that also do key exchange, there are other interesting requirements you should consider:

Recoverability from randomness problems

You might want to require that the system be able to recover if either the client or the server has a bad source of randomness. That is generally done by using a key agreement protocol , where both sides contribute to the key, instead of a key transport protocol , where one side selects the key and sends it to the other.

Forward secrecy

You might want to require that an attacker who manages to break one key exchange should not be able to decrypt old connections, if he happens to capture the data. Achieving this property often involves some tradeoffs.

Let's look at common technologies in light of these requirements.

Traditional UNIX crypt( )

This solution is a single-factor, password-based system. Using it requires a preexisting secure channel (and one that thwarts capture replay attacks). There are big windows of vulnerability because the user's password must be sent to the server every time the user wishes to authenticate. It does not meet any of the desirable security requirements for a password-based system we outlined above (it is susceptible to offline guessing attacks, for example), and the traditional mechanism is not even very strong cryptographically. Using this mechanism on an unencrypted channel would expose the password. Authentication using crypt( ) is covered in Recipe 8.9.

MD5 Modular Crypt Format (a.k.a. md5crypt or MD5-MCF)

This function replaces crypt( ) on many operating systems (the API is the same, but it is not backward-compatible). It makes offline cracking attacks a little harder, and it uses stronger cryptography. There are extensions to the basic modular format that use other algorithms and provide better protection against offline guessing; the OpenBSD project's Blowfish-based authentication mechanism is one. Using this mechanism on an unencrypted channel would expose the password. Authentication using MD5-MCF is covered in Recipe 8.10.

PBKDF2

You can use PBKDF2 (Password-Based Key Derivation Function 2; see Recipe 4.10) as a password storage mechanism. It meets all the same requirements as the Blowfish variant of MD5-MCF discussed in the previous subsection. Authentication using PBKDF2 is covered in Recipe 8.11.

S/KEY and OPIE

S/KEY and OPIE are one-time password systems, meaning that the end user sends a different password over the wire each time. This requires the user and the server to preestablish a secret. As a result, if an attacker somehow gets the secret database (e.g., if he manages to dumpster-dive for an old backup disk), he can masquerade as the client.

In addition, the user will need to keep some kind of physical token, like a sheet of one-time passwords (which will occasionally need to be refreshed) or a calculator to compute correct passwords. To avoid exposing the password if the server database is compromised, the user will also need to reinitialize the server from time to time (and update her calculator).

These mechanisms do not provide their own secure channel. S/KEY, as specified, relies on MD4, which is now known to be cryptographically broken. If it's used on an unencrypted channel, no information about the password is revealed, but an attacker can potentially hijack a connection.

CRAM

CRAM (Challenge-Response Authentication Mechanism) is a password-based protocol that avoids sending the password out over the wire by using a challenge-response protocol, meaning that the two ends each prove to the other that they have the secret, without someone actually sending the secret. Therefore, CRAM (which does not itself provide a secure channel) can be used over an insecure channel. However, it is still subject to a number of password attacks on the server, particularly because the server must store the actual password. Therefore, you should not use CRAM in new systems.

Digest-Auth (RFC 2617)

Digest-Auth is one of the authentication mechanisms specified for HTTP/1.1 and later (the other is quite weak). It does not provide a secure channel, and it provides only moderate protections against attacks on passwords (much of it through an optional nonce that is rarely used).

SRP

All of the mechanisms we've looked at so far have been password-based. None of them create their own secure channel, nor do they provide mutual authentication. SRP (Secure Remote Password) is a password-based mechanism that does all of the above, and it has a host of other benefits:

Client-server authentication

SRP not only allows a server to authenticate clients, but it also allows clients to know that they're talking to the right server—as long as the authentication database isn't stolen.

Protection against information leakage

SRP also prevents all but a minimal amount of information leakage. That is, an attacker can try one password at a time by contacting the server, but that is the only way he can get any information at all about the password's value. Throttling the number of allowed login attempts to a few dozen a day should reasonably thwart most attacks, though it opens up a denial of service risk. You might consider slightly more sophisticated throttling, such as a limit of 12 times a day per IP address. (Of course, even that is not perfect). A far less restrictive method of throttling failed authentication attempts is discussed in Recipe 8.8.

Protection against compromise

SRP protects against most server-compromise attacks (but not a multiserver masquerading attack, which we do not think is worth worrying about anyway). It even prevents an attacker who compromises the server from logging into other machines using information in the database.

Key exchange

Another big benefit is that SRP exchanges a key as a side effect of authentication. SRP uses public key cryptography, which can be a denial-of-service issue.

The big problem with SRP is that patents cover it. As a result, we do not explore SRP in depth. Another potential issue is that this algorithm does not provide forward secrecy, although you could easily introduce forward secrecy on top of it.

Basic public key exchange

There are plenty of strong authentication systems based on public key cryptography. These systems can meet most of the general requirements we've discussed, depending on how they're implemented.

Generally, the public key is protected by a password, but the password-protected key must be transported to any client machine the user might wish to use. This is a major reason why people often implement password-based protocols instead of using public key-based protocols. We discuss a basic protocol using public key cryptography in Recipe 8.16.

SAX

SAX (Symmetric Authenticated eXchange) is a protocol that offers most of the same benefits of SRP, but it is not covered by patents. Unlike SRP, it does not use public key encryption, which means that it minimizes computational overhead. There is a masquerading attack in the case of server compromise, but it effectively requires compromise of two servers and does not buy the attacker any new capabilities, so it is not very interesting in practice.

SAX has two modes of use:

§ You can avoid leaking any information about the password if the user is willing to carry around or memorize a secret provided by the server at account creation time (that secret needs to be entered into any single client only once, though).

§ Otherwise, SAX can be used in an SRP-like manner, where the user need not carry around anything other than the password, but information about the password can be learned, but primarily through guessing attacks. Someone can mount an offline dictionary attack on the server side, but the cost of such an attack can be made prohibitive.

If an attacker somehow gets the secret database (e.g., if he manages to dumpster-dive for an old backup disk), he can masquerade as the client. PAX is a similar protocol that fixes this problem.

PAX

PAX (Public key Authenticated eXchange) is a basic two-way authenticating key exchange using public key encryption that uses passwords to generate the keys. The server needs to know the password once at initialization time, and never again.

This protocol is similar to SAX, but has some minor advantages because it uses public key cryptography. For example, you can back away from using passwords (for example, you might take the key and put the client's private key onto a smart card, obviating the need to type in a password on the client end). Additionally, if an attacker does get the authentication database, he nonetheless cannot masquerade as the client.

PAX can be used in one of two modes:

§ You can get all the advantages of a full public-key based system if the user is willing to carry around or memorize a secret provided by the server at account creation time (that secret needs to be entered into any single client only once, though).

§ Otherwise, PAX can be used in an SRP-like manner, where the user need not carry around anything other than the password; information about the password can be learned, but only through guessing attacks.

As with SRP, you can easily layer forward secrecy on top of PAX (by adding another layer of cryptography; see Recipe 8.21).

Unlike SRP, PAX is not believed to be covered by patents.

Kerberos

Kerberos is a password-based authentication mechanism that requires a central authentication server. It does not use any public key cryptography whatsoever, instead relying on symmetric cryptography for encryption and authentication (typically DES or Triple-DES in CBC mode with MD5 or SHA1 for authentication).

Although Kerberos never transmits passwords in the clear, it does make the assumption that users will not use weak passwords, which is a poor assumption to make, because users will invariably use passwords that they find easy to remember. That typically also makes these passwords easy for an attacker to guess or to discover by way of a dictionary attack.

Kerberos does assume that the environment in which it operates is insecure. It can overcome a compromised system or network; however, if the system on which its central database resides is compromised, the security afforded by Kerberos is seriously compromised.

We cover authentication with Kerberos in Recipe 8.13. Because of the complexity of the SSPI API in Windows, we do not cover Kerberos on Windows in this book. Instead, recipes are available on our web site.

Windows NT LAN Manager (NTLM)

Windows NT LAN Manager is a password-based protocol that avoids sending the password out over the wire by using a challenge-response protocol, meaning that the two ends each prove to the other that they have the secret, without someone actually sending the secret. Therefore, NTLM (which does not itself provide a secure channel) can be used over an insecure channel. However, it is still subject to a number of password attacks on the server, particularly because the server must store the actual password.

Windows uses NTLM for network authentication and for interactive authentication on standalone systems. Beginning with Windows 2000, Kerberos is the preferred network authentication method on Windows, but NTLM can still be used in the absence of a Kerberos infrastructure.

Because of the complexity of the SSPI API in Windows, we do not cover authentication with NTLM in this book. Instead, recipes are available on our web site.

SSL certificate-based checking

Secure Sockets Layer (SSL) and its successor, Transport Layer Security (TLS), use certificates to allow entities to identify entities in a system. Certificates are verified using a PKI where a mutually trusted third party vouches for the identity of a certificate holder. See Recipe 10.1 for an introduction to certificates and PKI.

Certificates are obtained from a trusted third party known as a certification authority (CA), which digitally signs the certificate with its own private key. If the CA is trusted, and its signature on the certificate is valid, the certificate can be trusted. Certificates typically also contain other important pieces of information that must also be verified—for example, validity dates and the name of the entity that will present the certificate.

To be effective, certificates require the mutually trusted third party. One of the primary problems with certificates and PKI is one of revocation. If the private key for a certificate is compromised, how is everyone supposed to know that the certificate should no longer be trusted? CAs periodically publish lists known as certificate revocation lists (CRLs) that identify all of the certificates that have been revoked and should no longer be trusted, but it is the responsibility of the party verifying a certificate to seek out these lists and use them properly. In addition, there is often a significant window of time between when a CA revokes a certificate and when a new CRL is published.

SSL is widely deployed and works sufficiently well for many applications; however, because it is difficult to use properly, it is often deployed insecurely. We discuss certificate verification in Recipe 10.4 through Recipe 10.7.

See Also

§ Thinking Putty article on defeating biometric fingerprint scanners: http://www.puttyworld.com/thinputdeffi.html

§ RFC 1510: The Kerberos Network Authentication Service (V5)

§ RFC 2617: HTTP Authentication: Basic and Digest Access Authentication

§ Recipe 4.10, Recipe 8.8, Recipe 8.9, Recipe 8.10, Recipe 8.11, Recipe 8.12, Recipe 8.13, Recipe 8.16, Recipe 8.21, Recipe 10.1, Recipe 10.4, Recipe 10.5, Recipe 10.6, Recipe 10.7

8.2. Getting User and Group Information on Unix

Problem

You need to discover information about a user or group, and you have a username or user ID or a group name or ID.

Solution

On Unix, user and group names correspond to numeric identifiers. Most system calls require numeric identifiers upon which to operate, but names are typically easier for people to remember. Therefore, most user interactions involve the use of names rather than numbers. The standard C runtime library provides several functions to map between names and numeric identifiers for both groups and users.

Discussion

Declarations for the functions and data types needed to map between names and numeric identifiers for users are in the header file pwd.h . Strictly speaking, mapping functions do not actually exist. Instead, one function provides the ability to look up user information using the user's numeric identifier, and another function provides the ability to look up user information using the user's name.

The function used to look up user information by numeric identifier has the following signature:

#include <sys/types.h>

#include <pwd.h>

struct passwd *getpwuid(uid_t uid);

The function used to look up user information by name has the following signature:

#include <sys/types.h>

#include <pwd.h>

struct passwd *getpwnam(const char *name);

Both functions return a pointer to a structure allocated internally by the runtime library. One side effect of this behavior is that successive calls replace the information from the previous call. Another is that the functions are not thread-safe. If either function fails to find the requested user information, a NULL pointer is returned.

The contents of the passwd structure differ across platforms, but some fields remain the same everywhere. Of particular interest to us in this recipe are the two fields pw_name and pw_uid . These two fields are what enable mapping between names and numeric identifiers. For example, the following two functions will obtain mappings:

#include <sys/types.h>

#include <pwd.h>

#include <string.h>

int spc_user_getname(uid_t uid, char **name) {

struct passwd *pw;

if (!(pw = getpwuid(uid)) ) {

endpwent( );

return -1;

}

*name = strdup(pw->pw_name);

endpwent( );

return 0;

}

int spc_user_getuid(char *name, uid_t *uid) {

struct passwd *pw;

if (!(pw = getpwnam(name))) {

endpwent( );

return -1;

}

*uid = pw->pw_uid;

endpwent( );

return 0;

}

Note that spc_user_getname( ) will dynamically allocate a buffer to return the user's name, which must be freed by the caller. Also notice the use of the function endpwent( ) . This function frees any resources allocated by the lookup functions. Its use is important because failure to free the resources can cause unexpected leaking of memory, file descriptors, socket descriptors, and so on. Exactly what types of resources may be leaked vary depending on the underlying implementation, which may differ not only from platform to platform, but also from installation to installation.

In our example code, we call endpwent( ) after every lookup operation, but this isn't necessary if you need to perform multiple lookups. In fact, if you know you will be performing a large number of lookups, always calling endpwent( ) after each one is wasteful. Any number of lookup operations may be performed safely before eventually calling endpwent( ).

Looking up group information is similar to looking up user information. The header file grp.h contains the declarations for the needed functions and data types. Two functions similar to getpwnam( ) and getpwuid( ) also exist for groups:

#include <sys/types.h>

#include <grp.h>

struct group *getgrgid(gid_t gid);

struct group *getgrnam(const char *name);

These two functions behave as their user counterparts do. Thus, we can use them to perform name-to-numeric-identifier mappings, and vice versa. Just as user information lookups require a call to endpwent( ) to clean up any resources allocated during the lookup, group information lookups require a call to endgrent( ) to do the same.

#include <sys/types.h>

#include <grp.h>

#include <string.h>

int spc_group_getname(gid_t gid, char **name) {

struct group *gr;

if (!(gr = getgruid(gid)) ) {

endgrent( );

return -1;

}

*name = strdup(gr->gr_name);

endgrent( );

return 0;

}

int spc_group_getgid(char *name, gid_t *gid) {

struct group *gr;

if (!(gr = getgrnam(name))) {

endgrent( );

return -1;

}

*gid = gr->gr_gid;

endgrent( );

return 0;

}

Groups may contain more than a single user. Theoretically, groups may contain any number of members, but be aware that some implementations may impose artificial limits on the number of users that may belong to a group.

The group structure that is returned by either getgrnam( ) or getgrgid( ) contains a field called gr_mem that is an array of strings containing the names of all the member users. The last element in the array will always be a NULL pointer. Determining whether a user is a member of a group is a simple matter of iterating over the elements in the array, comparing each one to the name of the user for which to look:

#include <sys/types.h>

#include <grp.h>

#include <string.h>

int spc_group_ismember(char *group_name, char *user_name) {

int i;

struct group *gr;

if (!(gr = getgrnam(group_name))) {

endgrent( );

return 0;

}

for (i = 0; gr->gr_mem[i]; i++)

if (!strcmp(user_name, gr->gr_mem[i])) {

endgrent( );

return 1;

}

endgrent( );

return 0;

}

8.3. Getting User and Group Information on Windows

Problem

You need to discover information about a user or group, and you have a username or user ID or a group name or ID.

Solution

Windows identifies users and groups using security identifiers (SIDs), which are unique, variably sized values assigned by an authority such as the local machine or a Windows NT server domain. Functions and data structures typically represent users and groups using SIDs, rather than using names.

The Win32 API provides numerous functions for manipulating SIDs, but of particular interest to us in this recipe are the functions LookupAccountName( ) and LookupAccountSid( ), which are used to map between names and SIDs.

Discussion

The Win32 API function LookupAccountName( ) is used to find the SID that corresponds to a name. You can use it to obtain information about a name on either the local system or a remote system. While it might seem that mapping a name to a SID is a simple operation, LookupAccountName( )actually requires a large number of arguments to allow it to complete its work.

LookupAccountName( ) has the following signature:

BOOL LookupAccountName(LPCTSTR lpSystemName, LPCTSTR lpAccountName, PSID Sid,

LPDWORD cbSid, LPTSTR ReferencedDomainName,

LPDWORD cbReferencedDomainName, PSID_NAME_USE peUse);

This function has the following arguments:

lpSystemName

String representing the name of the remote system on which to look up the name. If you specify this argument as NULL, the lookup will be done on the local system.

lpAccountName

String representing the name of the user or group to look up. This argument may not be specified as NULL.

Sid

Buffer into which the SID will be written. Initially, you may specify this argument as NULL to determine how large a buffer is required to hold the SID.

cbSid

Pointer to an integer that both specifies the size of the buffer to receive the SID, and receives the size of the buffer required for the SID.

ReferencedDomainName

Buffer into which the domain name where the user or group name was found is to be written. Initially, you may specify this argument as NULL to determine how large a buffer is required to hold the domain name.

cbReferencedDomainName

Pointer to an integer that both specifies the size of the buffer to receive the domain name, and receives the size of the buffer required for the domain name.

peUse

Pointer to an enumeration that receives the type of SID to which the looked-up name corresponds. The most commonly returned values are SidTypeUser (1) and SidTypeGroup (2).

The following function, SpcLookupName( ) , is essentially a wrapper around LookupAccountName( ). It handles the nuances of performing user and group name lookup, including allocating the necessary buffers and error conditions. If the name is successfully found, the return will be a pointer to a dynamically allocated SID structure, which you must later free using LocalFree( ). If the name could not be found, NULL will be returned, and GetLastError( ) will return ERROR_NONE_MAPPED. If any other kind of error occurs, SpcLookupName( ) will return NULL, and GetLastError( ) will return the relevant error code.

#include <windows.h>

PSID SpcLookupName(LPCTSTR lpszSystemName, LPCTSTR lpszAccountName) {

PSID Sid;

DWORD cbReferencedDomainName, cbSid;

LPTSTR ReferencedDomainName;

SID_NAME_USE eUse;

cbReferencedDomainName = cbSid = 0;

if (LookupAccountName(lpszSystemName, lpszAccountName, 0, &cbSid,

0, &cbReferencedDomainName, &eUse)) {

SetLastError(ERROR_NONE_MAPPED);

return 0;

}

if (GetLastError( ) != ERROR_INSUFFICIENT_BUFFER) return 0;

if (!(Sid = (PSID)LocalAlloc(LMEM_FIXED, cbSid))) return 0;

ReferencedDomainName = (LPTSTR)LocalAlloc(LMEM_FIXED, cbReferencedDomainName);

if (!ReferencedDomainName) {

LocalFree(Sid);

return 0;

}

if (!LookupAccountName(lpszSystemName, lpszAccountName, Sid, &cbSid,

ReferencedDomainName, &cbReferencedDomainName, &eUse)) {

LocalFree(ReferencedDomainName);

LocalFree(Sid);

return 0;

}

LocalFree(ReferencedDomainName);

return Sid;

}

The Win32 API function LookupAccountSid( ) is used to find the name that corresponds to a SID. You can use it to obtain information about a SID on either the local system or a remote system. While it might seem that mapping a SID to a name is a simple operation, LookupAccountSid( )actually requires a large number of arguments to allow it to complete its work.

LookupAccountSid( ) has the following signature:

BOOL LookupAccountSid(LPCTSTR lpSystemName, PSID Sid,LPTSTR Name, LPDWORD cbName,

LPTSTR ReferencedDomainName, LPDWORD cbReferencedDomainName,

PSID_NAME_USE peUse);

This function has the following arguments:

lpSystemName

String representing the name of the remote system on which to look up the SID. If you specify this argument as NULL, the lookup will be done on the local system.

Sid

Buffer containing the SID to look up. This argument may not be specified as NULL.

Name

Buffer into which the name will be written. Initially, you may specify this argument as NULL to determine how large a buffer is required to hold the name.

cbName

Pointer to an integer that both specifies the size of the buffer to receive the name, and receives the size of the buffer required for the name.

ReferencedDomainName

Buffer into which the domain name where the SID was found is to be written. Initially, you may specify this argument as NULL to determine how large a buffer is required to hold the domain name.

cbReferencedDomainName

Pointer to an integer that both specifies the size of the buffer to receive the domain name, and receives the size of the buffer required for the domain name.

peUse

Pointer to an enumeration that receives the type of SID to which the looked-up SID corresponds. The most commonly returned values are SidTypeUser (1) and SidTypeGroup (2).

The following function, SpcLookupSid( ) , is essentially a wrapper around LookupAccountSid( ). It handles the nuances of performing SID lookup, including allocating the necessary buffers and error conditions. If the SID is successfully found, the return will be a pointer to a dynamically allocated buffer containing the user or group name, which you must later free using LocalFree( ). If the SID could not be found, NULL will be returned, and GetLastError( ) will return ERROR_NONE_MAPPED. If any other kind of error occurs, SpcLookupSid( ) will return NULL, and GetLastError( ) will return the relevant error code.

#include <windows.h>

LPTSTR SpcLookupSid(LPCTSTR lpszSystemName, PSID Sid) {

DWORD cbName, cbReferencedDomainName;

LPTSTR lpszName, ReferencedDomainName;

SID_NAME_USE eUse;

cbName = cbReferencedDomainName = 0;

if (LookupAccountSid(lpszSystemName, Sid, 0, &cbName,

0, &cbReferencedDomainName, &eUse)) {

SetLastError(ERROR_NONE_MAPPED);

return 0;

}

if (GetLastError( ) != ERROR_INSUFFICIENT_BUFFER) return 0;

if (!(lpszName = (LPTSTR)LocalAlloc(LMEM_FIXED, cbName))) return 0;

ReferencedDomainName = (LPTSTR)LocalAlloc(LMEM_FIXED, cbReferencedDomainName);

if (!ReferencedDomainName) {

LocalFree(lpszName);

return 0;

}

if (!LookupAccountSid(lpszSystemName, Sid, lpszName, &cbName,

ReferencedDomainName, &cbReferencedDomainName, &eUse)) {

LocalFree(ReferencedDomainName);

LocalFree(lpszName);

return 0;

}

LocalFree(ReferencedDomainName);

return lpszName;

}

8.4. Restricting Access Based on Hostname or IP Address

Problem

You want to restrict access to the network based on hostname or IP address.

Solution

First, get the IP address of the remote connection, and verify that the address has a hostname associated with it. To ensure that the hostname is not being spoofed (i.e., the address reverses to one hostname, but the hostname does not map to that IP address), look up the hostname and compare the resulting IP address with the IP address of the connection; if the IP addresses do not match, the hostname is likely being spoofed.

Next, compare the IP address and/or hostname with a set of rules that determine whether to grant the remote connection access.

Discussion

WARNING

Restricting access based on the remote connection's IP address or hostname is risky at best. The hostname and/or IP address could be spoofed, or the remote system could be compromised with an attacker in control. Address-based access control is no substitute for strong authentication methods.

The first step in restricting access from the network based on hostname or IP address is to ensure that the remote connection is not engaging in a DNS spoofing attack. No foolproof method exists for guaranteeing that the address is not being spoofed, though the code presented here can provide a reasonable assurance for most cases. In particular, if the DNS server for the domain that an IP address reverse-maps to has been compromised, there is no way to know.

The first code listing that we present implements a worker function, check_spoofdns( ) , which performs a set of DNS lookups and compares the results. The first lookup retrieves the hostname to which an IP address maps. An IP address does not necessarily have to reverse-map to a hostname, so if this first lookup yields no mapping, it is generally safe to assume that no spoofing is taking place.

If the IP address does map to a hostname, a lookup is performed on that hostname to retrieve the IP address or addresses to which it maps. The hostname should exist, but if it does not, the connection should be considered suspect. Although it is possible that something funny is going on with the remote connection, the lack of a name-to- address mapping could be innocent.

Each of the addresses returned by the hostname lookup is compared against the IP address of the remote connection. If the IP address of the remote connection is not matched, the likelihood of a spoofing attack is high, though still not guaranteed. If the IP address of the remote connection is matched, the code assumes that no spoofing attack is taking place.

#include <sys/types.h>

#include <sys/socket.h>

#include <netinet/in.h>

#include <arpa/inet.h>

#include <netdb.h>

#include <errno.h>

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <ctype.h>

#define SPC_ERROR_NOREVERSE 1 /* IP address does not map to a hostname */

#define SPC_ERROR_NOHOSTNAME 2 /* Reversed hostname does not exist */

#define SPC_ERROR_BADHOSTNAME 3 /* IP addresses do not match */

#define SPC_ERROR_HOSTDENIED 4 /* TCP/SPC Wrappers denied host access */

static int check_spoofdns(int sockfd, struct sockaddr_in *addr, char **name) {

int addrlen, i;

char *hostname;

struct hostent *he;

*name = 0;

for (;;) {

addrlen = sizeof(struct sockaddr_in);

if (getpeername(sockfd, (struct sockaddr *)addr, &addrlen) != -1) break;

if (errno != EINTR && errno != EAGAIN) return -1;

}

for (;;) {

he = gethostbyaddr((char *)&addr->sin_addr, sizeof(addr->sin_addr), AF_INET);

if (he) break;

if (h_errno = = HOST_NOT_FOUND) {

endhostent( );

return SPC_ERROR_NOREVERSE;

}

if (h_errno != TRY_AGAIN) {

endhostent( );

return -1;

}

}

hostname = strdup(he->h_name);

for (;;) {

if ((he = gethostbyname(hostname)) != 0) break;

if (h_errno = = HOST_NOT_FOUND) {

endhostent( );

free(hostname);

return SPC_ERROR_NOHOSTNAME;

}

if (h_errno != TRY_AGAIN) {

endhostent( );

free(hostname);

return -1;

}

}

/* Check all IP addresses returned for the hostname. If one matches, return

* 0 to indicate that the address is not likely being spoofed.

*/

for (i = 0; he->h_addr_list[i]; i++)

if (*(in_addr_t *)he->h_addr_list[i] = = addr->sin_addr.s_addr) {

*name = hostname;

endhostent( );

return 0;

}

/* No matches. Spoofing very likely */

free(hostname);

endhostent( );

return SPC_ERROR_BADHOSTNAME;

}

The next code listing contains several worker functions as well as the function spc_host_init( ) , which requires a single argument that is the name of a file from which access restriction information is to be read. The access restriction information is read from the file and stored in an in-memory list, which is then used by spc_host_check( ) (we'll describe that function shortly).

Access restriction information read by spc_host_init( ) is required to be in a very specific format. Whitespace is mostly ignored, and lines beginning with a hash mark (#) or a semicolon (;) are considered comments and ignored. Any other line in the file must begin with either "allow:" or "deny:" to indicate the type of rule.

Following the rule type is a whitespace-separated list of addresses that are to be either allowed or denied access. Addresses may be hostnames or IP addresses. IP addresses may be specified as an address and mask or simply as an address. In the former case, the address may contain up to four parts, where each part must be expressed in decimal (ranging from 0 to 255), and a period (.) must be used to separate them. A forward slash (/) separates the address from the mask, and the mask is expressed as the number of bits to set. Table 8-1 lists example representations that are accepted as valid.

Table 8-1. Example address representations accepted by spc_host_init( )

If any errors are encountered when parsing the access restriction data file, a message containing the name of the file and the line number is printed. Parsing of the file then continues on the next line. Fatal errors (e.g., out of memory) are also noted in a similar fashion, but parsing terminates immediately and any data successfully parsed so far is thrown away.

When spc_host_init( ) completes successfully (even if parse errors are encountered), it will return 1; otherwise, it will return 0.

#define SPC_HOST_ALLOW 1

#define SPC_HOST_DENY 0

typedef struct {

int action;

char *name;

in_addr_t addr;

in_addr_t mask;

} spc_hostrule_t;

static int spc_host_rulecount;

static spc_hostrule_t *spc_host_rules;

static int add_rule(spc_hostrule_t *rule) {

spc_hostrule_t *tmp;

if (!(spc_host_rulecount % 256)) {

if (!(tmp = (spc_hostrule_t *)realloc(spc_host_rules,

sizeof(spc_host_rulecount) * (spc_host_rulecount + 256))))

return 0;

spc_host_rules = tmp;

}

spc_host_rules[spc_host_rulecount++] = *rule;

return 1;

}

static void free_rules(void) {

int i;

if (spc_host_rules) {

for (i = 0; i < spc_host_rulecount; i++)

if (spc_host_rules[i].name) free(spc_host_rules[i].name);

free(spc_host_rules);

spc_host_rulecount = 0;

spc_host_rules = 0;

}

}

static in_addr_t parse_addr(char *str) {

int shift = 24;

char *tmp;

in_addr_t addr = 0;

for (tmp = str; *tmp; tmp++) {

if (*tmp = = '.') {

*tmp = 0;

addr |= (atoi(str) << shift);

str = tmp + 1;

if ((shift -= 8) < 0) return INADDR_NONE;

} else if (!isdigit(*tmp)) return INADDR_NONE;

}

addr |= (atoi(str) << shift);

return htonl(addr);

}

static in_addr_t make_mask(int bits) {

in_addr_t mask;

bits = (bits < 0 ? 0 : (bits > 32 ? 32 : bits));

for (mask = 0; bits--; mask |= (1 << (31 - bits)));

return htonl(mask);

}

int spc_host_init(const char *filename) {

int lineno = 0;

char *buf, *p, *slash, *tmp;

FILE *f;

size_t bufsz, len = 0;

spc_hostrule_t rule;

if (!(f = fopen(filename, "r"))) return 0;

if (!(buf = (char *)malloc(256))) {

fclose(f);

return 0;

}

while (fgets(buf + len, bufsz - len, f) != 0) {

len += strlen(buf + len);

if (buf[len - 1] != '\n') {

if (!(buf = (char *)realloc((tmp = buf), bufsz += 256))) {

fprintf(stderr, "%s line %d: out of memory\n", filename, ++lineno);

free(tmp);

fclose(f);

free_rules( );

return 0;

}

continue;

}

buf[--len] = 0;

lineno++;

for (tmp = buf; *tmp && isspace(*tmp); tmp++) len--;

while (len && isspace(tmp[len - 1])) len--;

tmp[len] = 0;

len = 0;

if (!tmp[0] || tmp[0] = = '#' || tmp[0] = = ';') continue;

memset(&rule, 0, sizeof(rule));

if (strncasecmp(tmp, "allow:", 6) && strncasecmp(tmp, "deny:", 5)) {

fprintf(stderr, "%s line %d: parse error; continuing anyway.\n",

filename, lineno);

continue;

}

if (!strncasecmp(tmp, "deny:", 5)) {

rule.action = SPC_HOST_DENY;

tmp += 5;

} else {

rule.action = SPC_HOST_ALLOW;

tmp += 6;

}

while (*tmp && isspace(*tmp)) tmp++;

if (!*tmp) {

fprintf(stderr, "%s line %d: parse error; continuing anyway.\n",

filename, lineno);

continue;

}

for (p = tmp; *p; tmp = p) {

while (*p && !isspace(*p)) p++;

if (*p) *p++ = 0;

if ((slash = strchr(tmp, '/')) != 0) {

*slash++ = 0;

rule.name = 0;

rule.addr = parse_addr(tmp);

rule.mask = make_mask(atoi(slash));

} else {

if (inet_addr(tmp) = = INADDR_NONE) rule.name = strdup(tmp);

else {

rule.name = 0;

rule.addr = inet_addr(tmp);

rule.mask = 0xFFFFFFFF;

}

}

if (!add_rule(&rule)) {

fprintf(stderr, "%s line %d: out of memory\n", filename, lineno);

free(buf);

fclose(f);

free_rules( );

return 0;

}

}

}

free(buf);

fclose(f);

return 1;

}

Finally, the function spc_host_check( ) performs access restriction checks. If the remote connection should be allowed, the return will be 0. If some kind of error unrelated to access restriction occurs (e.g., out of memory, bad socket descriptor, etc.), the return will be -1. Otherwise, one of the following error constants may be returned:

SPC_ERROR_NOREVERSE

Indicates that the IP address of the remote connection has no reverse mapping. If strict checking is not being done, this error code will not be returned.

SPC_ERROR_NOHOSTNAME

Indicates that the IP address of the remote connection reverse-maps to a hostname that does not map to any IP address. This condition does not necessarily indicate that a DNS spoofing attack is taking place; however, we do recommend that you treat it as such.

SPC_ERROR_BADHOSTNAME

Indicates that the likelihood of a DNS spoofing attack is high. The IP address of the remote connection does not match any of the IP addresses that its hostname maps to.

SPC_ERROR_HOSTDENIED

Indicates that no DNS spoofing attack is believed to be taking place, but the access restriction rules have matched the remote address with a deny rule.

The function spc_host_check( ) has the following signature:

int spc_host_check(int sockfd, int strict, int action);

This function has the following arguments:

sockfd

Socket descriptor for the remote connection. This argument is used solely to obtain the IP address of the remote connection.

strict

Boolean value indicating whether strict DNS spoofing checks are to be done. If this argument is specified as 0, IP addresses that do not have a reverse mapping will be allowed; otherwise, SPC_ERROR_NOREVERSE will be returned for such connections.

action

Default action to take if the remote IP address does not match any of the defined access restriction rules. It may be specified as either SPC_HOST_ALLOW or SPC_HOST_DENY. Any other value will be treated as equivalent to SPC_HOST_DENY.

You may use spc_host_check( ) without using spc_host_init( ), in which case it will essentially only perform DNS spoofing checks. If you do not use spc_host_init( ), spc_host_check( ) will have an empty rule set, and it will always use the default action if the remote connection passes the DNS spoofing checks.

int spc_host_check(int sockfd, int strict, int action) {

int i, rc;

char *hostname;

struct sockaddr_in addr;

if ((rc = check_spoofdns(sockfd, &addr, &hostname)) = = -1) return -1;

if (rc && (rc != SPC_ERROR_NOREVERSE || strict)) return rc;

for (i = 0; i < spc_host_rulecount; i++) {

if (spc_host_rules[i].name) {

if (hostname && !strcasecmp(hostname, spc_host_rules[i].name)) {

free(hostname);

return (spc_host_rules[i].action = = SPC_HOST_ALLOW);

}

} else {

if ((addr.sin_addr.s_addr & spc_host_rules[i].mask) = =

spc_host_rules[i].addr) {

free(hostname);

return (spc_host_rules[i].action = = SPC_HOST_ALLOW);

}

}

}

if (hostname) free(hostname);

return (action = = SPC_HOST_ALLOW);

}

8.5. Generating Random Passwords and Passphrases

Problem

You would like to avoid problems with easy-to-guess passwords by randomly generating passwords that are difficult to guess.

Solution

For passwords, choose random characters from an acceptable set of characters using spc_rand_range( ) (see Recipe 11.11). For passphrases, choose random words from a predefined list of acceptable words.

Discussion

In many situations, it may be desirable to present a user with a pregenerated password. For example, if the user is not present at the time of account creation, you will want to generate a reasonably secure password for the account and deliver the password to the user via some secure mechanism such as in person or over the phone.

Randomly generated passwords are also useful when you want to enforce safe password requirements. If the user cannot supply an adequately secure password after a certain number of attempts, it may be best to present her with a randomly generated password to use, which will most likely pass all of the requirements tests.

The primary disadvantage of randomly generated passwords is that they are usually difficult to memorize (and type), which often results in users writing them down. In many cases, however, this is a reasonable trade-off.

The basic strategy for generating a random password is to define a character set that contains all of the characters that are valid for the type of password you are generating, then choose random members of that set until enough characters have been chosen to meet the length requirements.

The string spc_password_characters defines the character set from which random password characters are chosen. The function spc_generate_password( ) requires a buffer and the size of the buffer as arguments. The buffer is filled with randomly chosen password characters and is properly NULL-terminated. As written, the function will always succeed, and it will return a pointer to the buffer filled with the randomly generated password.

#include <string.h>

static char *spc_password_characters = "abcdefghijklmnopqrstuvwxyz0123456789"

"ABCDEFGHIJKLMNOPQRSTUVWXYZ!@#$%^&*( )"

"-=_+;[ ]{ }\\|,./<>?;";

char *spc_generate_password(char *buf, size_t bufsz) {

size_t choices, i;

choices = strlen(spc_password_characters) - 1;

for (i = 0; i < bufsz - 1; i++) /* leave room for NULL terminator */

buf[i] = spc_password_characters[spc_rand_range(0, choices)];

buf[bufsz - 1] = 0;

return buf;

}

Although there is no conceptual difference between a password and a passphrase, each has different connotations to users:

Password

Typically one word, short or medium in length (usually under 10 characters, and rarely longer than 15).

Passphrases

Usually short sentences, or a number of unrelated words grouped together with no coherent meaning.

While a passphrase can be a long string of random characters and a password can be multiple words, the typical passphrase is a sentence that the user picks, usually because it is related to something that is easily remembered. Even though their length and freeform nature make passphrases much harder to run something such as the Crack program on, they are still subject to guessing.

For example, if you are trying to guess someone's passphrase, and you know that person's favorite song, trying some lyrics from that song may prove to be a very good strategy for discovering what the passphrase is. It is important to choose a passphrase carefully. It should be something easy to remember, but it should not be something that someone who knows a little bit about you will be able to guess quickly.

As with passwords, there are times when a randomly generated passphrase is needed. The strategy for randomly generating a passphrase is not altogether different from randomly generating a password. Instead of using single characters, whole words are used, separated by spaces.

The function spc_generate_passphrase( ) uses a data file to obtain the list of words from which to choose. The words in the file should be ordered one per line, and they should not be related in any way. In addition, the selection of words should be sufficiently large that a brute-force attack on generated passphrases is not feasible. Most Unix systems have a file, /usr/share/dict/words, that contains a large number of words from the English dictionary.

This implementation of spc_generate_passphrase( ) keeps the word data file open and builds an in-memory list of the offsets into the file for the beginning of each word. The function keeps offsets instead of the whole words as a memory-saving measure, although with a large enough list of words, the amount of memory required for this list is not insignificant. To choose a word, the function chooses an index into the list of offsets, moves the file pointer to the proper offset, and reads the word. Word lengths can be determined by computing the difference between the next offset and the selected one.

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#define SPC_WORDLIST_FILE "/usr/share/dict/words"

static FILE *spc_wordlist_file;

static size_t *spc_wordlist_offsets;

static size_t spc_wordlisthortest;

static unsigned int spc_wordlist_count;

static int load_wordlist(void) {

char buf[80];

FILE *f;

size_t *offsets, shortest, *tmp;

unsigned int count;

if (!(f = fopen(SPC_WORDLIST_FILE, "r"))) return 0;

if (!(offsets = (size_t *)malloc(sizeof(size_t) * 1024))) {

fclose(f);

return 0;

}

count = 0;

shortest = ~0;

offsets[0] = 0;

while (fgets(buf, sizeof(buf), f))

if (buf[strlen(buf) - 1] = = '\n') {

if (!((count + 1) % 1024)) {

if (!(offsets = (size_t *)realloc((tmp = offsets),

sizeof(size_t) * (count + 1025)))) {

fclose(f);

free(tmp);

return 0;

}

}

offsets[++count] = ftell(f);

if (offsets[count] - offsets[count - 1] < shortest)

shortest = offsets[count] - offsets[count - 1];

}

if (!feof(f)) {

fclose(f);

free(offsets);

return 0;

}

if (ftell(f) - offsets[count - 1] < shortest)

shortest = ftell(f) - offsets[count - 1];

spc_wordlist_file = f;

spc_wordlist_offsets = offsets;

spc_wordlist_count = count;

spc_wordlisthortest = shortest - 1; /* shortest includes NULL terminator */

return 1;

}

static int get_wordlist_word(unsigned int num, char *buf, size_t bufsz) {

size_t end, length;

if (num >= spc_wordlist_count) return -1;

if (num = = spc_wordlist_count - 1) {

fseek(spc_wordlist_file, 0, SEEK_END);

end = ftell(spc_wordlist_file);

} else end = spc_wordlist_offsets[num + 1];

length = end - spc_wordlist_offsets[num]; /* includes NULL terminator */

if (length > bufsz) return 0;

if (fseek(spc_wordlist_file, spc_wordlist_offsets[num], SEEK_SET) = = -1)

return -1;

fread(buf, length, 1, spc_wordlist_file);

buf[length - 1] = 0;

return 1;

}

char *spc_generate_passphrase(char *buf, size_t bufsz) {

int attempts = 0, rc;

char *outp;

size_t left, len;

unsigned int idx;

if (!spc_wordlist_file && !load_wordlist( )) return 0;

outp = buf;

left = bufsz - 1;

while (left > spc_wordlisthortest) {

idx = spc_rand_range(0, spc_wordlist_count - 1);

rc = get_wordlist_word(idx, outp, left + 1);

if (rc = = -1) return 0;

else if (!rc && ++attempts < 10) continue;

else if (!rc) break;

len = strlen(outp) + 1;

*(outp + len - 1) = ' ';

outp += len;

left -= len;

}

*(outp - 1) = 0;

return buf;

}

When spc_generate_passphrase( ) is called, it opens the data file containing the words to choose from and leaves it open. In addition, depending on the size of the file, it may allocate a sizable amount of memory that remains allocated. When you're done generating passphrases, you should callspc_generate_cleanup( ) to close the data file and free the memory allocated by spc_generate_passphrase( ).

void spc_generate_cleanup(void) {

if (spc_wordlist_file) fclose(spc_wordlist_file);

if (spc_wordlist_offsets) free(spc_wordlist_offsets);

spc_wordlist_file = 0;

spc_wordlist_offsets = 0;

spc_wordlist_count = 0;

spc_wordlisthortest = 0;

}

See Also

Recipe 11.11

8.6. Testing the Strength of Passwords

Problem

You want to ensure that passwords are not easily guessable or crackable.

Solution

Use CrackLib, which is available from http://www.crypticide.org/users/alecm/.

Discussion

When users are allowed to choose their own passwords, a large number of people will inevitably choose passwords that are relatively simple, making them either easy to guess or easy to crack. Secure passwords are often difficult for people to remember, so they tend to choose passwords that are easy to remember, but not very secure. Some of the more common choices are simple words, dates, names, or some variation of these things.

Recognizing this tendency, Alec Muffett developed a program named Crack that takes an encrypted password from the system password file and attempts to guess—or crack—the password. It works by trying words found in a dictionary, combinations of the user's login name and real name, and simple patterns and combinations of words.

CrackLib is the core functionality of Crack, extracted into a library for the intended purpose of including it in password-setting and -changing programs to prevent users from choosing insecure passwords. It exports a simple API, consisting of a single function, FascistCheck( ) , which has the following signature:

char *FascistCheck(char *pw, char *dictpath);

This function has the following arguments:

pw

Buffer containing the password that the user is attempting to use.

dictpath

Buffer containing the name of a file that contains a list of dictionary words for CrackLib to use in its checks.

The dictionary file used by CrackLib is a binary data file (actually, several of them) that is normally built as part of building CrackLib itself. A small utility built as part of CrackLib (but not normally installed) reads in a text file containing a list of words one per line, and builds the binary dictionary files that can be used by CrackLib.

If the FascistCheck( ) function is unable to match the password against the words in the dictionary and its other tests, it will return NULL to indicate that the password is secure and may be used safely. Otherwise, an error message (rather than an error code) is returned; it is suitable for display to the user as a reason why the password could not be accepted.

CrackLib is intended to be used on Unix systems. It relies on certain Unix-specific functions to obtain information about users. In addition, it requires a list of words (a dictionary). Porting CrackLib to Windows should not be too difficult, but we are not aware of any efforts to do so.

See Also

CrackLib by Alec Muffett: http://www.crypticide.org/users/alecm/

8.7. Prompting for a Password

Problem

You need to prompt an interactive user for a password.

Solution

On Unix systems, you can use the standard C runtime function getpass( ) if you can accept limiting passwords to _PASSWORD_LEN, which is typically defined to be 128 characters. If you want to read longer passwords, you can use the function described in the following Section 8.7.3.

On Windows, you can use the standard EDIT control with ES_PASSWORD specified as a style flag to mask the characters typed by a user.

Discussion

In the following subsections we'll look at several different approaches to prompting for passwords.

Prompting for a password on Unix using getpass( ) or readpassphrase( )

The standard C runtime function getpass( ) is the most portable way to obtain a password from a user interactively. Unfortunately, it does have several limitations that you may find unacceptable. The first is that only up to _PASSWORD_LEN (typically 128) characters may be entered; any characters after that are simply discarded. The second is that the password is stored in a statically defined buffer, so it is not thread-safe, but ordinarily this is not much of a problem because there is fundamentally no way to read from the terminal in a thread-safe manner anyway.

The getpass( ) function has the following signature:

#include <sys/types.h>

#include <unistd.h>

char *getpass(const char *prompt);

The text passed as the function's only argument is displayed on the terminal, terminal echo is disabled, and input is gathered in a buffer internal to the function until the user presses Enter. The return value from the function is a pointer to the internal buffer, which will be at most _PASSWORD_LEN + 1 bytes in size, with the additional byte left to hold the NULL terminator.

FreeBSD and OpenBSD both support an alternative function, readpassphrase( ) , that provides the underlying implementation for getpass( ). It is more flexible than getpass( ), allowing the caller to preallocate a buffer to hold a password or passphrase of any size. In addition, it also supports a variety of control flags that control its behavior.

The readpassphrase( ) function has the following signature:

#include <sys/types.h>

#include <readpassphrase.h>

char *readpassphrase(const char *prompt, char *buf, size_t bufsiz, int flags);

This function has the following arguments:

prompt

String that will be displayed to the user before accepting input.

buf

Buffer into which the input read from the interactive user will be placed.

bufsiz

Size of the buffer (in bytes) into which input read from the interactive user is placed. Up to one less byte than the size specified may be read. Any additional input is silently discarded.

flags

Set of flags that may be logically OR'd together to control the behavior of the function.

A number of flags are defined as macros in the readpassphrase.h header file. While some of the flags are mutually exclusive, some of them may be logically combined together:

RPP_ECHO_OFF

Disables echoing of the user's input on the terminal. If neither this flag nor RPP_ECHO_ON is specified, this is the default. The two flags are mutually exclusive, but if both are specified, echoing will be enabled.

RPP_ECHO_ON

Enables echoing of the user's input on the terminal.

RPP_REQUIRE_TTY

If there is no controlling tty, and this flag is specified, readpassphrase( ) will return an error; otherwise, the prompt will be written to stderr, and input will be read from stdin. When input is read from stdin, it's often not possible to disable echoing.

RPP_FORCELOWER

Causes all input from the user to be automatically converted to lowercase. This flag is mutually exclusive with RPP_FORCEUPPER; however, if both flags are specified, RPP_FORCEUPPER will take precedence.

RPP_FORCEUPPER

Causes all input from the user to be automatically converted to uppercase.

RPP_SEVENBIT

Indicates that the high bit will be stripped from all user input.

For both getpass( ) and readpassphrase( ), a pointer to the input buffer will be returned if the function completes successfully; otherwise, a NULL pointer will be returned, and the error that occurred will be stored in the global errno variable.

WARNING

Both getpass( ) and readpassphrase( ) can return an error with errno set to EINTR, which means that the input from the user was interrupted by a signal. If such a condition occurs, all input from the user up to the point when the signal was delivered will be stored in the buffer, but in the case of getpass( ), there will be no way to retrieve that data.

Once getpass( ) or readpassphrase( ) return successfully, you should perform as quickly as possible whatever operation you need to perform with the password that was obtained. Then clear the contents of the returned buffer so that the cleartext password or passphrase will not be left visible in memory to a potential attacker.

Prompting for a password on Unix without getpass( ) or readpassphrase( )

The function presented in this subsection, spc_read_password( ) , requires two arguments. The first is a prompt to be displayed to the user, and the second is the FILE object that points to the input source. If the input source is specified as NULL, spc_read_password( ) will use _PATH_TTY, which is usually defined to be /dev/tty.

The function reads as much data from the input source as memory is available to hold. It allocates an internal buffer, which grows incrementally as it is filled. If the function is successful, the return value will be a pointer to this buffer; otherwise, it will be a NULL pointer.

Note that we use the unbuffered I/O API for reading data from the input source. The unbuffered read is necessary to avoid potential odd side effects in the I/O. We cannot use the stream API because there is no way to save and restore the size of the stream buffer. That is, we cannot know whether the stream was previously buffered.

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <termios.h>

#include <signal.h>

#include <paths.h>

#define BUF_STEP 1024 /* Allocate this much space for the password, and if it gets

* this long, reallocate twice the space.

* Rinse, lather, repeat.

*/

static unsigned char *read_password(int termfd) {

unsigned char ch, *ret, *tmp;

unsigned long ctr = 0;

if (!(ret = (unsigned char *)malloc(BUF_STEP + 1))) return 0;

for (;;) {

switch (read(termfd, &ch, 1)) {

case 1:

if (ch != '\n') break;

/* FALL THROUGH */

case 0:

ret[ctr] = 0;

return ret;

default:

free(ret);

return 0;

}

ret[ctr] = ch;

if (ctr && !(ctr & BUF_STEP)) {

if (!(tmp = (unsigned char *)realloc(ret, ctr + BUF_STEP + 1))) {

free(ret);

return 0;

}

ret = tmp;

}

ctr++;

}

}

unsigned char *spc_read_password(unsigned char *prompt, FILE *term) {

int close = 0, termfd;

sigset_t saved_signals, set_signals;

unsigned char *retval;

struct termios saved_term, set_term;

if (!term) {

if (!(term = fopen(_PATH_TTY, "r+"))) return 0;

close = 1;

}

termfd = fileno(term);

fprintf(term, "%s", prompt);

fflush(term);

/* Defer interruption when echo is turned off */

sigemptyset(&set_signals);

sigaddset(&set_signals, SIGINT);

sigaddset(&set_signals, SIGTSTP);

sigprocmask(SIG_BLOCK, &set_signals, &saved_signals);

/*Save the current state and set the terminal to not echo */

tcgetattr(termfd, &saved_term);

set_term = saved_term;

set_term.c_lflag &= ~(ECHO|ECHOE|ECHOK|ECHONL);

tcsetattr(termfd, TCSAFLUSH, &set_term);

retval = read_password(termfd);

fprintf(term, "\n");

tcsetattr(termfd, TCSAFLUSH, &saved_term);

sigprocmask(SIG_SETMASK, &saved_signals, 0);

if (close) fclose(term);

return retval;

}

Prompting for a password on Windows

On Windows, prompting for a password is as simple as setting the ES_PASSWORD style flag for an EDIT control. When this flag is set, Windows will not display the characters typed by the user. Instead, the password character will be displayed for each character that is typed. By default, thepassword character is an asterisk (*), but you can change it by sending the control an EM_SETPASSWORDCHAR message with wParam set to the character to display.

Unfortunately, there is no way to prevent Windows from displaying something as the user types. The closest that can be achieved is to set the password character to a space, which will make it difficult for an onlooker to determine how many characters have been typed.

To safely retrieve the password stored in the EDIT control's internal buffer, the control should first be queried to determine how many characters it holds. Allocate a buffer to hold the data and query the data from the control. The control will make a copy of the data but leave the original internal buffer unchanged.

To be safe, it's a good idea to set the contents of the buffer to clear the password from internal memory used by the EDIT control. Simply setting the control's internal buffer to an empty string is not sufficient. Instead, set a string that is the length of the string retrieved, then set an empty string if you wish. For example:

#include <windows.h>

BOOL IsPasswordValid(HWND hwndPassword) {

BOOL bValid = FALSE;

DWORD dwTextLength;

LPTSTR lpText;

if (!(dwTextLength = (DWORD)SendMessage(hwndPassword, WM_GETTEXTLENGTH, 0, 0)))

return FALSE;

lpText = (LPTSTR)LocalAlloc(LMEM_FIXED, (dwTextLength + 1) * sizeof(TCHAR));

if (!lpText) return FALSE;

SendMessage(hwndPassword, WM_GETTEXT, dwTextLength + 1, (LPARAM)lpText);

/* Do something to validate the password */

while (dwTextLength--) *(lpText + dwTextLength) = ' ';

SendMessage(hwndPassword, WM_SETTEXT, 0, (LPARAM)lpText);

LocalFree(lpText);

return bValid;

}

WARNING

Other processes running on the same machine can access the contents of your edit control. Unfortunately, the best mitigation strategy, at this time, is to get rid of the edit control as soon as possible.

8.8. Throttling Failed Authentication Attempts

Problem

You want to prevent an attacker from making too many attempts at guessing a password through normal interactive means.

Solution

It's best to use a protocol where such attacks don't leak any information about a password, such as a public key-based mechanism.

Delay program execution after a failed authentication attempt. For each additional failure, increase the delay before allowing the user to make another attempt to authenticate.

Discussion

Throttling failed authentication attempts is a balance between allowing legitimate users who simply mistype a password or passphrase to have a quick retry and delaying attackers who are trying to brute-force passwords or passphrases.

Our recommended strategy has three variables that control how it delays repeated authentication attempts:

Maximum number of attempts

If this limit is reached, the authentication should be considered a complete failure, resulting in a disconnection of the network connection or shutting down of the program that requires authentication. A reasonable limit on the maximum number of allowed authentication attempts is three, or perhaps five at most.

Maximum number of failed attempts allowed before enabling throttling

In general, it is reasonable to allow one or two failed attempts before instituting delays, depending on the maximum number of allowed authentication failures.

Number of seconds to delay between successive authentication attempts

For each successive failure, the delay increases exponentially. For example, if the base number of seconds to delay is set to two, the first delay will be two seconds, the second delay will be four seconds, the third delay will be eight seconds, and so on. A reasonable starting delay is generally one or two seconds, but depending on the settings you choose for the first two variables, you may want to increase the starting delay. In particular, if you allow a large number of attempts, it is probably a good idea to increase the delay.

The best way to institute a delay depends entirely upon the architecture of your program. If authentication is being performed over a network in a single-threaded server that is multiplexing connections with select( ) or poll( ), the best option may be to compute the future time at which the next authentication attempt will be accepted, and ignore any input until that time arrives.

When authenticating a user interactively on a terminal on Unix, the best solution is likely to be to use the sleep( ) function. On Windows, there is no strict equivalent. The Win32 API functions Sleep( ) and SleepEx( ) will both return immediately—regardless of the specified wait time—if there are no other threads of equal priority waiting to run.

WARNING

Some of these techniques can increase the risk of denial-of-service attacks.

In a GUI environment, any authentication dialog presented to the user will have a button labeled "OK" or some equivalent. When a delay must be made, disable the button for the duration of the delay, then enable it. On Windows, this is easily accomplished using timers.

The following function, spc_throttle( ) , computes the number of seconds to delay based on the three variables we've described and the number of failed authentication attempts. It has four arguments:

attempts

Pointer to an integer used to count the number of failed attempts. Initially, the value of the integer to which it points should be zero, and each call to spc_throttle( ) will increment it by one.

max_attempts

Maximum number of attempts to allow. When this number of attempts has been made, the return from spc_throttle( ) will be -1 to indicate a complete failure to authenticate.

allowed_fails

Number of attempts allowed before enabling throttling.

delay

Base delay in seconds.

If the maximum number of attempts has been reached, the return value from spc_throttle( ) will be -1. If there is to be no delay, the return value will be 0; otherwise, the return value will be the number of seconds to delay before allowing another authentication attempt.

int spc_throttle(int *attempts, int max_attempts, int allowed_fails, int delay) {

int exp;

(*attempts)++;

if (*attempts > max_attempts) return -1;

if (*attempts <= allowed_fails) return 0;

for (exp = *attempts - allowed_fails - 1; exp; exp--)

delay *= 2;

return delay;

}

8.9. Performing Password-Based Authentication with crypt( )

Problem

You need to use the standard Unix crypt( ) function for password-based authentication.

Solution

The standard Unix crypt( ) function typically uses a weak one-way algorithm to perform its encryption, which is usually also slow and insecure. You should, therefore, use crypt( ) only for compatibility reasons.

Despite this limitation, you might want to use crypt( ) for compatibility purposes. If so, to encrypt a password, choose a random salt and call crypt( ) with the plaintext password and the chosen salt. To verify a password encrypted with crypt( ), encrypt the plaintext password using the already encrypted password as the salt, then compare the result with the already encrypted password. If they match, the password is correct.

Discussion

TIP

What we are doing here isn't really encrypting a password. Actually, we are creating a password validator. We use the term encryption because it is in common use and is a more concise way to explain the process.

The crypt( ) function is normally found in use only on older Unix systems that still exclusively use the /etc/passwd file for storing user information. Modern Unix systems typically use stronger algorithms and alternate storage methods for user information, such as the Lightweight Directory Access Protocol (LDAP), Kerberos (see Recipe 8.13), NIS, or some other type of directory service.

The traditional implementation of crypt( ) uses DES (see Recipe 5.2 for a discussion of symmetric ciphers, including DES) to perform its encryption. DES is a symmetric cipher, which essentially means that if you have the key used to encrypt, you can decrypt the encrypted data. To make the function one-way, crypt( ) encrypts the key with itself.^[1^]

The DES algorithm requires a salt, which crypt( ) limits to 12 bits. It also prepends the salt to the resulting ciphertext, which is base64-encoded. DES is a weak block cipher to start, and the crypt( ) function traditionally limits passwords to a single block, which serves to further weaken its capabilities because the block size is 64 bits, or 8 bytes.

Because DES is a weak cipher and crypt( ) limits the plaintext to a single DES block, we strongly recommend against using crypt( ) in new authentication systems. You should use it only if you have a need to maintain compatibility with an older system that uses it.

Encrypting a password with crypt( ) is a simple operation, but programmers often get it wrong. The most common mistake is to use the plaintext password as the salt, but recall that crypt( ) stores the salt as the first two bytes of its result. Because passwords are limited to eight bytes, using the plaintext password as the salt reveals at least a quarter of the password and makes dictionary attacks easier.

The crypt( ) function has the following signature:

char *crypt(const char *key, const char *salt);

This function has the following arguments:

key

Password to encrypt.

salt

Buffer containing the salt to use. Remember that crypt( ) will use only 12 bits for the salt, so it will use only the first two bytes of this buffer; passing in a larger salt will have no effect. For maximum compatibility, the salt should contain only alphanumeric characters, a period, or a forward slash.

The following function, spc_crypt_encrypt( ) , will generate a suitable random salt and return the result from calling crypt( ) with the password and generated salt. The crypt( ) function returns a pointer to a statically allocated buffer, so you should not call crypt( ) more than once without using the results from earlier calls because the data returned from earlier calls will be overwritten.

#include <string.h>

#include <unistd.h>

char *spc_crypt_encrypt(const char *password) {

char salt[3];

static char *choices = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"

"0123456789./";

salt[0] = choices[spc_rand_range(0, strlen(choices) - 1)];

salt[1] = choices[spc_rand_range(0, strlen(choices) - 1)];

salt[2] = 0;

return crypt(password, salt);

}

Verifying a password encrypted with crypt( ) involves encrypting the plaintext password to be verified and comparing it with the already encrypted password, which would normally be obtained from the passwd structure returned by getpwnam( ) or getpwuid( ). (See Recipe 8.2.)

Recall that crypt( ) stores the salt as the first two bytes of its result. For purposes of verification, you will not want to generate a random salt. Instead, you should use the already encrypted password as the salt.

You can use the following function, spc_crypt_verify( ) , to verify a password; however, we're really only providing an example of how crypt( ) should be called to verify a password. It does little more than call crypt( ) and compare its result with the encrypted password.

#include <string.h>

#include <unistd.h>

int spc_crypt_verify(const char *plain_password, const char *cipher_password) {

return !strcmp(cipher_password, crypt(plain_password, cipher_password));

}

See Also

Recipe 5.2, Recipe 8.2, Recipe 8.13