Hacker News new | ask | show | jobs
by hoseja 1274 days ago
Yes, with autogenerated passwords you want to be extra-sure the machine has actually remembered them and the process breaks down sometimes. This is a good (if unexpected, should be advertised) feature and I can't see security implications.
2 comments

When using 1Password this bit me once when I was signing up to my countries online finance and tax management. I managed to sign up and store the wrong password, without being able to look up the previously generated one. For extra "learned my lessons annoyance" I needed to get a new signup-code via snail mail to change the password.
That's impressive for 1Password with the history feature but I wouldn't put anything past financial systems. One of our utilities broke their bill payment system in some manner that I was able to save my new password, have it be rejected on login, and then when I followed the password reset flow and tried to use that password it was rejected because it was the same as the current password.
Password truncated at [login|reset] but not vice versa.
I’ve definitely seen that kind of before (app had max length in the HTML different than the max enforced by the validator). It’s amazing how much bad UX is tolerated in the name of security.
The security implication I see is that the password generation is deterministic. My assumption when using a password generator is that it is random.
I think in this case the behavior is that the initial generation of the password is random, but subsequently it is, shall we say, "trivially deterministic": it (intentionally) always spits out a cached copy of the initial randomly generated password.

I think security implications here would mostly apply to cases where you wanted to create multiple accounts on the same website within a short period.

Deterministic doesn't mean predictable by an attacker who can't read system memory but consider also that this could be implemented as simply as a cache: store the generated password for that hostname for n minutes and reuse it for autofill when present. There are a number of hokey things web developers do around security and this would seem like a good hedge against, for example, the ones who split the password and confirmation into separate forms or make you login to their related services because they haven't setup SSO properly.
That’s why I mentioned “depending on copy” (or more broadly “UI”).

If I’m clicking a “Generate password” button I expected a new password every time. But here it’s an autocomplete-like dropdown rather than an action. By your definition, such dropdown would show different passwords for different fields, even if the second field is a “confirm password” field.