A Password Cracker is a piece of software that attempts to break into a system by trying many different user names and passwords.

To break a password, a Password Cracker uses two methods of attack to break into your account.

The first method is Brute Force Attack. In this type of attack, the software generates passwords of every possible combination of words, letters, or even symbols to try to break into your account. The longer the password, the longer it takes to break into the system. However, since computers are gearing up the speed every year (according to Moore’s law, the computer speed doubles every 18 months), the time to break a password of any certain length reduces 50% every 1.5 years.

The second method is Dictionary Attack. This is a more clever method in which the attacker uses a pool of words such as names, common vocabularies, etc., and tries various combinations of them to crack the system. The pool of effective possible choices to use in the trial and error process is much smaller than in a Brute Force Attack because of the more confined choices of numbers and letters to combine. It is very easy to get a word list. Do a search on Google for the search phrase “word list” to look for many databases available on the web.

Originally, I’d planned to write a summary on tactics you can use to choose passwords that you can easily memorize but at the same time are difficult to be cracked. But then I accidentally stumbled upon a page that has this done nicely. And in the interest of not reinventing the wheel, here is the link to that page:

http://www.wikihow.com/Remember-Your-Password

Enjoy, and if you have other innovative ways to remember difficult passwords, let me know.

Tags: password management, password generation methods, how to craft a password

Technorati Tags: Password Cracker, Brute Force Attack, Dictionary Attack, password management, password generation methods, how to craft a password

I wrote this article because I need to talk about this topic to a group of local bank executives. What I have in mind is how to get them to understand the vague differences between these three terms using illustrations from our daily lives.

For these reasons, I picked up a number of books to read. Indeed, I have to give credit to the book Beyond Fear by Bruce Schneier, as he gave a number of analogies about these terms in chapter 13 of his book.

I hope writing this article can help clarify my explanation of the key concepts of these three terms.

To start, let’s use some simple ideas to describe these three terms:

Identification: Who are you?

Authentication: Prove it!

Authorization: Okay, you are allowed to do these things because we have successfully authenticated you (proved you are who you say you are)

Let’s look at an example to illustrate this. Suppose you take your passport (containing your photo and signature) and go through an immigration counter to get into a country. The immigration officer asks who you are, and you reply politely with your name. This is the step of Identification. The office then verifies your identity by looking at your photo, and may check your signature on your immigration form against that of your passport. After this process, hopefully you are authenticated by him to be the genuine holder of the passport you have shown. This is the step of Authentication. Then the officer will check against your country of origin and whether you need and have any visa to show that you have the authorization to get into the country. This is the step of Authorization.

In an Access Control system, these three steps are crucial since they control whether a person is authorized to gain access to the particular area of a system. This is essentially a Prevention Control System.

In Schneier’s book, he used another interesting example using the London Underground ticket system. A passenger can purchase a monthly ticket with unlimited travel for a month. This ticket (authorization) contains no authentication capability. The passenger has to bear another photo card (which is permanent) with a unique number for authentication. The unique number has to be written down on the monthly ticket the passenger purchases to get it validated. So, these two items form an authentication-and-authorization system. Note there is no serious identification element in this system (though you can write your name on the ticket beside the photo card number) since no one will check your ID to verify if you really own the name shown on the photo card. The London Underground only cares to prevent two persons from sharing the same monthly ticket, and your photo card is already an effective tool to prevent this from happening (unless you have a look-alike or a twin, in which case you can ride at half-price!). The ticket itself is sufficient to serve the purpose of authorization.

However, in an IT system, we need a full identification system. This is because we need the information to complete an entire authorization process (just like the previous example of using a passport to get into a country).

We also need to track against the users’ activities in the system for the purpose of having an Audit Trail (a kind of security detection control). Without a good identification element, we can still analyze the system log to uncover abnormal user activities, such as when a breach of a user’s limit of accessing certain network resources, etc. But we will have a hard time following up without knowing the identity of the user.

In this way, the three-step authentication, identification, and authorization process serves both the prevention and detection access control for an IT system.

Tags: Access Control System

