1 |
On Fri, Feb 8, 2019 at 9:26 AM Kai Peter <kp@×××××××××××××××.org> wrote: |
2 |
> |
3 |
> On 2019-02-05 22:17, Neil Bothwick wrote: |
4 |
> > On Wed, 6 Feb 2019 04:28:49 +0800, Mark David Dumlao wrote: |
5 |
> > |
6 |
> >> My own solution is actually very simple. I have a "secret algorithm" |
7 |
> >> that incorporates several secrets with a predictable way to generate a |
8 |
> >> site-specific secret. The end result is a 100% predictable way to |
9 |
> >> generate unique passwords for every site that are cryptographically |
10 |
> >> secure from each other (you cannot derive |
11 |
> >> one from the other) which can be generated by any device using the |
12 |
> >> appropriate tools. |
13 |
> > |
14 |
> > The was a tool in portage this did this. I tried it but it did not work |
15 |
> > in the real world because you couldn't set a rule for generated |
16 |
> > passwords |
17 |
> > that matched the requirements of all sites, for example some require a |
18 |
> > non-alphanumeric character while other sites only allow alphanumerics. |
19 |
> > |
20 |
> > I can remember what the tools was called, although I'm pretty sure it |
21 |
> > was written in Python. I'd be interested to know how you get around the |
22 |
> > conflicting restrictions as this seems a good way to do things. |
23 |
> |
24 |
> By using an existing tool you have to live with its restrictions always. |
25 |
> But who says that it could not be done? At least Mark's solution will |
26 |
> (maybe) not work for everybody (yet), but he did think about an issue |
27 |
> and found a way/solution which sounds really reasonable. |
28 |
> |
29 |
|
30 |
I just stumbled on lesspass which seems to be such a tool for |
31 |
algorithmic password generation (lesspass.com). |
32 |
|
33 |
Some thoughts regarding this approach: |
34 |
|
35 |
1. Remembering the right "site name" for every site might be tricky - |
36 |
sites change names/URLs and you won't have any database to search. |
37 |
2. The solution does allow incremental counters for sites, but of |
38 |
course that is basically state and it looks like they have a way to |
39 |
sync this somewhere, but of course that means having a cloud sync |
40 |
infrastructure and that info could get compromised (doesn't include |
41 |
the passwords themselves). |
42 |
3. Master password complexity probably matters more than for |
43 |
something like Lastpass/KeepassX. With traditional password managers |
44 |
you need the database plus you need to crack the master password (or |
45 |
get it some other way). With a purely algorithmic approach you can |
46 |
probably guess at all the parameters other than the master password, |
47 |
so anybody can try to crack you without stealing any data at all, |
48 |
assuming they think you're using the algorithm. It sounds like the |
49 |
hashing system they're using is considered secure, but it is obviously |
50 |
only as good as the master password. |
51 |
4. I'm not sure how straightforward it would be to change |
52 |
passwords/etc. If you have 100 sites, you'd have to remember what |
53 |
password you used for what site, or change them all at once. Again, |
54 |
the stateless approach has its downsides as passwords are not |
55 |
stateless from the standpoint of the remote sites. |
56 |
|
57 |
The big upside to stateless is that if you never increment passwords |
58 |
then as long as you remember your master password you always have |
59 |
access to your password everywhere, with nothing to back up. |
60 |
|
61 |
If you do increment passwords, well, now you just introduced state |
62 |
back in, and the "stateless" solution isn't really so. |
63 |
|
64 |
Password incrementing is an issue for any algorithmic solution - you |
65 |
need to be able to remember which password version is in use on what |
66 |
site. |
67 |
|
68 |
-- |
69 |
Rich |