Authentication succeeds without verifying prefix from LDAP on autoprovision

[jralbert]

If a user that's either new or has no yubikey prefix assigned in yubiauth attempts to authenticate to yubiauth with user/pass credentials that successfully validate to LDAP, and an OTP that successfully validates to the YK validator service, they will be autoprovisioned from LDAP if the configuration is set to allow it - but on that first request authentication will succeed, even if the (valid) token provided doesn't have the prefix that the user's LDAP record specifies. Further requests will fail, because the prefix store in yubiauth doesn't match the one specified in LDAP.

This would mean that an attacker who can obtain a valid user/pass credential pair and ANY valid yubikey can successfully authenticate to yubiauth at least once - more if they can delete the user record after it's created.

This comes down to behaviour in the authenticate_otp function in client/controller.py: if the user already has a key provisioned, the function calls user.validate_otp(otp, password), which correctly checks the prefix against LDAP; but if they don't already have a yubikey provisioned, then the function assigns the current key's prefix to their yubiauth record and immediately returns True. This is in error. Instead, line 67 should replace "return True" with "return user.validate_otp(otp, password)", which would match the existing prefix behaviour as above.

Please let me know if there's any additional information you need from me on this.

[dainnilsson]

I'm not sure I follow. What I think you're saying is that USE_LDAP, LDAP_AUTO_IMPORT, and AUTO_PROVISION are all enabled, is that correct? Then you're saying that a call to Client.authenticate() with a valid username and password, and any valid OTP for YubiCloud (or whichever OTP validation server you've configured) allows the user to authenticate once? If so, that is the intended behavior when AUTO_PROVISION is enabled. A user self-enrolls a YubiKey by authenticating with it once, thereby enabling (and subsequently enforcing) 2FA for the account. Am I misunderstanding anything?

[jralbert]

All the statements you made are correct, but there’s one piece missing from that description: when the YubiKey is auto-enrolled on that first authentication, YubiAuth doesn’t validate whether that key’s public ID matches the public ID that’s stored on the LDAP record that the user/pass creds are compared against. Subsequent auth requests do validate this way, so that a user can only successfully authenticate with a Yubikey whose public ID is on their LDAP record; but the first auth during enrollment isn’t bound by this constraint. This inconsistency means that the enrollment step doesn’t enforce the same auth requirements as subsequent auth requests. The change I proposed initially would reconcile this inconsistency, checking the public ID of the key a user attempts to enroll against the their LDAP record to confirm it’s valid for them.

From: Dain Nilsson [mailto:notifications@github.com] Sent: Tuesday, February 21, 2017 5:30 AM To: Yubico/yubiauth yubiauth@noreply.github.com Cc: Jeff Albert jralbert@uvic.ca; Author author@noreply.github.com Subject: Re: [Yubico/yubiauth] Authentication succeeds without verifying prefix from LDAP on autoprovision (#9)

I'm not sure I follow. What I think you're saying is that USE_LDAP, LDAP_AUTO_IMPORT, and AUTO_PROVISION are all enabled, is that correct? Then you're saying that a call to Client.authenticate() with a valid username and password, and any valid OTP for YubiCloud (or whichever OTP validation server you've configured) allows the user to authenticate once? If so, that is the intended behavior when AUTO_PROVISION is enabled. A user self-enrolls a YubiKey by authenticating with it once, thereby enabling (and subsequently enforcing) 2FA for the account. Am I misunderstanding anything?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/Yubico/yubiauth/issues/9#issuecomment-281344382, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ATtuT7h4L7CpVQHLf6Hp1d8w41Cc5FjKks5reubKgaJpZM4ME4QF.