US10075432B2 - Updating stored passwords - Google Patents

Abstract

A device may include an authentication server and a server. The authentication server may receive a first form of a password from a client device in accordance with an authentication protocol, and authenticate the client device based on a comparison of the first form to a value derived from a second form of the password stored in a password database, where the comparison fails when the first form is not comparable to a value derived from the second form. The server may establish a secure connection to the client, receive a plain-text password from the client device over the secure connection, authenticate the client device by comparing a value derived from the plain-text password with a value derived from the second form, and update the password database with a third form of the password that permits the authentication server to successfully authenticate the client device when the authentication server receives the first form.

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No. 14/659,618, filed Mar. 17, 2015, now U.S. Pat. No. 9,401,913, which is a continuation of U.S. application Ser. No. 13/312,062, filed Dec. 6, 2011, now U.S. Pat. No. 9,001,999, which is a continuation of U.S. application Ser. No. 11/864,598, filed Sep. 28, 2007, now U.S. Pat. No. 8,094,812, all of which are incorporated by reference in their entirety.

BACKGROUND

A network device that is connected to a communication port of a network access device (NAD) may be granted a point-to-point connection to a network if an authentication of the network device succeeds. The network device may be upgraded to support more advanced authentication hardware and/or software.

SUMMARY

According to one aspect, a device may include an authentication server and a server. The authentication server may receive a first form of a password from a client device in accordance with an authentication protocol, and authenticate the client device based on a comparison of the first form to a value derived from a second form of the password stored in a password database, where the comparison fails when the first form is not comparable to a value derived from the second form. The server may establish a secure connection to the client, receive a plain-text password from the client device over the secure connection, authenticate the client device by comparing a value derived from the plain-text password with a value derived from the second form, and update the password database with a third form of the password that permits the authentication server to successfully authenticate the client device when the authentication server receives the first form.

According to another aspect, a method may include receiving a first form of a password from a client device, retrieving a second form of the password from a password database, deriving a value from the second form, comparing the first form to the derived value, establishing a secure connection to the client device, receiving a plain-text password from the client device over the secure connection, authenticating the client device by comparing a value derived from the plain-text password with a value derived from the second form; and replacing the second form in the password database with a third form that permits the client device to be authenticated based on the first form of the password.

According to yet another aspect, a device may include means for receiving a first form of a password, means for authenticating a client device by comparing a value derived from the first form with a value derived from a second form, means for establishing a connection that includes the client device as one endpoint when the client device cannot be authenticated based on the first form, means for receiving the plain-text password from the client device over the connection, means for authenticating the client device by comparing a value derived from the plain-text password with the value derived from the second form, means for overwriting the second form in a password database with a third form, means for subsequently receiving the first form of the password, means for comparing the first form to a value derived from the third form in the database, means for successfully authenticating the client device based on the comparison.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of an exemplary system in which the concepts described herein may be implemented;

FIG. 2 is a block diagram of an exemplary network device;

FIG. 3 is a functional block diagram of a client device ofFIG. 1;

FIG. 4 is a functional block diagram of a policy server device ofFIG. 1;

FIG. 5A is a flow diagram of a process for authenticating the client device ofFIG. 1;

FIG. 5B is a flow diagram of a process for updating a stored password at the policy server device ofFIG. 1;

FIG. 6A illustrates an authentication process before and after upgrading an authentication client at the client device ofFIG. 1;

FIG. 6B is a diagram illustrating exemplary flow of a password through devices ofFIG. 1;

FIG. 6C is a diagram illustrating exemplary flow of passwords through components of the policy server device ofFIG. 1;

FIG. 7A illustrates an authentication process before and after upgrading an authentication client that sends plain-text passwords over Institute of Electrical and Electronics Engineers (IEEE) 802.1X with an authentication client that sends a Microsoft-Challenge Handshake Authentication Protocol Version 2.0 (MSCHAPv2) password over IEEE 802.1X;

FIG. 7B is a block diagram of an embodiment of the policy server device ofFIG. 1; and

FIG. 7C is a diagram illustrating exemplary flow of a password in a VLAN.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements.

The term “authentication,” as used herein, may refer the act of establishing, verifying, or confirming the identity of a client device or a user of the client device.

