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

[Mark David Dumlao]

On Thu, Feb 14, 2019 at 12:32 AM Rich Freeman <rich0@g.o> 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.
> I just stumbled on lesspass which seems to be such a tool for
> algorithmic password generation (lesspass.com).

Great tool. Good to know there are those that think alike. One
important point though is that in my "version", the user has to
completely know a secure algorithm (which is where all the security
comes from), with a managed tool this is only feasible for technical
users (or at least technical past a certain level). A version of
lesspass that allows users to view and customize the secret-generation
algorithm would be much more secure.

Or another way to put it might be: if an attacker knows that you're
using lesspass, then the only encryption they have to break is that on
your master password, so your security is only as strong as your
master password. On the other hand, if an attacker knows that I am
using an algorithm-generating technique, they need to break both the
master secret AND the algorithm, which could have vastly more entropy
than the master secret itself.

>
> 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.

In my personal practice, not a problem. In practice you always
remember the old site name for any common enough site. If you don't,
you reset the password to the new site name.

> 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).

Also not an issue for me in practice. In practice you also remembr
which sites forced you to change passwords, since they're pretty much
the only ones in that class.

> 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,

This is an issue for lesspass, because the only secret is the master
password. This is not an issue for algorithmic approaches in general,
because the algorithm is part of the secret. Every which way that you
choose to encode the intermediary steps in my example above is also
part of the secret, because none of those can be guessed from the
resulting password.

As an example, encoding "madumlao@×××××.com" as the site-specific
identifier would give a completely different password than
"gmail:madumlao" or "madumlao@gmail" or "madumlao+gmail", etc. And
that hasn't yet counted any peppering which influences intermediary
hashes.

That being said, any system that depends on a master password had
better be goddamned secure. In fact, my email account - which is a
resetting point for basically all services - is exempt from my
password algorithm and uses some ridiculously long secret. Likewise,
your keepass / lesspass secrets should probably be some insane
paranoid level secret that themselves don't come from keepass /
lesspass and their alternatives.

> 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.

Actually the generation approach is massively simpler since the
passwords themselves don't matter. If you don't like your secret, are
not sure which iteration a site is, are not sure if a site used an old
or new secret, etc, you can trigger a password reset on most services
and force it to use the current generated password. You can update any
passwords on an as-needed basis to always use the current generated
iteration.

> 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.

If you're talking about remembering the iteration counter for a
particular site, well, yes you have to store state somewhere. But
consider:
1 very strong secret + remember that these 3 or 4 sites are on iteration X

is a LOT less headspace than
4+ independent strong secrets

and I'm pretty sure most people have logins on more than 4 sites.

If literally the only state you need to know about a site is the Nth
iteration, I wouldn't mind cloud providers knowing that because they
can't do anything about that number.