88

But shouldn't it suppose verify before I get the OTP? What's the reason, Isn' it a security issue? This is absolutely NOT a security issue! quite the opposite it's a protection. Lets go through the steps. You put in card details. You put in CVV You put in the OTP. The payment is processed if and only if the combination of all of it are correct. Now ...


85

The answers I've gotten have been good, but I wanted to provide a bit more depth, going specifically in to why the system exists at all, which should explain a bit more about what it's good for. Disclaimer: While I now work for Google, I knew nothing about this project at the time this answer was written. Everything reported here was gathered from public ...


63

I'm basing my answer on the assumption that a One-Time Password is used as a second factor, in addition to a traditional username/password combination. If this is not the case, and the One-Time Password is the only factor, then Gilles' Answer is certainly more applicable. Most likely due to Cargo Cult Programming, which means blindly following patterns that ...


38

Working: Authenticator implements the Time-Based One-Time Password (TOTP) algorithm. It has the following ingredients: • A shared secret (a sequence of bytes) • An input derived from the current time • A signing function Shared Secret : The shared secret is what you need to obtain to set up the account on your phone. Either you take a photo of a QR code ...


35

U2F is capable of using an encrypted channel using public key crypto to ensure ONLY the right server can get the one time token. This means plugging it in when on a phishing site means nothing happens—they can't get into your account. Instead they have to rely on technical attacks like XSS and local malware. It is supposed to be able to hide the fact ...


30

A magic link alone is not necessarily bad. A 512 bit entirely random value is going to be no easier to guess than a 512 bit private key. In general it is considered good practice to expire them after a reasonable amount of time. A good approach - which also avoids having to store database entries is to embed the token data in the url and sign it with a ...


30

The reason to hide passwords is to prevent shoulder surfing: someone being physically present (or someone observing through a camera) might be able to read the password on the screen. This is also a risk for a one-time password, but to a much lesser extent for two reasons: the one-time password is only valid for a short time, and it's displayed on the OTP ...


23

There are three problems here. As the documentation writes, email is not a secure protocol. Emails are stord in plaintext on the mailservers. The encryption between servers and between servers and clients is optional and beyond your control. And you are very likely not in a scenario where you can use any of the optional end-to-end encryption systems people ...


22

I have not yet fully explored the spec. But: In what way is U2F fundamentally different from OTP? U2F is not using an OTP. It is really about site authentication and using possession of a private key as a factor. How does U2F affect the feasibility of phishing attacks in comparison to OTP systems? Time-bound OTP systems do an excellent job of combating ...


22

Having a recovery option is perfectly fine as long as it is adequately secured. Whether you prefer losing your passwords if you lose the master password or want to trust the password manager company with access to your passwords is up to you. Keep in mind that security is a means to an end. There are always trade-offs to be made. You can have a perfectly ...


20

I personally prefer Google Authenticator which is basically an elegant implementation of Time-Based One-Time Password Algorithm but I would not feel comfortable saying it “is more secure”. To use one of my favourite buzzwords… it all comes down to Threat Modelling. What exactly are you trying to protect against? Is it a technical attacker who might be able ...


20

Seems like you've got it pretty much down. Universal Authentication Framework (UAF) is meant as a replacement for simple authentication, and Universal Second Factor (U2F) is meant to replace today's time-based, second factor authentication. While it does seem like the end-user will experience the same experience on both devices, this won't always be the case....


20

Why can't you use TOTP or HOTP which is standard and supported by most authenticator apps? When people register for your service they need to enroll their authenticator app by scanning a QR code which contains the secret seed used to generate codes. On subsequent visits the site prompts them to enter codes generated by the app, without any network access ...


18

It is a bit of a fetish. As far as we currently know, there is no reason to believe that using the first four bytes of the HMAC output would not be equally secure. However, lack of reason to believe does not imply that nobody believes. Some people "feel" that systematic truncation may help the attacker in some completely unspecified way. With a lot of ...


17

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


17

I just read some of the specs because I wanted to know if the device stores the actual (private) keys. I can try to answer some of the questions. OTP are simply one-time tokens, while U2F is based on public key cryptography; more specifically, the Yubico Fido U2F key seems to use elliptical curve cryptography. U2F should help to protect against phishing ...


15

No. Security remains the same + extra cognitive overhead. Presumably the plugin uses OATH HOTP where the KeePass file or master key is re-encypted after each access with the next one-time-password. However to generate the next password on the device, the plugin would require either a secret stored on the device or the normal password for the KeePass file. ...


15

Speculating about the motive of other developers is perhaps a poor use of time, but I can see one advantage that hasn't been mentioned. Psychologically, making it look like a password helps people associate it with security. It transfers the message we have pushed for decades that "you don't tell people your password" to OTPs, and hopefully helps a few more ...


14

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: https://stackoverflow.com/questions/8340495/how-rsa-tokens-works


13

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


13

The QR code remains valid and usable; nothing will make it stop working. This actually makes it very dangerous to leak the QR code. If an attacker sees it, even years after you use it the first time, they can set up their own TOTP (Authenticator) app to use your code, and it will generate the same tokens yours does, which can potentially help the attacker ...


13

As well as the general rule of not giving the attacker information by rejecting too early, there are some things specific to the payment industry which are somewhat relevant. Although often presented to the customer as mandatory, the authentication information on a payment is generally used to evaluate risk and to assign liability. For instance: A ...


12

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


11

From reading the source it looks like the secret is stored on the Yubikey and stored encrypted multiple times with different keys inside the otp.xml file. The encryption keys are derived from the next n OTPs (derived from the secret) starting from OTP i..i+m where i is the current counter and m is the look ahead value. When the user enters their OTP values, ...


11

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


11

There are some commercial schemes, e.g. GridGuard from SyferLock that claim to do this, but I have never used them (I have no affiliation). This relies on the user choosing correctly from multiple options during authentication rather than a typical time or counter based OTP (which means no mental arithmetic). Solitaire (Schneier), is often cited for a human-...


11

Compared with something like SMS or email OTPs, I don't think there's as strong a case to make these one-time-use, but the same arguments still apply. Let's assume that I have the codes printed out on paper. Then during the recovery process, the recovery code passes through all of the following nodes: Plaintext: My computer's keyboard, OS, browser ...


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


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