Using the password, among other values, as key data in two-factor authentication

Question

I'm writing an implementation and a thesis about two-factor authentication, and am currently doing some research. I'm currently looking at an implementation for deterministically generating a composite shared key based on certain data, which I will be using for TOTP. M'Raihi, et al specify in RFC 4226 (chapter 8, Composite Shared Secrets, page 14) that a composite shared key:

"[...] can consist of any data known at the token but not easily obtained by others."

They specify the following examples:

• PIN or Password obtained as user input at the token
• Phone number
• Any unique identifier programmatically available at the token

To me this seemed like a reasonably sound way of generating a shared composite key (with some disadvantages that are out of scope for my question). RFC 4226 looks like a solid, high quality, document from a trusted source with writers who have papers about multiple advanced subjects. To me it looks like the writers and document can be trusted to use for safe implementation.

I then ran in to "The Case for Mobile Two-Factor Authentication" (unfortunately requires login/pay, but I have free access to it using my university account) by Dimitri DeFigueiredo, who is a cryptography and security researcher at Adobe.

The document is more a, as the title gives away, case for mobile two-factor authentication. However, he makes a couple of claims that got me interested. Namely the following, which to me seems to contradict RFC 4226 (emphasis mine):

"By itself, a stolen in-phone token shouldn't provide a way to authenticate an attacker and can't leak the corresponding PIN."

This made me wonder if using a password in a key is really such a good idea. My main question is whether using the password in the composite shared key can leak information about how the shared key is generated. Or worse, completely compromise the security of the key? I know this sort of counts as a whole second question, but: should data that is used for the key be salted/peppered/hashed or does this also compromise security?

As a small note: I don't think I will use the document by DeFigueiredo. He seems to be mixing up PIN's for unlocking phones with two-factor authentication and some other vague statements which make me doubt the quality of the document. On the other hand he has a job at Adobe as cryptography research, so it might be I'm just not getting what he says. Any feedback on the quality of that document would be well appreciated, if anyone has the chance to read it.

Answer 1

The important part of this seems to be the next line in the RFC:

In this scenario, the composite shared secret K is constructed during the provisioning process from a random seed value combined with one or more additional authentication factors.

The key data should never be just the data known at that point, but should be derived from it using a strong process, which should ensure that the individual components of a composite key are sufficiently mixed to make reconstruction impossible.

This doesn't necessarily contradict the DeFigueiredo statement - if you used a PIN of 1234, and your tokens were 1234-token1 and 1234-token2, clearly the tokens leak the PIN. If they were MTIzNC10b2tlbjE= and MTIzNC10b2tlbjI=, they still leak it, just slightly less obviously - these are just the base-64 representations of the above tokens. If they were 32e38e71a26e560092e395a02fb85132 and bd7c0c61696eb5716fc866c21246e846, it takes a lot more effort to work out what is going on - in this case, hex representation of the MD2 hash of the above strings. That's not a strong generation process, but it shows the basic principle.

Therefore, if you have a strong generation process, you can put almost anything you want into it, and not leak what went in.