Tag Info

Hot answers tagged

49

Google Authenticator supports both the HOTP and TOTP algorithms for generating one-time passwords. With HOTP, the server and client share a secret value and a counter, which are used to compute a one time password independently on both sides. Whenever a password is generated and used, the counter is incremented on both sides, allowing the server and client ...


11

Google Authenticator supports the TOTP and HOTP algorithms. In both algorithms, a secret needs to be shared between the server and the client to successfully generate the one time passwords. I suggest you read the respective RFCs of the algorithms (or my answer here) to understand it better. Yes, if the attacker manages to get hold of the shared secret the ...


10

One-Time Passwords (not to be confused with "One-Time Pad", a theoretically perfect but practically heavyweight technique for encryption) are a sound concept which cannot, as itself, deprecate. It just means: a given password (i.e. a secret value shared between prover and verifier, used for authentication) can be used just once with the verifier; in other ...


9

There are some explanations on what YubiKey does here. Basically, the password which the YubiKey "types" (from the point of view of the computer, it is a keyboard) can be either a static password, or a one-time password. If it is a static password, then you just revealed it, and it is time to be very sorry (and promptly change that password). The one-time ...


8

First, this exists in practice in one form which isn't very secure: “security questions”. The second password is (if the security questions are used as intended) something that is easily memorable, but that is known by other people. There is no security reason not to have two passwords: one for daily use, and one (longer, non-memorable) for recovery. ...


7

I think this is to ensure that the response entered into the website is a fresh(ish) one. If the one time password was generated directly then it could be used at any point in the future, the server has no way of checking when it was generated. By providing the challenge to the card it means that the response generated can only be used for the transaction ...


7

Overview. TOTP is pretty simple and is described pretty well in the RFC you linked to again. You might want to read through the RFC another time: it's all there. I'm going to summarize the RFC for you, but you could have gotten all of this yourself by reading the RFC. Time steps. For example, you asked about what is a timestamp vs a time step. The first ...


7

The TOTP specification points, for the security analysis, to HOTP. HOTP uses a counter, shared by both parties, and "resynchronized" every time a successful authentication occurs; TOTP replaces that counter with knowledge of the current time, which is also a shared value. As such, almost all the security analysis of HOTP applies to TOTP. The security ...


6

It'll work on a seed based on time so it's similar to the way the RSA key fobs work. i.e. they also don't require any connectivity. I've just had a look around and this is answered here: http://stackoverflow.com/questions/8340495/how-rsa-tokens-works


5

HMAC/SHA-1 is not broken. SHA-1 has a weakness with regards to collisions (and it is still "theoretical" since producing a collision for SHA-1, though conceptually easier than the generic attack, is still so expensive that nobody has computed one such collision yet). But HMAC resistance does not rely on resistance to collisions. Indeed, HMAC is proven ...


5

First time I've heard about this, but it doesn't mean it's not well-known. Sounds a little similar to OATH HOTP / TOTP. OATH is based on RFC 4226 and seems at least at a first glance more robust. For example it uses HMAC instead of simple hash (motp uses MD5). OATH was also adopted by products like Yubikey and recently Google Authenticator. Based on these ...


5

For a brief description, see Wikipedia. This is basically a one-time password system: the user does not have a single password, but a long chain of passwords, each password being usable only once. The point is that if a key logger grabs a used password, then the attacker gains nothing because once a password has been used, it no longer grants any further ...


5

Should we allow the administrators of the site to turn off TFA for users? This is a very interesting question. I suspect the answer very much depends on the individual site's risk assessment. Let's look at some pros and cons of allowing the administrator to turn off 2FA for an individual user. Pros Convenient for the user if he loses access to his ...


5

I agree that this is bad practice. You can make it better practice by scrambling the answers in one of many ways -- making questions about your father refer to your first car and vice versa, and so on, or giving false answers, or given IRRELEVANT answers (if you can remember what your irrelevant answers were), would discourage/prevent social engineering ...


4

If done properly, time-based one-time passwords will be reasonably secure. That's a bigger "if" than usually assumed. What would work would be the following: Decide about your time granularity, e.g. 5 minutes. All dates considered here will be a multiple of that granularity (i.e. 8:05:00, 17:25:00... but not 16:34:00). Generate a secret symmetric key K of ...


