| JP Vossen on 5 Jan 2016 10:10:48 -0800 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
| Re: [PLUG] password safe |
But *I* trigger it and manual steps are involved so the browser can't do anything. (OK, a really hacked browser/OS could re-transmit data elsewhere.)
I see the point of the more integrated tools, but I'm personally willing to put up with the few extra steps. There's that trade-off thing... I also use No-Script, which breaks a LOT of stuff, but my wife will not. Same thing.
On 01/05/2016 12:59 PM, Keith C. Perry wrote:
Ok, thanks for re-explaining. For me, browsers are too powerful today to be involved in doing security related things automagically but I can see the attraction to the system for many people. On Linux we're able to be more deliberative in implemented real multiple layers of security so the risk level isn't going to be as high as it might be elsewhere :D ----- Original Message ----- From: "Rich Freeman" <r-plug@thefreemanclan.net> To: "Philadelphia Linux User's Group Discussion List" <plug@lists.phillylinux.org> Sent: Tuesday, January 5, 2016 12:35:48 PM Subject: Re: [PLUG] password safe On Tue, Jan 5, 2016 at 11:56 AM, Keith C. Perry <kperry@daotechnologies.com> wrote:Wait... if passwords can be "skimmed" then are you saying that the communication between the the lastpass client and their servers is NOT encrypted?No. The server stores an encrypted password database. The client authenticates to the server (I'm not sure what the details of this are - it is based on your master password but I'm pretty sure the master password itself isn't sent). The server sends the client the encrypted password database over SSL or such (so, double-encrypted at that point). Then the client uses your password to decrypt the database and use it. Their server never sees the plaintext passwords. However, this all depends on the client behaving as advertised. The client is just a browser extension. I'm not sure what if any code is loaded from the server at runtime. Presumably if the servers are compromises they could just update your client to not behave in a secure fashion, such as having it transmit your master password to the server, allowing the server to decrypt your local password database. It is no different than sticking a cracked package on Debian's servers that transmits your Keepass database in plaintext to some random server when you use it. If you compromise the client and the client has access to the plaintext, then you can get the plaintext. However, if the chrome extension doesn't download any code at runtime but instead relies on the Chrome Store for updates then it would be harder to crack, since the company could keep their credentials for the chrome store offline so that the clients are not easy to compromise. I don't know exactly how they do things. For the most part my sense is that Lastpass is doing things the right way, but as with any service outside your control there is really no way to be certain. The fact is that when they have had compromises in the past they've been limited in scope which suggests that they compartmentalize their systems, which is a good way to protect against attacks. As long as the client isn't tampered with somebody can in theory have full access to all of Lastpass's servers and not be able to get your passwords, short of brute forcing your master password. I don't know how many rounds they use either, and how easy it would be to brute force as a result. But, they'd have to brute force everybody's keys independently most likely. On this front the biggest question I'd have is how they authenticate since the client only prompts for a single password which is used both to authenticate to their servers and encrypt local keys. Depending on how this is implemented it might make it easier to brute-force the password if you had all the server-side data. With proper salting/etc it might not be any easier. And on a side note as you might guess from my email address on my posts, I also use distinct email addresses for every service. Useful for filtering, and also to see who is selling addresses to who.
Later, JP -- ------------------------------------------------------------------- JP Vossen, CISSP | http://www.jpsdomain.org/ | http://bashcookbook.com/ ___________________________________________________________________________ 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