Mobile-OTP

On the server side you will need the shell script:

You should also download the RADIUS server found at XTRadius (FreeRADIUS is also possible, see below).

There are also token clients for iPhone, Android, PalmOS and Openmoko in the Add-Ons and Links sections.

OTA install

The MIDlet is also available for direct download at www.getjar.com.
Just enter 2990 at their WAP-Download-Page.

Source

Installation

Client-Installation (token)

Server-Installation (authentication server)

To install and configure your authentication server, take the following steps:

1. Copy the otpverify.sh-script to /usr/local/bin and make it executable by chmod'ing it to +x
2. The script needs to have read/write access rights on /var/motp. Running it as root will make sure of this.
3. try to run it. It should report: USAGE: otpverify.sh Username, OTP, Init-Secret, PIN, Offset
4. run it again, this time supplying 5 arguments: otpverify.sh 1 2 3 4 5
   it should return: FAIL
5. initialize a token. Write down the Init-Secret. Generate a one time password by entering 5555 on the token. Try to verify this password by running "otpverify.sh testuser {password} {Init-Secret} 5555 0"
6. The script should return "ACCEPT". If it returns "FAIL", the clocks of server and token might differ. Take a look at the FAQ section.
7. As soon as you successfully authenticated a user, you should continue by installing the XTRadius-server. Keep to the instructions provided at XTRadius.
8. After the installation of the RADIUS server there are only 4 configuration-files to modify in /etc/raddb
9. Add a new dictionary file to /etc/raddb. It is called dictionary.motp and contains three new RADIUS-attributes: Secret, PIN and Offset. You can download the file here.
10. Add a line "$INCLUDE dictionary.motp" to /etc/raddb/dictionary, so that the new dictionary file will be loaded at server start up.
11. Add 3 macros to /etc/raddb/execparams or replace it by this file.
12. To create a /etc/raddb/users file containing your users, stick to this sample file: users. You can add further RADIUS attributes to each user entry, of course.
13. You are all set. Start the RADIUS server in debug-mode (radiusd -sxxy) and test the authentication with the "radtest" client provided with the RADIUS server.

Important security information for the use with FreeRADIUS:
Please be aware that FreeRADIUS interprets the exit codes of otpverify.sh differently as intended:
otpverify.sh returns exit codes from "0" to "7". Exit codes other than "0" are failure codes. Exit code "3" signals that authentication failed because the user has been locked. Unfortunately FreeRADIUS interprets "3" as "authentication accepted". It is therefore necessary to change the exit codes in otpverify.sh to something not in conflict with FreeRADIUS. Exit code "0" is still good for a successful authentication. Codes above "10" are safe to use for all failures (so change "exit 3" to "exit 13" in otpverify.sh (and so on)).

FAQ

How to test if authentication works?

1. Make sure that the otpverify.sh-script has read/write-access to /var/motp
2. Initialize a token by pressing "0000"
3. Write down the generated Init-Secret, e.g. 7ac61d4736f51a2b
4. Generate a one time password by entering a PIN, e.g. PIN=5555, result: af6543
5. Verify the one time password with the otpverify.sh-script: "otpverify.sh test af6543 7ac61d4736f51a2b 5555 0"
6. The script should return "ACCEPT". If it returns "FAIL" there might be a time difference between the token and the server. See How to synchronize server clock and token clock?
7. After successful authentication, try to authenticate with the same OTP again. It should fail, as a lock-file named "af65a3" has been touched in /var/motp/cache

How to synchronize server clock and token clock?

To find out the offset between a token and the server, do the following:

1. Access the "Info"-screen on the token, write down the 9-digit number under "Epoch-Time"
2. Enter "date +%s" on the server to display the current time in epoch notation. Write down the first 9 digits of the output.
3. Subtract both values. The result is the offset in 10s of seconds, i.e. an hour would be 360, two hours 720, etc.
4. The offset has to be configured in the "users" file of the RADIUS server for the specific user (Offset-Attribute).
5. Since version 1.05 there is the ability to alternatively set the time zone on the token itself as an offset in hours from UTC. So a user traveling to New York City would set the time zone on his Nokia phone to UTC-5 and change it back to UTC+1 when coming back to Berlin. The Offset configured for this user on the RADIUS server would be 0 at all times.
6. You can verify authentication on the command-line by "otpverify.sh test {OTP} {Init-Secret} {PIN} {offset}"

How to trouble-shoot authentication on the RADIUS server?