The term “virtual local area network (VLAN),” as used herein, may refer to a logical network within a physical network. A VLAN may include a network of hosts, computers, or other devices that behave as if they are connected to the same portion or segment of the physical network.

The term “cleartext” or “plain-text,” as used herein, may refer to a message or data that is in a form readily comprehensible to a human being without additional processing.

The term “hash,” as used herein, may refer to a message or data that is encoded, cryptographically hashed, and/or encrypted. The term “hashed password,” as used herein, may refer the result of applying an encryption, encoding, and/or cryptographic hashing to a plain-text password.

As used herein, depending on context, a password may be a plain-text password or a hashed password.

The term “old hash,” as used herein, may refer to a hashed password that is generated by a device prior to upgrading the scheme that is used by the device to generate hashes. The term “new hash,” as used herein, may refer to a hashed password that is generated by the device after the upgrade. An old hash may or may not refer to a plain-text password.

The term “IEEE 802.1X” or “802.1X,” as used herein, may refer to a standard set by the Institute of Electrical and Electronics Engineers (IEEE). The standard may provide for an authentication protocol for a device that is seeking a point-to-point connection to a network, based on the Extensible Authentication Protocol (EAP).

In the following description, after a client device upgrades its password generating component, hashed passwords that are stored at a policy server device may be updated.FIG. 1 is a diagram of asystem100 in which the concepts described herein may be implemented. As shown,system100 may include aclient device102, anetwork104, and a network access device (NAD)106. Depending on implementation,network100 may include additional, fewer, or different components than those illustrated inFIG. 1. For instance,network100 may include multiple client devices and/or NADs.

Client device102 may include a computational and/or communication device, such as a personal computer, a laptop, an electronic notepad, a personal digital assistant (PDA), or another type of computational or communication device that includes a browser or a client application that can communicate with a server. Network104 may include the Internet, an ad hoc network, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a cellular network, a public switched telephone network (PSTN), any other network, or a combination of networks. NAD106 may include a device that selectively permits other devices that are outside ofnetwork104 to accessnetwork104, in accordance with instructions or communication messages frompolicy server device108.Policy server device108 may include a device for managing access tonetwork104 and for administering authentication, authorization, and/or accounting (AAA).

InFIG. 1, upgrading a password generating component of client device may result in changingclient device102's scheme for generating a hash based on a plain-text password. Consequently, after the upgrade, whenclient device102 is required to provide a password topolicy server device108 to gain access tonetwork104,client device102 may send a new hash topolicy server device108. Whenpolicy server device108 cannot authenticateclient device102 because the hash has changed,policy server device108 may allowclient device102 to send the plain-text password. Ifpolicy server device108 can authenticateclient device102 by comparing an old hash that is determined based on the plain-text password to a hash retrieved from a password database,policy server device108 may update the password database. Updating the password database may permitpolicy server device108 to thereafter authenticateclient device102 based on the new hash.

In the above, the server-side mechanism for receiving a plain-text password, authenticating the client device based on the plain-text password, and upgrading the password database may be constructed using server applications and components, such as a telnet server, a web server (e.g., Apache web server), and/or other types of server-side resources (e.g., a login script, a web page, etc.). By using these server applications and resources, the mechanism may be implemented inexpensively.

If a mechanism different from the one described above is used to update the password database, a policy server device may need to recognize when a client device upgrades its password generating component and use information related to old hashes. Implementing such mechanisms may entail writing complex server-side software.

FIG. 2 is a block diagram of anetwork device200 that may representclient device102,NAD106, and/orpolicy server device108. As shown,network device200 may include aprocessor202, amemory204, anetwork interface206, and/or input/output devices208 connected via one ormore communication paths210.

Processor202 may include one or more processors or microprocessors, and/or processing logic capable of controllingnetwork device200.Memory204 may include static memory, such as a read only memory (ROM), and/or a dynamic memory, such as a random access memory (RAM), an onboard cache, etc., for storing data and machine-readable instructions.Memory204 may also include storage devices, such as a floppy disk, compact disk (CD), and/or flash memory, as well as other types of storage devices.

