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

[Rich Freeman]

On Wed, Feb 13, 2019 at 12:12 PM Mark David Dumlao <madumlao@×××××.com> wrote:
>
> On Thu, Feb 14, 2019 at 12:32 AM Rich Freeman <rich0@g.o> wrote:
> > 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.

Maybe.  Here is the problem with this:

If you just give the user a choice of one of several secure algorithms
to use, then basically all you're doing is adding a few more bits of
entropy to the mix.  You also have to deal with vulnerabilities in any
algorithm your software uses, and not just the one you picked.

If you instead let the user code their own algorithm, then while this
increases complexity, it also makes it easy for users to shoot
themselves in the feet with an insecure algorithm.

I think it would make more sense for users to focus on more robust
master keys than to rely on security by obscurity with an algorithm
that doesn't benefit from peer review.


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

Sure, assuming you don't regularly change your passwords everywhere.
I'm not sure that this is as important with manager-generated
passwords, but it is a consideration.

> Likewise,
> your keepass / lesspass secrets should probably be some insane
> paranoid level secret that themselves don't come from keepass /
> lesspass and their alternatives.

While any master password should be secure, the algorithmic approaches
suffer more, IMO.  With something like Keepass or Lastpass you need
both the database and the master password to do an attack.  Now, with
lastpass anybody with the master password can obtain the database from
the cloud, but they're going to throttle attacks or lock the account
after so many failures, and you have nothing to crack offline.
Lastpass would be vulnerable to intruders stealing the database of
course, which then reduces the difficulty of an attack to the same as
something like Lesspass.

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

The problem with "as-needed" is that you have to remember which
accounts use which master password.  That sounds simple until you have
100 different accounts.  My password manager has a huge number of
accounts in it.  Granted, some of those are more disposable than
others, but keep in mind that everything from the local burger chain
to your bank has a password these days.  Either that, or it supports
something even worse like Facebook authentication.  I'm all for SSO,
but not ones locked into a single provider, and especially not
Facebook.


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

Sure, but I'm mostly comparing altorithmic password managers to
database-based ones.  In neither case are you remembering hundreds of
passwords.

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

It still means having a need to sync state, that was my main point.
If it were truly stateless you wouldn't need any kind of cloud sync at
all, and I think most would agree that would be an objective benefit.
However, here we still have the need to maintain a cloud account, have
devices that sync to it, and a need to keep that data backed up less
that cloud provider shut down without warning.

I think we're mostly on the same page though.

-- 
Rich