KBA/KBV Doesn't Verify an Identity

[TerryMcBride]

Organization: 1

Type:

Reference (Include section and paragraph number): Part A Section 5.3

Comment (Include rationale for comment): Probably to big of a discussion for Github, but since I have seen only one comment go by and it was closed fairly quickly without much debate...

In section 5.3, you claim that KBA verifies the identity (so you have renamed it KBV). But it only verifies knowledge about the person, which aligns with the validation requirements you have in 5.2.2.1: "All personal details and evidence details have been confirmed as valid by comparison with information held/published by the issuing source". At best, KBA is useful to validate that this identity exists in the real world by virtue of the fact hat there are multiple sources (utilities, financial) that have dealt with the person. It can also be useful for determining risk if risk scores and/or indicators of previous fraud are being returned by the KBA source.

In 800-63 version 2, (1) Resolution was Name, Address, DoB and a Government ID Number. (2) Validation was financial or utility account linkage with address, etc. (3) Verification was done by Address Confirmation (which this document treats as a separate part of the process). BTW, micro-transaction (which is not KBA) along with general transaction history (note that 800-63 version had a provision for financial accounts in good standing > 1year) might be a valid Identity Verification method. These seem to be more aligned with the Resolve, Validate, Verify approach than version 3 so far.

We know that fraudsters have been successful at attacking our services by exploiting KBA. Five main bullets and some sub bullets are not enough to make KBA/KBV secure. Some questions: I assume aggregators are allowed, because we can't possibly strike up a contract with every bank, right? Who are the aggregators allowed to sell their services to? Who are the banks allowed to give the info to? What are the privacy implications around requiring the issuing sources of identity evidence to offer KBA services in order for their identity document (i.e., evidence) to be useful for remote proofing? Are we encouraging the public to give their identity data to organizations who will offer it for sale as a KBA service?

Suggested Change: Drop KBV as a requirement for anything.

---

Organization: 1 = Federal, 2 = Industry, 3 = Other

[mridentity]

KBA in essence is just a special form of possession based authentication, except the possessed are unique information rather than physical objects or biometrics. KBA is best used to supplement physical objects when additional verification is warranted. Unfortunately the world had long flipped to using knowledge (namely password) first approach in the early days of the Internet due to the lack of hardware that could be used to remotely verify a computer user.

[mschleiff]

While a user's knowledge of KVA may not add much identity assurance, in cases where a user doesn't know his/her claimed identity's KVA could lower identity assurance. So to me it seems like KVA has some verification value.

[mridentity]

Agreed. If white house secret service agents wake up tomorrow morning and see two presidents in the oval office they will have no option but to interrogate both. God forbid that ain't gonna happen.

[rsfaron23]

This thread is touching on some real issues, especially where the service provider has no prior interaction with the user. In that case, while not perfect, dynamic KBV (KBA) can provide at least a second factor for identity verification, to connect the user claiming that identity to a resolved and validated identity. In a first contact situation, I cannot think of another way to go, unless the system established a federated and trusted identity verification link, through linking the issuing source of information for the token to a previously resolved and validated identity. I realize there are populations and even valid individuals who have trouble with KBA quizzes, and I realize 63A, section 5.3.2 is trying to put parameters around the process. I think the listed parameters may be too strict and or expensive for some relying parties, since many Credential Service Providers and Identity Providers are not the originating source of the data or transaction history. The standards for KBA need to be adjusted to provide for these cases which may in fact rely upon purchased data, like credit data, known fraudulent data lists, etc. Otherwise these users will need to go through troublesome and expensive processes to establish their identity. (Think of the new articles recently on underprivileged individuals being unable to get their identity from state identity organizations and DMVs. And also consider the DMVs who continue to maintain they are licensing bureaus, not identity bureaus.) Where do we go from here to the vision of 63A?

[TerryMcBride]

