4 replaced http://security.stackexchange.com/ with https://security.stackexchange.com/
source | link

If you're looking for an absolute guarantee of protection from impersonationabsolute guarantee of protection from impersonation, then look at the Fido U2F token. This standard shines where SQRL falls short, and gives you guaranteed immunity to MITM (e.g. phishing) attacks. It does so by authenticating not just the user, but also the channel, so you're guaranteed that (a) your account can't be authenticated without the token, and also (b) your token can only be used to authenticate a connection to the machine it's attached to. See this answerthis answer for more information.

If you're looking for an absolute guarantee of protection from impersonation, then look at the Fido U2F token. This standard shines where SQRL falls short, and gives you guaranteed immunity to MITM (e.g. phishing) attacks. It does so by authenticating not just the user, but also the channel, so you're guaranteed that (a) your account can't be authenticated without the token, and also (b) your token can only be used to authenticate a connection to the machine it's attached to. See this answer for more information.

If you're looking for an absolute guarantee of protection from impersonation, then look at the Fido U2F token. This standard shines where SQRL falls short, and gives you guaranteed immunity to MITM (e.g. phishing) attacks. It does so by authenticating not just the user, but also the channel, so you're guaranteed that (a) your account can't be authenticated without the token, and also (b) your token can only be used to authenticate a connection to the machine it's attached to. See this answer for more information.

3 added 620 characters in body
source | link

Credentials are not stored on your computer. This protects you against a small subset of workstation-directed attacks. Specifically, you're protected against attacks that steal your password from your computer. You are not protected against any sort of session hijacking or browser-takeover attacks, though, and you are now also succeptiblesusceptible to phone-related attacks. More on that later.

This technique combines both authentication and identity into a physical object which is frequently lost or stolen. In this sense it's more like a passport rather than a password. Anyone in possession of your phone is suddenly exclusively in possession of your identity: not only can the attacker impersonate you, but without a second copy on a second phone (unlikely), now you have lost the ability to identify yourself. Authentication keys are not revokable, so without out-of-band recovery from each and every site, you cannot recover your identity. And even if out-of-band recovery exists, when confronted with two users, one with posesssionpossession of the identity and one without, it may be difficult to see why the site operator should trust you.

The most secure universally-accepted option today is lastpass, keepass, and other such browser-integrated password systems. In particular, client-side encryption alleviates the need to trust any third party. And more importantly, browser integration makes phishing practically impossible. LastPass or KeePass will only fill the password if served from the correct domain, which means that if presented with a malicious site, the user won't have access to his password.

Finally, existingExisting second-factor authentication schemes which use phones or similar devices help protect user logins today already do so in such a way that doesn't make you immediately vulnerable to identity theft if your device is stolen. The added security of two-factor authentication lies in the fact that neither the device nor the password can be used if stolen without the other. Gibson's technique is largely resistant to being included in a two-factor scheme, which makes this level of protection unavailable.

As for concerns about browser-side authentication being vulnerable to client-workstation attacks: while the is true, it's also true that if your browser is compromised, then no usage of that browser is safe, no matter what authentication mechanism you use. Malware authors can (and already do) wait for you to authenticate on your own using your super-secure technique, and then silently send the necessary traffic to "own" your account, all without you seeing anything amiss. Neither SQRL nor any other authentication system can protect the user of a compromised browser, any more than door locks can protect you from a house fire. Buying fireproof locks is not a solution.

Where Next

If you're looking for an absolute guarantee of protection from impersonation, then look at the Fido U2F token. This standard shines where SQRL falls short, and gives you guaranteed immunity to MITM (e.g. phishing) attacks. It does so by authenticating not just the user, but also the channel, so you're guaranteed that (a) your account can't be authenticated without the token, and also (b) your token can only be used to authenticate a connection to the machine it's attached to. See this answer for more information.