Technorati Tags: Beyond Fear, Bruce Schneier, Identification, Authentication, Authorization, Access Control, Audit Trail, Access Control System

According to Convery, S.(2007)¹: “RADIUS was developed by Livingston Enterprises (now part of Alcatel-Lucent) in the early 1990s, became an Internet standard through the IETF in 1997, and today is the most widely accepted AAA protocol.

Another widely adopted AAA protocol, which predates RADIUS as an RFC by four years, is the Terminal Access Controller Access Control System (TACACS). Though never an Internet standard, TACACS evolved into XTACACS and then TACACS+, the latter of which is the only version of TACACS in use today.”

RADIUS server is one of the most popular remote access technology components.  Its main functions are to:

• consolidate the login request received by the remote network authenticator(s) within an organization,
• verify the eligibility of the remote user’s right to access inside the corporate network, and
• authenticate the user per the agreed-upon authentication methods.

The acronym AAA stands for Authentication, Authorization, and Accounting. The authentication process performs verification of a remote user’s identity, the authorization process determines what a remote user is allowed to do on the network, and the accounting process logs the user’s activities in relation to network access.  These actions are activities the RADIUS server performs with other network remote access components within a corporate network environment.

RFC 2865² describes in detail the authentication methods and the packet format of a RADIUS server, and RFC 2866³ describes a protocol for carrying accounting    information between a Network Access Server and a shared Accounting Server. It should be noted that RFC 2866 does not specify an Internet standard of any kind.

TACACS+ (Terminal Access Controller Access-Control System Plus) is another popular protocol that provides access control for routers, network access servers and other networked computing devices via one or more centralized servers. The main difference between TACACS+ and RADIUS is that TACACS+ separates the two operations: authentication and authorization are combined within the RADIUS server.  Also, TACACS+ uses TCP to communicate, while RADIUS uses UDP. (Source: Wikipedia.org)⁴

¹ Convery, S. (2007), Network Authentication, Authorization, and Accounting: Part One, The Internet Protocol Journal - Volume 10, No. 1, Available from: http://www.cisco.com/web/about/ac123/ac147/
archived_issues/ipj_10-1/101_aaa-part1.html  [Accessed 31 March 2008]

² Rigney, C. Ed. (2000) Request for Comments: 2865, Network Working Group, Available from: http://rfc.net/rfc2865.html [Accessed 31 March 2008]

³ Rigney, C. (2000) Request for Comments: 2866, Network Working Group, Available from: http://rfc.net/rfc2866.html [Accessed 31 March 2008]

⁴ Wikipedia, the free encyclopedia (2008) TACACS+, Available from: http://en.wikipedia.org/wiki/TACACS%2B  [Accessed 31 March 2008]

Technorati Tags: AAA, Terminal Access Controller Access Control System, TACACS, XTACACS, TACACS+, RADIUS server, authentication, Authorization, Accounting, TCP, UDP, http://rfc.net/rfc2865, rfc2866

Point-To-Point Tunneling Protocol Point-to-Point Tunneling Protocol (PPTP) is a method for implementing virtual private networks that works on the data link layer. It serves the purpose of encrypting a remote computer’s network traffic to a host using Point-to-Point Protocol’s (PPP’s) authentication methods of PAP (Password Authentication Protocol) or CHAP (Challenge-Handshake Authentication Protocol). It was replaced by L2TP (Layer 2 Tunneling Protocol) or IPSEC (Internet Protocol Security) as a common remote network connection change, replacing dial-up network access to broadband access in recent years.

PPTP can be regarded as an extension of PPP, which provides router-to-router and host-to-network connections over asynchronous and synchronous connections. Since PPTP works on a data link layer (the second layer of a seven-layer model of network communications), it allows multi-protocol communications of the upper layers to be held using a secure communication channel over the Internet.

How does PPTP work?

According to Microsoft Corporation (2006) ¹, the benefits of PPTP are:

“Through PPTP, it is possible for remote users to access their corporate networks & applications by dialing into the ISP’s point of presence (POP), instead of dialing directly into the company network. PPTP connects directly to the target server by creating a virtual network for each remote client, one that the server administrator can monitor and manage like any other Remote Access port ”

