We have all got something to hide. There are some data that the law itself states not everybody should have access to.
Data need to be protected
Some data need to be protected. We need to make sure that we can reliably verify the identity of the individual attempting to access the data. To this end, there are systems available that we can employ to manage identities. Like Univention Corporate Server, for example. The simplest version of verifying an authorised user’s identity is also the one which has been tried and tested for the longest time: whether the user knows a secret. A password.
Yet simple passwords are falling more and more into disuse. For a long time now we’ve heard from reports across all media that simply knowing the secret “password” is no longer enough for reliably guaranteeing identities and protecting access to our data.
Way back in 1982, Admiral James T. Kirk could only access the Genesis data when he authenticated himself by means of a retinal scan in “The Wrath of Khan”. Hollywood has already done away with simple passwords.
Nevertheless, it took a further four years before the RSA launched the first SecurID token on the market in 1986, with the aim of helping to secure access to protected areas and sensitive information by means of possession of the SecurID device. As such, the user is only granted access if he can enter a password that he knows and uses the device that he owns. This is also know as two-factor authentication, comprising knowledge and possession, which makes verification of the user’s identity considerably more reliable.
The SecurID token was the first OTP (one-time password) token. The idea behind it is that a device uses a secret code to generate an apparently random password The system can then check whether the apparently random password is correct. If the user enters the correct one-time password, it can be concluded that the user has the corresponding device in his possession, as only that device is able to generate the apparently random password.
Although the RSA SecurID token works with a proprietary algorithm right up to the present day, there are now a whole range of standards which verifiably describe how this type of one-time password can be generated.
Standardisation of the “HOTP” and “TOTP” algorithms
The standardisation of the “HOTP” and “TOPT” algorithms in RFC 4226 in 2005 and RFC 6238 in 2011 has without a doubt contributed to authentication via OTP becoming considerably more widespread in recent years.
As the reliable mathematics were available, it was simple for many manufacturers to offer ever more cost-effective and attractive devices in the form of key rings, USB sticks (YubiKey) or flat EC cards (SmartDisplayer) on the market as of 2006. As smartphones became more popular and especially with the introduction of the App Store and Play Store in 2008, it became possible to integrate smartphones into the world of secure identities as a virtual possession with a corresponding app. The globally popular Google Authenticator and the Open Source FreeOTP from Red Hat are the most noteworthy in this respect.
Fundamentally speaking, all algorithms function really similarly and they are all based on a symmetrical, secret code. A sequential counter incremented either by the press of a button or with the passing of time is combined with a code and embedded in a hash function. The result is adjusted accordingly, for example: so that it can be shown on a display or entered via a keyboard. The possibility of entering the credentials via a normal keyboard without the need to install drivers or hardware on the computer, tablet or smartphone has always been an enormous advantage of OTP-based authentication.
As the result is cropped to a 6-digit or 8-digit number, it is only possible to use a symmetrical procedure, unlike with PGP or X509 certificates. This means that the system performing the authentication needs to perform the same steps.
The secret code and the last counter value are saved on the server side too. When the user attempts to authenticate himself, the server calculates the same OTP value using the secret code it knows and the last counter value. To allow for desynchronisation, the server can also calculate additional attempts with the values counter+1 to counter+n. If the server calculates the same value, it can be concluded that the user is in possession of the device.
Open Source project privacyIDEA launched in 2014
The authentication and administration also require a backend system. 2014 saw the launch of privacyIDEA, an Open Source project offering a management system allowing administration of different devices and their assignment to users.
It supports all TOPT and HOPT devices as well as all common smartphone apps like Google Authenticator, FreeOTP and mOPT.
Since the end of April 2015, privacyIDEA has also been available in the App Center on the Univention Corporate Server and for integration in the UCS domains. As such, it is now possible to assign any authentication devices to any UCS user easily and quickly.
Plugins can be used to expand existing web applications with a login with a second factor. The login to the Linux system can be expanded with a centrally administrated OTP token in the PAM stack. Even the login to Windows clients can be made even more secure now with the help of the privacyIDEA Credential Provider.
33 years after James T. Kirk accessed the data of the Genesis project securely, this idea has now developed into a reliable, available solution. You too can now finally secure access to your data in the UCS network reliably.