Skip to content
shadcn.io

shadcn.io is not affiliated with official shadcn/ui

Password Policy Settings Block for React

A password policy settings panel with rules for length, number, symbol, case, a breached list, expiry and history, and a field that tests a password against them with one verdict that names the first rule it fails.

Framework
UI library

Preview

Preview width

Installation

Part of Pro
Pro unlocks the code and one-line install of every Pro button and text effect, plus the MCP for your AI editor.
Have Pro already? Sign in to open it.Opens here as soon as you're Pro.

Overview

Set the rules for passwords and try one against them before you save, with this password policy settings panel for React with Base UI. A hairline frame with a plus mark on each corner has the rules at the start: a minimum length in a Number Input, Switches for needing a number, a symbol, both cases and refusing breached passwords, and Native Selects for how long a password lives and how many old ones can't come back, with one sentence that says what the rules amount to. At the end, a field takes a password and gives one verdict, Accepted or Rejected, naming only the first rule it fails, in the order the rules are listed, or the day it would expire when it passes; five sample buttons fill the field (too short, no symbol, breached, used before, passes) so each rule is seen at work. There is no strength bar and no meter per rule. What you type is held in the page only: it is not saved, sent or listed. The action foot counts unsaved changes beside a Shine Button that saves them and an outline button that discards them. It's built from Password Input, Number Input, Switch, Native Select, Field, Button, Shine Button and Guides, with a CSS entrance only. For a password manager, an admin console or any product with a password rule to set.

FAQ

How do I set my own rules, breached list and history?

Edit SAVED for the starting rules, BREACHED for the short list of passwords refused when that rule is on (compared in lower case) and HISTORY for the sample member's earlier passwords, newest first. AS_OF is the fixed day expiry is counted from, so the date in a verdict is that day plus the chosen days. The sentence, the counts and every verdict come from pure functions over those, so nothing is typed twice. The breached list here has eight entries standing in for a real one.

Which rule is named when several fail?

Only the first, in a fixed order: length, number, symbol, upper and lower case, the breached list, then history. The order is the order of the rules on the page, and the tester says so. A rule that is switched off is skipped, and "Used before" only fails while the history is long enough to include it: choose the last 3 and the fifth-newest sample is accepted. The status line says a short version of the verdict a moment after you stop typing, never on load and never on every key.

Is the tested password kept or sent?

No. It lives in the field's state in this page, is compared in the browser with the typed lists and goes nowhere. The field is a masked Password Input with its own show button, set up as a new password so the browser doesn't fill in a saved one. In your app, never test real passwords against a policy on a server you don't control, and check breached passwords with a service that never receives the password itself, such as one that takes only a hash prefix.

What stays local, and how do I make it real?

Everything. Nothing is saved or enforced: Save keeps the rules in this page's state and says so. To make it real, store the rules with the account, run the same checks on the server when a password is set or changed, and use a real breached-password source. The expiry date and the history need the account's real password history, which only the server has.

How does it look on a phone, and is it accessible?

Below the large breakpoint the tester sits under the rules, the rules keep their rows and the action foot is pinned to the bottom of the screen. Every control is named, the verdict has a word and a dot (solid when accepted, a ring when rejected, never colour alone) and is tied to the field as its description, and the status line is a polite live region present from the start.

  • Pro

    A multi-factor policy settings panel with choice cells for who must use it, allowed methods with a keep-one guard, a grace period that prints the start day, and a coverage meter that draws the people who have not set one up.

  • Pro

    Sign-in Methods Settings

    Sign-in and security

    A sign-in methods settings panel with five methods you can switch and reorder, a drawn sign-in card that is redrawn from them, a last-method guard and a lockout rule that restates itself.

  • Pro

    Session Policy Settings

    Sign-in and security

    A session policy settings panel that leads with the sentence the settings amount to, two sliders with stops for the idle timeout and the longest session that hold each other to one rule, a device limit and an end-all-sessions dialog.

  • Pro

    Change Password Dialog

    Account and security

    A password manager's account page with its change-password dialog shown open: three password fields, a live checklist of five rules with a strength meter, a match line, and an Update button that stays quiet until every rule passes.

  • Pro

    A change-password form that says what it ends: three password fields with a line naming what the new one still needs, boxes for the other sessions, an app password and trusted devices, and a sentence that follows them.

  • Pro

    Security Checkup Settings

    Sign-in and security

    A workspace security checkup page with a score and meter, eight checks that each say Pass or Needs attention with a reason and a button that flips them, and one primary button that moves focus to the first failing check.