Design flaws of password managers

Re:Design flaws of password managers by LordAtlas on Sunday January 03, 2021 @02:10AM (#25620158)

How does this method work for sites that require password changes every X days or sites that need a password change because they had a data breach?

[ Parent | on HN ]

Re:Design flaws of password managers by klyrs on Sunday January 03, 2021 @02:33AM (#25620244)

Forced rotation always results in users using this "add a bit of junk" strategy. Both this strategy, and password rotation, are weak for that reason. And the whole point is that a breach of one site may expose almost-your password for many more sites.

[ Parent | on HN ]

Re:Design flaws of password managers by dheera on Sunday January 03, 2021 @02:28AM (#25620219)

I have a stored parameter "n" that just increments the number of irritations of PBKDF2. That's a lot less to deal with than the amount of state in a traditional password manager, and I'm much less worried about losing it since it's likely I can estimate n for most sites even if I don't have it with me.

[ Parent | on HN ]

Re:Design flaws of password managers by simonebrunozzi on Sunday January 03, 2021 @05:01AM (#25620817)

You could add a date (202101 for YYY-MM) to the string (domain URL or service name) before you apply your custom "hash" function.

[ Parent | on HN ]

Re:Design flaws of password managers by LordAtlas on Wednesday January 06, 2021 @05:21AM (#25656359)

But then you would need to remember the date you changed your password for each site that needs it.

[ Parent | on HN ]