Hot answers tagged

58

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 are ...


11

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 ...


7

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 ...


6

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 ...


6

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

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. ...


4

I managed to find it out by reproducing the test vectors. TL;DR: The standard assumes that you use the low 4 bits of the last byte of the hash, regardless of its length. So replace 19 in the original DT definition with 31 for SHA-256 or 63 for SHA-512 and you are good to go. Finding this out wasn't completely straightforward, as the standard only has a ...


4

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 ...


3

So my question is that if an attacker has gained access to this secret, would he not be able to generate the OTP just as easily as the client software on my system because HOTP(key,counter) will remain the same for all? Yes, if an attacker learns your shared secret, he can calculate OTPs whenever she wants. But this is very unlikely, since every secret is ...


3

I do not fully understand the scheme you are describing, especially the interactions between your apps A and B. I'll try to describe a sensible HSM usage for a OTP based authentication. I think you have a little misconception about how a typical OTP is usually handled. There is no need to store an OTP ever, it is always calculated upon use. The typical ...


3

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

I had only a quick read through the source, and I am not particularly fluent in C#, so I may have gotten something wrong. That said the process appears to be: Generate a random encryption key, encrypt the database with it. Generate (up to six) HOTP tokens, derive a key from those, use that to encrypt the database key. To read: Ask for the HOTP tokens, ...


2

I think this simply comes down to the definition of Unix time, which is given in the Wikipedia article: Unix time (also known as POSIX time[1][2] or UNIX Epoch time[3]) is a system for describing a point in time. It is the number of seconds that have elapsed since 00:00:00 Thursday, 1 January 1970,[2] Coordinated Universal Time (UTC), minus leap seconds. ...


2

No, this is not a proper way to perform the One Time Pad, even with just 5 letters (assuming the pad and message are bound to be letters that is in range [65..90]). Problem is, when we see that the first encrypted character is 139, and since we know that the pad is in range [65..90], we know that the first plaintext character is in range [65..74], not in ...


1

The security property needed for one-time password generation is that of a pseudorandom function. HMAC is assumed to be a pseudorandom function, when the hash function has certain properties. Collision resistance is not a required property for HMAC to be a secure pseudorandom function. However, when collision resistance is broken, this brings into question ...


1

Can HOTP algorithm be used over an unencrypted channel securely? Yes. Essentially, HOTP is a stateful function that keeps an internal counter and then computes an HMAC over that counter followed by some truncations to get the right format. In the process the counter is also incremented. So assuming we can model HMAC as a PRF then the output of each HOTP ...


1

I assume you mean using time-based OTP. At the end - the client and server need to have another (?) common shared secret to compute the OTP and the server needs to validate the OTP based on the time. My first question is that whether certain OTP values can be considered as nonce well - not really. The TOTP is not guaranteed to be unique and it is ...


1

(Note: I think, In general OTP is usually understood as One-Time Pad. Here it means One-Time Password.) Using an OTP as a nonce does not seem possible in general. An OTP doesn't necessarily always have to be distinct. Since there is some kind of synchronization between the communicating parties the OTP might repeat. Specifically, say your OTP consists of ...


1

No, you do not have to do any key derivation. The shared secret is just an arbitrary byte string which is used to key the HMAC function.


1

In your model, the OTP could simply be a random number generated by the bank, independent of a key or transaction details. All that matters is that the random number is unpredictable. 8-digit integers are typical. Not having a key is a great advantage, as it can't be compromised. The bank receives the transaction details and alleged originating user, ...


1

What you're imagining is impossible to be secure. Basically what you're describing is a message authentication system where a message is MAC'ed and only the MAC is matched against the actual MAC, but it isn't checked whether the message actually generates this MAC, so an attacker could just fake the transaction details and leave the MAC be and the user ...


1

As mentioned by SEJPM in the comments, four bytes is much too short for an HMAC key. Since KEY_SECRET is already in place, you could just use it directly as a MAC key, but then you need to make sure that DATA cannot collide with any counter value. You could do this by prefixing DATA with enough constant values to make it longer than the counter. For ...


1

It's not really clear what you're trying to do, so I cannot give a definitive answer. But the default answer, in the absence of more details that you've provided, is that whatever you're doing, it probably isn't secure. Specifically, TOTP (RFC 6238) keys are generated from two inputs: a fixed secret key, and an incremental counter, counting the number of (...


1

Yes, that's fine where TOTPs are generated in accordance with RFC 6238; this is because the time is combined with the secret before generating the HMAC. This means that it isn't practically possible to derive the time (or information about it, such as the time difference) based on the key alone because of the Avalanche effect in the hashing algorithm that is ...


1

Usually OTP needs to send the password in clear text to your AAA server. As the otp value is concatenated with a static password, the AAA server, which verifies the credentials, need to split the password. E.g.: Your secret password is "secret" and your OTP generator creates "987432". Then you need to enter "secret987432". As the client component does not ...


1

It is very hard to estimate time it takes for attacker to brute-force password. This is because HMAC-SHA256 can be calculated billions of times per second on some devices, and there are some devices existing which take millisecond to calculate one HMAC. BTW, I understood that password is actually a 128-bit cryptographic key, i.e. it can may contain any ...


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 ...


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