Previous section.

X/Open Single Sign-on Service (XSSO) -<br> Pluggable Authentication Modules

X/Open Single Sign-on Service (XSSO) -
Pluggable Authentication Modules
Copyright © 1997 The Open Group


The issue of codesets is viewed by the working group as a general issue that requires addressing globally. It would be to parochial to try and address currently in PAM.

This appendix documents the issue and some proposals as presented to and discussed by the working group.


The PAM architecture assumes that usernames and passwords are selected from the same codeset and handled using C programming character pointers. This may not be true since there are a variety of codesets available. In addition, not all characters sets are handled using C character pointers. A proposal from Hewlett-Packard recommends a parameter to maintain the codeset type.

Single System Codesets

A username and corresponding password are compared against stored data, (/etc/passwd on a simple UNIX machine). On a stand-alone machine, the comparison data and the interface which captures data, utilize the same codeset.

A simple byte by byte match between the text collected by the interface and the comparison data may be used for the username. Yet, passwords comparisons are not so simple since it is dependent upon the codeset by which the password is represented.

For example, let us consider a user with password "ABCD" on a system where the password comparison data is formed in the UNIX manner.

If the system uses the ASCII codeset, an encryption key is generated from {0x41, 0x42, 0x43, 0x44} and a fixed plaintext is encrypted with this key. If the system uses EBCDIC, the encryption key is generated from {0xC1, 0xC2, 0xC3, 0xC4}.

Therefore, even if the plaintext is encrypted using identical algorithms on these two systems, the results will differ due to the codeset.


If the login interface and the authentication service (AS) do not reside on the same machine, it is not reasonable to assume compatible codesets are deployed.

For example, in a Japanese enterprise where the username is in Kanji, a user logs into a machine which uses Shift-JIS. But suppose the authentication service is based upon eucJP. In order to achieve successful authentication, the Shift-JIS username must be recognized by the eucJP service.


A system may restrict passwords to a particular set of characters which exist in all versions of EBCDIC and localizations of ISO 646, such as ASCII. The system may also perform conversions to ISO 646 prior to processing. Although this guarantees consistent comparison data, it may be undesirable. Technically, this approach is not sufficient - as the character set decreases, passwords become weaker. In addition, it is inconvenient to use an unfamiliar set of characters for password selection.

Proposed Solution

From the previous example, a user has a Kanji password (Shift-JIS codeset) but an AS which requires a different codeset, eudJP. One potential solution involves passing the Shift-JIS password, with a tag indicating the codeset type, from the client to the AS though a protected channel. The AS converts the password to eucJP and proceeds with its comparison to the stored data.

The stored value in the remote AS differs from the encrypted Shift-JIS password (on the local machine) since different codesets are employed. If local authentication is required, password synchronization between the machines may not be achieved by simply copying the remote AS's stored value to the client, even though both use the same encryption algorithm.

Further complications arise if the client attempts to convert the password to the codeset used by the remote AS. That is, the client must determine the codeset used by the AS. In addition, if local authentication is required, the client must not only verify the type of codeset applied to generate the data, but also securely retrieve the stored value from the remote AS.

Regardless of codesets, authentication services must function properly.

Smart Cards

The issues discussed above apply to smart cards which are used primarily as a repository of passwords and computations are performed elsewhere. If passwords on a card are indexed by username, there may be complications if identical usernames are used on machines with different codesets. However, if passwords are indexed by system name and username pairs, smart cards may hold passwords in the localized codeset.
Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.

Contents Next section Index