Rich Freeman on 10 Jan 2017 05:59:19 -0800


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] Lastpass - friend of foe


On Tue, Jan 10, 2017 at 8:40 AM, Rich Kulawiec <rsk@gsp.org> wrote:
> 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?

Because they can't get the client-side passwords without compromising
the client.

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

You're suggesting a practical attack on AES.  Unless your master
password is fairly weak, that just isn't practical if it is properly
implemented.  And I have completely control over the complexity of my
master password.

Sure, if somebody cracks AES, then the scheme falls apart.  But why
stop there?  Why not just crack RSA and just sniff all the passwords
going over the network?

> Oh, sure,
> you could make it tick by forcing periodic password updates, but that's
> rather well known as a worst practice in security.

Well, it is a worst practice because it leads people to choose
easy-to-guess passwords.  However, when you're using system-generated
strong passwords that concern actually goes away.  If I did want to
rotate my passwords using lastpass I can have it generate a new set of
strong passwords and update them on my sites.  For many sites they
actually have a one-click option to generate a new password and change
it on the site, which makes it pretty easy to do.  And that does in
fact protect you if after a long delay somebody manages to crack a
vault.  So, with the use of a password vault I'd actually consider it
a best practice, and it would be better if sites actually had some
standardized protocol for interacting with password vaults so that it
could be rotated in a more automated fashion.  Of course, if you're
going to implement such a standard you might as well go to OAUTH2/etc.

Sure, the attacks you cite are potential risks of this approach.  I
don't disagree.  However, in most cases the alternative is having a
few easy-to-remember passwords that you use on all your sites, and
that is MUCH worse IMO.  I don't argue that there aren't stronger
approaches that you can take.  That Mooltipass hardware vault that was
posted earlier certainly seems like one of them.  However, they all
come at the cost of convenience, and at some point you have to decide
what you can live with.  If you don't offer somebody something they
can live with they'll just pick something you'd prefer they not pick.
And that is how you end up with passwords stuck to the side of
monitors/etc, or periodic password updates where each password is just
an incrementing number tacked on the last.

-- 
Rich
___________________________________________________________________________
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