Gentoo Archives: gentoo-user

From: Mark David Dumlao <madumlao@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Re: Coming up with a password that is very strong.
Date: Wed, 13 Feb 2019 21:34:59
Message-Id: CAG2nJkMbj2q2+N0auRFZkT6kLtKOw-6VHYkLPJvDfGhr=Q_hHg@mail.gmail.com
In Reply to: Re: [gentoo-user] Re: Coming up with a password that is very strong. by Rich Freeman
1 On Thu, Feb 14, 2019 at 3:18 AM Rich Freeman <rich0@g.o> wrote:
2 >
3 > On Wed, Feb 13, 2019 at 12:12 PM Mark David Dumlao <madumlao@×××××.com> wrote:
4 > >
5 > > On Thu, Feb 14, 2019 at 12:32 AM Rich Freeman <rich0@g.o> wrote:
6 > > > I just stumbled on lesspass which seems to be such a tool for
7 > > > algorithmic password generation (lesspass.com).
8 > >
9 > > Great tool. Good to know there are those that think alike. One
10 > > important point though is that in my "version", the user has to
11 > > completely know a secure algorithm (which is where all the security
12 > > comes from), with a managed tool this is only feasible for technical
13 > > users (or at least technical past a certain level). A version of
14 > > lesspass that allows users to view and customize the secret-generation
15 > > algorithm would be much more secure.
16 >
17 > Maybe. Here is the problem with this:
18 >
19 > If you just give the user a choice of one of several secure algorithms
20 > to use, then basically all you're doing is adding a few more bits of
21 > entropy to the mix. You also have to deal with vulnerabilities in any
22 > algorithm your software uses, and not just the one you picked.
23 >
24 > If you instead let the user code their own algorithm, then while this
25 > increases complexity, it also makes it easy for users to shoot
26 > themselves in the feet with an insecure algorithm.
27 >
28 > I think it would make more sense for users to focus on more robust
29 > master keys than to rely on security by obscurity with an algorithm
30 > that doesn't benefit from peer review.
31
32 Changing (or rather customizing) algorithms is not security by
33 obscurity. While it may be true that at the end of the day you're
34 adding bits of entropy, the fact is the freeform nature of design
35 implies the number of bits of entropy you are adding could very easily
36 exceed any humane password.
37
38 And on second point, you can completely automate simply running
39 lesspass, whereas to automate cracking an unknown algorithm you would
40 have to automate writing arbitrary programs, which is in theory
41 reducible to the halting problem. TLDR: you probably can't.
42
43 > While any master password should be secure, the algorithmic approaches
44 > suffer more, IMO. With something like Keepass or Lastpass you need
45 > both the database and the master password to do an attack. Now, with
46 > lastpass anybody with the master password can obtain the database from
47 > the cloud, but they're going to throttle attacks or lock the account
48 > after so many failures, and you have nothing to crack offline.
49 > Lastpass would be vulnerable to intruders stealing the database of
50 > course, which then reduces the difficulty of an attack to the same as
51 > something like Lesspass.
52
53 That's technically correct, which is why I would suggest a
54 custom-designed algorithm as opposed to something like lesspass. With
55 lesspass all the security directly goes to your secret, so the
56 pressure to make the secret ridiculous is huge. With your own
57 algorithm, the algorithm itself adds entropy between your secret and
58 the generated password.
59
60 Consider:
61 - to crack a lesspass secret, you can bruteforce the lesspass secret
62 and check if they produce a valid output. On any success, you're
63 99.99x% certain to have cracked the original lesspass secret, which
64 will instantly work on other sites.
65 - to crack an arbitrary algorithm, it is insufficient to bruteforce an
66 input secret because by itsef it does not produce an output secret.
67 You would also have to bruteforce different transformation algorithms
68 that map from the input secret to the output secret. Even if you end
69 up producing a valid password, you cannot guarantee that thje guessed
70 algorithm works on other accounts, because it might simply be a
71 collision, which is indistinguishable from the algorithm being wrong
72 due to missing some site-specific rules.
73
74 >
75 > >
76 > > > 4. I'm not sure how straightforward it would be to change
77 > > > passwords/etc. If you have 100 sites, you'd have to remember what
78 > > > password you used for what site, or change them all at once. Again,
79 > > > the stateless approach has its downsides as passwords are not
80 > > > stateless from the standpoint of the remote sites.
81 > >
82 > > Actually the generation approach is massively simpler since the
83 > > passwords themselves don't matter. If you don't like your secret, are
84 > > not sure which iteration a site is, are not sure if a site used an old
85 > > or new secret, etc, you can trigger a password reset on most services
86 > > and force it to use the current generated password. You can update any
87 > > passwords on an as-needed basis to always use the current generated
88 > > iteration.
89 >
90 > The problem with "as-needed" is that you have to remember which
91 > accounts use which master password. That sounds simple until you have
92 > 100 different accounts.
93
94 The point of an approach like this is to reduce the number of secrets,
95 ideally, to only a handful, in practice only to one. Thus you don't
96 need to remember which account uses which master password because just
97 like keepass there is just one. I have over 100 different accounts
98 (software testing) and I can say it's very simple, at least no
99 different than using something like keepass.
100
101 In the algorithmic approach, you don't have to change your master
102 password per iteration. Your algorithm can take iterations into
103 account to use the same secret to generate an Nth iteration. For
104 instance, using iteration numbers as part of a site-specific ID.

Replies