Skip to content
Notifications
Clear all

Opinion: The 'smart' password generator suggestions are often wrong

1 Posts
1 Users
0 Reactions
1 Views
(@infra_architect_rebel_2)
Estimable Member
Joined: 4 months ago
Posts: 103
Topic starter   [#19295]

Let's talk about the password generator in 1Password Business, specifically the "smart" suggestions it makes when you're creating a new login. The premise is sound: analyze the website's requirements and generate a compliant, strong password. In practice, I've found its heuristic for determining those requirements is frequently, and sometimes catastrophically, incorrect.

The core issue is that it seems to primarily scan the webpage's text or the HTML `type` attribute, which is a notoriously unreliable method. Legacy enterprise systems, bespoke internal tools, and even some modern SaaS admin panels have validation rules that are not exposed in the front-end HTML. The generator makes its best guess, and you end up with a password that *seems* valid during creation but will be rejected silently (or not so silently) during the actual credential submission or, worse, during a future password change.

Here are a few concrete failure modes I've documented:

* **Misreading Special Character Requirements:** It will often add a special character where none is allowed, or worse, use a special character from a set the backend explicitly blacklists (like `&`, ``). I've seen it generate passwords with `@` for systems that only allow `!`, `#`, `$`, `%`.
* **Ignoring Max Length Limits:** This is the most dangerous one. It will happily generate a 64-character password for a system whose backend column is `varchar(20)`. The creation works, the vault stores it, but authentication fails mysteriously because the password is silently truncated.
* **Botching "No Similar Characters" Rules:** Some systems (looking at you, old Oracle products) have rules against 'I', 'l', '1', 'O', '0'. The generator's "smart" suggestion blithely includes them.

The result? You think you have a stored, valid credential. In reality, you've stored a liability. The first time you need to use that password—often during an urgent, time-sensitive access scenario—it fails. You then waste cycles debugging, only to find the vault itself gave you a bad value. This undermines the entire purpose of a password manager: reliable, secure credential storage.

My workflow now is to ignore the suggestion entirely. I manually click into the generator, set the parameters myself after digging into the site's actual rules (if you can find them), or worse, fall back to the dreaded "human-memorable" pattern for systems with truly byzantine requirements. This is a step backward.

For a tool built on precision and security, this "smart" feature feels like an over-engineered gimmick that introduces risk. It attempts to solve a complex parsing problem with what appears to be a naive client-side solution. I'd rather it default to a conservative, user-defined template or, at minimum, provide a prominent warning that its analysis is a guess and to verify the target system's constraints.


monoliths are not evil


   
Quote