# Tag Info

17

One of the advantages is purely on the human side of security. From RFC 6238's abstract: The HOTP algorithm specifies an event-based OTP algorithm, where the moving factor is an event counter. The present work bases the moving factor on a time value. A time-based variant of the OTP algorithm provides short-lived OTP values, which ...

10

The HOTP standard describes the resynchronization algorithm (section 7.4). Basically, the server remembers the last value $C$ of the counter for which a correct password was presented. When a new password is to be verified, the server tries $C+1$, $C+2$... until one matches, or $C+w$ is reached for some $w$ called the "window size". The intended scenario is ...

7

It looks to me that the original intent was to make sure that all bits of the hash digest have an equal chance to contribute to the truncated portion. But one of the properties of a secure hash function is to ensure that a single bit change results in a cascade that yields changing bits across the entire digest. If you don't trust this property in the hash ...

4

The usual resynchronization method involves getting several consecutive codes from the token and then running the algorithm once with a very large look-ahead window until the set of consecutive codes are found. The number of consecutive codes needed depends on how far off the token is. With a typical token, two codes would suffice to handle a desynch of ...

4

Why stop at 8 digits? 10 digits will be even more secure. Or 12. The output of the HOTP algorithm is 160 bits so you could go all the way to about 48 digits. Bottom line: 6 digits is secure enough for most applications and that is all that counts. Any more is inconvenient for the user and slightly more expensive when used in a hardware token (8 digit ...

4

As hunter notes, the only people who can really say what LastPass actually does are those who work there. However, as long as we only consider what they can and should do... They don't really need to store a separate copy of your data for each one-time password. Instead, all they need to store for each password is an encrypted copy of the key used to ...

3

From RFC 4226: 7.4. 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. ...

3

So I was finally able to work this out. The pin code isn't important and is simply used to decrypt the activation code locally (not sure why our server asks for it in that case). The activation code is a base32 encoding of a seed where every fifth character acts as a checksum for the previous four. The seed is then passed through KDF1 to generate the ...

3

Just using random strings is simple and often reasonable solution. However, if you have significant customer base, it can become too expensive, because all of those random strings need to be stored. But in short, these more complex schemes are mainly for reducing storage requirements and amount of entropy needed. Note: I am partially building this reply ...

3

Different modes of operation have different requirements. For example, the IV for CBC mode should be generated with a CSPRNG, where as the IV for CTR mode just needs to be unique for each encryption. In terms of cryptography, the 'random' functions found in many languages are more predictable than you might imagine. That being said, there's absolutely no ...

3

It sounds like you're trying to improve the security of OTP schemes by adding extra "random-ish" data. My answer will address that, please update your question if that is a wrong interpretation. These schemes don't literally have multiple inputs that you could feed this extra data into, but you don't need them to. For example, with HOTP the security of the ...

3

It is for user experience reasons, as you surmise, but the security is not compromised as much as you may think. Most implementations use 6 digit HOTP/TOTP schemes and design their implementation of the scheme to give them a security level they are comfortable with. For HOTP, the key parameter that allows 6 digits to be secure enough is the throttling ...

3

There is no "fresh client" with HOTP. The whole counter business is based on the idea that there is a single client, who maintains his counter which is more-or-less synchronized with the server counter. The synchronization window is just a way to cope with small unsynchronization events which come from realistic situations (e.g. your 3-year-old played with ...

2

It looks like unnecessary window dressing to me. As far as I can see, there is absolutely no reason to use this scheme instead of just choosing the first four bytes of the hash. It looks like unnecessary complexity -- or, as fgrieu put it, over-engineering. If the hash function is any good, then all this should be unnecessary. And if the hash function ...

2

I agree that Gilles' interpretation in the comments is the only one that makes sense; the RFC clearly contains an editorial error, and should read either (emphasis indicates corrections): "If the value calculated by the authentication server matches the value calculated by the client, then the HOTP value is validated." or: "If the value received by ...

2

Yes, HOTP can include a PIN/Password also. If you check RFC 4226, it says Composite Shared Secrets It may be desirable to include additional authentication factors in the shared secret K. These additional factors can consist of any data known at the token but not easily obtained by others. Examples of such data include: PIN or ...

2

My opinion on “Random vs. TOTP (Time-based OTP)”. With a random token, you need to keep track of what was generated for whom, when it expires, and you need to purge the expired tokens. A (TOTP) has the inherent feature of be being useful for a defined period of time. If the server receives an OTP for an account, the server can generate OTPs for that ...

2

There is OpenBSD, where you can use S/KEY for login-purposes. Check the OpenBSD – Frequently Asked Questions: 8.10 - S/Key S/Key is a one-time password'' authentication system. It can be useful for people who don't have the ability to use an encrypted channel which protects their authentication credentials in transit, as can be established using ...

1

The best way to encrypt a seed in a db would be to use multiparty computation and heterogeneous computing (multiple core systems). The only other way would be to store them in plaintext, e.g. in a shadow password (non-public file).

1

In theory, it is not: TOTP, like HOTP, is based on a Hash-based message authentication code (HMAC), which in turn relies on a cryptographic hash. Both the key, and the HMAC message (a time counter in TOTP) are hashed using the specified cryptographic hash. One key goal of cryptographic hashes is: it should be infeasible to generate a message that has a ...

1

Think about it this way.. with AES, you only generate one key, and use that for all encryptions(of the day).., however with OTP a single key won't work and you'll need to have (say) $n$ keys to send $n$ packets securely.. Now, again, you might suggest using a seed with a PRNG to create a $128*n$ bit key for all $n$ packets.. but then here's the problem: ...

1

Yes, it is possible. You described how in your question. I'm not sure what your remaining problem is. You can think of this as two totally different, independent logical "users" -- or as two different OTP sequences -- with both of them assigned to the same person, using a different one for each channel. If the OTP scheme is secure, then your approach ...

1

Applying the hash function assures that only the next password in sequence will be valid. There is no reason to store the previous state, or the client's original secret. Once a valid key is used, the server stores the hash of it (which is the same algorithm used to generate the list of hashes in the first place.) This puts the burden of storage on the ...

1

The only people who can answer your question definitively are the programmers at LastPass, however, I'll try. I assume you're referring to this. If LastPass really does encrypt your data with your password/username, then logically it could only be decrypted with the same key. Their 'one-time' password feature is an interesting idea, but I'm dubious about ...

1

RFC 4226, section 7.5 defines two shared key generation schemes: deterministic and random. I would suggest that you use the deterministic scheme, which only requires the server to store a single "master key": "Deterministic Generation A possible strategy is to derive the shared secrets from a master secret. The master secret will be stored at ...

1

As I understand, the user's token normally can't be reset (without destroying it). So, the assistance would consist in either giving a new token to the user (and declaring the old one invalid), or in stepping the server ahead until it matches again (i.e. running the algorithm once with a really large window size).

Only top voted, non community-wiki answers of a minimum length are eligible