Generate strong passwords and UUID v4 identifiers

Prefer long, unique passwords

A password should be unique to one account and long enough to resist guessing. Random generation avoids predictable names, dates and keyboard patterns. Character variety can satisfy site rules, but length and independent randomness matter more than swapping a few letters for familiar symbols.

Generate on a device you trust, then save the result directly in a reputable password manager. Do not email a password to yourself, reuse it on another service or keep an unprotected screenshot. Where available, passkeys or phishing-resistant multifactor authentication can further reduce reliance on typed secrets.

Use browser cryptographic randomness

The W3C Web Cryptography API exposes crypto.getRandomValues as a cryptographically strong random source and crypto.randomUUID for version 4 UUIDs in secure contexts. SableApps uses these browser functions rather than Math.random, whose output is not designed for secrets.

Mapping random integers to an alphabet can introduce bias when the range does not divide evenly. The generator rejects out-of-range values before choosing a character, ensures enabled character groups appear and cryptographically shuffles the result. Even so, the browser and operating system remain part of the trust boundary.

Use UUIDs as identifiers, not credentials

A UUID v4 contains random bits plus fixed version and variant bits, normally displayed as hexadecimal groups. It is useful for identifiers in databases, files, test records and distributed systems where coordination is inconvenient. Collision probability is extremely small when generated correctly, but uniqueness is probabilistic rather than a central guarantee.

A UUID is commonly visible in URLs, logs or APIs and should not be treated as an access token. Knowing an object's UUID must not grant permission to view or modify it. Apply authentication and authorization separately, and use purpose-built high-entropy secrets for reset links or session credentials.

Handle generated values safely

Copy only the value needed and clear shared clipboards when the device or operating system retains history. Register account recovery before replacing an existing password, and test the new sign-in in a separate session. For team credentials, use an approved secrets system with audit and rotation rather than sending generated text through chat.

For UUIDs, store them in a canonical format and validate input at system boundaries. Decide whether identifiers are case-normalized and never let a client-supplied identifier overwrite an existing object silently. Random generation addresses naming collisions; it does not validate the associated record.

Worked example: create an account password and record ID

For a new account, select a 24-character password with all character groups, generate it once and save it directly into the password manager entry for the verified domain. Complete signup, enable the strongest available second factor and test recovery. If the site rejects a symbol, generate again under its documented rules instead of manually shortening a strong result into a memorable pattern.

For an application's new local record, generate a UUID and store it as the record identifier. Keep a separate authorization rule that checks the signed-in user owns or may access that record. Log creation and changes without logging passwords or reset tokens. A UUID appearing in a browser URL is normal; a password appearing there would leak through history, logs and referrer data.

Review and rotate with a reason

Change a password when compromise is suspected, the service reports a breach or policy requires rotation; unnecessary manual changes can encourage weaker patterns. Revoke exposed sessions and recovery tokens as well as changing the password. For UUID-backed records, investigate duplicates as an implementation or import failure instead of quietly generating a replacement that could hide corrupted references.

Quick checklist

• Generate a different password for every account.
• Use a trusted device and password manager.
• Enable phishing-resistant MFA or passkeys where possible.
• Treat UUIDs as public identifiers.
• Keep authorization independent from identifier secrecy.
• Test recovery before replacing a working credential.

Primary references

Standards and platform support change. Use these authoritative sources to check the current specification and migration guidance.

• W3C — Web Cryptography Level 2
• NIST — Digital Identity Guidelines