The popularity of PPTP rests in the fact that it is the bundled dialup networking feature Microsoft put forth in most of its Windows Client products. (Microsoft was one of the members of the development group of PPTP).

RFC1334 defines both CHAP and PAP.

PAP according to RFC 1334 ²:

The Password Authentication Protocol (PAP) provides a simple method for the peer to establish its identity using a 2-way handshake.  This is done only upon initial link establishment.

After the Link Establishment phase is complete, an Id/Password pair is repeatedly sent by the peer to the authenticator until authentication is acknowledged or the connection is terminated.

PAP is not a strong authentication method.  Passwords are sent over the circuit “in the clear”, and there is no protection from playback or repeated trial and error attacks.  The peer is in control of the frequency and timing of the attempts.

Any implementations which include a stronger authentication method (such as CHAP, described below) MUST offer to negotiate that method prior to PAP.

CHAP according to RFC1334 ²:

The Challenge-Handshake Authentication Protocol (CHAP) is used to periodically verify the identity of the peer using a 3-way handshake. This is done upon initial link establishment, and MAY be repeated anytime after the link has been established.

After the Link Establishment phase is complete, the authenticator sends a “challenge” message to the peer.  The peer responds with a value calculated using a “one-way hash” function.  The authenticator checks the response against its own calculation of the expected hash value.  If the values match, the authentication is acknowledged; otherwise the connection SHOULD be terminated.

This authentication method depends upon a “secret” known only to the authenticator and that peer.

(Comment: Usually the secret refers to the peer’s password.)

The secret is not sent over the link.

(Comment: There is no way an attacker can gain access to the secret.)

This method is most likely used where the same secret is easily accessed from both ends of the link.

(Comment: On the authenticator’s side, we usually use a Radius server to store the password database centrally inside of it. (The Radius Server verifies the “secret” for the remote access terminal carrying out the authentication process with the peer.) The Challenge packet from the authenticator contains one octet of “Identifier” field and a variable stream of “Challenge” values. These two variables MUST be changed every time a Challenge packet is sent.)

The Response Value is the one-way hash calculated over a stream of octets consisting of the Identifier, followed by (concatenated with) the “secret”, followed by (concatenated with) the Challenge Value.  The length of the Response Value depends upon the hash algorithm used (16 octets for MD5).

If the peer’s Response value matches what has been calculated by the authenticator using the same algorithm, then the authentication is successful.

References:

¹ Microsoft Corporation (2006), How to Set Up a Windows NT PPTP Client, Available from: http://support.microsoft.com/kb/154062 [Accessed 28 March 2008]

² Lloyd, B. Simson, W. (1992), Request for Comments: 1334, Network Working Group, Available from: http://rfc.net/rfc1334.html [Accessed 28 March 2008]

Technorati Tags: Protocol Point-to-Point Tunneling Protocol, PPTP, private networks, Point-to-Point Protocol’s, PPP’s, PAP, Password Authentication Protocol, CHAP, Challenge-Handshake Authentication Protocol, RFC1334, Radius server

In Greek mythology, Kerberos is the monstrous three-headed dog that guards the entrance to Hades. Indeed, we can view modern-day Kerberos as the god who guards the entrance to a network’s resources.

Kerberos, a computer network authorization protocol, was originally invented and published by MIT. This system allows individuals communicating over a non-secure network to prove their identity to one another in a secure manner. In general, we call this function access control.

Before we address the working mechanisms of Kerberos, we need to understand several terms in the discussion.

Kerberos is based on a system of “tickets,” which serve to prove the identity of users. It consists of a number of components found within its system. Two main components are:

Authentication Server (AS): The AS is responsible for identifying the user and issuing a valid ticket for the client to use. This is referred to as a Ticket Granting Server (TGS) service. The AS also generates a short-term secret key for the communication between the client and the TGS.

Ticket Granting Server (TGS): The TGS is logically separate from the AS. It is responsible for issuing a Service Request Ticket (SRT) to users in the network when they request certain resources within the Kerberos network environment.

Physically, the AS and the TGS can reside within a single server.