Network interface206 may include any transceiver-like mechanism that enablesnetwork device200 to communicate with other devices and/or systems. For example,network interface206 may include mechanisms for communicating with other devices on a network. Additionally or alternatively,network interface206 may include an Ethernet interface and/or an interface/connection for connectingnetwork device200 to other devices (e.g., a wireless interface).

Input/output (I/O)devices208 may include a display (e.g., a LCD, a cathode ray tube (CRT) display, etc.), a mouse, a speaker, a Digital Video Disk (DVD) writer, a DVD reader, Universal Serial Bus (USB) lines, and/or other types of devices for converting physical events or phenomena to and/or from digital signals that pertain to networkdevice200.Communication paths210 may provide an interface through which components ofnetwork device200 can communicate with one another.

InFIG. 2, each of the components (e.g.,processor202,memory204, etc.) may be implemented or configured differently, depending on whethernetwork device200 is implemented asclient device102,NAD106, orpolicy server device108. For example, ifnetwork device200 is implemented asclient device102, input/output devices208 may include a liquid crystal display (LCD), a keyboard, a mouse, etc. In another example, ifnetwork device200 is implemented aspolicy server device108, input/output devices208 may include a specialized storage device for fast data access.

FIG. 3 is a functional block diagram ofexemplary client device102. As shown,client device102 may include anauthentication client302 and are-authentication client304. Depending on implementation,client device102 may include fewer, additional, or different components than those illustrated inFIG. 3.

Authentication client302 may include hardware and/or software for generating and sending a plain-text or a hashed password in accordance with a specific authentication protocol.Authentication client302 may prompt the user for the password, retrieve the password from storage, or retrieve the password from other software running onclient device102. Examples of the specific authentication protocol may include a challenge-handshake authentication protocol (CHAP), a Microsoft (MS) CHAP (MSCHAP), MSCHAP Version 2 (MSCHAPv2), etc.Re-authentication client304 may include hardware and/or software for generating/obtaining and sending a plain-text password.Re-authentication client304 may send the plain-text password in a specific format (e.g., Hyper-Text Markup Language (HTML)) and/or in accordance with a specific communication protocol (e.g., Hyper-Text Transfer Protocol (HTTP)). Examples ofre-authentication client304 may include a telnet client, a web browser, etc.

FIG. 4 is a functional block diagram ofpolicy server device108. As shown,policy server device108 may include anauthentication server402, are-authentication server404, and apassword database406. Depending on implementation,policy server device108 may include additional, fewer, or different components than those illustrated inFIG. 4 in various configurations. For example,policy server device108 may include additional components that pertain to accounting functions. In another example, components that are illustrated inFIG. 4 may be distributed over multiple network devices.

Authentication server402 may include hardware and/or software for performing authentication in accordance with a specific protocol (e.g., Remote Authentication Dial-In User Service (RADIUS) protocol, Diameter protocol, etc.). In performing the authentication,authentication server402 may compare a hash fromclient device102 to a value derived from a stored value. The stored value may be retrieved frompassword database406. The authentication may succeed if the hash in the message and the derived value are identical.

Re-authentication server404 may include hardware and/or software for providingclient device102 with a capability to send a plain-text password topolicy server device108 whenauthentication server402 fails to authenticateclient device102. In one example,policy server device108 may placeclient device102 on a quarantine VLAN and allowclient device102 to send the plain-text password to the re-authentication server via a browser over the VLAN.

Whenre-authentication server404 receives the plain-text password fromclient device102 over the quarantine VLAN,re-authentication server404 may compare a value derived from the plain-text password with a value derived from a stored value retrieved frompassword database406. If the authentication succeeds (e.g., the value derived from the plain-text password is identical to the value derived from the value stored in database406),re-authentication server404 may updatepassword database406 or causepassword database406 to be updated. The update may replace the hash with a new hash inpassword database406. The reason it may be possible forre-authentication server404 to authenticate the user whenauthentication server402 was unable to is thatre-authentication server404 has received the user's plain-text password and can thus compute a value from the plain-text password which can be compared to the value stored inpassword database406.

Password database406 may include pairs of keys and hashed passwords. A key may include an identifier, such as a user identifier. A hashed password may include either an old hash or a new hash.

Exemplary Process for Updating Stored Passwords