4

TOTP authentication (like that used by Google Authenticator) works by converting the timestamp to a 6-digit number using the pre-shared secret that only exists on your phone and the the authentication server. To express this simply, f(timestamp, secret) = 6-digit code. If the secret is known to a 3rd party, the yes, the purpose of 2-factor authentication is ...


4

The secret (or the seed) is the value upon which the One-time Password OTP. It's essential for you (or rather, your password generator, and in your case your Google Authenticator) to know that secret value. It's essential that both you and server know that value. The QR code you're scanning is the secret value, just encoded in a way that your camera ...


4

Quibble: you are not really setting up two-factor authentication here, you are setting one authentication factor, of the “what you have” type. This is meant to be combined with a password, which is a “what you know” authentication factor, giving you two-factor authentication. “What you have” is intended to be a mobile device. The way a user is authenticated ...


3

What you are trying to do is a great challenge and currently isn't possible. There has been some discussion about using TPMs to provide a vendor locked trusted environment that could be used as the basis of such a system, but the problem currently is that an untrusted system can not prove itself trustworthy since any inspection a trusted system could do ...


3

Sure, but this makes a certain set of assumptions. The OTP is event-based, not time-based You have to be tracking previously used tokens You have to track expected future tokens The user doesn't have the ability to reset their OTP sequence with the initial seed In theory with an event-based OTP once you use it anything generated before it is unsuable ...


3

Unfortunately, it's not currently possible. From: http://training.apple.com/pdf/WP_FileVault2.pdf Two-Factor Authentication As discussed earlier, when using FileVault 2 (FDE), the initial authentication takes place as part of the EFI pre-boot authentication process. At this very early stage of the boot phase, none of the OS-reliant services are ...


3

It's not only the code sample and the test values, it's even there explicitly in the RFC 6238: 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 in [RFC4226]. So, yes. My inexperienced but ...


2

Roughly speaking, the best you can do is to harden the server to make it as resistant to compromise as possible. Ideally, you would store the seed in a hardware security module (HSM; aka a crypto co-processor). You'd ake sure the seed never leaves the HSM, i.e., do all cryptographic computations in the HSM. This offers better protection, though it is ...


2

Things about Yubikey to consider: It appears as a keyboard device. (Works almost everywhere they say you can't use Keysticks... there are ways to prevent it on almost all OSs but most places don't lock down Human Interface Devices.) If someone else gets a hold of it and your password, (and you're using OTP) and they record a few OTPs, they can use that ...


2

Provided you use a cryptographic hash of a concatenation of high-entropy randomly-generated server-side-secret, a timestamp known to the client, along with a username, I don't see a flaw in that method. Granted I would not use an 8-digit number (e.g., 1 in 100 million chance of randomly bypassing) or 8-digit hexadecimal number (1 in ~4 billion chance), but ...


2

A generator for one-time passwords is a system which, as a whole, contains a master secret from which the one-time passwords are generated. Details vary depending on the specific OTP algorithm, but the generic concept applies: there is some secret data stored in the system, and that data is a very valuable target for the attacker. The system consists of ...


2

This question makes more sense when you invert it. Which is to say that the main weakness of software-based OTP generators is the same as the main strength of hardware-based OTP devices. Specifically, software based devices can be cloned if the secret key can be retrieved. Hardware devices ideally implement physical security measures to make it difficult ...


2

Kind of a vague question, but off the top of my head: Leaving protection of the key/seed to the mobile device means that its possible to extract the key on various platforms unlike dedicated hardware devices with protected storage You lose your phone you lose your key


2

The tricky point is pre-usage synchronization. When you want to use a one-time password, the client must "somehow" learn the one-time password to use. HOTP is for situations where this out-of-band synchronization is through a counter which is maintained both client-side and server-side. If you have another out-of-band mechanism which can be invoked on a per ...


2

The YubiKey supports the Yuibco OTP, which is the long OTP generated.The YubiKey One Time Password (OTP) is a 44-character, one use, secure, 128-bit encrypted Public ID and Password, near impossible to spoof. The OTP is comprised of two major parts; the first 12 characters remain constant and represent the Public ID of the YubiKey token itself. The ...



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