1. If authentication fails with a script-return-code of "1", make sure that PIN, Init-Secret and offset are correct. It is most likely that you have to configure an offset other than "0" for this user. See How to synchronize server clock and token clock? for details.
2. If the script returns "3", the account of this user has been locked as there have been 8 or more failed authentication attempts by this user. Delete the corresponding file in /var/motp/users to unlock the user account again.
3. A return code of "4" says that the otpverify.sh-script has not been called with 5 arguments. Check the configuration of the external authentication in the "users"-file of the RADIUS server.
4. A return code of "5" states that the specified password has already been used. Generate a new one time password and try to authenticate again.
5. A return code of "6" indicates that you do not have "md5" or "md5sum" installed on your system.
6. A return code of "7" is returned if the otpverify.sh cannot access the /var/motp directory to write a file.

Limitations

1. PINs and Init-Secrets are stored in clear text on the RADIUS server. It is hence obligatory to keep the server safe from unwanted access. This also applies to the log file of the RADIUS server /var/log/radius.log, that can contain authentication data.
2. Mobile-OTP is based on a function of PIN x Init-Secret —> OTP. It is obvious, that anyone who has access to the Init-Secret and the PIN can authenticate with it. Neither PIN nor Init-Secret nor a thousand known one time passwords alone will let an attacker find both Init-Secret and PIN. If an attacker gains knowledge of either PIN or Init-Secret and one or more one time passwords, this information can be used in a brute-force attack that might be successful. As Mobile-OTP is an open software, there is no way around that. Increasing the number of digits in the PIN (a 16 digit Init-Secret is quite safe) would make a brute-force attack more difficult, but it would not be convenient for users to remember and type in a 10 digit PIN.
3. For devices that do not take time zones and daylight-savings-time into account when doing their epoch-time calculations, it might be necessary to manually adjust the Offset-attribute in the user record on the RADIUS server or alternatively one the token itself. For devices that are aware of time zones and daylight-saving-times, server-clock and token-clock should always be in sync.
4. MD5 is not a limitation - Mobile-OTP would not be any safer with any different hash algorithm. Even if we used SHA2, which is less readily available than MD5, an attack on Mobile-OTP would be equally (but not more) difficult. An attack would need to involve several sniffed one-time-passwords and a brute force attack on PIN and secret. The complexity of this brute-force attack depends on secret and PIN size rather than the chosen hash algorithm. I dare anyone, including the NSA, to brute-force a 16 character secret plus PIN (78 bits). If still in doubt, choose a Mobile-OTP implementation that allows for a 32 character secret (142 bits complexity, including PIN) and read this elaboration.

Add-Ons

Server-Side

Full blown RADIUS server specifically for Mobile-OTP. Features include:
- authenticating users by RADIUS (and optionally PAM or Apache)
- SQL database for user/device configuration
- Administration Web Interface (for admins and users)

Download it at github.

Potato is an authentication server integrated with Freeradius and Active Directory.
It comes with a user-friendly front-end allowing users to register their own tokens (while at the office).
Users enroll their tokens once while at the office and can automatically use them later for remote access.
Enrollment can be done entirely without involvement of an administrator. Potato is currently used in a productive environment with 500 users.
More information, documentation, and source code is available here: http://kelvin.nu/software/potato/
There is also a demo site here:Potato demo

Sebastian Korff wrote a PAM module for Linux and Solaris that can be used for login authentication locally without a RADIUS server. You do not even need otpverify.sh. The package includes the complete server components. You can download it here. Use this PAM module to authenticate users for Unix shell access (typically via SSH). Thanks go to Per Dalgas Jakobsen for contributing to version 0.4 and to Adrian Huryn for 0.5 (see CHANGELOG for details).

To simplify server integration, Vaidas Jablonskis provided us with RPMs (source, i386, x86_64) for the pam_mobile_otp module, including "motp-manager", a shell script to simplify user management.

As an alternative to a compiled PAM module you can also use PAM-script instead.
Davidhai Gootvilig provided a script for Mobile-OTP.

He also wrote a rlm_perl script to use with RADIUS.
If you have difficulties getting it to work, take a look at Gyuris Szabolcs's modular Python script for PAM.

Mobile-OTP is also available as a pre-compiled PAM-module for Nokia's IPSO operating system. Download the Nokia package here motp-0.2.tgz. It can be installed with 'newpkg' as any other Nokia package. Configuration can be done through the IPSO web interface Voyager!