The above paragraphs describe system elements that are related to devices and/or components for updating password storage formats.FIGS. 5A and 5B showexemplary process500 that is capable of being performed by one or more of these devices and/or components.

FIG. 5A is a flow diagram of part ofprocess500, for authenticatingclient device102. Assume that prior tostarting process500,authentication client302 may or may not have been upgraded. Ifauthentication client302 has been upgraded, the upgrade may have been performed by installing a software update forauthentication client302. In one implementation, the upgrade may have been performed by downloading and installing a network copy of the software update forauthentication client302. The upgrade ofauthentication client302 may change the hashing scheme used byauthentication client302.

Process500 may begin atblock502, where a request for a connection to a network fromNAD106 may be received at authentication server402 (FIG. 4) (block502). The request may include parameters such as a user identifier and a hash of a password. The request may have been generated byNAD106, based on the user identifier and/or the hash of a password that are received fromclient device102. The hash may have been obtained by applying a hashing scheme (e.g., Message-Digest algorithm 5 (MD5)) to a challenge string from the policy server and the password, which, in turn, may or may not already have been a hash of a plain-text password.

Client device102 may be authenticated (block504). The authentication may be performed by comparing the hashed password in the request with a value derived from a hash that is retrieved frompassword database406. The hash may be retrieved by using the identifier in the request as a key.

Atblock506, if the authentication fails,process500 may proceed toblocks510 inFIG. 5B. The authentication may fail if the hashed password in the received request and the derived value are different. In a different implementation, if the authentication fails, a user may be presented with a choice of either returning to block502 to supply another password or proceeding to block510. If the authentication succeeds,client device102 may be provided with a connection to network104 (block508).

Atblock506, whetherclient device102 is successfully authenticated may depend on ifauthentication client302 atclient device102 has been upgraded since the last successful attempt byclient device102 to connect tonetwork104.FIG. 6A highlights the differences in the authentication process whenauthentication client302 has not been and has been upgraded.

As illustrated inFIG. 6A, before the upgrade,authentication client302 may provide a password O(X,C)602, where X is a plain-text password, C is a challenge string from the policy server device, and O( ) is a function that encodes or hashes the plain-text password X and the challenge string C. Note that O may involve computing a cryptographic hash of plain-text password X and then computing a second cryptographic hash of the cryptographic hash of the plain-text password X combined with challenge string C. Depending on the authentication scheme in use before the upgrade, challenge string C may not be specified. In addition, depending on the authentication scheme in use before the upgrade, O(X,C) may be identical to X. AtNAD106, a transformation function R( ) may be applied to O(X,C)602 to produce R(O(X,C))604. The transformation function R( ) may hash, encrypt, or leave intact O(X,C). As further shown inFIG. 6A, R(O(X,C))604 may be sent topolicy server108. Atpolicy server108,client device102 may be authenticated by comparing R(O(X,C))604 to a value derived from a hash that is retrieved frompassword database406. The authentication may succeed, as both R(O(X,C))604 and the value derived from the retrieved hash may be identical.

After the upgrade,authentication client302 may provide password N(X,C)606, where N(X,C) is a function that maps plain-text password X and challenge string C to a new hash. N( ) may involve computing a cryptographic hash of plain-text password X, and computing a second cryptographic hash of the cryptographic hash of plain-text password X, combined with challenge string C. Depending on the authentication scheme in use after the upgrade, challenge string C may not be specified. In addition, depending on the authentication scheme in use after the upgrade, O(X,C) may be identical to X. AtNAD106, a transformation function G( ) may be applied to N(X,C)606 to produce G(N(X,C))608. In one implementation,NAD106 may employ G( ) in place of R( ) whenNAD106 recognizes the upgrade of authentication client302 (e.g., via messages received), and modify its transformation function from R( ) to G( ). In some implementations, G(N(X,C)) may not further encode N(X,C), but merely preserve N(X,C). That is, G(N(X,C)) may equal N(X,C).

