Are online password managers safe to use?
in [Cryptography]
|
Prev: Shamir's Identity Based Encryption -- consensus
Next: Explicit Encapsulation Within the Ciphertext or Implicit Markup Database.
From: Ohm on 20 Apr 2010 09:06 I have been looking into online password managers lately because I think they are much more useful than locally stored password managers such as KeePass. I have four candidates in mind: Passpack.com Lastpass.com clipperz.com Mitto.com Besides interface usability, they all claim to use AES 256 bit for encryption, and what is best, is that the encryption is performed locally on your computer before sending it encrypted over SSL to their encrypted servers. The fact that encryption is performed locally gives me some peace of mind in regards to the possibility that their servers may not be as secure as they say they are. But not being myself an expert in cryptology and not being any of those programs open source, adds to concerns. Can a password manager such as one of the listed above be trusted? I am open to alternatives, if you know of a better online password manager let me know. Thanks
From: Doc O'Leary on 22 Apr 2010 10:09 In article <op.vbh3mqgp71z69w(a)aopenxpc>, Ohm <Ohm(a)no.no> wrote: > > > >> Can a password manager such as one of the listed above be trusted? > > > > No. You need to trust the owner of the online password manager. > > > I do not see where I should trust them, the encryption is performed on my > browser > before the data is sent, even if they read it, the password is still > encrypted. How do you figure? HTTPS only secures the communication channel. It doesn't keep the server from reading the data; it wouldn't be very useful if it did. It would take a plug-in or some JavaScript for the data to be encrypted before it gets sent, and then it would just shift your trust from their server to their local code. -- My personal UDP list: 127.0.0.1, localhost, googlegroups.com, ono.com, and probably your server, too.
From: bmearns on 22 Apr 2010 11:57 On Apr 22, 10:09 am, Doc O'Leary <droleary.use...(a)2q2010.subsume.com> wrote: > In article <op.vbh3mqgp71z69w(a)aopenxpc>, Ohm <O...(a)no.no> wrote: > > > >> Can a password manager such as one of the listed above be trusted? > > > > No. You need to trust the owner of the online password manager. > > > I do not see where I should trust them, the encryption is performed on my > > browser > > before the data is sent, even if they read it, the password is still > > encrypted. > > How do you figure? HTTPS only secures the communication channel. It > doesn't keep the server from reading the data; it wouldn't be very > useful if it did. It would take a plug-in or some JavaScript for the > data to be encrypted before it gets sent, and then it would just shift > your trust from their server to their local code. > > -- > My personal UDP list: 127.0.0.1, localhost, googlegroups.com, ono.com, > and probably your server, too. If I understand the system correctly, they use JavaScript to perform symmetric encryption on your passwords locally. Only these encrypted versions are stored on their servers and you need just one strong password/key to unlock them all. In this model, it is secure against the server. The real issue is that the JavaScript can trivially capture the decrypted value or even the master key and send that to the server without the user knowing. -Brian
From: unruh on 22 Apr 2010 13:01 On 2010-04-22, bmearns <mearns.b(a)gmail.com> wrote: > On Apr 22, 10:09?am, Doc O'Leary <droleary.use...(a)2q2010.subsume.com> > wrote: >> In article <op.vbh3mqgp71z69w(a)aopenxpc>, Ohm <O...(a)no.no> wrote: >> >> > >> Can a password manager such as one of the listed above be trusted? >> >> > > No. You need to trust the owner of the online password manager. >> >> > I do not see where I should trust them, the encryption is performed on my ? >> > browser >> > before the data is sent, even if they read it, the password is still ? >> > encrypted. >> >> How do you figure? ?HTTPS only secures the communication channel. ?It >> doesn't keep the server from reading the data; it wouldn't be very >> useful if it did. ?It would take a plug-in or some JavaScript for the >> data to be encrypted before it gets sent, and then it would just shift >> your trust from their server to their local code. >> >> -- >> My personal UDP list: 127.0.0.1, localhost, googlegroups.com, ono.com, >> ? ? and probably your server, too. > > If I understand the system correctly, they use JavaScript to perform > symmetric encryption on your passwords locally. Only these encrypted And you know that is what it does how? That javascript could also encrypt your password with a key known to them, which they can then decrypt. You would know it does not do this how? > versions are stored on their servers and you need just one strong > password/key to unlock them all. In this model, it is secure against > the server. No it is not. Only to the same extent as you knew your money was safe with Bernie Madoff, because he told you so. > > The real issue is that the JavaScript can trivially capture the > decrypted value or even the master key and send that to the server > without the user knowing. Yup. > > -Brian
From: bmearns on 23 Apr 2010 09:09
On Apr 22, 1:01 pm, unruh <un...(a)wormhole.physics.ubc.ca> wrote: > On 2010-04-22, bmearns <mearn...(a)gmail.com> wrote: > > > > > On Apr 22, 10:09?am, Doc O'Leary <droleary.use...(a)2q2010.subsume.com> > > wrote: > >> In article <op.vbh3mqgp71z69w(a)aopenxpc>, Ohm <O...(a)no.no> wrote: > > >> > >> Can a password manager such as one of the listed above be trusted? > > >> > > No. You need to trust the owner of the online password manager. > > >> > I do not see where I should trust them, the encryption is performed on my ? > >> > browser > >> > before the data is sent, even if they read it, the password is still ? > >> > encrypted. > > >> How do you figure? ?HTTPS only secures the communication channel. ?It > >> doesn't keep the server from reading the data; it wouldn't be very > >> useful if it did. ?It would take a plug-in or some JavaScript for the > >> data to be encrypted before it gets sent, and then it would just shift > >> your trust from their server to their local code. > > >> -- > >> My personal UDP list: 127.0.0.1, localhost, googlegroups.com, ono.com, > >> ? ? and probably your server, too. > > > If I understand the system correctly, they use JavaScript to perform > > symmetric encryption on your passwords locally. Only these encrypted > > And you know that is what it does how? That javascript could also > encrypt your password with a key known to them, which they can then > decrypt. You would know it does not do this how? > > > versions are stored on their servers and you need just one strong > > password/key to unlock them all. In this model, it is secure against > > the server. > > No it is not. Only to the same extent as you knew your money was safe > with Bernie Madoff, because he told you so. > > > > > The real issue is that the JavaScript can trivially capture the > > decrypted value or even the master key and send that to the server > > without the user knowing. > > Yup. > > > > > -Brian See, I thought my post was short enough that people would read the whole thing before starting a response =). My point was that the model being portrayed is safe, but that there is no guarantee that this is the model they're actually using. *If* the JavaScript used your master key to encrypt the password and only sent the ciphertext, then its safe against the service spying on your passwords. But as we both pointed out, you won't know that this is what its doing unless you carefully inspect the code every time you use it, which is obviously ridiculous. A better option, if you this is the sort of service you want, is to set up a webserver for yourself, host the service on your own webserver (after inspecting the code to make sure it only does the right thing), and always make a secure connection to ensure no one can swap out their own JavaScript for yours. If you already have a webserver with a secure connection and know how to write JavaScript and server-side script, then this is a pretty reasonable option. However, this sort of service in general has significant flaws. Obviously hardware/os-level key capture is an issue anytime you're using an insecure system (like at work or in a public library, for instance), but the fact that this all goes down on the web makes it much worse. JavaScript in general was not designed and is not implemented with this sort of security in mind, and there are a number of ways a site could spy on you as you do whatever it is you need to do to get your password. For instance, it would be pretty trivial for a site to listen for all changes made to the DOM, notice when one of these services adds an input field, and then add a key listener to it to capture your master password. Just my $0.02 -Brian |