Clarification on Wells Fargo Status

[todd]

cc @tehroot as it appears that you were responsible for the commit that makes note of Advanced Access.

How exactly are we defining 2FA here? Is it a strict adherence to the idea that you need a secondary authorization scheme for accessing a resource or the idea that only some actions on a protected resource require the additional security? I.e., are we saying you need a token to access an account or that you only need a token to perform certain actions on the account? Advanced Access is the latter (and, I might add, as a Wells Fargo customer, I've never been prompted to use it, regardless of having it set up).

[tehroot]

I've had AA prompt me with large money transfers or withdrawls through the web interface. I put it under custom since it's a custom form of 2fa. This is supposed to let people know what kind of authentication, if any, institutions have, it's also why I included the direct link to wells fargo's documentation.

I don't think there was a rigorous look into the defining characteristics of 2fa besides whether it fit in custom, or in a normal OTP app like Authy or Authenticator.

[todd]

I think it's still worth having a discussion about since it's not what I would consider 2FA (others may disagree). I would agree that having some additional form of security in the way that Advanced Access provides is good, but I don't think it's necessarily what 2FA has colloquially become known as.

@jdavis Thoughts?

[todd]

Bump.

[jdavis]

Thanks for the bump, @todd. We're working on a big change in #333 and then hopefully we can come back to fixing up all the issues/PRs.

Custom is no longer there, instead we are having a section for Hardware, Software, SMS, Phone Call, and Email.

Regarding AA, I've never used it so could use some more info (their site isn't that helpful: https://www.wellsfargo.com/help/faqs/advanced-access/)

How is it being used?

[todd]

@jdavis Totally understood.

AA is only used when Wells Fargo determines you're performing a high-risk operation (like transferring a large amount of money). It works pretty much the same way as traditional 2FA - you're sent a code and asked to enter it on the site before you can complete your request.

It differs from 2FA in that it's only used in certain situations and you can still gain access to an account without having used it. As I mentioned above, I've never been prompted to use AA, despite having it set up. This is a huge issue because you can still access and perform all sorts of sensitive actions/information by just logging into the account (i.e., account numbers, statements, bill pay). In instances like that, AA does not come into play.

Fundamentally, the question here is what we are considering to be 2FA and what we aren't. You could make the argument for AA being some form of 2FA, but considering that it plays literally zero role in authentication (albeit while still providing some occasional authorization redundancy), I'd argue it doesn't count as 2FA.

So, tl;dr:

1. How are we defining 2FA? Does it need to play an active role in authentication or is occasional authorization support good enough?
2. Does Wells Fargo's AA count as 2FA based on the definition provided in the answer to the previous question?

[smholloway]

I think AA is a neat idea, and I appreciate a bank trying to prevent fraud; however, I don't think it fits the current thrust of the site (the homepage links to the Wikipedia page for two step verification, which is authentication focused).

With PR #208 I suggested that we add a separate page for 2fa providers; perhaps we could do something similar and add another page for services like AA that don't quite fit on the homepage.

[jdavis]

I can see the argument for it being 2FA, but I completely agree in that the real issue is like what you said "you can still access and perform all sorts of sensitive actions/information by just logging into the account."

To answer your questions:

1. I think 2FA (for this site) should be limited to logging into your account and prevention of access of any info.
2. I would be in favor of saying that no, it doesn't count.

How does that sound, @todd?

[todd]

Sounds shiny to me. Perhaps we should clarify that in the README? More than happy to submit a PR.

[jdavis]

That'd be great and very much appreciated. ❤️

[todd]

On it.

[todd]

PR submitted. Closing this issue since we came to a conclusion about what 2FA is and isn't.

[the-solipsist]

I'm unclear why transaction verification (authorization verification) is not being included within 2FA when it meets all the criteria set forth on the Wikipedia page. On the Wikipedia page for multi-factor authentication, which is much more detailed than the one for two-factor authentication, it talks multiple times of online 'transactions':

E.g.,
"An alternative approach to OTP used primarily in Finland, is to assign a pseudo-random reply number from a pool of numbers to the communication and authenticate the user entirely out of band using that reply address along with the originating customer number and reply options within the body of the message to authenticate the user.[17] This approach minimizes vulnerability to MITM attacks by asking the user to verify the transaction details within the body of the text message as well as on-line — if they don't match, the user can see plainly that there is a MITM attack in progress and reject the transaction."

"Two-factor authentication solutions sometimes includes technologies to generate one-time passwords..."

Smartphone push

"The push notification services offered by modern mobile platforms, such as iPhone's APNS and Android's C2DM/GCM, can be used to provide a real-time challenge/response mechanism on a mobile device. Upon performing a sensitive transaction or login, the user will instantly receive a challenge pushed to their mobile phone, be prompted with the full details of that transaction, and be able to respond to approve or deny that transaction by simply pressing a button on their mobile phone. Smartphone push two-factor authentication has the capability to not only be more user-friendly, but also more secure as a mutually-authenticated connection can be established to the phone over the data network."

I know a bank that enables all monetary transactions (not just high-value ones) to require a special one-time code, but doesn't require a code for login. I don't see why that doesn't fall within the definition of 2FA when withdrawing money from an ATM falls within the definition of 2FA.

[todd]

I'm assuming you read the rest of this thread which does, I think, a pretty good job of outlining our intentions here.

I think that most people have the idea of 2FA/MFA being authentication and not authorization related. I, for instance, would assume that 2FA/MFA provided by a service would be authentication, not authorization related (although I may be a poor example as I'm the OP for this issue).

Regardless, I think that MF-authorization is certainly a good thing, but authorization redundancy tends to differ wildly between services (i.e., you know a bank that requires all transactions to require a challenge-response while Wells Fargo only requires it for some transactions) - that inconsistency alone would seem to be a good reason not to include MF-authorization information on this site (not to mention the plethora of sensitive data you can view by just accessing the account without performing any transactions). With MF-authentication, you know that different services' implementations are going to be more or less consistent with what you expect.

I know a bank that enables all monetary transactions (not just high-value ones) to require a special one-time code, but doesn't require a code for login. I don't see why that doesn't fall within the definition of 2FA when withdrawing money from an ATM falls within the definition of 2FA.

Technically, an ATM uses 2F-authentication since it requires you to have two unique ways to identify yourself (ATM card, PIN) to the machine before you can access your account, let alone start transactions. But I digress.

Actually, after thinking about it some more, my previous statement isn't really true, though it's not the classic username/email/password combo that we've been discussing here. Anyway, I concede the point.

All that being said, I'm not opposed to this site having a separate section for authorization redundancy, but I think just lumping that data in with the authentication data would be terribly misleading.

[the-solipsist]

I think that most people have the idea of 2FA/MFA being authentication and not authorization related. I, for instance, would assume that 2FA/MFA provided by a service would be authentication, not authorization related (although I may be a poor example as I'm the OP for this issue).

My point was that that's a questionable claim. I have always thought of 2-factor authorization (password + one-time code) as "two factor auth", and the quotes I dumped from the Wikipedia page for MFA were to show that at least some of the editors of that page don't see the distinction either.

that inconsistency alone would seem to be a good reason not to include MF-authorization information on this site

I'm not sure I agree. Google requires you to provide your password a second time while accessing Google Accounts, even if you're already logged in; different services implement access controls differently, but that doesn't mean they don't use 2FA. All that is needed is a note. (As we currently have with the exceptions tag.)

All that being said, I'm not opposed to this site having a separate section for authorization redundancy, but I think just lumping that data in with the authentication data would be terribly misleading.

Thanks. I agree that lumping them together, without annotations isn't desirable.

(I also think that separating "software" into two sub-categories of HOTP-/TOTP-based and custom software implementations would be helpful, but that's a separate issue.)

[Benson665]

I appreciate your patience with me ,and now on I will put on my best to make it up thank you all