Re: [PLUG] Lastpass - friend of foe

[Rich Kulawiec <rsk@gsp.org>]

On Mon, Jan 09, 2017 at 08:04:40AM -0500, Rich Freeman wrote:
> On Mon, Jan 9, 2017 at 7:53 AM, Rich Kulawiec <rsk@gsp.org> wrote:
> >
> > Given that approach, how will LastPass know?
> 
> Presumably they have security monitoring.  A hacker would need to
> compromise the client side, since the vaults are encrypted on the
> server side.  

Why would an attacker bother compromising anything?  If I were the
attacker, and if I had a sufficient budget, I wouldn't.  Keep in mind
Schneier's observation on this sort of thing: amateurs hack systems.
Professionals hack people.  (And in this case, there are more people
to choose from than might be apparent at first glance.  See below.)

And yes, the vaults are encrypted on the server side, but as we've
seen over and over again, the theoretical complexity of encryption
algorithms is not reflected in the resistance of encrypted data to
brute-force efforts assisted by a priori knowledge, informed speculation,
and domain-specific experience.  Not to mention custom-built hardware
utilizing arrays of GPUs.  In other words: the stuff that we thought
should remain encrypted past the heat death of the universe showed
up on Pastebin in plaintext last week.  Again.

A related problem here is that if your adversary gets your encrypted data
and you don't know they have it (which you probably won't), they have
the luxury of taking their time.  The clock is not ticking.  Oh, sure,
you could make it tick by forcing periodic password updates, but that's
rather well known as a worst practice in security.  You'd be trying to
fix one mistake with another -- instead of correcting the original one,
which was handing over useful data (and metadata, incidentally) to an
unknown number of strangers.  Maybe they're the most honest ethical
competent careful people in the world.  Or maybe they backdoored the
encryption algorithm and have written the default password on their
whiteboard.  You have no way to tell the difference between those two
cases or any of the ones in between.  Nor can you control it in any
fashion: they don't work for you.

(I'm not picking on LastPass, by the way.  I have no idea who started
or runs the operation, nor do I care.  But I do want to point out that
even companies started by/run by/employing amazingly good people
often make amazingly bad mistakes.  I think one of the canonical
examples of this is RSA:

	Researchers Uncover RSA Phishing Attack, Hiding in Plain Sight
	https://www.wired.com/2011/08/how-rsa-got-hacked/

Multiple beginner-level errors.  Made by a company that has one job:
security.  A company founded by some of the world's best cryptographers.
Wound up compromising about 40 million devices.  Why should we believe
that any other company will do any better?)

So I'm going to go with Thomas Delrue (elsewhere in this thread):

	Sharing secrets for convenience is not a wise approach in my
	not-so-humble opinion.

And Benjamin Franklin, at an earlier date:

	Three can keep a secret, if two of them are dead.

In case you can't tell, I'm *not* a fan of outsourcing core functions,
particularly those with strong security and privacy implications.
It means that you're paying them money to increase your risk, and as I
pointed out in a message upthread, you don't know and can't know how
much you're increasing that risk.  "Take my money and my data and feel
free to gamble with both as much as you want at your sole discretion"
doesn't seem like a good move to me.

And I'm even more skeptical of outsourcing them to the cloud.  Which you
did, because -- well, look at the A, NS, and MX records for their domain.
Do you really think you should trust your passwords -- encrypted or not --
to people who lack the sysadmin 101 skills required to run their own
mail server?  Clearly, they aren't even a little bit serious about their
own operational security, so why would you trust them with *anything*?

---rsk

___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug