| 1 |
On Wed, Feb 13, 2019 at 4:34 PM Mark David Dumlao <madumlao@×××××.com> wrote: |
| 2 |
> |
| 3 |
> On Thu, Feb 14, 2019 at 3:18 AM Rich Freeman <rich0@g.o> wrote: |
| 4 |
> > |
| 5 |
> > If you instead let the user code their own algorithm, then while this |
| 6 |
> > increases complexity, it also makes it easy for users to shoot |
| 7 |
> > themselves in the feet with an insecure algorithm. |
| 8 |
> > |
| 9 |
> |
| 10 |
> And on second point, you can completely automate simply running |
| 11 |
> lesspass, whereas to automate cracking an unknown algorithm you would |
| 12 |
> have to automate writing arbitrary programs, which is in theory |
| 13 |
> reducible to the halting problem. TLDR: you probably can't. |
| 14 |
|
| 15 |
Only if the algorithm the user chooses is secure. If they pick |
| 16 |
something equivalent to ROT13 then the attacker's problem becomes |
| 17 |
easier. |
| 18 |
|
| 19 |
That was my point, and users aren't necessarily good at picking secure |
| 20 |
algorithms. |
| 21 |
|
| 22 |
Now, if they just copy/paste one off the website, then they become |
| 23 |
open to attacks that check the commonly used algorithms. |
| 24 |
|
| 25 |
> > The problem with "as-needed" is that you have to remember which |
| 26 |
> > accounts use which master password. That sounds simple until you have |
| 27 |
> > 100 different accounts. |
| 28 |
> |
| 29 |
> In the algorithmic approach, you don't have to change your master |
| 30 |
> password per iteration. Your algorithm can take iterations into |
| 31 |
> account to use the same secret to generate an Nth iteration. For |
| 32 |
> instance, using iteration numbers as part of a site-specific ID. |
| 33 |
|
| 34 |
Of course, but my point is that if you ever DO have to change the |
| 35 |
master password it is a mess. Maybe you have to change it because |
| 36 |
somebody beat it out of you with a hose. Or maybe you accidentally |
| 37 |
typed it into the wrong window. Or maybe somebody stole it with a |
| 38 |
sniffer. Or whatever. |
| 39 |
|
| 40 |
My point is that if it fails then it is more painful to recover. If |
| 41 |
you lose your master password on a database-backed solution and the |
| 42 |
database isn't compromised, then you just change your password. If |
| 43 |
the database is compromised then you also have to change all your site |
| 44 |
passwords, but as you change them the database maintains state and you |
| 45 |
can forget the old master password the moment it is changed. |
| 46 |
|
| 47 |
It is just a pro/con of the approach - individuals can judge the overall merits. |
| 48 |
|
| 49 |
-- |
| 50 |
Rich |
Archives