USER AUTHENTICATION


What is user authentication?

User authentication is the act of confirming the truth of information that is claimed as being true by a potential user (i.e. determining whether someone is, in fact, who they declare they are). In IT systems, authentication is a process in which the credentials provided by someone wanting to access a system are compared to those on file of authorised users’ information. If the credentials match, the user is granted access.


Under what circumstances is user authentication required?

An authentication regime should be used at any time when confidence is required that access to information is being given to specific authorised users. For shared IT systems user authentication it is a critical process because it allows for checking that users are who they say they are, and that access can be subsequently granted only to qualified users.


How is user authentication achieved?

Authentication can be achieved by various methods including using passwords, biometric measurements, cryptographic tokens or smartcards.

The three aspects that can be used to authenticate someone are:

  • Something the person knows (e.g. password, or a response to a question);
  • Something the person has (e.g. a mobile phone, a smartcard, a physical token);
  • Something the person is (e.g. biometric data like a fingerprint, facial morphology).

Single-factor authentication uses only one of the above authentication aspects to assure a user’s identity.

Multi-factor authentication uses two or more of the above authentication aspects to assure a user’s identity.


Existing National Authentication Frameworks and Systems

National e-Authentication Framework

The National e-Authentication Framework (NeAF) is primarily aimed at government agencies in Australia, but provides a structure to help decide how robust an authentication procedure should be employed for a shared IT system. This is directly related to the level of sensitivity of information held in the IT system, and the risk associated with / consequences of what would happen should authentication not be done appropriately and data being inadvertently released to unauthorised 3rd parties.

The NeAF defines 5 assurance levels based upon the assessment of the threats and impacts to agencies and/or end-users of getting authentication wrong:

table1

Interpretation by med.data.edu.au Node Operators of the NeAF with respect to data stored on med.data.edu.au (i.e. human-derived, de-identified or not, encrypted or not) is as follows:

table2

Australian Access Federation

The Australian Access Federation (AAF) provides the means of allowing participating institutions (e.g. a University or Medical Research Institute) and IT service providers (e.g. Node Operators of med.data.edu.au) to trust the information they receive from one another, and to ensure that users of IT systems are identified and authenticated by an appropriate authority (i.e. the user’s employing institution), which allows seamless access to resources.

With respect to authentication across this federation, AAF have developed an Assurance Framework that is based on the US National Institute of Standards and Technology (NIST) Electronic Authentication Guideline – NIST SP 800-63-2 and the US Government OMB Memorandum M-04-04, E-Authentication Guidance for Federal agencies (December 16, 2003) which define 4 levels of assurance, that are broadly equivalent to Levels 1-4 of the NeAF discussed above.

Through the AAF Assurance Framework, the AAF cater (by default) for Level 1 (minimal) assertion, and Level 2 (low) assertion through the optional use of the “AAF Assurance” Tool which can be used by individuals wishing to be granted permission to services which require slightly tighter authentication controls.

Level 3 (high) and Level 4 (very-high) of assurance would be asserted by providing additional forms of personal information, and this is not currently catered for via AAF.

National Authentication Service for Health (NASH)

The National Authentication Service for Health (NASH) is specialist authentication framework and service developed specifically to allow healthcare providers and others to securely access and exchange personally identifiable e-heath information in Australia. It has been developed by the National E-Health Transition Authority (NEHTA).

NASH provides Public Key Infrastructure (PKI) Certificates that help an organisation to: (a) access the Personally Controlled Electronic Health Record (eHealth record) system and to (b) send and receive messages securely using software that meets the requirements of Secure Message Delivery. NASH PKI Certificates can be issued to healthcare providers and supporting organisations that are registered in the Healthcare Identifiers Service.

The applicability of NASH to underpin authentication requirements in the Health and Medical research requires ongoing examination.


What are the Australian Standards for Authentication?

In addition to the standards employed by the NASH service for authenticating users of identified Health Information, the Australian Signals Directorate (ASD) provides extensive guidance to Commonwealth entities surrounding authentication standards to safeguard any type of data ranging in different levels of sensitivity, from “unclassified but sensitive or official information not intended for public release” (UD), through “protected” (P), to “Top Secret” (TS). Associated security controls are outlined in the ASD’s Information Security Manual (ISM).

Whilst it is only Australian Government agencies that are required to adopt the ASD controls outlined in the ISM, the controls also provide a useful framework for non-government organisations to consider when protecting data that ranges across various levels of sensitivity. Data of this type includes Personal Health Information that contains identifying aspects which is considered to be both “sensitive”[1] and “protected”[2].

The following ASD controls are issued for agencies in protecting data that are considered “unclassified but sensitive or official information not intended for public release” (UD) or “protected” (P).

Policies and procedures

ASD Control: 0413; Revision: 4, Applicability: UD, P. A set of policies and procedures covering user identification, authentication and authorisation must be developed and maintained, as well as communicated to and understood by others.

Authentication methods

ASD Control: 0417; Revision: 3. Applicability: UD, P.
Agencies must not use a numerical password (or personal identification number) as the sole method of authenticating a user.

ASD Control: 0421; Revision: 4. Applicability: UD, P.
Agencies using passphrases as the sole method of authentication must enforce the following passphrase policy:

  • a minimum length of 13 alphabetic characters with no complexity requirement; or
  • a minimum length of 10 characters, consisting of at least three of the following character sets:
    • lowercase alphabetic characters (a–z),
    • uppercase alphabetic characters (A–Z),
    • numeric characters (0–9),
    • special characters.

