3 ms·

Question: How secure would it be to use a QR code as a password, and scan it with a phone camera?

by jokoon 6y ago

geofft 6y ago
It'd be about as secure as writing down a password or using a password manager. Note that it would be a password, not multi-factor authentication. These days, really, the important part isn't so much "something you know" vs. "something you have," it's the nature of how the credentials work. A password is sort of a one-way credential, something that serves by itself to authenticate you (or whoever is in possession of it). Anyone who holds the password can authenticate until it's changed. You should pick a long password, something that it hard for others to guess. A phone number (SMS or phone call) requires an active cell network connection. This is spoofable/interceptable/SIM-jackable, but for the most part, it retains the important property that at the time you log in, the site makes a request to your device to confirm the login. Things like Duo Push is a less attackable version of this mechanism. In both cases that makes it harder to use stolen credentials if "stolen" simply means 'digitally copied" - they'd need some way of disabling the actual physical device in your possession, too. A code generator doesn't require an network connection, but it's still active unlike passwords: it changes every 30-60 seconds. That means a code that logs you in now can't actually log you in forever, so someone who happens to intercept a particular login request (say, someone who watches you type) can't come back and log in later. They'd need the long-term secret which isn't ordinarily revealed by the app except during backups. Things like RSA hardware tokens are less attackable versions of this mechanism. An SSH key also falls in this category - logging in with the SSH key doesn't reveal the entire key, the way logging in with a password does. A security key (U2F/FIDO/WebAuthn) is active like a code generator, but it also verifies the website that's requesting the credential. If someone tricks you into visiting gitIab.com (with a capital I), your browser will send that domain name to the security key, which will not respond with your actual gitlab.com credentials. A password manager with a browser extension is a weaker form of this mechanism - there are a lot more avenues to attack, but fundamentally none of the above mechanisms attempt to be resistant to phishing / social-engineering attacks. So, sure, you could use a large QR code as a password, but that doesn't get you the protections against attacks that the other MFA mechanisms do. It's well worth setting up MFA on important accounts even if you are using a long and unique password, because it protects you from attacks other than password-guessing.
- tialaramex 6y ago
  One thing you missed here: In most of these designs the Relying Party (a web site in these cases) has to store secrets and we know bad guys steal secrets and the site won't always find about it immediately or sometimes at all. For a password we somewhat mitigate this using password hashing. If the site uses a halfway decent password hash and you use a halfway decent truly random password then this is enough to protect both of you. But if you use a bad password or the site does a less than great job protecting it then game over. For SMS the site stores your phone number (not terrible but not great for bad guys to learn) and maybe a temporary code (bad guys may be able to use this by learning it before you do but that's typically a small time window) But for TOTP and similar "One time" codes the site stores the generator value. Bad guys who have this value can make any number of fresh codes at any time. What jumps out here for WebAuthn is that the site stores nothing of value. A random-looking identifier that's useless for anyone other than the Relying Party, and a Public Key that's useless for anything at all other than confirming signatures made with the corresponding Private Key. I've published the actual database contents for some of my own WebAuthn credentials on HN before, because they don't matter, unlike even an Argon2id password hash they are designed to be utterly useless to bad guys. That's a huge benefit because there are fewer people trying to break in because what you have ain't worth stealing any more.

Question: How secure would it be to use a QR code as a password, and scan it with a phone camera?

by jokoon 6y ago

Question: How secure would it be to use a QR code as a password, and scan it with a phone camera?

It'd be about as secure as writing down a password or using a password manager. Note that it would be a password, not multi-factor authentication. These days, really, the important part isn't so much "something you know" vs. "something you have," it's the nature of how the credentials work. A password is sort of a one-way credential, something that serves by itself to authenticate you (or whoever is in possession of it). Anyone who holds the password can authenticate until it's changed. You should pick a long password, something that it hard for others to guess. A phone number (SMS or phone call) requires an active cell network connection. This is spoofable/interceptable/SIM-jackable, but for the most part, it retains the important property that at the time you log in, the site makes a request to your device to confirm the login. Things like Duo Push is a less attackable version of this mechanism. In both cases that makes it harder to use stolen credentials if "stolen" simply means 'digitally copied" - they'd need some way of disabling the actual physical device in your possession, too. A code generator doesn't require an network connection, but it's still active unlike passwords: it changes every 30-60 seconds. That means a code that logs you in now can't actually log you in forever, so someone who happens to intercept a particular login request (say, someone who watches you type) can't come back and log in later. They'd need the long-term secret which isn't ordinarily revealed by the app except during backups. Things like RSA hardware tokens are less attackable versions of this mechanism. An SSH key also falls in this category - logging in with the SSH key doesn't reveal the entire key, the way logging in with a password does. A security key (U2F/FIDO/WebAuthn) is active like a code generator, but it also verifies the website that's requesting the credential. If someone tricks you into visiting gitIab.com (with a capital I), your browser will send that domain name to the security key, which will not respond with your actual gitlab.com credentials. A password manager with a browser extension is a weaker form of this mechanism - there are a lot more avenues to attack, but fundamentally none of the above mechanisms attempt to be resistant to phishing / social-engineering attacks. So, sure, you could use a large QR code as a password, but that doesn't get you the protections against attacks that the other MFA mechanisms do. It's well worth setting up MFA on important accounts even if you are using a long and unique password, because it protects you from attacks other than password-guessing.

tialaramex 6y ago
One thing you missed here: In most of these designs the Relying Party (a web site in these cases) has to store secrets and we know bad guys steal secrets and the site won't always find about it immediately or sometimes at all. For a password we somewhat mitigate this using password hashing. If the site uses a halfway decent password hash and you use a halfway decent truly random password then this is enough to protect both of you. But if you use a bad password or the site does a less than great job protecting it then game over. For SMS the site stores your phone number (not terrible but not great for bad guys to learn) and maybe a temporary code (bad guys may be able to use this by learning it before you do but that's typically a small time window) But for TOTP and similar "One time" codes the site stores the generator value. Bad guys who have this value can make any number of fresh codes at any time. What jumps out here for WebAuthn is that the site stores nothing of value. A random-looking identifier that's useless for anyone other than the Relying Party, and a Public Key that's useless for anything at all other than confirming signatures made with the corresponding Private Key. I've published the actual database contents for some of my own WebAuthn credentials on HN before, because they don't matter, unlike even an Argon2id password hash they are designed to be utterly useless to bad guys. That's a huge benefit because there are fewer people trying to break in because what you have ain't worth stealing any more.