[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-user
Subject:    Re: [gentoo-user] Re: Coming up with a password that is very strong.
From:       Rich Freeman <rich0 () gentoo ! org>
Date:       2019-02-13 21:50:25
Message-ID: CAGfcS_mFSoSzJ=MKSbVEkBdb60QM-PJP5nZpacuk3oAU7obkpQ () mail ! gmail ! com
[Download RAW message or body]

On Wed, Feb 13, 2019 at 4:34 PM Mark David Dumlao <madumlao@gmail.com> wrote:
>
> On Thu, Feb 14, 2019 at 3:18 AM Rich Freeman <rich0@gentoo.org> wrote:
> >
> > 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.
> >
>
> And on second point, you can completely automate simply running
> lesspass, whereas to automate cracking an unknown algorithm you would
> have to automate writing arbitrary programs, which is in theory
> reducible to the halting problem. TLDR: you probably can't.

Only if the algorithm the user chooses is secure.  If they pick
something equivalent to ROT13 then the attacker's problem becomes
easier.

That was my point, and users aren't necessarily good at picking secure
algorithms.

Now, if they just copy/paste one off the website, then they become
open to attacks that check the commonly used algorithms.

> > 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.
>
> In the algorithmic approach, you don't have to change your master
> password per iteration. Your algorithm can take iterations into
> account to use the same secret to generate an Nth iteration. For
> instance, using iteration numbers as part of a site-specific ID.

Of course, but my point is that if you ever DO have to change the
master password it is a mess.  Maybe you have to change it because
somebody beat it out of you with a hose.  Or maybe you accidentally
typed it into the wrong window.  Or maybe somebody stole it with a
sniffer.  Or whatever.

My point is that if it fails then it is more painful to recover.  If
you lose your master password on a database-backed solution and the
database isn't compromised, then you just change your password.  If
the database is compromised then you also have to change all your site
passwords, but as you change them the database maintains state and you
can forget the old master password the moment it is changed.

It is just a pro/con of the approach - individuals can judge the overall merits.

-- 
Rich

[prev in list] [next in list] [prev in thread] [next in thread]