Methods Of Verifying A Password Computer Science Essay


Over the first few decades of the computer networks technology was being introduced, computer networks were primarily used by university researchers for sending email, or some corporate employees for some basic files and printers sharing. Under these conditions, security did not get a lot of attention. But nowadays, we all are living along with internet! From ordering the food to transferring a millions amount of money from one bank account to the other. We are virtually cannot separate from the internet. That's the reason that network security is becoming a hot topic in the network communication industry. It is a massive problem for influencing the trust from different network user.

Security topic is covering many components. These include confidentiality and integrity (not allow unauthorized parties to read or modify information), authentication and nonrepudiation (providing the equivalent of an electronic signature) and the encryption technique and etc. Of course, we will not missing the Cryptography as one of the key component in the Security community!

Lady using a tablet
Lady using a tablet


Essay Writers

Lady Using Tablet

Get your grade
or your money back

using our Essay Writing Service!

Essay Writing Service

Cryptography overview

Cryptography has a long and colorful history. It has played a very important role in the information Security area. Historically, 4 major group of the user has used and contributed to the development of Cryptography. They are: the military, the diplomatic corps (spies), banking and lovers. Obviously, the military has had the most important role and has shaped the field. Within military organizations, one of the main constraints on Cryptography is the ability of "code clerk" to perform the necessary transformations (encryption), often on a battlefield with little equipment (such as Carda's Grille [1] was being employed in the past.) An additional constraint has been the difficulty in switching over from one cryptographic method to another one as this entails retraining a large number of people. However, the danger of a "code clerk" being captured by the enemy has made it essential to be able to change the cryptographic method instantly.

This kind of problem was leading the development of the Cryptographic and the Security system of computer network for the Authentication system and how we can authorization the users grant for the right to accessing the network resources and encryption/decryption the secret message for secret message exchange.

In this paper, I will study the different type of authentication system. What is the principle and how does it operate. Furthermore, in Chinese, we have a very old military strategist treatise (may be the oldest in the world) which calls "The Art of the War", composed by Sun Tzu, a military general. It states:

"If you know the enemy and know yourself, you need not fear the result of a hundred battles!"

So, I will introduce the advantage and the disadvantage for difference Authentication system (Traditional Authentication System, Two-Factor Authentication system and Kerberos Authentication System) in order to know what are the merits as well as the weaknesses for the different authentication system.

Authentication system vs. Authorization system [2][3]

It is very easy to mix-up the method of authentication with that of authorization. In a lot of computer system (with standalone host-based systems or even some network base - client server systems), there two method are performed by the same physical hardware or even the same application.

It is important to draw the distinction between these two methods, since they should be performed by separate systems.


Authentication is the method that systems can securely identify the users. Authentication systems are trying to find an answer to the follow questions:

Who is the end user?

Does the user really represent the identity that he / she claim?

An authentication system may be as simple as a plain-text password system (such as some old FTP servers) or as complicated as the Kerberos system. In all cases, authentication systems depend on some unique bit of information known (or available) only to the individual being authenticated and the authentication system -- a unique secret. Such as:

What the requestor individually knows as a secret, such as a password or a Personal Identification Number (PIN), or

What the requesting owner uniquely has, such as a passport, physical token, or an ID-card, or

Lady using a tablet
Lady using a tablet


Writing Services

Lady Using Tablet

Always on Time

Marked to Standard

Order Now

What the requesting bearer individually is, such as biometric data, like a fingerprint or the face geometry.

What is the electric ID, SMART card, Digital signature of the requestor?

In order to verify the user identity, the authenticating system asks the user to provide his unique information (his password, fingerprint, etc.) -- if the authenticating system can verify that the unique secret was matched, the user is authenticated.


Besides, Authorization is the method of which a system determines the privilege of an authenticated user for accessing a secure resources controlled by the system. For an instance, a database management system might be designed to provide some specified individuals with the right to access information from a database but not the right to change data stored in the database (I.e.: read only mode), while giving other individuals the right to change data (i.e.: full control mode). Authorization systems also try to provide answers to the following questions:

Does the user A authorize to access resource W?

Does the user A authorize to perform operation X?

Does the user B authorize to perform operation X on resource W?

Authentication and authorization are to a certain degree of tightly-coupled methods -- authorization systems depend on secure authentication systems to ensure that users are who they claim and thus prevent unauthorized users from gaining access to secured resources.

It is illustrated the interactions between authentication and authorization systems in a typical network base, client/server application in the Figure I below.

Figure I

As the diagram shown, a user is dealing with the authentication system for proving his identity in a client system and then goes on an interaction with a server system. On the other hands, on the server system side, it interacts with an authorization system to control what rights and privileges that the client host's user should be granted.

Traditional Authentication Method [4]

The simplest authentication method available is the traditional local authentication.

In this model, username and password information for each authentication user is stored on the server system locally. The network users send the usernames and passwords in plain text to the server system, which compares their authentication information with its local database. If the provided username and password are matched, the user can be authenticated.

Basically, this is the model used for login authentication on traditional multi-user systems, it has been replicated numerous times within various application packages.

It is illustrated a overview of the traditional authentication method in Figure II below,

Figure II

The advantage of the Traditional Authentication Method

Obviously, the traditional Authentication systems are simple to implement.

This is the most basic Authentication Method that can be run on difference system (cross-platform). From the embedded system, handheld system to a mainframe computer systems.

The disadvantage of the Traditional Authentication Method

Most of the systems are storing the users' passwords in plain-text form on the server machine. Anyone who can gain access to the database has access to enough information to pretend as any authentication user.

Even some of the systems are storing the users' passwords in encrypted form on the server machine, plain-text passwords are still sent across an insecure network from the client to the server. Anyone with access right to the insecure network may be able to "snoop" the username and password from the communications between the user and the server.

Every separate system must own a copy of the user's authentication information. At the end of the day, users must keep passwords on each system to which they authenticate. So, many people are likely to choose less-than-secure passwords for their convenience.

Authentication is not reusable. Users must authenticate separately to each system or application they wish to access. As a result, users must repeatedly type their passwords and will tend to choose less-then-secure passwords for convenience.

There is no connection for cross-authenticating the server and client. A system which can be pretended the server system (via IP address spoofing) cannot be identified by the client from the real server. It is possible for a hacker who is opening a trojan-horse (fake) servers and collecting username/password information. Then, the hacker can use the stolen user information to accessing the real server.

Two-factor Authentication system

Lady using a tablet
Lady using a tablet

This Essay is

a Student's Work

Lady Using Tablet

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Examples of our work

Two-factor authentication (TFA) is an authentication method that is using at least two (or more for Multi-factor authentication, two or more of the authentication factor required for being authenticated) unique identification information (for example: PIN + the number from a physical token) to increase the security of the authentication process. The username is usually known and visually during the user input hence it is not secure information.

Two-factor authentication is not a new concept. Two-factor authentication is used by a bank customer uses the local ATM. One authentication factor is the physical ATM card which the customer inserted into the machine. The second factor is the token that displaying the random number. Without either one, authentication cannot be taken place. This scenario illustrates the basic parts of most multi-factor authentication systems which is the "something you have" plus "something you know" concept.

The owner of secure data or the operator of the secure systems is implementing two-factor authentication for laptops first because of the security risks in mobile computers is much higher. The TFA make more difficult for those unauthorized persons to use a "steal" laptop for accessing secure data or systems. For the mobile phones or smart phones, the problem still exists. A lost or left phone shall not be activated to enable the finder for unauthorized access to secure data or system. 

Figure III: The second factors: password used with token

Types of Authentication that can be used as a second factor

Token Device

A physical device can be provided a One Time Password (OTP) token. The token have an LCD screen which displays a pseudo-random number consisting of 6 or more alphanumeric characters (sometimes numbers, sometimes combinations of letters and numbers). This pseudo-random number changes at pre-determined intervals, usually every one minutes, or change at any time intervals. It can be triggered by the user such as pushing a button on the token.

Figure IV: The token devices from my bank and my company VPN access


A variation on "something you know", is resistant to keystroke logging and shoulder surfing, is a patented method (by Swivel Secure Ltd. In 2000) that is using a mask to extract a One Time Password. Masking can be used with "something else you know" or in combination with a token - so the security risk associated with device theft or borrowing can be avoided.

Figure V: Two factors: a password used as a mask to extract a One Time Code. 

The Security String changes with every transaction.


Biometric authentication also satisfies the regulatory definition of true multi-factor authentication. Users may biometrically authenticate via their fingerprint, voiceprint, their face or iris scan by a biometric scanner or camera thus entering a user PIN in order to access or open a credential vault. However, this type of authentication is suitable in limited applications / location. This second factor authentication solution is comparatively expensive when there are a large number of users. Furthermore, it is extremely vulnerable to a replay attack: once the biometric information is compromised, it may easily be replayed unless the reader is completely secure and guarded. At last, there is great user resistance to biometric authentication. Users resist having their personal physical characteristics captured and recorded for authentication purposes.

Figure VI: My thumbprint - for biometric data used in authentication.

Magnetic Cards

Magnetic cards (credit cards,  ATM cards, etc) combined with secure, encrypting card readers provide a solution for two-factor authentication. Each magnetic stripe card has unique characteristics much like the card's own fingerprint called a magnetic fingerprint. The advantage is that a magnetic fingerprint already exists on every magnetic stripe card because it is an intrinsic characteristic and no cards would need to be re-issued. It does require a special reader that can read the magnetic fingerprint value.

Mobile Phones

A new two-factor authentication token is the user's mobile phone. It can transform as a token device using SMS or install a Soft-Token application to a smartphone. As the user communicates through two channels, the mobile phone becomes a two-factor, two-channel authentication solution.

Figure VII: The Soft-Token application of my company installed in my Blackberry Smartphone

SMS One Time Password

SMS One time password uses information sent in an SMS to the user as a second factor for authentication. One scenario is where a user registers their contact information on a website. During this time the user is also asked to enter his or her regularly used telephone numbers (home, mobile, work, etc).

Mobile Signature

Mobile signatures are digital signatures created on a SIM card securely on a mobile device by a user's private key. In such a system text to be signed is securely sent to the SIM card on a mobile phone. The SIM then displays the text to the end-user who checks it before entering a PIN code to create a signature which is then sent back to the service provider. The signature can be verified using standard PKI systems.

Smart cards

Smartcard based systems use a credit-card sized card with an onboard microprocessor.

Typically the card is inserted into a reader and a password or PIN entered to gain access to data on the card, which is transmitted to the authentication server to confirm that the card is physically present.

Figure VIII: My Hong Kong SMART ID card

Digital Certificates

Digital Client certificates are a PKI solution for enabling the enhanced user identification and access controls needed to protect sensitive online information. Digital certificates can also be stored and transported on smart cards or USB tokens for use when traveling. Each certificate can only be used to authenticate one particular user because only that user's computer has the corresponding and unique private key needed to complete the authentication process. Client certificates are delivered electronically; however, deployment and support of digital certificates have proven problematic. Digital certificates were noted in averag very high support costs and very low rates of user acceptance due to difficult technical implementation requirements.

USB Token

USB tokens are plastic capsules around 7cm long, which are normally designed to be carried on a keyring. The token is plugged into a USB port on the access device, and operates in the same way as a smartcard.

The advantage and disadvantage of Two-factor authentication method


Smartcards have the advantage that they may be used to store other, non-authentication information such as PKI keys, certificates or financial data. They may even be used to control physical access to buildings.

The main disadvantage is the requirement for a reader at every access terminal used. This may be acceptable for users if only one machine is ever used for access: but for the system owner it represents a considerable initial capital outlay and an ongoing administrative and maintenance burden - as does the issue, recording and delivery of the smartcards. An authentication server is required, and normally a separate smartcard is needed for each protected application.

USB tokens

Although no dedicated reader is required, the access device must have an available USB port - which can be inconvenient on an older machine. USB tokens are relatively expensive to purchase (typically around USD$50 per unit), and require initialization, recording, delivery and ongoing maintenance.

An authentication server is required on the protected site or network to handle interrogation and verification of the USB token on the client machine. The server requires installation, configuration and maintenance.

Also, as more applications require strong authentication, users have to carry more and more tokens to provide access to their bank accounts, business networks and so on - a problem known as the "token necklace".

Token Device

The authenticators have the advantage of being "device independent", since they are not connected to the access device.

Same as smartcards and USB tokens they require an authentication server, often with substantial licensing and maintenance costs. As well as the initial capital cost of the tokens there is a significant ongoing administration and maintenance overhead: although it is difficult to find published research, we understand from corporate users that around 20% of tokens have to be replaced each year due to loss or damage, and tokens also need to be reset if they drift out of synchronisation with the authentication server.


The obvious advantage is that the right system will provide a very high level of identity verification.

Disadvantages are high costs, both for the associated readers (which have to be

available on every access device) and for the initial implementation of the system when users are enrolled. There are data protections and privacy implications which need to be resolved; and recent studies in the USA have raised questions about the reliability of fingerprint recognition in large user samples.

Phone-based TFA system

The main advantage, of course, is that there is no need to purchase, initialize or deliver any new user hardware in the form of tokens or readers. However, SMS and voice synthesis systems incur a cost every time the user logs on: since this happens more often than is normally realized (because of time-outs etc.) running costs are difficult to predict. These systems need an authentication server.

Phone-based systems have to deal with the problem of enabling authentication in areas with no mobile phone signal. This may be done by providing a time-limited "emergency PIN" - as used in many other systems to cope with lost, forgotten or broken tokens.

Digital certificates

Strictly speaking digital certificates identify access devices rather than users. They are blocks of data installed on individual machines and can be thought of as "pre-installed tokens" proving the identity of the machine, rather than the user, to an authentication server. They may form part of a full PKI suite allowing encryption, digital signature of documents, non- repudiation and etc.

Digital certificates are frequently complex to administer and use, and are inflexible in that they restrict use to the machine that they are installed on. Although the user are normally has to enter a password to activate the certificate, in most environments they do not provide a high level of user authentication.

Cost effectiveness

There are drawbacks to two-factor authentication that are keeping many approaches from becoming widespread. Some consumers have difficulty keeping track of a hardware token or USB plug. Many consumers do not have the technical skills needed to install a client-side software certificate.

As a result, adding a second factor to the authentication process typically leads to increase in costs for implementation and maintenance. Most hardware token-based systems are proprietary and charge an annual fee per user in the $50-100 USD range. Deployment of hardware tokens is logistically challenging. Hardware tokens may get damaged or lost and issuance of tokens in large industries such as banking or even within large enterprises needs to be managed.

In addition to deployment costs, two-factor authentication often carries significant additional support costs. A survey conducted by [12] the Credit Union Journal reported on the support costs associated with two-factor authentication. In their report, software certificates and software toolbar approaches were reported to have the highest support costs. Virtual tokens and geo-locations were reported to have the lowest support costs.

Kerberos Authentication Model [13]

Beside the two-factor Authentication system, another better authentication system model was developed and shepherded through the IETF standards process by MIT staff - the Kerberos authentication model. Kerberos addresses each of the major problems identified with the traditional authentication model, albeit at the expense of being significantly more complex than the traditional model.

Kerberos authentication system is based on a variant of Needham-Schroeder. It is named for a multiheaded dag in Greek Mythology that used to guarad the entrance to Hades (presumable to keep undesirables our). The biggest difference with Needham-Schroedar is its assumption that all clocks are fairly-well synchronized. The protocol has gone through several iterations.

In overview, the Kerberos authentication model uses one or more trusted authentication servers (termed KDCs or "Key Distribution Centers") to provide third-party authentication services for cooperating systems and applications. In the Kerberos model, client machines acquire authentication credentials (called tickets) from the trusted authentication server(s) which they can subsequently present to systems and applications as proof of authentication and which, due to their being strongly encrypted, can be passed securely over an insecure network.

A typical Kerberos session starts when a user runs software on his local client machine to acquire an initial authentication ticket (termed a ticket-granting ticket). The client later presents the user's ticket-granting ticket to the Kerberos ticket-granting service to acquire a service ticket for the particular system or application the user wishes to use. This service ticket is then presented to the desired service in lieu of a [username, password] pair as proof of authentication.

The details of the conversations between a Kerberos client, the KDCs, and the various Kerberized services used by the client are rather complex. Figure III, below, graphically depicts the interactions between cooperating systems involved in the Kerberos model. Click here for a more detailed description of the internal workings (the "magic", if you will) of Kerberos.

Figure IX

Figure IV: Kerberos Authentication Model: Definitions and Notational Conventions

In order to discuss the internal workings of the Kerberos authentication model, we will need to define some terms and notational conventions:

Authentication ticket, ticket

A record of authentication issued by a Kerberos authentication server to a client system as proof of that client's user being authentic.

Authenticated service

A service which is only provided to users who have authenticated themselves via Kerberos and whose clients can present valid authentication tickets as proof of authentication.

Target service

The authenticated service for which a client is requesting a ticket or to which the client is presenting a ticket.

Initial ticketing service

The service (provided by the Kerberos KDC) by which clients receive their initial (ticket-granting) tickets.

Ticket-granting service

The service (provided by the Kerberos KDC) by which clients receive tickets to specific target services (service tickets).

Ticket-granting ticket

A ticket provided on demand by the initial ticketing service which must be presented to the ticket-granting service in order to request a service ticket.

Clear text

Unencrypted data.


Encrypted data.


A strong, symmetric encryption algorithm used by Kerberos. Uses 64-bit encryption keys. Given ciphertext and the DES key with which it was encrypted, it is possible to decrypt the ciphertext to yield the original clear text. Decrypting a DES-encrypted ciphertext with the wrong key produces garbled clear text.

Dual encryption

The concept of encrypting clear text twice -- once with each of two different keys. The basis of authentication under the Kerberos model.


A function used to convert arbitrary strings (such as users' passwords) into valid DES keys.


The Kerberos term for a user's "username".


Notation for "The string DES-encrypted using as the DES key".


Notation for "A ticket of type ".


Notation for "The secret key associated with ".


Notation for an encrypted ticket-granting ticket, {Ttgs,Ksession}Ktgs.

Kerberos Authentication Model: How does it operate? [14]

The Kerberos authentication model relies on a secret-key symmetric encryption scheme (DES in the case of Kerberos IV, DES/IDEA/etc. in the case of Kerberos V) and the concept of dual encryption to provide secure authentication across a possibly insecure network. Authentication tickets are delivered to Kerberos clients encrypted in two keys -- one which both the client user and the ticket granting service know (either the user's password or a session key -- see below) and one which both the ticket-granting service and the target service know.

If a client machine is able to decrypt a ticket encrypted in the user's password, the user of the client may be considered authenticated (since only he and the authentication service know the user's password). If a target service is able to decrypt an encrypted ticket using its own secret key, the service may presume that the user who presented the ticket is authentic, since only the ticket-granting service and the target service have knowledge of the target service's secret key.

This allows authentication to occur under the Kerberos model without any password information passing over a possibly insecure network and without any one system or party in the Kerberized exchange having access to enough information to impersonate any other system or party.

Kerberos authentication can be viewed as a six-step process. Below is our Figure V, again, graphically depicting the steps involved in a typical Kerberized authentication session:

Figure X

In Step 1, the user wishing access to an authenticated target service provides his principal (username) and his password to the client system he is using. Note that the client system has no record of the user's principal *or* password -- it merely accepts a [principal,password] pair provided by the user.

In Step 2, the client system sends a request to the Kerberos Initial Ticketing Service requesting a ticket-granting ticket for the user whose principal it has been given. This request is totally unauthenticated.

In Step 3, the Initial Ticketing Service creates a unique session key (Ksession) for later use during the user's authenticated session and sends back to the client a dual-encrypted ticket-granting ticket and the session key in the form:


The client then uses the agreed-upon string_to_key() function to convert the user's password into an encryption key and attempts to decrypt the ticket-granting ticket using that key. If the decryption succeeds, the client can be certain that the user is authentic, and the client records the TGT ({Ttgs,Ksession}Ktgs) for later use.

In Step 4, when the user attempts to use a particular target service, the client sends a service ticket request to the Kerberos ticket granting service. This request is in the form:


(where TGT = {Ttgs,Ksession}Ktgs)

In Step 5, the Kerberos ticket-granting service uses its own secret key (Ktgs) to decrypt the TGT in the request it has received, then uses the session key (Ksession) in that TGT to decrypt the rest of the request. If the ticket-granting service is able to properly decrypt the ticket, it knows:

that the TGT was issued by the correct initial ticketing service, since it was encrypted with the ticket-granting service's secret key.

that the request it received was sent by an authenticated user (and, due to the contents of the Ttgs, what principal the ticket was issued for), since the sender was able to encrypt the request in the secret session key, Ksession.

If the decryption is successful, then, the ticket-granting service accepts the user's authentication, generates a service-session key for later use in encrypting transactions between the client and the target service, and issues a service ticket for the requested target service. This is sent back to the client machine in the form:


In Step 6, the client decrypts the service ticket it has received using the session key (Ksession) provided to it in Step 3 to yield the service-sesson key (Kservice-session) and an encrypted service ticket ({Tservice,Kservice-session}Kservice).

The client then presents the encrypted service ticket to the target service, which in turn decrypts it using its own secret key (Kservice). If the decryption works, the target service may presume that the user is authentic (since only an authenticated user would have access to a decryptable service key). The client and target service may choose to further secure their later communications by encrypting their conversations in the service-session key issued by the ticket-granting service (Kservice-session), since it is a secret known only to the client and the target service. This latter step, encrypting the authenticated conversation, has the added advantage of allowing the client and server to be certain of one another's identities -- an interloper attempting to sabotage the authenticated conversation would need to know the shared encryption key (Kservice-session) in order to properly encrypt data to inject into the conversation.

Steps 4, 5, and 6 may be repeated by the client in order to allow the user access to other Kerberized services without the user's having to re-enter his principal or password information. Kerberos tickets are, in that sense, a reusable proof of authentication.

Kerberos: advantage and disadvantage

The Kerberos authentication model offers a number of advantages over more traditional authentication schemes:

User's passwords are never sent across the network, encrypted or in plain text. Secret keys are only passed across the network in encrypted form. Hence, a miscreant snooping and logging conversations on a possibly insecure network cannot deduce from the contents of network conversations enough information to impersonate an authenticated user or an authenticated target service.

Client and server systems mutually authenticate -- at each step of the process, both the client and the server systems may be certain that they are communicating with their authentic counterparts.

Although the preceding discussion did not go into sufficient detail to elucidate the fact, the tickets passed between clients and servers in the Kerberos authentication model include timestamp and lifetime information. This allows Kerberos clients and Kerberized servers to limit the duration of their users' authentication. While the specific length of time for which a user's authentication remains valid after his initial ticket issued is implementation dependent, Kerberos systems typically use small enough ticket lifetimes to prevent brute-force and replay attacks. In general, no authentication ticket should have a lifetime longer than the expected time required to crack the encryption of the ticket.

Authentications are reusable and durable. A user need only authenticate to the Kerberos system once (using his principal and password). For the lifetime of his authentication ticket, he may then authenticate to Kerberized services across the network without re-entering his personal information.

As a side-effect of the dual-key encryption scheme employed in the Kerberos model, a service-session key is generated which constitutes a shared secret between a particular client system and a particular service. This shared secret may be used as a key for encrypting the conversation between the client and the target service, further enhancing the security of Kerberized transactions.

Unlike many alternative authentication methods, Kerberos is entirely based on open Internet standards. A number of well-tested and widely-understood reference implementations are available free of charge to the Internet community. Commercial implementations based on the accepted standards are also available.

Unlike many of its proprietary counterparts, Kerberos has been scrutinized by many of the top programmers, cryptologists and security experts in the industry. This public scrutiny has ensured and continues to ensure that any new weaknesses discovered in the protocol or its underlying security model will be quickly analyzed and corrected.

There is no prefect authentication system in the world, the Kerberos model also have some weaknesses:

In Kerberos IV (the version of Kerberos used by AFS and Zephyr) all encryption is performed using the DES algorithm. While DES was considered "unbreakable" at the time of the release of Kerberos IV, it is now believed that a sufficiently motivated miscreant could, with only modest computing resources, conceivably crack DES encryption in a relatively short period of time. Some researchers have, in fact, been able to do just that under certain specific circumstances. Since the trust ability of Kerberos authentication depends entirely on unbreakability of the underlying encryption technology used by the system, this poses a threat to the security of Kerberos IV. In the current release of Kerberos, Kerberos V, support is provided for "plug-in" symmetric encryption algorithms. Kerberos V systems can use, for example, the much more secure triple-DES or IDEA encryption algorithms. The overall structure of Kerberos V remains the same as that of Kerberos IV. Webauth, for example, used 3DES keys to secure services.

Kerberos was designed for use with single-user client systems. In the more general case, where a client system may itself be a multi-user system, the Kerberos authentication scheme can fall prey to a variety of ticket-stealing and replay attacks. The overall security of multi-user Kerberos client systems (filesystem security, memory protection, etc.) is therefore a limiting factor in the security of Kerberos authentication. No amount of cleverness in the implementation of a Kerberos authentication system can replace good system administration practices on Kerberos client and server machines.

Because Kerberos uses a mutual authentication model, it is necessary for both client machines and service providers (servers) to be designed with Kerberos authentication in mind. Many proprietary applications already provide support for Kerberos or will be providing Kerberos support in the near future. Some legacy systems and many locally-written and maintained packages, however, were not designed with any third-party authentication method in mind, and would have to be re-written (possibly extensively) to support Kerberos authentication.

The Kerberos authentication model is vulnerable to brute-force attacks against the KDC (the initial ticketing service and the ticket-granting service). The entire authentication system depends on the trustability of the KDC(s), so anyone who can compromise system security on a KDC system can theoretically compromise the authentication of all users of systems depending on the KDC. Again, no amount of cleverness in the design of the Kerberos system can take the place of solid system administration practices employed in managing the Kerberos KDC(s).


It is a great chance for me to further study some common authentication system we are using. I more understand the operation detail of individual system and also the advantage and the disadvantage of each of the authentication system.

Yet, during the study of difference authentication system, I realize that in some countries, all nongovernmental cryptography is simply forbidden unless the government is given all the keys being used. Government eavesdropping has been practiced on a far more massive scale the most of the general public could be imagined.

The U.S. government even has an encryption scheme for future cryptography system that includes a special feature to allow the police to tap and decrypt all digital information in United States. So, the police can be "Authenticated" as a right user to being "authorize" to access any resource they want!

Even the government promises not to use this feature without a court order, but there was a case that a former FBI director J. Edgar Hoover [15] illegally tapped the telephones of Martin Luther King. Jr and other people attempt to neutralize them. It raised a lot of discussion about how the general public can be supervised how the law enforcement to implement this kind of action "legally"!

So, there is a open question has been raised. No matter how robust of the Authentications system or how advanced of the cryptography technology. The human (i.e.: government official, law enforcement people or even the ex-employee of the company) is always a major factor that can be "crashed" into any secured system in the world. The security is politicized to an extent few other technical issues are. It relates to the difference between a democracy and police state in the digital era. This is totally out of the scope of technical or technology!