On Thu, Feb 14, 2019 at 3:18 AM Rich Freeman <[hidden email]> wrote:
> On Wed, Feb 13, 2019 at 12:12 PM Mark David Dumlao <[hidden email]> wrote:
> > On Thu, Feb 14, 2019 at 12:32 AM Rich Freeman <[hidden email]> 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.
Changing (or rather customizing) algorithms is not security by
obscurity. While it may be true that at the end of the day you're
adding bits of entropy, the fact is the freeform nature of design
implies the number of bits of entropy you are adding could very easily
exceed any humane password.
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.
> 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.
That's technically correct, which is why I would suggest a
custom-designed algorithm as opposed to something like lesspass. With
lesspass all the security directly goes to your secret, so the
pressure to make the secret ridiculous is huge. With your own
algorithm, the algorithm itself adds entropy between your secret and
the generated password.
- to crack a lesspass secret, you can bruteforce the lesspass secret
and check if they produce a valid output. On any success, you're
99.99x% certain to have cracked the original lesspass secret, which
will instantly work on other sites.
- to crack an arbitrary algorithm, it is insufficient to bruteforce an
input secret because by itsef it does not produce an output secret.
You would also have to bruteforce different transformation algorithms
that map from the input secret to the output secret. Even if you end
up producing a valid password, you cannot guarantee that thje guessed
algorithm works on other accounts, because it might simply be a
collision, which is indistinguishable from the algorithm being wrong
due to missing some site-specific rules.
> > > 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.
The point of an approach like this is to reduce the number of secrets,
ideally, to only a handful, in practice only to one. Thus you don't
need to remember which account uses which master password because just
like keepass there is just one. I have over 100 different accounts
(software testing) and I can say it's very simple, at least no
different than using something like keepass.
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.
On Wed, Feb 13, 2019 at 4:34 PM Mark David Dumlao <[hidden email]> wrote:
> On Thu, Feb 14, 2019 at 3:18 AM Rich Freeman <[hidden email]> 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
That was my point, and users aren't necessarily good at picking secure
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.
|Free forum by Nabble||Edit this page|