Default verify_ap_req_nofail used by krb5_verify_init_creds is insecure #1129
Comments
Correct, which means that the default is to fail if there is no service principal and key to verify the user's TGT with. That is the correct and secure default. That said, we don't have a test of this. Did I miss something? |
|
Correction: I misread the krb5_kt_default code and didn't test it; evidently it doesn't fail, just returns a krb5_keytab object with presumably nothing in it -- doesn't even check whether the file exists, according to ktrace. So the Heimdal behaviour is not, after all, different from mit-krb5. Nevertheless, this means that, for krb5_verify_init_creds (and krb5_verify_user) to actually do the basic thing it is supposed to do, it must be run with a krb5.conf having the obscure option This appears to be for the benefit of (hypothetical) legacy pam_krb5 installations, according to the reasoning of https://mailman.mit.edu/pipermail/krbdev/2011-January/009796.html, which have had this security hole open for the quarter century since its fix has been available in 1997, to the detriment of any new or already-keyed installations -- and has the effect that keying an installation doesn't actually defend against authentication attacks. |
The excessive number of negatives in the option's name is confusing at least one of us! I think it has managed to confuse everyone who has ever laid eyes on it. This name deserves an award for the level of confusion it packs into a mere 20 characters. If I'm reading this correctly:
Did I misread or miss anything here? (I haven't tested it.) |
|
Oracle's Kerberos, which I think is based on mit-krb5, has the secure default, documented here in contrast to mit-krb5:
That links to the krb5.conf man page which says:
They provide instructions for how to disable it in applications that for some reason require being vulnerable to spoofing: |
netbsd-srcmastr
pushed a commit
to NetBSD/src
that referenced
this issue
Jun 21, 2023
New allow_kdc_spoof overrides this to restore previous behaviour which was vulnerable to KDC spoofing, because without a host or service key, pam_krb5 can't distinguish the legitimate KDC from a spoofed one. This way, having pam_krb5 enabled isn't dangerous even if you create an empty /etc/krb5.conf to use client SSO without any host services. Perhaps this should use krb5_verify_init_creds(3) instead, and thereby respect the rather obscurely named krb5.conf option verify_ap_req_nofail like the Linux pam_krb5 does, but: - verify_ap_req_nofail is default-off (i.e., vulnerable by default), - changing verify_ap_req_nofail to default-on would probably affect more things and therefore be riskier, - allow_kdc_spoof is a much clearer way to spell the idea, - this patch is a smaller semantic change and thus less risky, and - a security change with compatibility issues shouldn't have a workaround that might introduce potentially worse security issues or more compatibility issues. Perhaps this should use krb5_verify_user(3) with secure=1 instead, for simplicity, but it's not clear how to do that without first prompting for the password -- which we shouldn't do at all if we later decide we won't be able to use it anyway -- and without repeating a bunch of the logic here anyway to pick the service name. References about verify_ap_req_nofail: - mit-krb5 discussion about verify_ap_req_nofail: https://mailman.mit.edu/pipermail/krbdev/2011-January/009778.html - Oracle has the default-secure setting in their krb5 system: https://docs.oracle.com/cd/E26505_01/html/E27224/setup-148.html https://docs.oracle.com/cd/E26505_01/html/816-5174/krb5.conf-4.html#REFMAN4krb5.conf-4 https://docs.oracle.com/cd/E19253-01/816-4557/gihyu/ - Heimdal issue on verify_ap_req_nofail default: heimdal/heimdal#1129
netbsd-srcmastr
pushed a commit
to NetBSD/src
that referenced
this issue
Jun 22, 2023
lib/libpam/modules/pam_krb5/pam_krb5.c: revision 1.31 lib/libpam/modules/pam_krb5/pam_krb5.8: revision 1.13 pam_krb5: Refuse to operate without a key to verify tickets. New allow_kdc_spoof overrides this to restore previous behaviour which was vulnerable to KDC spoofing, because without a host or service key, pam_krb5 can't distinguish the legitimate KDC from a spoofed one. This way, having pam_krb5 enabled isn't dangerous even if you create an empty /etc/krb5.conf to use client SSO without any host services. Perhaps this should use krb5_verify_init_creds(3) instead, and thereby respect the rather obscurely named krb5.conf option verify_ap_req_nofail like the Linux pam_krb5 does, but: - verify_ap_req_nofail is default-off (i.e., vulnerable by default), - changing verify_ap_req_nofail to default-on would probably affect more things and therefore be riskier, - allow_kdc_spoof is a much clearer way to spell the idea, - this patch is a smaller semantic change and thus less risky, and - a security change with compatibility issues shouldn't have a workaround that might introduce potentially worse security issues or more compatibility issues. Perhaps this should use krb5_verify_user(3) with secure=1 instead, for simplicity, but it's not clear how to do that without first prompting for the password -- which we shouldn't do at all if we later decide we won't be able to use it anyway -- and without repeating a bunch of the logic here anyway to pick the service name. References about verify_ap_req_nofail: - mit-krb5 discussion about verify_ap_req_nofail: https://mailman.mit.edu/pipermail/krbdev/2011-January/009778.html - Oracle has the default-secure setting in their krb5 system: https://docs.oracle.com/cd/E26505_01/html/E27224/setup-148.html https://docs.oracle.com/cd/E26505_01/html/816-5174/krb5.conf-4.html#REFMAN4krb5.conf-4 https://docs.oracle.com/cd/E19253-01/816-4557/gihyu/ - Heimdal issue on verify_ap_req_nofail default: heimdal/heimdal#1129
netbsd-srcmastr
pushed a commit
to NetBSD/src
that referenced
this issue
Jun 22, 2023
lib/libpam/modules/pam_krb5/pam_krb5.c: revision 1.31 lib/libpam/modules/pam_krb5/pam_krb5.8: revision 1.13 pam_krb5: Refuse to operate without a key to verify tickets. New allow_kdc_spoof overrides this to restore previous behaviour which was vulnerable to KDC spoofing, because without a host or service key, pam_krb5 can't distinguish the legitimate KDC from a spoofed one. This way, having pam_krb5 enabled isn't dangerous even if you create an empty /etc/krb5.conf to use client SSO without any host services. Perhaps this should use krb5_verify_init_creds(3) instead, and thereby respect the rather obscurely named krb5.conf option verify_ap_req_nofail like the Linux pam_krb5 does, but: - verify_ap_req_nofail is default-off (i.e., vulnerable by default), - changing verify_ap_req_nofail to default-on would probably affect more things and therefore be riskier, - allow_kdc_spoof is a much clearer way to spell the idea, - this patch is a smaller semantic change and thus less risky, and - a security change with compatibility issues shouldn't have a workaround that might introduce potentially worse security issues or more compatibility issues. Perhaps this should use krb5_verify_user(3) with secure=1 instead, for simplicity, but it's not clear how to do that without first prompting for the password -- which we shouldn't do at all if we later decide we won't be able to use it anyway -- and without repeating a bunch of the logic here anyway to pick the service name. References about verify_ap_req_nofail: - mit-krb5 discussion about verify_ap_req_nofail: https://mailman.mit.edu/pipermail/krbdev/2011-January/009778.html - Oracle has the default-secure setting in their krb5 system: https://docs.oracle.com/cd/E26505_01/html/E27224/setup-148.html https://docs.oracle.com/cd/E26505_01/html/816-5174/krb5.conf-4.html#REFMAN4krb5.conf-4 https://docs.oracle.com/cd/E19253-01/816-4557/gihyu/ - Heimdal issue on verify_ap_req_nofail default: heimdal/heimdal#1129
netbsd-srcmastr
pushed a commit
to NetBSD/src
that referenced
this issue
Jun 22, 2023
lib/libpam/modules/pam_krb5/pam_krb5.c: revision 1.31 lib/libpam/modules/pam_krb5/pam_krb5.8: revision 1.13 pam_krb5: Refuse to operate without a key to verify tickets. New allow_kdc_spoof overrides this to restore previous behaviour which was vulnerable to KDC spoofing, because without a host or service key, pam_krb5 can't distinguish the legitimate KDC from a spoofed one. This way, having pam_krb5 enabled isn't dangerous even if you create an empty /etc/krb5.conf to use client SSO without any host services. Perhaps this should use krb5_verify_init_creds(3) instead, and thereby respect the rather obscurely named krb5.conf option verify_ap_req_nofail like the Linux pam_krb5 does, but: - verify_ap_req_nofail is default-off (i.e., vulnerable by default), - changing verify_ap_req_nofail to default-on would probably affect more things and therefore be riskier, - allow_kdc_spoof is a much clearer way to spell the idea, - this patch is a smaller semantic change and thus less risky, and - a security change with compatibility issues shouldn't have a workaround that might introduce potentially worse security issues or more compatibility issues. Perhaps this should use krb5_verify_user(3) with secure=1 instead, for simplicity, but it's not clear how to do that without first prompting for the password -- which we shouldn't do at all if we later decide we won't be able to use it anyway -- and without repeating a bunch of the logic here anyway to pick the service name. References about verify_ap_req_nofail: - mit-krb5 discussion about verify_ap_req_nofail: https://mailman.mit.edu/pipermail/krbdev/2011-January/009778.html - Oracle has the default-secure setting in their krb5 system: https://docs.oracle.com/cd/E26505_01/html/E27224/setup-148.html https://docs.oracle.com/cd/E26505_01/html/816-5174/krb5.conf-4.html#REFMAN4krb5.conf-4 https://docs.oracle.com/cd/E19253-01/816-4557/gihyu/ - Heimdal issue on verify_ap_req_nofail default: heimdal/heimdal#1129
netbsd-srcmastr
pushed a commit
to NetBSD/src
that referenced
this issue
Jul 30, 2023
lib/libpam/modules/pam_krb5/pam_krb5.c: revision 1.31 lib/libpam/modules/pam_krb5/pam_krb5.8: revision 1.13 pam_krb5: Refuse to operate without a key to verify tickets. New allow_kdc_spoof overrides this to restore previous behaviour which was vulnerable to KDC spoofing, because without a host or service key, pam_krb5 can't distinguish the legitimate KDC from a spoofed one. This way, having pam_krb5 enabled isn't dangerous even if you create an empty /etc/krb5.conf to use client SSO without any host services. Perhaps this should use krb5_verify_init_creds(3) instead, and thereby respect the rather obscurely named krb5.conf option verify_ap_req_nofail like the Linux pam_krb5 does, but: - verify_ap_req_nofail is default-off (i.e., vulnerable by default), - changing verify_ap_req_nofail to default-on would probably affect more things and therefore be riskier, - allow_kdc_spoof is a much clearer way to spell the idea, - this patch is a smaller semantic change and thus less risky, and - a security change with compatibility issues shouldn't have a workaround that might introduce potentially worse security issues or more compatibility issues. Perhaps this should use krb5_verify_user(3) with secure=1 instead, for simplicity, but it's not clear how to do that without first prompting for the password -- which we shouldn't do at all if we later decide we won't be able to use it anyway -- and without repeating a bunch of the logic here anyway to pick the service name. References about verify_ap_req_nofail: - mit-krb5 discussion about verify_ap_req_nofail: https://mailman.mit.edu/pipermail/krbdev/2011-January/009778.html - Oracle has the default-secure setting in their krb5 system: https://docs.oracle.com/cd/E26505_01/html/E27224/setup-148.html https://docs.oracle.com/cd/E26505_01/html/816-5174/krb5.conf-4.html#REFMAN4krb5.conf-4 https://docs.oracle.com/cd/E19253-01/816-4557/gihyu/ - Heimdal issue on verify_ap_req_nofail default: heimdal/heimdal#1129
ryo
pushed a commit
to IIJ-NetBSD/netbsd-src
that referenced
this issue
Aug 5, 2023
lib/libpam/modules/pam_krb5/pam_krb5.c: revision 1.31 lib/libpam/modules/pam_krb5/pam_krb5.8: revision 1.13 pam_krb5: Refuse to operate without a key to verify tickets. New allow_kdc_spoof overrides this to restore previous behaviour which was vulnerable to KDC spoofing, because without a host or service key, pam_krb5 can't distinguish the legitimate KDC from a spoofed one. This way, having pam_krb5 enabled isn't dangerous even if you create an empty /etc/krb5.conf to use client SSO without any host services. Perhaps this should use krb5_verify_init_creds(3) instead, and thereby respect the rather obscurely named krb5.conf option verify_ap_req_nofail like the Linux pam_krb5 does, but: - verify_ap_req_nofail is default-off (i.e., vulnerable by default), - changing verify_ap_req_nofail to default-on would probably affect more things and therefore be riskier, - allow_kdc_spoof is a much clearer way to spell the idea, - this patch is a smaller semantic change and thus less risky, and - a security change with compatibility issues shouldn't have a workaround that might introduce potentially worse security issues or more compatibility issues. Perhaps this should use krb5_verify_user(3) with secure=1 instead, for simplicity, but it's not clear how to do that without first prompting for the password -- which we shouldn't do at all if we later decide we won't be able to use it anyway -- and without repeating a bunch of the logic here anyway to pick the service name. References about verify_ap_req_nofail: - mit-krb5 discussion about verify_ap_req_nofail: https://mailman.mit.edu/pipermail/krbdev/2011-January/009778.html - Oracle has the default-secure setting in their krb5 system: https://docs.oracle.com/cd/E26505_01/html/E27224/setup-148.html https://docs.oracle.com/cd/E26505_01/html/816-5174/krb5.conf-4.html#REFMAN4krb5.conf-4 https://docs.oracle.com/cd/E19253-01/816-4557/gihyu/ - Heimdal issue on verify_ap_req_nofail default: heimdal/heimdal#1129
ryo
pushed a commit
to IIJ-NetBSD/netbsd-src
that referenced
this issue
Aug 5, 2023
lib/libpam/modules/pam_krb5/pam_krb5.c: revision 1.31 lib/libpam/modules/pam_krb5/pam_krb5.8: revision 1.13 pam_krb5: Refuse to operate without a key to verify tickets. New allow_kdc_spoof overrides this to restore previous behaviour which was vulnerable to KDC spoofing, because without a host or service key, pam_krb5 can't distinguish the legitimate KDC from a spoofed one. This way, having pam_krb5 enabled isn't dangerous even if you create an empty /etc/krb5.conf to use client SSO without any host services. Perhaps this should use krb5_verify_init_creds(3) instead, and thereby respect the rather obscurely named krb5.conf option verify_ap_req_nofail like the Linux pam_krb5 does, but: - verify_ap_req_nofail is default-off (i.e., vulnerable by default), - changing verify_ap_req_nofail to default-on would probably affect more things and therefore be riskier, - allow_kdc_spoof is a much clearer way to spell the idea, - this patch is a smaller semantic change and thus less risky, and - a security change with compatibility issues shouldn't have a workaround that might introduce potentially worse security issues or more compatibility issues. Perhaps this should use krb5_verify_user(3) with secure=1 instead, for simplicity, but it's not clear how to do that without first prompting for the password -- which we shouldn't do at all if we later decide we won't be able to use it anyway -- and without repeating a bunch of the logic here anyway to pick the service name. References about verify_ap_req_nofail: - mit-krb5 discussion about verify_ap_req_nofail: https://mailman.mit.edu/pipermail/krbdev/2011-January/009778.html - Oracle has the default-secure setting in their krb5 system: https://docs.oracle.com/cd/E26505_01/html/E27224/setup-148.html https://docs.oracle.com/cd/E26505_01/html/816-5174/krb5.conf-4.html#REFMAN4krb5.conf-4 https://docs.oracle.com/cd/E19253-01/816-4557/gihyu/ - Heimdal issue on verify_ap_req_nofail default: heimdal/heimdal#1129
ryo
pushed a commit
to IIJ-NetBSD/netbsd-src
that referenced
this issue
Aug 5, 2023
lib/libpam/modules/pam_krb5/pam_krb5.c: revision 1.31 lib/libpam/modules/pam_krb5/pam_krb5.8: revision 1.13 pam_krb5: Refuse to operate without a key to verify tickets. New allow_kdc_spoof overrides this to restore previous behaviour which was vulnerable to KDC spoofing, because without a host or service key, pam_krb5 can't distinguish the legitimate KDC from a spoofed one. This way, having pam_krb5 enabled isn't dangerous even if you create an empty /etc/krb5.conf to use client SSO without any host services. Perhaps this should use krb5_verify_init_creds(3) instead, and thereby respect the rather obscurely named krb5.conf option verify_ap_req_nofail like the Linux pam_krb5 does, but: - verify_ap_req_nofail is default-off (i.e., vulnerable by default), - changing verify_ap_req_nofail to default-on would probably affect more things and therefore be riskier, - allow_kdc_spoof is a much clearer way to spell the idea, - this patch is a smaller semantic change and thus less risky, and - a security change with compatibility issues shouldn't have a workaround that might introduce potentially worse security issues or more compatibility issues. Perhaps this should use krb5_verify_user(3) with secure=1 instead, for simplicity, but it's not clear how to do that without first prompting for the password -- which we shouldn't do at all if we later decide we won't be able to use it anyway -- and without repeating a bunch of the logic here anyway to pick the service name. References about verify_ap_req_nofail: - mit-krb5 discussion about verify_ap_req_nofail: https://mailman.mit.edu/pipermail/krbdev/2011-January/009778.html - Oracle has the default-secure setting in their krb5 system: https://docs.oracle.com/cd/E26505_01/html/E27224/setup-148.html https://docs.oracle.com/cd/E26505_01/html/816-5174/krb5.conf-4.html#REFMAN4krb5.conf-4 https://docs.oracle.com/cd/E19253-01/816-4557/gihyu/ - Heimdal issue on verify_ap_req_nofail default: heimdal/heimdal#1129
ryo
pushed a commit
to IIJ-NetBSD/netbsd-src
that referenced
this issue
Aug 7, 2023
lib/libpam/modules/pam_krb5/pam_krb5.c: revision 1.31 lib/libpam/modules/pam_krb5/pam_krb5.8: revision 1.13 pam_krb5: Refuse to operate without a key to verify tickets. New allow_kdc_spoof overrides this to restore previous behaviour which was vulnerable to KDC spoofing, because without a host or service key, pam_krb5 can't distinguish the legitimate KDC from a spoofed one. This way, having pam_krb5 enabled isn't dangerous even if you create an empty /etc/krb5.conf to use client SSO without any host services. Perhaps this should use krb5_verify_init_creds(3) instead, and thereby respect the rather obscurely named krb5.conf option verify_ap_req_nofail like the Linux pam_krb5 does, but: - verify_ap_req_nofail is default-off (i.e., vulnerable by default), - changing verify_ap_req_nofail to default-on would probably affect more things and therefore be riskier, - allow_kdc_spoof is a much clearer way to spell the idea, - this patch is a smaller semantic change and thus less risky, and - a security change with compatibility issues shouldn't have a workaround that might introduce potentially worse security issues or more compatibility issues. Perhaps this should use krb5_verify_user(3) with secure=1 instead, for simplicity, but it's not clear how to do that without first prompting for the password -- which we shouldn't do at all if we later decide we won't be able to use it anyway -- and without repeating a bunch of the logic here anyway to pick the service name. References about verify_ap_req_nofail: - mit-krb5 discussion about verify_ap_req_nofail: https://mailman.mit.edu/pipermail/krbdev/2011-January/009778.html - Oracle has the default-secure setting in their krb5 system: https://docs.oracle.com/cd/E26505_01/html/E27224/setup-148.html https://docs.oracle.com/cd/E26505_01/html/816-5174/krb5.conf-4.html#REFMAN4krb5.conf-4 https://docs.oracle.com/cd/E19253-01/816-4557/gihyu/ - Heimdal issue on verify_ap_req_nofail default: heimdal/heimdal#1129
netbsd-srcmastr
pushed a commit
to NetBSD/src
that referenced
this issue
Aug 20, 2023
lib/libpam/modules/pam_krb5/pam_krb5.c: revision 1.31 lib/libpam/modules/pam_krb5/pam_krb5.8: revision 1.13 pam_krb5: Refuse to operate without a key to verify tickets. New allow_kdc_spoof overrides this to restore previous behaviour which was vulnerable to KDC spoofing, because without a host or service key, pam_krb5 can't distinguish the legitimate KDC from a spoofed one. This way, having pam_krb5 enabled isn't dangerous even if you create an empty /etc/krb5.conf to use client SSO without any host services. Perhaps this should use krb5_verify_init_creds(3) instead, and thereby respect the rather obscurely named krb5.conf option verify_ap_req_nofail like the Linux pam_krb5 does, but: - verify_ap_req_nofail is default-off (i.e., vulnerable by default), - changing verify_ap_req_nofail to default-on would probably affect more things and therefore be riskier, - allow_kdc_spoof is a much clearer way to spell the idea, - this patch is a smaller semantic change and thus less risky, and - a security change with compatibility issues shouldn't have a workaround that might introduce potentially worse security issues or more compatibility issues. Perhaps this should use krb5_verify_user(3) with secure=1 instead, for simplicity, but it's not clear how to do that without first prompting for the password -- which we shouldn't do at all if we later decide we won't be able to use it anyway -- and without repeating a bunch of the logic here anyway to pick the service name. References about verify_ap_req_nofail: - mit-krb5 discussion about verify_ap_req_nofail: https://mailman.mit.edu/pipermail/krbdev/2011-January/009778.html - Oracle has the default-secure setting in their krb5 system: https://docs.oracle.com/cd/E26505_01/html/E27224/setup-148.html https://docs.oracle.com/cd/E26505_01/html/816-5174/krb5.conf-4.html#REFMAN4krb5.conf-4 https://docs.oracle.com/cd/E19253-01/816-4557/gihyu/ - Heimdal issue on verify_ap_req_nofail default: heimdal/heimdal#1129
rokuyama
pushed a commit
to IIJ-NetBSD/netbsd-src
that referenced
this issue
Oct 27, 2023
lib/libpam/modules/pam_krb5/pam_krb5.c: revision 1.31 lib/libpam/modules/pam_krb5/pam_krb5.8: revision 1.13 pam_krb5: Refuse to operate without a key to verify tickets. New allow_kdc_spoof overrides this to restore previous behaviour which was vulnerable to KDC spoofing, because without a host or service key, pam_krb5 can't distinguish the legitimate KDC from a spoofed one. This way, having pam_krb5 enabled isn't dangerous even if you create an empty /etc/krb5.conf to use client SSO without any host services. Perhaps this should use krb5_verify_init_creds(3) instead, and thereby respect the rather obscurely named krb5.conf option verify_ap_req_nofail like the Linux pam_krb5 does, but: - verify_ap_req_nofail is default-off (i.e., vulnerable by default), - changing verify_ap_req_nofail to default-on would probably affect more things and therefore be riskier, - allow_kdc_spoof is a much clearer way to spell the idea, - this patch is a smaller semantic change and thus less risky, and - a security change with compatibility issues shouldn't have a workaround that might introduce potentially worse security issues or more compatibility issues. Perhaps this should use krb5_verify_user(3) with secure=1 instead, for simplicity, but it's not clear how to do that without first prompting for the password -- which we shouldn't do at all if we later decide we won't be able to use it anyway -- and without repeating a bunch of the logic here anyway to pick the service name. References about verify_ap_req_nofail: - mit-krb5 discussion about verify_ap_req_nofail: https://mailman.mit.edu/pipermail/krbdev/2011-January/009778.html - Oracle has the default-secure setting in their krb5 system: https://docs.oracle.com/cd/E26505_01/html/E27224/setup-148.html https://docs.oracle.com/cd/E26505_01/html/816-5174/krb5.conf-4.html#REFMAN4krb5.conf-4 https://docs.oracle.com/cd/E19253-01/816-4557/gihyu/ - Heimdal issue on verify_ap_req_nofail default: heimdal/heimdal#1129
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
The default value of [libdefaults] verify_ap_req_nofail is false.
This means that applications which rely on krb5_verify_init_creds, such as pam_krb5, are vulnerable to KDC spoofing attacks by default.
I suspect this option was created for legacy mit-krb5 applications which were (foolishly) made to rely on krb5_verify_init_creds without a keytab to authenticate the KDC, because in mit-krb5, krb5_verify_init_creds is allowed to succeed when there is no keytab:
However, in Heimdal, krb5_verify_init_creds has failed immediately when there is no keytab as far back as 1997 when krb5_verify_init_creds was first filled out:
heimdal/lib/krb5/verify_init.c
Lines 104 to 109 in d5b74e0
So it appears to me this is only really relevant for legacy realms where there is a keytab that the application could use to authenticate the KDC, and the default-off option is just waiting to shoot you in the foot.
I suggest turning this option on by default so that a default (empty) /etc/krb5.conf is safe by default. Of course, legacy applications that rely on allowing a fraudulent KDC to function can still turn it off.
To Reproduce
code inspection and history spelunking
Expected behavior
krb5_verify_init_creds authenticates the KDC with its keytab, and treats spoofed KDC as authentication failure.
The text was updated successfully, but these errors were encountered: