6

Most of the conventional IT.Sec thinking I've seen says that a user can only have one multi factor authentication device. I'd like to challenge that defacto-thinking and ask if there is ever an occasion where:

  • More than one multifactor device (token) would be issued to a single human (or user account)

  • In a ASP scenario, (or service like Amazon Web Services) when would more than one token be registered?

The key difference I'm illustrating above is corporate controlled vs web service like banking, IAAS, SAAS, etc

  • Should users be allowed a "backup" token if they lose or forget their primary token? How many tokens should they be offered?

This last point would also be valid where a YubiKey Nano (or similar) is installed on a Work and Home PC. This user may also have a travel token as well. The concept is that the threat footprint is reduced (albeit not "perfect")

makerofthings7
  • 50,090
  • 54
  • 250
  • 536

6 Answers6

6

I have several multifactor authnetication devices linked to my paypal account. I also have two different multi-factor authentication devices securing my stackexchange logon. It is definitely possible to do so.

THere are multiple requirements to do so. One is simple convenience (I authenticate with the device nearest to me at the time). A more formal requirement might arise because different tokens are issued at different levels of Assurance (LoA) - I have multiple credentials at different levels of assurance. It may be convenient for me to sign in with a low assurance credential, but if I want to take an action that requires a higher assurance, I may need to re-authenticate with a different credential.

@Lucas Kauffman is entirely correct; I do NOT want my admins to log in with the same credential when they are browsing the internet that they do when they are patching my servers.

This answer could easily go on at book length and be outside the scope of SEC:SE. The National Strategy for Trusted Identities in Cyberspace (NSTIC) can be viewed as an answer to the question.

MCW
  • 2,572
  • 1
  • 15
  • 26
4

If your user is a testuser and needs for instance access to an account with admin, a normal and a special account (not making it an admin account but also more privileges than normal). Then more than one token might be needed.

Also I see this happening in practice when one single account can't perform action A and B. If the user needs access to action A and B, then you might need to issue two tokens. (if you do this please make sure to maintain a good segregation of duties). This is however a workaround for a limitation within the application.

Lucas Kauffman
  • 54,169
  • 17
  • 112
  • 196
3

The "common wisdom" that only one device is needed for an organization is a cost thing: if a token costs $60 each, and you already trust it to secure your most sensitive access, you could reuse it to provide lower access. The same token could be associated with your "admin" account, your "regular" account, and your low level "test system" account. The onus is on the user to use the appropriate account for the situation.

It's important to understand that the token is associated with your identity, and not with your level of authority. By itself, the token doesn't grant the admin authority. The token is associated with you and your account, and it's your account's membership in the admin user group that grants admin authority.

Where multiple tokens are needed is when two different organizations are granting access, and the two organizations don't know about, talk to, or trust each other. You might have a token issued by a vendor to access the vendor's site, and if you don't have a federated login agreement with them, then I can understand issuing a second token. But there's little reason to make your users carry around 8 different tokens, and lots of reasons not to - cost per token, and user confusion (which of these three identical tokens do I use for the lab account?)

John Deters
  • 33,650
  • 3
  • 57
  • 110
  • the only problem with this is the 'onus is on the user' piece. The more we can remove that sort of risk decision from the user, the safer the business will be... – Rory Alsop Jan 08 '13 at 21:41
  • 1
    @RoryAlsop, that's a common misconception. Consider a person who needs admin authority to do part of their job. Would you want them to have that authority 100% of the time when they're logged in, even when surfing the web, or doing non-admin stuff? That's a huge security risk. Instead, that person should know "when I'm surfing the web, I will use my regular non-admin account." People with jobs that require elevated security have to be responsible for when they use it - that's much more desirable than a one-size-fits-all approach. – John Deters Jan 10 '13 at 19:22
  • 1
    You misunderstood my point. I mean don't use the same token for the different security levels. – Rory Alsop Jan 10 '13 at 22:43
  • @RoryAlsop In the hypothetical case of a perfectly uncrackable OTP generator, would that still be the case? - I guess yes, since the token user still needs to make sure the machine has not been manipulated and tricks them into an admin login while displaying a lower level. But a compromise might be something like the Yubikey's two-in-one function, where the keypress duration determines which of two authentications to use. – Tobias Kienzler Feb 09 '13 at 08:12
3

...for each environment

Depending on the security requirements of each environment, (test, dev, qa, prod) there should be a separate token. This can prevent operational issues where a QA test script "leaks" into production and affects service.

...for each role

Tokens should be unique according to the risk to operations it poses: (Domain Admin, CA admin).

... multiple tokens per login

I've never seen this in production but can imagine a scenario where someone is challenged for a username, password, HTOP password, and Yubikey password.

..as is appropriate for the security need

I think there is a middle ground between not having multifactor device at all, versus having only one assigned token. Specifically, once IT Security hinders the usability of the system, users will find a way around it. Here is a user who is using a video camera to remotely automate his RSA key fob challenge.

If a user is using this technique, or simply using a Webcam pointed at a token, then it may be a good idea to find out why. If it's to reduce physical keychain bloat, or because they may lose it, then perhaps issuing that user multiple tokens could address the issue. For example; a YubiKey nano could be plugged into a home and work PC. Since the nano is hard to remove, it may make sense to also have a portable USB token as well.

Security is slightly more diluted than the one-token-per-person model, but is a far cry from not having any multi-factor at all. In this case, the surface area of attack is reduced so that random tokenless sessions will be rejected.

Community
  • 1
makerofthings7
  • 50,090
  • 54
  • 250
  • 536
  • "... multiple tokens per login" I dont think for each login attempt but for each "user", so a user can have another token as emergency backup. – My1 Feb 02 '16 at 08:40
1

The disadvantages of requiring more than two authentication factors become evident when you answer the question: "will a user need to provide all of these factors every time to access their account?".

If the answer is yes, then while the system would technically become more secure (more pieces of information would have to fall into the wrong hands in order for the authentication scheme to be spoofed), it would also become less user-friendly. If the user needed to enter their name, a secret password they created and memorized, the number off a card in their wallet, and the number off a crypto-key on their keychain, then a lot has to go wrong for a user's account to be logged into by someone other than that person. However, only one thing has to go wrong for the legitimate user to become locked out of their own account (forget their password, lose their card, lose their keys). They also have to enter all this information to log in, every time; I don't know about you, but the average user would consider that an extreme barrier to entry.

If the answer is no, then the system becomes less secure; if the user could use their crypto-key fob or their card number, then they could still get in if their wallet were stolen, but an attacker now has a choice; he can steal the user's wallet or their keychain to obtain a device that provides the needed authentication, on top of the password that was acquired with a keylogger. He can choose the easier target, making the option a reduction in the total level of security.

KeithS
  • 6,678
  • 1
  • 22
  • 38
0

I think it should be possible for each user to get multiple keys, if your key gets lost or stolen (or in case of the tokens that have their own battery, if the battery dies) you should always have a backup token, so you can get in (and disable the other token for example)

that's also the reason Google, Github and Dropbox allow Multiple U2F devices.

My1
  • 394
  • 2
  • 12