Knowledge of transaction history is not secret and therefore not even private. Each company that I have done business with has that information. The aggregator has that information. My behaviors are consistently tracked, calculated, and predicted. And hackers steal that information routinely. There are multiple marketplaces - one legal (the aggregators) and another illegal (the fraudsters). I'm surprised that the privacy folks in NIST are OK with encouraging the proliferation of tracking and selling this personal (but not really private) information for the purposes of authenticating people to the Federal Government.

Could KBA be improved, sure. Might it be useful as a compensating control, yes. Should it be considered "Verification" that the right subject is on the other end of the keyboard, NO!? Other techniques, such as demonstrating access to address that has been verified as belonging to the person (an address of record) have a better track record. It's much harder to automate an attack on a individual's phone and a Federal web site at the same time than it is to simply attack the website by knowing/guessing the answers to a KBA quiz. Escalating levels based on successful transaction history has also been successful in the payments industry. We have real world examples of successful attacks on KBA at large scales (e.g., current count of the IRS Get Transcripts event is 724,000). You can try to chalk that up to "not enough rules" on KBA or "poor implementation." But in the end 800-63-3 in its current form doesn't fix all of the reasons for the successful attack.

More concerning, this version puts KBA in a place of higher importance in the process (version 2 treated it as a compensating control). For IAL2 we need at least one Strong piece of evidence. The likely implementation of Strong Identity Evidence Verification from 5.2.3 is a picture of an ID and a KBA quiz. My feeling is that these can both be attacked en mass (I wonder how many actual pictures of drivers licenses are on Facebook, Instagram, and Twitter aside from the ability to fake them?).

Who can/can't Equifax and Experian sell their services to? Can an attacker hire them and phish, sit in the middle, or test answers? Where are those rules? How come we are placing so much trust in these KBA providers without any requirements on their practices? If those requirements are based in regulation (which I don't see 800-63 limiting KBA providers to regulated entities) then they are not enough. It is way to easy to get a credit report on someone.

By the way, passwords are shared secrets established between the CSP and the user. If implemented a securely (which they almost never are - e.g., randomly set by the server, not-reused, etc.) passwords are more similar to a symmetric key than KBA (the later of which defacto requires a third party).

[Terebi42]

KBA should be aggressively deprecated as a form of 2FA as two things you know are not two different forms of authentication. Especially since the vast majority of implementations are using information which is easy to publicly find. If SMS is weak, surely KBA is weaker.

[rsfaron23]

I am still trying to come up with a way for a person unknown to the RP to use first time internet access to an account regarding Personal information about someone, to establish they, the first time user are the same person as the subject of the information that the RP Government holder of that information has. No national identity card please. All suggested processes welcome. We are talking a process without prior enrollment at the RP. Thoughts?

[paul-grassi]

I'm hesitant to get into this on GitHub, but heck, this is why we are here. We created very explicit, hardened requirements around KBV, so it's not the KBV you know and hate. Some examples include characteristics of the data source (never in the public domain or available in any way, shape or form), question composition - your spouse reasonably doesn't know the answer, etc. etc. We put a preference on micro-deposit as we know a financial statement has valid proofing properties. AND, we only allow KBV against one form of identity evidence, not both, so passing KBV is just a subset of the overall pass/fail decision, not the ONLY factor as we have today. So I hear you all, and pretty much agree. We have alternatives in the market to KBV, we've seen them in practice in the UK (which also allows KBV), and we like their strength - hence this update. If we drop KBV from 63A, any replacements we have missed in this update?

[paul-grassi]

A few things on KBV - We have tightened the requirements of a valid source to KBV against pretty significantly. In addition, we only allow KBV to prove verification against 1 form of identification, not both. Meaning, if you pass KBV for a bank statement, you still need your DL to be validated and verified. Also, as a result of pull request #223, we downgraded KBV to evidence that is marked "acceptable", so there are even more requirements to prove you are who you say you are when you present "acceptable", not "strong" or "superior" evidence.

We are not KBV fans based on how it is currently implemented, but we also have to be pragmatic based on the market, so throwing it completely out, as opposed to providing secure guidance, seems untenable. We're always open to alternatives that could allow an agency to proof (successfully) a broad range of stakeholders.