The Single Sign-On Process

When a user logs into the system, he or she presents to the client server a username and password. The client performs a one-way hash transformation to yield a secret key, called the client’s own secret key or long-term secret key. The client then sends the information to the Authentication Server (AS).

When the AS receives the user’s clear text identification information from the client machine, it checks to see if the user’s long-term secret key is in the database. If the user has entered the password correctly, this secret key will be identical to the client’s own secret key. (Please note that this process does NOT involve the transfer/exchange of the user’s actual password or client’s own secret key through the network, thus eliminating the possibility of unauthorized third parties capturing sensitive information.)

The AS then generates two items. The first item is a random session key, referred to as the TGS session key, or the short-term secret key. This key is encrypted with the client’s own secret key (the long-term secret key) and sent to the client machine, which can then decrypt the TGS session key by its own secret key. The TGS session key (short-term secret key) is stored within the client’s system (usually in its volatile memory, for security purposes).

The second item the AS generates is a Ticket Granting Ticket (TGT), encrypted with the TGS’s secret key, the username, and some other information encrypted by TGS’s secret key. The TGT is sent to the client, but it cannot be tampered with or altered by the client or any other party. This use of a TGT is the essence of this type of access control technology.

Now the client has enough information to present itself to the Ticket Granting Server (TGS) for authentication and service request. The client presents the following three items to the TGS:

1. The TGT it received from AS
2. The service ID of the network service requested
3. The client’s own authentication information (authenticator).
   (The authenticator is encrypted by the TGS’s session key.)

After receiving the TGT, the TGS uses its secret key to decrypt the content. It extracts the TGS’s session key from the TGT and uses it to decrypt the client’s authenticator in order to verify the client’s identity.

After successful verification, TGS then issues the client two messages. The first message is the client’s own service session key to a particular service. As an example, let’s say the user requested a printer service. So the service session key is a printer service session key encrypted by the TGS’s session key. The client can immediately decrypt the printer service session key using the same TGS session key (the short-term secret key).

The second message the TGS sends to the client is the Service Request Ticket (SRT) encrypted by the printer service’s secret key. This SRT contains the printer service session key already shared with the client. (Again this second message cannot be altered or tampered with by the client and any other third parties because it is encrypted by the printer’s secret key.)

When the client requests the service from the printer, it sends the SRT to the printer together with its own authenticator (encrypted by the printer service session key.) The printer first decrypts the ticket by its own secret key, and extracts the respective printer service session key shared with the client. It then uses the session key to decrypt the authenticator to verify the client’s identity.

After successful verification, the printer can communicate with the client and provides the service to the client. From that point forward, the two parties communicate using the printer service session key.

Why it is called Single Sign-On?
The magic of the single sign-on process lies in the fact that the client logs onto the AS only one time, using a password. The password is “hashed” in order to produce the long-term secret key for verification. The authentication process within the AS then creates a TGS session key (the short-term secret key) for the client. The client then uses this short-term secret key to communicate with the TGS, requesting different network services. At this point there is no need to enter the password again—hence, the “single sign-on” name.

Security Threats
It is still possible to compromise this short-term secret key, threatening the security of the system. However, this threat is minimized by the fact that the user is required to re-enter his or her password every six to eight hours. This causes the Kerberos system to go through the authentication process with AS once again, and the short-term secret key is renewed with another one. Additionally, in order to protect the short-term secret key further, it should reside on the client’s volatile memory side instead of within permanent secondary storage, which is vulnerable to attack.

Pros and Cons of Single Sign-On Systems
On the one hand, the single sign-on process offers the user the convenience of typing in a password only once to request different services during any six-to-eight-hour period. However, it has the disadvantage of possible compromise of services for that period of time if the short-term secret key is compromised.

Tags: Short-term session key, Long-term session key, Single point of failure, Password Management, Replay-attack, Single Sign-On Access Control

Technorati Tags: Kerberos, access control, Authentication Server, Ticket Granting Server, Single Sign-On, Ticket Granting Ticket, Short-term session key, Long-term session key, Single point of failure, Password Management, Replay-attack, Single Sign-On Access Control