Credentials are not stored on your computer. This protects you against a small subset of workstation-directed attacks. Specifically, you're protected against attacks that steal your password from your computer. You are not protected against any sort of session hijacking or browser-takeover attacks, though, and you are now also succeptible to phone-related attacks. More on that later.

This technique combines both authentication and identity into a physical object which is frequently lost or stolen. In this sense it's more like a passport rather than a password. Anyone in possession of your phone is suddenly exclusively in possession of your identity: not only can the attacker impersonate you, but without a second copy on a second phone (unlikely), now you have lost the ability to identify yourself. Authentication keys are not revokable, so without out-of-band recovery from each and every site, you cannot recover your identity. And even if out-of-band recovery exists, when confronted with two users, one with posesssion of the identity and one without, it may be difficult to see why the site operator should trust you.

The most secure option today is lastpass, keepass, and other such browser-integrated password systems. In particular, client-side encryption alleviates the need to trust any third party. And more importantly, browser integration makes phishing practically impossible. LastPass or KeePass will only fill the password if served from the correct domain, which means that if presented with a malicious site, the user won't have access to his password.

Finally, existing second-factor authentication schemes which use phones or similar devices help protect user logins today already do so in such a way that doesn't make you immediately vulnerable to identity theft if your device is stolen. The added security of two-factor authentication lies in the fact that neither the device nor the password can be used if stolen without the other. Gibson's technique is largely resistant to being included in a two-factor scheme, which makes this level of protection unavailable.

As for concerns about browser-side authentication being vulnerable to client-workstation attacks: while the is true, it's also true that if your browser is compromised, then no usage of that browser is safe, no matter what authentication mechanism you use. Malware authors can (and already do) wait for you to authenticate on your own using your super-secure technique, and then silently send the necessary traffic to "own" your account, all without you seeing anything amiss. Neither SQRL nor any other authentication system can protect the user of a compromised browser, any more than door locks can protect you from a house fire. Buying fireproof locks is not a solution.

Credentials are not stored on your computer. This protects you against a small subset of workstation-directed attacks. Specifically, you're protected against attacks that steal your password from your computer. You are not protected against any sort of session hijacking or browser-takeover attacks, though, and you are now also susceptible to phone-related attacks. More on that later.

This technique combines both authentication and identity into a physical object which is frequently lost or stolen. In this sense it's more like a passport rather than a password. Anyone in possession of your phone is suddenly exclusively in possession of your identity: not only can the attacker impersonate you, but without a second copy on a second phone (unlikely), now you have lost the ability to identify yourself. Authentication keys are not revokable, so without out-of-band recovery from each and every site, you cannot recover your identity. And even if out-of-band recovery exists, when confronted with two users, one with possession of the identity and one without, it may be difficult to see why the site operator should trust you.

The most secure universally-accepted option today is lastpass, keepass, and other such browser-integrated password systems. In particular, client-side encryption alleviates the need to trust any third party. And more importantly, browser integration makes phishing practically impossible. LastPass or KeePass will only fill the password if served from the correct domain, which means that if presented with a malicious site, the user won't have access to his password.

Existing second-factor authentication schemes which use phones or similar devices help protect user logins today already do so in such a way that doesn't make you immediately vulnerable to identity theft if your device is stolen. The added security of two-factor authentication lies in the fact that neither the device nor the password can be used if stolen without the other. Gibson's technique is largely resistant to being included in a two-factor scheme, which makes this level of protection unavailable.

As for concerns about browser-side authentication being vulnerable to client-workstation attacks: while the is true, it's also true that if your browser is compromised, then no usage of that browser is safe, no matter what authentication mechanism you use. Malware authors can (and already do) wait for you to authenticate on your own using your super-secure technique, and then silently send the necessary traffic to "own" your account, all without you seeing anything amiss. Neither SQRL nor any other authentication system can protect the user of a compromised browser, any more than door locks can protect you from a house fire. Buying fireproof locks is not a solution.

Where Next

