New in Yurbi: Two-Factor Authentication and Sign-In Security for Embedded Analytics

Short answer: The latest Yurbi release adds two-factor authentication (authenticator app, email code, or text message, plus Cisco Duo), password security with breached-password screening, account lockout, self-service password reset and one-time sign-in links, welcome emails, and new administrator controls — including service accounts so embedded dashboards and integrations keep signing in. Everything is off after an upgrade, so nothing changes until you turn it on.

When you embed analytics in your product, your customers' security teams review it as part of your product. Sign-in security is near the top of every questionnaire: Do you support multi-factor authentication? What's your password policy? Do you lock accounts after failed attempts? Is every sign-in logged? This release lets you answer yes to all of them, with controls you configure on your own servers.

What's new

• Two-factor authentication — authenticator app, email code, text message, or Cisco Duo, set to Off, Optional, or Required.
• Password security following NIST SP 800-63B, with common-password and breached-password screening.
• Account lockout after five wrong passwords, with an administrator Unlock.
• Self-service recovery — password reset and one-time sign-in links by email.
• Welcome emails that let new users set their own password.
• Administrator controls — disable accounts, force password changes, reset two-factor.
• Service accounts for the accounts your application, embedded dashboards, and scripts sign in with.
• A full audit trail of every sign-in security event.

Two-factor authentication

Users add a second step after their password using the methods you allow: an authenticator app (Google Authenticator, Microsoft Authenticator, Authy, 1Password, and others), a six-digit email code, or a six-digit text-message code. Cisco Duo push and passcode are still supported, now as one of four methods.

You choose the mode. Optional lets users turn two-factor on from My Profile. Required makes every password user enroll before they can reach their reports. Each user gets 10 single-use backup codes, can enroll more than one method with a "Try another way" option at sign-in, and can remember a browser for 30 days.

Text-message codes are sent through your own provider: connect a Twilio account, or any SMS gateway with an HTTP API, and use the built-in Send test button to confirm it works. Authenticator-app codes need nothing external at all.

Password security and account lockout

With password security on, new and changed passwords must be 12 to 128 characters, can't contain the user's login name, and are checked against a built-in list of common passwords and against known breach data. The breach check uses k-anonymity — only a short fragment of a hash leaves your server, never the password. Rejections explain what to do instead, such as using a passphrase of four or five random words.

Account lockout locks an account for five minutes after five wrong passwords. Only wrong-password attempts count, so a database or network problem never locks your customers out. Administrators can unlock an account at any time.

Self-service recovery and welcome emails

Turn on "Forgot password?" and "Email me a sign-in link," and your customers' users stop opening tickets for password resets. Links expire after 15 minutes, work once, and are rate limited, and a user with two-factor still needs their code. When you create a user, Yurbi can send a welcome email in your own words with a 72-hour link to set their own password. The emails use your product name from Server Settings, and links open on your own branded domain.

Administrator controls and service accounts

• Disable an account — active sessions end immediately and every sign-in method is refused.
• Force a password change for one user, or through the API for everyone whose password is older than a set number of days.
• Unlock accounts and reset two-factor for a user who lost their phone.
• Send a setup or reset link to any user from the user editor.
• Service accounts for anything that signs in automatically. They skip the second factor and forced password changes so integrations keep running, and every skip is recorded in the audit log.

All of these are available through the REST API too, so you can automate them as part of tenant provisioning. See the developer docs.

What this means for embedded analytics

Yurbi's embed flow signs users in through the DoLogin API with their own credentials. If you make two-factor Required for those users, the embedded sign-in stops at the enrollment or code step — and API calls made with a session that hasn't finished two-factor are refused. Before turning on Required, decide how each kind of account signs in:

• Accounts your application signs in with automatically — mark them as service accounts.
• End users who only see embedded dashboards — keep two-factor Optional, or sign them in through header-based SSO, where your own identity system enforces the second factor.
• Users who sign in to Yurbi directly — administrators, architects, and report builders are the ones to require two-factor for first.

A new External authentication method marks users who sign in only through an upstream identity system. They have no local password, so password sign-in, reset links, and sign-in links are all refused for them.

An audit trail for your customers' security reviews

Every sign-in security event is written to Yurbi's audit log, stored in your own database: password resets and changes, sign-in links, lockouts and unlocks, two-factor enrollments, challenges, and failures, backup-code use, remembered devices, disabled accounts, and service-account changes. When a customer's reviewer asks for evidence, it's already there.

Getting started

Upgrade to the latest Yurbi release. Nothing changes until you turn features on under Settings → Server Settings → Security Settings. The recommended order:

1. Make sure SMTP is configured — reset links, welcome emails, and email codes depend on it.
2. Set the Public URL to the address your users actually visit.
3. Turn on password security, account lockout, and password reset.
4. Mark integration and embedding accounts as service accounts.
5. Set two-factor to Optional and pilot it with your administrators.
6. Switch to Required for the users who should have it.

A few notes for self-hosted environments. Air-gapped servers can use everything except the breached-password check, which needs outbound internet; the common-password list still applies offline. If you run Yurbi on more than one server, lockout attempts are counted per server and clear on restart.

What's next

Native SAML 2.0 and OpenID Connect sign-in are in development. Until then, Yurbi supports session-token SSO through the DoLogin API, header-based SSO, and Windows and Active Directory sign-in. For the full security model — including Tenant Mode, App Shield, and what to tell your customers' security team — see Security & Data Handling.

Frequently asked questions

Does Yurbi support two-factor authentication?

Yes. Yurbi includes two-factor authentication by authenticator app, email code, or text message, plus Cisco Duo. Administrators set it to Off, Optional, or Required, and each user gets 10 backup codes and can remember a trusted browser for 30 days.

Are the new security features on by default after upgrading?

No. Every new sign-in security feature is off after an upgrade, so your deployment behaves exactly as before until an administrator turns each feature on under Settings → Server Settings → Security Settings.

Will two-factor authentication break embedded dashboards?

It can if you require it for the accounts your application signs in with. An embedded sign-in for a user who must enroll or enter a code stops at that step. For embedded users, use Optional mode, mark integration accounts as service accounts, or sign users in through header-based SSO.

What password rules does Yurbi enforce?

With password security on, passwords must be 12 to 128 characters, can't contain the user's login name, and are checked against a list of common passwords and against known breaches using k-anonymity, so the password itself is never sent anywhere. The rules follow NIST SP 800-63B.

Does the breached-password check work on an air-gapped server?

The breach check needs outbound internet access. If it can't reach the service, the password is allowed and a warning is written to the log; the built-in common-password list still applies. Everything else, including authenticator-app two-factor, works without internet access.

Does Yurbi support SAML or OIDC?

Native SAML 2.0 and OpenID Connect sign-in are in development. Today Yurbi supports session-token single sign-on through the DoLogin API, header-based SSO, and Windows and Active Directory sign-in.