ASD Control: 1426; Revision: 0. Applicability: UD, P.
When systems cannot be configured to enforce passphrase complexity requirements, passphrases must be checked by alternative means for compliance with passphrase policies.

ASD Control: 0974; Revision: 4. Applicability: UD, P.
Agencies should use multi–factor authentication for all users. (System administrators, database administrators and other privileged users are more likely to be targeted by an adversary as their credentials can potentially allow access to an entire system. For this reason, it is important that multi-factor authentication is used for these accounts – see ASD Control 1173).

ASD Control: 1173; Revision: 1. Applicability: UD, P.
Agencies must use multi–factor authentication for:

  • system administrators,
  • database administrators,
  • privileged users,
  • positions of trust,
  • remote access.

When multi–factor authentication is used, the requirements for passphrases can be relaxed due to the additional protection afforded by a second, and different, authentication method.

ASD Control: 1401; Revision: 0. Applicability: UD, P.
Agencies using passphrases as part of multi-factor authentication must ensure a minimum length of 6 alphabetic characters with no complexity requirement.

ASD Control: 1357; Revision: 0. Applicability: UD, P.
Where multi–factor authentication is implemented, none of the factors on their own should be useful for authentication on another system.

ASD Control: 0423; Revision: 2. Applicability: UD, P.
Agencies must:

  • ensure that passphrases are changed at least every 90 days,
  • prevent passphrases from being changed by the user more than once a day,
  • prevent passphrases from being reused within eight passphrase changes,
  • prevent the use of sequential passphrases where possible,
  • prevent passphrases being stored in cleartext.

ASD Control: 1403; Revision: 0. Applicability: UD, P.
Agencies must ensure accounts are locked after a maximum of five failed logon attempts.

ASD Control: 0976; Revision: 3. Applicability: UD, P.
Agencies must ensure users provide sufficient evidence to verify their identity when requesting a passphrase reset for their system account. Issuing accounts with unique complex reset passphrases ensures the security of the account is maintained during the passphrase reset process.

ASD Control: 1227; Revision: 1. Applicability: UD, P.
Agencies must ensure reset passphrases are:

  • random for each individual reset
  • not reused when resetting multiple accounts
  • not based on a single dictionary word
  • not based on another identifying factor, such as the user’s name or the date.

ASD Control: 0428; Revision: 0. Applicability: UD, P.
Agencies must configure systems with a session or screen lock which:

  • activates either after a maximum of 15 minutes of user inactivity or if manually activated by the user
  • completely conceals all information on the screen
  • ensures that the screen does not enter a power saving state before the screen or session lock is activated
  • requires the user to reauthenticate to unlock the system
  • denies users the ability to disable the session or screen locking mechanism.

ASD Control: 0430; Revision: 4. Applicability: UD, P.
Agencies must remove or suspend accounts on the same day a user no longer has a legitimate business requirement for its use.

ASD Control: 1404; Revision: 0. Applicability: UD, P.
Agencies should remove or suspend accounts after one month of inactivity.

ASD Control: 0408; Revision: 3. Applicability: UD, P.
Systems should have a logon banner that requires a user to acknowledge and accept their security responsibilities before access to the system is granted.

ASD Control: 0979; Revision: 3. Applicability: UD, P.
Agencies should seek legal advice on the exact wording of logon banners.

ASD Control: 0980; Revision: 5. Applicability: UD, P.
Logon banners should explicitly state conditions of access to a system, including:

  • access is restricted to authorised users
  • acceptable usage and information security policies
  • the user’s agreement to abide by abovementioned policies
  • informing the user of activity monitoring and auditing
  • legal ramifications of violating the relevant policies
  • a point of contact for questions on these conditions.

ASD Control: 0856; Revision: 3. Applicability: UD, P.
Users’ authorisations must be enforced by access controls.

Protecting authentication information

Storing authentication credentials such as usernames and passphrases as plaintext in databases poses a significant risk.

ASD Control: 1252; Revision: 1. Applicability: UD, P.
Passphrases stored in databases must be hashed with a strong hashing algorithm which is uniquely salted.

ASD Control: 0418; Revision: 1. Applicability: UD, P.
Authentication information must be stored separately to a system to which it grants access.

ASD Control: 1402; Revision: 0. Applicability: UD, P.
Authentication information stored on a system must be protected.

ASD Control: 0419; Revision: 2. Applicability: UD, P.
Authentication information must be protected when communicated across networks.


[1] The Commonwealth Privacy Act (1988) http://www.oaic.gov.au/privacy/privacy-act/the-privacy-act) defines what is considered personal and sensitive information in Australia. Personal Information means information about an identified individual, or an individual who is reasonably identifiable, and of relevance to med.data, Sensitive Information includes: Information about an individual’s Racial or ethnic origin or Sexual orientation or practices; Health information; Genetic information and Biometric information.
[2] The US HIPPA Privacy Rule (http://www.hhs.gov/ocr/privacy/hipaa/administrative/privacyrule/index.html ) defines protected health information” as individually identifiable health information, including identifiable demographic and other information relating to the past, present, or future physical or mental health or condition of an individual, or the provision or payment of health care to an individual that is created or received by a health care provider, health plan, employer, or health care clearinghouse. Genetic information is considered to be health information.