NAD106 may send G(N(X,C))608 topolicy server108.Policy server108 may perform an authentication ofclient device102 by comparing G(N(X,C))608 to a value derived from a hash retrieved frompassword database406. The authentication may fail, as the value derived from the hash retrievedform password database406 may not be identical to G(N((X,C))608, but to R(O(X,C))604.

FIG. 5B is a flow diagram of part ofprocess500 for updating a password atpolicy server device108. Atblock510, a limited network access may be granted toclient device102. In one implementation, the limited network access may be granted bypolicy server device108. In other implementations, the limited network access may be granted by other devices and/or components that may be included innetwork104.

The purpose of granting the limited network access may be to allowclient device102 to create a temporary channel (e.g., a secure HTTP connection) betweenclient device102 andpolicy server device108 and to allowclient device102 to send a plain-text password topolicy server device108. Without the limited network access and the temporary channel, when a password is sent fromclient device102 topolicy server108,NAD106 may prevent the password from being relayed topolicy server device108 or may hash or encrypt the password and prevent the password from arriving atpolicy server device108 in plain-text.

The limited network access may be granted in various ways. For example,policy server device108 may placeclient device102 on a VLAN viaNAD106. In another example,policy server device108 may causeNAD106 to grantclient device102 the limited network access, by sending an access control list (ACL) toNAD106.

A plain-text password may be received (block512). The password may be provided byclient device102 over the temporary channel that is established betweenclient device102 andpolicy server108. In one implementation, the user may launch a web browser and provide the password in the plain-text in HTML over a secure HTTP (HTTPS) connection betweenclient device102 andre-authentication server404.

FIG. 6B shows the flow of plain-text password X610. As shown,re-authentication client304 may provide plain-text password X610.NAD106 may not hash messages that are exchanged over the temporary channel, and therefore, plain-text password X612 is in the same format aspassword X610.

FIG. 6C highlights the difference between how the plain-text password and a new hash (e.g., a password that is produced byauthentication client302 after the upgrade) may be received atpolicy server device108. As shown, G(N(X,C)), a new hash, is received atauthentication server402. In contrast, the plain-text password is received atre-authentication server404.

Returning toFIG. 5B, atblock514, a hash of the received password may be determined. In one implementation, the hash may be determined by applying O( ) to the plain-text password X and challenge string C and R( ) to O(X,C). Both O( ) and R( ) may be known tore-authentication server404 and/orauthentication server402.

The client device may be authenticated by comparing the hash of the received password to a value derived from a hash that is retrieved from password database406 (block516). If the received hash and the value derived from the retrieved hash are identical, the authentication may succeed; otherwise, the authentication may fail.

Atblock518, if the authentication fails,process500 may terminate. In a different implementation,process500 may return to block510 ifclient device102 has not exhausted a particular number oftimes client device102 is permitted to input a plain-text password. Ifclient device102 has failed to supply the correct password within the particular number of tries,process500 may terminate.

If the authentication succeeds,password database406 may be updated by replacing the old hash (e.g., one that may be used bypolicy server108 to compute R(O(X,C)) with the new hash (e.g., one that may be used bypolicy server108 to compute G(N(X,C)) (block520). The new hash may be determined based on the plain-text password X, N( ), and G( ).

Afterblock520 completes, ifclient device102requests policy server108 to provide a new connection tonetwork104,authentication server402 may successfully authenticate client device by comparing a hash fromclient device102 to a value derived from the new hash retrieved from updatedpassword database406, provided that the hash fromclient device102 is generated based on a correct password.

EXAMPLE

The following example illustrates a process for updating stored passwords, with reference toFIGS. 7A-7C. The example is consistent with the exemplary process described above with reference toFIGS. 5A and 5B.

In the example, as illustrated inFIG. 7A-7C, assume thatclient device102 includes anauthentication client702. Also, assume thatclient device102 includes a web browser704 (FIG. 7C) as its re-authentication client. In addition, assume thatpolicy server706 includes aweb server708 as its re-authentication server, aRADIUS authentication server710 as its authentication server, and a password database712 (FIG. 7B). Furthermore, assume thatauthentication client702 prior to an upgrade sends plain-text passwords andauthentication client702 after the upgrade is compliant with MSCHAPv2.

Prior to the upgrade, whenauthentication client702 attempts to obtain a connection to a network to whichpolicy server706 may grant access,authentication client702 sends a plain-text password714 and a user identifier. WhenRADIUS authentication server710 receives plain-text password714,RADIUS authentication server710 generates thehash718 ofplain text password714. Provided that the password is correct, the authentication succeeds, ashash718 matches a hash that is retrieved fromRADIUS password database712.

After the upgrade, whenauthentication client702 attempts to obtain a connection to the network,authentication client702 uses EAP-MSCHAPv2 to send a cryptographic hash of a cryptographic hash of the password combined with a challenge string toRADIUS authentication server710.RADIUS authentication server710 performs an authentication. The authentication fails. The hash that is stored inpassword database712 does not produce the same value computed byauthentication client702, because the hash stored inpassword database712 is produced by a different algorithm than the algorithm used for hashing passwords in EAP-MSCHAPv2.

After the authentication failure,policy server device706 instructsNAD716 to placeauthentication client702 onVLAN724, and a user at the client device sends a plain-text password inHTTP request726 viabrowser704.Browser704 transmits plain-text password inHTTP request726 toNAD716, which relays the plain-text password inHTTP726 toweb server708 inpolicy server device706.

Web server708 computeshash718 of the plain-text password and compares the computed hash to the hash inpassword database712. The hash of the plain-text password matches the retrieved hash, andRADIUS authentication server710 succeeds in authenticatingclient device102. Furthermore,password database712 is updated with a different hash of the password using the algorithm for hashing password from MSCHAPv2. Afterdatabase712 has been updated, subsequent authentication attempts byclient device102 using EAP-MSCHAPv2 may succeed.

In the above, the server-side mechanism for updating the password may be constructed using server applications and components, such as a telnet server, a web server, etc., and/or other types of server-side resources (e.g., a login script, a web page, etc.). By using such components (e.g., web server), the mechanism may be implemented inexpensively.

CONCLUSION

The foregoing description of implementations provides illustration, but is not intended to be exhaustive or to limit the implementations to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the teachings.

For example, while a series of blocks have been described with regard to the process illustrated inFIGS. 5A and 5B, the order of the blocks may be modified in other implementations. In addition, non-dependent blocks may represent acts that can be performed in parallel to other blocks.

It will be apparent that aspects described herein may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement aspects does not limit the invention. Thus, the operation and behavior of the aspects were described without reference to the specific software code—it being understood that software and control hardware can be designed to implement the aspects based on the description herein.

Further, certain portions of the implementations have been described as “logic” that performs one or more functions. This logic may include hardware, such as a processor, an application specific integrated circuit, or a field programmable gate array, software, or a combination of hardware and software.

Even though particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to limit the invention. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification.

No element, act, or instruction used in the present application should be construed as critical or essential to the implementations described herein unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items. Where one item is intended, the term “one” or similar language is used. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise.

Claims (21)

What is claimed is:

1. A client device comprising:

an input/output device;

a processor communicatively coupled to the input/output device;

a memory storing executable instructions that, when executed by the processor,

instantiate an authentication client module and a re-authentication client module, the authentication client module configured to:

generate a plain-text password;

generate a first hash value based on the plain-text password, the first hash value generated according to a first hash generating scheme, the first hash generating scheme defining a first hash function that generates a first hash value based on an input value;

request, via the input/output device, access to a network comprising a network access device according to an authentication protocol;

send, via the input/output device, the first hash value to the network access device;

modify the first hash generating scheme to produce a second hash generating scheme, the second hash generating scheme defining a second hash function different than the first hash function that generates a second hash value based on the input value; and

generate a second hash value based on the plain-text password according to the second hash generating scheme; and

the re-authentication client module configured to:

in response to a policy server operating on the network receiving both the first hash value and the second hash value from the client device and failing to authenticate both the first hash value and the second hash value, establish, via the input/output device, a secure HTTP connection between the client device and the policy server; and

transmit, via the input/output device, the plain-text password from the client device to the policy server over the secure HTTP connection.

2. The client device ofclaim 1, wherein the processor comprises a microprocessor or a hardware processing logic, and wherein the memory includes any one of a static memory, a dynamic memory, and an onboard cache for storing data and machine-readable instructions.

3. The client device ofclaim 2, further comprising a network interface device comprising any one of a wired local area network interface device, a wired wide area network device, a wireless local area network interface device, a wireless wide area network interface device, and a cellular network interface device.

4. The client device ofclaim 1, wherein generating the plain-text password comprises one of: prompting a user of the client device to enter the plain-text password, retrieving the plain-text password from the memory, and retrieving the plain-text password from another module operating on the client device.

5. The client device ofclaim 1, wherein the authentication protocol is any one of a challenge-handshake authentication protocol (CHAP), a Microsoft (MS) CHAP (MSCHAP) authentication protocol, or a MSCHAP Version 2 (MSCHAPv2) authentication protocol.

6. The client device ofclaim 1, wherein the re-authentication client module is further configured to transmit the plain-text password from the client device to the policy server in either one of the Hyper-Text Markup Language (HTML) or the Hyper-Text Transfer Language (HTTP).

7. The client device ofclaim 1, wherein the authentication client module is configured to generate the second hash value based on the plain-text password according to the second hash generating scheme by downloading to the client device and installing on the client device a software update of the authentication client module.

8. The client device ofclaim 1, wherein the authentication client module is further configured to:

receive a challenge string from the policy server;

store the challenge string on the memory; and

generate each of a first cryptographic hash value of the challenge string and the plain-text password and a second cryptographic hash value of the challenge string and the plain-text password based on one of the first hash generating scheme and the second hash generating scheme.

9. The client device ofclaim 8, wherein the authentication client module is further configured to transmit each of the first cryptographic hash value and the second cryptographic hash value to the policy server.

10. The client device ofclaim 1, wherein the secure HTTP connection between the client device and a policy server is a temporary connection.

11. The client device ofclaim 1, wherein the policy server is further configured to configure the secure HTTP connection between the client device and the policy server to prevent the network access device from modifying the plain-text password.

12. The client device ofclaim 1, wherein the policy server is further configured to configure the secure HTTP connection between the client device and a policy server by establishing a virtual local area network (VLAN) between the authentication client module and the policy server.

13. The client device ofclaim 1, wherein the policy server is further configured to configure the secure HTTP connection between the client device and the policy server by transmitting an access control list to the network access device.

14. A method comprising:

generating, by an authentication client module of a client device comprising at least one hardware processor, a plain-text password;

generating, by the authentication client module, a first hash value based on the plain-text password according to a first hash generating scheme, the first hash generating scheme defining a first hash function that generates a first hash value based on an input value;

requesting, via an input/output device of the client device, access to a network comprising a network access device according to an authentication protocol;

sending, via the input/output device, the first hash value to the network access device;

modifying, by the authentication client module, the first hash generating scheme to produce a second hash generating scheme, the second hash generating scheme defining a second hash function different than the first hash function that generates a second hash value based on the input value;

generating, by the authentication client module, a second hash value based on the plain-text password according to the second hash generating scheme;

establishing, by a policy server communicatively coupled to the client device via a network, a secure HTTP connection between a re-authentication module of the client device and the policy server in response to the policy server receiving both the first hash value and the second hash value and failing to authenticate both the first hash value and the second hash value from the client device; and

transmitting, by the re-authentication client module via the input/output device, the plain-text password from the client device to the policy server over the secure HTTP connection.

15. The method ofclaim 14, wherein generating the plain-text password comprises one of: prompting a user of the client device to enter the plain-text password, retrieving the plain-text password from the memory, and retrieving the plain-text password from another module operating on the client device.

16. The method ofclaim 14, wherein the authentication protocol is any one of a challenge-handshake authentication protocol (CHAP), a Microsoft (MS) CHAP (MSCHAP) authentication protocol, or a MSCHAP Version 2 (MSCHAPv2) authentication protocol.

17. The method ofclaim 14, wherein the plain-text password is transmitted from the client device to the policy server in either one of the Hyper-Text Markup Language (HTML) or the Hyper-Text Transfer Language (HTTP).

18. The method ofclaim 14, wherein the second hash value is generated based on the plain-text password according to the second hash generating scheme by downloading to the client device and installing on the client device a software update of the authentication client module.

19. The method ofclaim 14, wherein the secure HTTP connection between the client device and a policy server is a temporary connection.

20. The method ofclaim 14, wherein the secure HTTP connection between the client device and a policy server is configured to prevent the network access device from modifying the plain-text password.

21. The client device ofclaim 1, wherein the second hash function is a function of the first hash function.

Images