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