This part was taken from SECURITY file of OTPasswd distribution.
OTPasswd - One-Time Password Authentication System -------------------------------------------------- http://otpasswd.thera.be Updated: 02-Nov-2013 (v0.8) SECURITY GUIDE Contents ======== 0. Intro 1. Security Concerns 2. Passcode Generation Algorithm 3. About PAM (short lecture) Intro ----- Security is a difficult topic, especially once you give up the notion of ultimately `trusted' client while being unable to estimate your trust at all. Use appropriate measures against threats based on their probability and risk factor. This file sumarises some topics the authors of OTPasswd had in mind while developing it. Let it inspire you to do your own thinking. How often do you log into your systems from untrusted clients? I don't really trust my mobile in the first place, so... the answer for me is 'often'. OTPasswd lets me reduce the risks a bit. 1. Security Concerns ==================== There are certain security related issues you should be aware of. OTPasswd goal ------------- This program is not intended to replace normal passwords, it's supposed to add a second level of authentication -- a second "factor". In other words, an attacker attempting to log into your system must know something you know -- a UNIX password -- and additionally must possess something only you have -- a passcard with one-time passcodes, or a mobile device to which a passcode can be sent. Therefore, even if the attacker manages to discover your UNIX password, for example through the use of a key logger or by sniffing the E-M radiation of your keyboard's PS/2 connection, the attacker would still need to have access to your passcard. It lets you use weaker unix passwords which you might be willing to type-in on an untrusted client station without compromising security. Denial-of-Service ----------------- The second issue is that a Denial-of-Service (DoS) attack is possible in some configurations. When an attacker repeatedly tries to authenticate he can use up all of your printed passcodes and therefore cause you to be unable to login. This can be fixed in several ways: 1) By requesting that the UNIX password be correctly entered before asking for (and therefore using up) a passcode. (Consult the PAM description chapter for the distinction between the required/requisite keywords). This will limit the problem to the case when the attacker sniffs your password. In this case, the attacker will still be unable to login, but the DoS described above would now be possible. This is arguably an acceptable situation, since it alerts the user to the fact that his UNIX password has been compromised and must be changed. 2) By limiting number of failed authentication attempts. For example, sshguard can block IP access to SSH after 3 unsuccessful attempts to authenticate. The use of such a security measure is advisable regardless of whether OTP is used, or not. This type of filter would force an attacker to consume a large number of IP addresses in the process of an attack. In certain configurations of OTPasswd an attacker would need around 23 IP addresses to skip a single passcard. 3) By receiving passcodes on an as-needed basis via a secure channel which cannot be blocked by attacker, such as SMS text-messaging. In some scenarios this scheme could also be susceptible to a DoS attack. For example, if a free SMS gateway is used which imposes usage limits, an attacker who is aware of your phone number could easily exhaust your daily quota of text messages. While this type of attack is technically possible, it's also quite unlikely. However, it does serve to highlight the fact that every countermeasure has vulnerabilities. As far as this particular attack is concerned, SMS transmissions could simply be sent using a different method, such as making use of a GSM phone/modem connected to the computer. NOTE: Early versions of OTPasswd included what was known as the 'dont-skip' option. This option prevented the skipping of a passcode that was used in a failed authentication attempt. In essence, the dont-skip option slightly changed the semantics of what is meant by a "one-time password" from never allowing the reuse of a passcode, to allowing reuse of passcodes on authentication failures. The intent of this modified semantic was to protect against passcode exhaustion as a consequence of a DoS attack. However, due to limitations of the implementation, enabling this option did not completely prevent the consumption of passcodes when the attack involved concurrent login sessions. Since this option did not meet its intended design goal, it was ultimately removed. Cryptographic security ---------------------- If an attacker is able to collect used passcards, it is conceivable that a brute-force attack could be made on the cryptographic key which was used to generate the passcodes. If the key is discovered, then future passcodes could be generated at will. Brute-forcing a 256 bit long key is currently in unfeasible. However, if weaknesses are discovered in the Rijndael cipher at some point, then it is possible that such an attack may be more likely to succeed. See 'Passcode Generation Algorithm' (below) for details. Man-in-the middle attacks ------------------------- OTPasswd secures the process of authentication by addressing the problem of classic static passwords -- the fact that they are /static/. After you've successfully authenticated, however, someone might still be able to takeover your session to do something nasty. So while a man-in-the-middle (MITM) attack on your SSH session to eavesdrop your password for later authentication might not be feasible, a MITM can still be used to hijack authenticated sessions. IMPORTANT. In order to securely login to a system with SSH you still must have trusted SSH client software (from a pendrive, for example) and you must validate the SSH server key fingerprint. Also, beware of man-from-behind attacks when you're banged in the head after authenticating. 2. Passcode Generation Algorithm ================================ The heart of the system is the Rijndael (AES) cipher working in CTR (Counter) mode. It encrypts 128-bit blocks with a 256-bit key; single encryption operation generates 128-bits of data which is used to calculate a passcode. During key generation, the user is equipped with a 256-bit key and a 128-bit passcode counter. Whenever a passcode is validated or generated, such as when the user authenticates or prints a passcard, the counter value is encrypted with the key to produce a corresponding passcode:
The salt needs a bit of explanation. In cryptography, a 'salt' comprises random bits of data that are used as one of the inputs to a key derivation function. Genuine PPPv3 algorithms don't use salt at all -- the counter is a 128-bit value which starts at zero. This allows the use of over 3.4 * 10^38 passcodes, which is around 4.86 * 10^36 passcards. Nobody will ever need that many passcodes, hence many bits of the counter would be wasted. In addition, any attacker who is able to key log your authentications will know both the passcodes (the ciphertext) and the corresponding counter values (the plaintext), and thus the attacker lacks only the key in order to be able to predict future passcodes. Once both plaintext and ciphertext are available, an attacker can employ the traditional attack model known as a Known-Plaintext Attack (KPA). Many ciphers have been vulnerable to such an attack. As far as is known, Rijndael (AES) is not currently vulnerable to such an attack, but there are no guarantees of what the future might hold. In the case of OTPasswd, addressing this issue was easy. By generating an additional 96-bits of random data and storing them inside the counter value an attacker will no longer be able to easily deduce the counter value used to produce a given passcode. This makes the attacker's already impossible task of breaking the key even more impossible. Additionally, using a salt will also increase the amount of time needed for a brute-force attack. To illustrate this point, suppose you had 10^6 3GHz machines each being able to test one key every machine cycle... this would allow you to test 3 * 10^9 * 10^6 keys per second. Even at that rate, without a salt, it would still take you... 1.22 * 10^54 yeeeaaarrrsss to check every key. By salting the counter, each key would now need to be checked against 2^96 counter values instead of just one, so it would now take longer than 10^82 years for an exhaustive search of the key-space. Good luck! ###