If you're looking for an absolute guarantee of protection from impersonation, then look at the Fido U2F token. This standard shines where SQRL falls short, and gives you guaranteed immunity to MITM (e.g. phishing) attacks. It does so by authenticating not just the user, but also the channel, so you're guaranteed that (a) your account can't be authenticated without the token, and also (b) your token can only be used to authenticate a connection to the machine it's attached to. See this answer for more information.

2 added 2440 characters in body
source | link

Gibson's Updates

Gibson recently announced some additional protection against phishing because this has been a major criticism. Their protection is this: If you're NOT using the QR codes, cell phone, etc., and instead have an authentication agent on your system (in-browser, for example), then the server can check to make sure that the authentication response comes from the same IP as the authentication request. This is good and well, but the whole purpose of this protocol is move your identity to your cell phone. If the only safe way to use the protocol is to not use it's core feature, then perhaps we should re-think what we're trying to accomplish.

Theoretically you could continue to use your cell phone if (and only if) your cell phone knew that it was using the same IP as your computer. Which, of course, it can't know because it doesn't know your computer's IP address.

A Better Solution

As stated before, if the authentication measure is in your browser, then the whole phishing problem is immediately solved with no effort or verification on the part of the user. Even the least capable user can't be tricked into authenticating to the wrong site because the site's authentication token is associated with the domain name, and the browser won't allow authentication to the wrong domain. This is a technique already in use today, is completely automatic, and does not require the site's cooperation or any intelligence on the part of the user.

This method can be strengthened by requiring a second authentication factor (such as a time-varying key on a cell phone) which, again, is already available and in use today, which protects you (most notably) against screw-ups on the part of the destination site or company.

As for concerns about browser-side authentication being vulnerable to client-workstation attacks: while the is true, it's also true that if your browser is compromised, then no usage of that browser is safe, no matter what authentication mechanism you use. Malware authors can (and already do) wait for you to authenticate on your own using your super-secure technique, and then silently send the necessary traffic to "own" your account, all without you seeing anything amiss. Neither SQRL nor any other authentication system can protect the user of a compromised browser, any more than door locks can protect you from a house fire. Buying fireproof locks is not a solution.

Gibson's Updates

Gibson recently announced some additional protection against phishing because this has been a major criticism. Their protection is this: If you're NOT using the QR codes, cell phone, etc., and instead have an authentication agent on your system (in-browser, for example), then the server can check to make sure that the authentication response comes from the same IP as the authentication request. This is good and well, but the whole purpose of this protocol is move your identity to your cell phone. If the only safe way to use the protocol is to not use it's core feature, then perhaps we should re-think what we're trying to accomplish.

Theoretically you could continue to use your cell phone if (and only if) your cell phone knew that it was using the same IP as your computer. Which, of course, it can't know because it doesn't know your computer's IP address.

A Better Solution

As stated before, if the authentication measure is in your browser, then the whole phishing problem is immediately solved with no effort or verification on the part of the user. Even the least capable user can't be tricked into authenticating to the wrong site because the site's authentication token is associated with the domain name, and the browser won't allow authentication to the wrong domain. This is a technique already in use today, is completely automatic, and does not require the site's cooperation or any intelligence on the part of the user.

This method can be strengthened by requiring a second authentication factor (such as a time-varying key on a cell phone) which, again, is already available and in use today, which protects you (most notably) against screw-ups on the part of the destination site or company.

As for concerns about browser-side authentication being vulnerable to client-workstation attacks: while the is true, it's also true that if your browser is compromised, then no usage of that browser is safe, no matter what authentication mechanism you use. Malware authors can (and already do) wait for you to authenticate on your own using your super-secure technique, and then silently send the necessary traffic to "own" your account, all without you seeing anything amiss. Neither SQRL nor any other authentication system can protect the user of a compromised browser, any more than door locks can protect you from a house fire. Buying fireproof locks is not a solution.

1
source | link