We've setup SSO using Entra AD, I get the Microsoft sign in when I choose SSO, it warned me that the app wasn't created by MS, I accepted it, entered my credentials, got my MFA prompt, entered that, the MS login proceeded as normal, then Netdata dumped me back to the sign in screen. At that point if I enter my email address again it sends me the 'we sent a email' sign in option which violates our company policies for data access. Any ideas on how we troubleshoot this?
In the end we require SSO and no other sign in option, we will need the 'we sent a email' option disabled as well.
Thanks!
This behavior is expected for existing Netdata accounts. For new accounts created through SSO, this verification step does not occur.
The purpose of this verification is to prevent account hijacking. When a Netdata account already exists and a new sign-in method is being linked, we must confirm that the user still has access to the registered email.
We are seeing this error coming from you server:
"invalid_client" "XXXXXXXXXXX15: Invalid client secret provided. Ensure the secret being sent in the request is the client secret value, not the client secret ID, for a secret added to app 'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXX2f5'.
I deleted the app registration in Entra and recreated it and now I can sign in with SSO; however, the default, insecure method of signing in with an email link still works. How do we force SSO sign-ins only? We only have 2 days left in the trial to validate and approve it so any help would be greatly appreciated. If you could extend our trial a week that would be helpful too, but I understand if that’s not policy. Thank you.
Glad to hear that SSO login now works as expected.
Unfortunately, there’s no way to disable login methods. Any Netdata account is able to login with any of the available login methods.
Could you provide, on a private message, a contact so I can forward the subject to our product team.
Thank you.
I must be blind, I don’t see where I can PM you.
I do, however, submit, that the inability to disable the insecure login method is a huge oversight on your developers’ part. We, as security folks, have tried to beat into folks’ heads for decades not to send sensitive info via email, CC #s, SSN #s, passwords, etc… but for all intents and purposes that’s exactly what Netdata does with the login link. Literally any Netdata user with a breached email account, which users often don’t catch for days or weeks, would be giving the bad actors access to their Netdata account. Honestly, it’s not a login system that should have ever been implemented. Unfortunately, I see it all too often that the “easy” method often wins out over the right method when it comes to security. It’s only a matter of time before one of your customers has their Netdata account breached. What a hacker could do with that information is debatable, but any breach, even if the data accessed is read-only, is bad for business.
We will have to discuss internally if the risk is acceptable. At the very least your system should be saying to any login that’s from a domain setup with SSO that a non-SSO login isn’t allowed even if it also still sends the email after as a additional login requirement.
I started a private chat with you, let me know if you can see it.
We will discuss internally the availability to develop the feature you are requesting (ability to disable certain login methods).
Could you please clarify how this vulnerability differs in practice from a conventional password breach? Based on the example, it appears that an attacker with access to a compromised email account could obtain full access to the associated Netdata account, much as they could with stolen credentials in a traditional authentication model.
Thank you.
Conventional password breaches are essentially exactly the same and the lack of 2FA for regular Netdata logins is just as risky. Since you cannot ensure that users have 2FA on their email accounts, simply sending a login link creates a risk that should be unacceptable to any organization. It also essentially renders the security SSO provides useless with Netdata since the insecure method still works. The second SSO is enabled, the insecure method should be disabled to ensure that users who don’t use 2FA on their emails accounts don’t facilitate access to Netdata information. I would bet a significant number of your users do not have 2FA enabled on their email accounts. I would further bet an even higher % of your users recycle passwords. Since there’s no way for you to control either, using a system that could be breached by any bot by simply submitting an email address should be seen a dangerous.
Like I said before, I see all too many vendors going this “easy” way for authentication and this trend this is a huge step backward in security. I’m going to bet you personally never send a CC, SSN, or non-temporary password via email to someone, so why would Netdata users want a login to a system that gives very detailed information about their systems when using a superior, 2FA-enforced, security SSO greatly enhances security without adding much overhead to logins?
BTW, run this by AI like Gemini. It will return:
The Core Flaw: Bypassing Your Security Policy
The vendor’s system creates a single point of failure: the user’s email account. While the passwordless email link method is a valid form of authentication on its own, it becomes a major vulnerability when a superior method—your organization’s 2FA-enforced SSO—is available but not mandatory. By allowing users to choose the less secure option, the vendor’s system:
-
Undermines 2FA: Your organization has invested in and configured a robust security system to protect sensitive data. The vendor’s bypass directly contradicts this policy and negates the security benefits of 2FA.
-
Increases Attack Surface: An attacker only needs to compromise a single, potentially unprotected, email account to gain access to detailed server metrics. They don’t need to defeat your corporate security and 2FA.
-
Enables Phishing: Attackers can create fake login links that mimic the vendor’s emails, tricking users into providing credentials or clicking malicious links.
Thank you very much for your detailed explanation.
I completely understand your perspective, and I agree that enabling 2FA provides an important additional layer of security.
That said, I believe that if users choose not to enable 2FA on their email accounts, the responsibility lies more with the users themselves rather than with the system.
Returning to the main topic, as mentioned earlier, we will discuss internally the possibility of disabling other login methods when SSO is configured.
It’s still YOUR responsibility to ensure YOUR platform is secure and what you have no is NOT secure. That you rely on a system that you admit could be insecure because it relies on users enabling security is passing the buck. In the end, WHEN one of your customers has their account breached it won’t be them who’s embarrassed in the IT world, it’ll be you.