Requireris

School project where we had to develop a One Time Password generator, Google accounts compatible.

RFC powered

HOTP (HMAC-Based One-Time Password)

• HOTP algorithm is based on an increasing counter value and a static symmetric key known only to the token and the validation service.
• HOTP algorithm compute an HMAC-SHA-1 value and truncate it.

Input

• strong shared secret must be at least 128 bits (160 bits recommended).
• The 8-byte counter value must be synchronised between the HOTP generator (client) and the HOTP validator (server).

Output

• HOTP value must be at least 6-digit value up to 8.
• HOTP value desirable 'numeric only'.

Generate HOTP Values

• The HOTP values generated by the HOTP generator are treated as big endian.
• HOTP(K,C) = Truncate(HMAC-SHA-1(K,C)) // The Key (K), the Counter (C)
• As the output of the HMAC-SHA-1 calculation is 160 bits, we must truncate this value to something that can be easily entered by a user.
• The purpose of the dynamic offset truncation technique is to extract a 4-byte dynamic binary code from 160-bit (20-byte) HMAC-SHA-1 result.
• We get the offset value from the last byte low-order nibble of the hmac digest.
• We extract 4-byte from the hmac digest at offset.
• We mask the most significant bit of that 4-byte buffer. (Now, the buffer is 31 bits.)
• The reason for masking the most significant bit of P is to avoid confusion about signed vs. unsigned modulo computation. Different processors perform these operations differently.
• Last step is to return the buffer value modulo 10^Digit (Where digit is the length of HOTP token)

Validation of HOTP Values

• The HOTP client (hardware or software token) increments its counter and then calculates the next HOTP value HOTP client. If the value received by the authentication server matches the value calculated by the client, then the HOTP value is validated. In this case, the server increments the counter value by one.
• If the value received by the server does not match the value calculated by the client, the server initiate the resynch protocol (look-ahead window) before it requests another pass.
• If the resynch fails, the server asks then for another authentication pass of the protocol to take place, until the maximum number of authorized attempts is reached.
• the server will refuse connections from a user after n unsuccessful authentication attemps. Server should lock out the account and initiate a procedure to inform the user.

Throttling at the Server

• Truncating the HMAC-SHA-1 value to a shorter value makes a brute force attack possible. Therefore, the authentication server needs to detect and stop brute force attacks.
• We RECOMMEND setting a throttling parameter T, which defines the maximum number of possible attempts for One-Time Password validation. The validation server manages individual counters per HOTP device in order to take note of any failed attempt. We RECOMMEND T not to be too large, particularly if the resynchronization method used on the server is window-based, and the window size is large. T SHOULD be set as low as possible, while still ensuring that usability is not significantly impacted.
• Another option would be to implement a delay scheme to avoid a brute force attack. After each failed attempt A, the authentication server would wait for an increased T times A number of seconds, e.g., say T = 5, then after 1 attempt, the server waits for 5 seconds, at the second failed attempt, it waits for 5 times 2 = 10 seconds, etc.
• The delay or lockout schemes MUST be across login sessions to prevent attacks based on multiple parallel guessing techniques.

Resynchronization of the Counter

• Although the server's counter value is only incremented after a successful HOTP authentication, the counter on the token is incremented every time a new HOTP is requested by the user. Because of this, the counter values on the server and on the token might be out of synchronization.
• We RECOMMEND setting a look-ahead parameter s on the server, which defines the size of the look-ahead window. In a nutshell, the server can recalculate the next s HOTP-server values, and check them against the received HOTP client.
• Synchronization of counters in this scenario simply requires the server to calculate the next HOTP values and determine if there is a match. Optionally, the system MAY require the user to send a sequence of (say, 2, 3) HOTP values for resynchronization purpose, since forging a sequence of consecutive HOTP values is even more difficult than guessing a single HOTP value.
• The upper bound set by the parameter s ensures the server does not go on checking HOTP values forever (causing a denial-of-service attack) and also restricts the space of possible solutions for an attacker trying to manufacture HOTP values. s SHOULD be set as low as possible, while still ensuring that usability is not impacted.

Bi-Directional Authentication

• Interestingly enough, the HOTP client could also be used to authenticate the validation server, claiming that it is a genuine entity knowing the shared secret.
• nce the HOTP client and the server are synchronized and share the same secret (or a method to recompute it), a simple 3-pass protocol could be put in place:
  • The end user enter the TokenID and a first OTP value OTP1;
  • The server checks OTP1 and if correct, sends back OTP2;
  • The end user checks OTP2 using his HOTP device and if correct, uses the web site.
• Obviously, as indicated previously, all the OTP communications have to take place over a secure channel, e.g., SSL/TLS, IPsec connections.

TOTP (Time-Based One-Time Password)

• Based on HOTP using a time-based moving factor as a counter
• TOTP implementations may use HMAC-SHA-256 or HMAC-SHA-512 functions, based on SHA-256 or SHA-512 [SHA2] hash functions , instead of the HMAC-SHA-1 function that has been specified for the HOTP computation.
• The prover (client) and the verifier (server) must know or be able to derive the current Unix time (i.e., the number of seconds elapsed since midnight UTC of January 1, 1970) for OTP generation.
• The prover and verifier MUST use the same time-step value X.
• There MUST be a unique secret (key) for each prover.

Input

• X, A time step in seconds (default 30 seconds)
• T0, Unix time to start conting time steps (default 0 seconds)
• TOTP = HOTP(K, T)
• T is an integer and represents the number of time steps between the initial counter time T0 and the current Unix time
• T = (Current Unix time - T0) / X // where the default floor function is used in the computation
• T must support a time value larger than a 32-bit integer.

Bonus

• HTTPS access
• Auto-lock PIN
• Responsive Design
• base32 angular2 recode (thirty-two)
• TOTP/HOTP Javascript implémentations
• Multiple accounts
• Configuration (OTP algorithm, hash, validity period, start value, length)
• Google compatible
• QR Code displayed
• OTP code stored in clipboard
• Bcrypt hashed
• SQLcipher
• nodeJS module myotp RFC compliant (Look Ahead Window, time offset, hashing algorithms sha1, sha256, sha512)