Re: [gentoo-user] Re: Coming up with a password that is very strong.

[Rich Freeman <rich0@gentoo.org>]

On Fri, Feb 8, 2019 at 9:26 AM Kai Peter <kp@lists.openqmail.org> wrote:
>
> On 2019-02-05 22:17, Neil Bothwick wrote:
> > On Wed, 6 Feb 2019 04:28:49 +0800, Mark David Dumlao wrote:
> >
> >> My own solution is actually very simple. I have a "secret algorithm"
> >> that incorporates several secrets with a predictable way to generate a
> >> site-specific secret. The end result is a 100% predictable way to
> >> generate unique passwords for every site that are cryptographically
> >> secure from each other (you cannot derive
> >> one from the other) which can be generated by any device using the
> >> appropriate tools.
> >
> > The was a tool in portage this did this. I tried it but it did not work
> > in the real world because you couldn't set a rule for generated
> > passwords
> > that matched the requirements of all sites, for example some require a
> > non-alphanumeric character while other sites only allow alphanumerics.
> >
> > I can remember what the tools was called, although I'm pretty sure it
> > was written in Python. I'd be interested to know how you get around the
> > conflicting restrictions as this seems a good way to do things.
>
> By using an existing tool you have to live with its restrictions always.
> But who says that it could not be done? At least Mark's solution will
> (maybe) not work for everybody (yet), but he did think about an issue
> and found a way/solution which sounds really reasonable.
>

I just stumbled on lesspass which seems to be such a tool for
algorithmic password generation (lesspass.com).

Some thoughts regarding this approach:

1. Remembering the right "site name" for every site might be tricky -
sites change names/URLs and you won't have any database to search.
2.  The solution does allow incremental counters for sites, but of
course that is basically state and it looks like they have a way to
sync this somewhere, but of course that means having a cloud sync
infrastructure and that info could get compromised (doesn't include
the passwords themselves).
3.  Master password complexity probably matters more than for
something like Lastpass/KeepassX.  With traditional password managers
you need the database plus you need to crack the master password (or
get it some other way).  With a purely algorithmic approach you can
probably guess at all the parameters other than the master password,
so anybody can try to crack you without stealing any data at all,
assuming they think you're using the algorithm.  It sounds like the
hashing system they're using is considered secure, but it is obviously
only as good as the master password.
4.  I'm not sure how straightforward it would be to change
passwords/etc.  If you have 100 sites, you'd have to remember what
password you used for what site, or change them all at once.  Again,
the stateless approach has its downsides as passwords are not
stateless from the standpoint of the remote sites.

The big upside to stateless is that if you never increment passwords
then as long as you remember your master password you always have
access to your password everywhere, with nothing to back up.

If you do increment passwords, well, now you just introduced state
back in, and the "stateless" solution isn't really so.

Password incrementing is an issue for any algorithmic solution - you
need to be able to remember which password version is in use on what
site.

-- 
Rich