-2

The idea of 2 factor authentication is that if you can prove that you have both a password and a device, you are trusted to be who you say you are. My question is, why does the service still ask you for the password, instead of just asking you to prove that you have it?

In particular, since we have a device, it could just use a 2 server password-authenticated key retrieval instead. In a three-way communication between the service, the device, and the user (well, actually their browser or a USB dongle if they prefer), the user proves that they have the password. That way, an adversary needs to compromise both the service and the device to get a chance at even brute-forcing the password, and if the service or device are just super insecure (i.e. not generating random numbers properly or something), you are still protected if the other one is secure.

Should I distrust 2fa services that ask for the password as possibly using poor security practices (i.e. should I not use them to store sensitive data), or is there some valid reason for them to ask for a password?

schroeder
  • 123,438
  • 55
  • 284
  • 319
PyRulez
  • 2,937
  • 4
  • 15
  • 29
  • 1
    Your logic is not clear. In the current, standard practice, adversaries need to compromise both the device and the service. Should you distrust services using standard practice as "using poor security practices"? I don't follow. – schroeder Jan 21 '19 at 00:32
  • @schroeder What do you mean? If they compromise the service, they can get the password by brute-forcing the hash. They will not be able to use 2FA to impersonate you, but they will have your password. – PyRulez Jan 21 '19 at 00:34
  • I still do not follow. Yes, if the adversary compromises the service, then they get the password. But then they need to compromise the security of the 2FA device in order to use the password. – schroeder Jan 21 '19 at 07:43
  • @schroeder Oh, I guess that's true. The password is kind of useless if you can not use it to compromise the account. – PyRulez Jan 21 '19 at 18:19

3 Answers3

1

To begin with, Smart Cards DO provide the type of authentication you are wanting. As an example, IIS allows the use of client certificates for authentication and at the creation of a session, the user can choose their smart card credential to access the website. They must provide the correct PIN in order for the card to properly sign the authentication request or else they will not have access. This is one of the many benefits smart cards bring for strong authentication.

Since not all public facing websites want to undergo the effort of using standard PKI (plus the distribution of smart cards), users in the general public may use a system like FIDO. Now, FIDO allows for the generation of secure keys between the user and the authenticating services which is a major benefit to authentication and user security. However, most FIDO keys do not have a PIN or password protection feature for access (at least by default). As such, the authenticating service must ensure that a user has the proper credentials by asking for their password their second factor device.

In both of these scenarios, we have multi-factor authentication. However, where a Smart Card comes with a certain level of assurance as to hardware policy, FIDO does not.

Enforcing PIN policies with the general population is very difficult when you do not control the hardware and can only provide an interface to interact with. This starts us down the path of "level of assurance" which is a critical component to trust and verification of identities as well. Since not all devices require a PIN or Password (Computers, smartphones, FIDO devices), the authentication service must supplement through Something You Know or Something You Are authentication. The easiest path at that point is passwords.

So I would consider sites requiring multiple steps to authenticate as more secure than sites without a second factor of authentication requirement. Like other sites, I would also trust them as far as you are able to verify they aren't breached. Trust is often required, but from a security standpoint is always a vulnerability.

Connor Peoples
  • 1,421
  • 5
  • 12
  • They could just use the mobile devices most users have instead of a smart card. That's how must 2FA systems operate now-a-days anyways. – PyRulez Jan 21 '19 at 00:46
  • The only system I would consider trusting on phones would be UAF, and that's with a highly skeptical eye. SMS is a major security risk, SMTP has always been a security risk, and user policies aren't often up to security standards (unless within an enterprise controlled environment). You can't trust the mobile device. – Connor Peoples Jan 21 '19 at 00:48
  • Well, presumably it would be a custom app. Additionally, an adversary would need to compromise both the device *and* the password, which is the point of 2FA. – PyRulez Jan 21 '19 at 00:51
  • UAF would be the protocol I would expect a custom app to use. Examples would be PIngID for use with Ping Federate controlled systems.This is a well documented protocol through the FidoAlliance. – Connor Peoples Jan 21 '19 at 01:04
  • So, the point of my question is why they would not do that. Also, how would you implement UAF on a mobile phone without biometric sensors? It seems like using a password would be easier. – PyRulez Jan 21 '19 at 01:14
  • Development costs is a major discourager. Also, your asking several questions within a single post which is leading to collision of thoughts. You are both arguing for and against passwords in the same question. – Connor Peoples Jan 21 '19 at 01:19
  • Sigh. I am not arguing *against* passwords. I am asking why does the service *request* the password. I am arguing that only the *user* should know the password. The service can still use possession of a password as a form of authentication without asking for it. – PyRulez Jan 21 '19 at 01:20
1

You must provide a password because you are providing "something you know". An option that does not involve providing a password would be Secure Remote Password protocol, which uses Zero-knowledge proof

2FA that uses a mobile device provides the second authentication, "something you have".

they
  • 923
  • 1
  • 5
  • 7
0

The idea of 2 factor authentication is that if you can prove that you have both a password and a device, you are trusted to be who you say you are.

This is not quite precisely true. The purpose of two-factor auth is to prove that you both know a trusted piece of information (a password) and possess a trusted piece of hardware (a security key, a smartphone with a secret seed, etc.).

In particular, since we have a device, it could just use a 2 server password-authenticated key retrieval instead. In a three-way communication between the service, the device, and the user (well, actually their browser or a USB dongle if they prefer), the user proves that they have the password. That way, an adversary needs to compromise both the service and the device to get a chance at even brute-forcing the password, and if the service or device are just super insecure (i.e. not generating random numbers properly or something), you are still protected if the other one is secure.

Well, to start with, most people do not have access to MFA devices that are well-protected by password, so it would be foolish for any service to assume all authentication is happening through one.

Secondly, the scenario you lay out is not a particularly concerning one. If someone breaches a website and gains access to their user database and successfully reverses passwords hopefully stored in a secure manner (e.g. salted and hashed with a gpu-resistant algorithm), this doesn't do them much good: they still need the MFA device to impersonate the user. This is Working As Intended.

Thirdly, two-factor authentication is still quite uncommon. A user will sign up for a service with a username and a password. They may additionally add an MFA device (most likely, SMS, which isn't great). You're going to have a hell of a time convincing all users to use 2fa, especially if it requires the use of a device they don't already own, which means your theoretical service would probably mostly be secure by way of having no users.

Xiong Chiamiov
  • 9,384
  • 2
  • 34
  • 76