Practical risks of a single password for keychain AND cloud
March 23, 2013 10:14 AM Subscribe
I have a third party password manager app that I love. That app syncs to an online cloud service, so I can access all my passwords from all my devices (as well as from a web browser if necessary). In practical terms, how much worse is my risk of having info compromised by using a single password for both my password vault and the online storage service?
Assume that the reason I'm using a single password is so I can devote all my password memory to a single ungodly long password with a mix of symbols, numbers, cases, non-dictionary words, etc.
In other words, what is the practical impact of having two strong passwords (say 15 characters each) vs. one mega-long strong password (say 25-30 characters)?
Assume that the reason I'm using a single password is so I can devote all my password memory to a single ungodly long password with a mix of symbols, numbers, cases, non-dictionary words, etc.
In other words, what is the practical impact of having two strong passwords (say 15 characters each) vs. one mega-long strong password (say 25-30 characters)?
Sharing passwords increases the chance that both of the services will be cracked by a lot -- say 50% chance that once one is cracked, the cracker will find the other and automatically get in, added to the chance the other would be cracked first. I like the XKCD advice for people who can't deal with long passwords otherwise, but it's definitely safer to be more random than that. At least write the series of words in l33t style substitution.
posted by michaelh at 11:08 AM on March 23, 2013
posted by michaelh at 11:08 AM on March 23, 2013
What's the relationship between the vault and the cloud service?
If gaining access to the cloud service gives access to your unencrypted vault, then it makes sense to use the same, longer password — two passwords, even of the same quality, are much less secure because now there are two ways to access the data.
If gaining access to the cloud service just gives you access to the encrypted vault, then you want different passwords, since the real protection is the vault password.
There may be other vulnerabilities that are more problematic than the quality of your password. For example, if the encryption of the vault is not correct, then the cloud service might have access to your passwords. Such a cloud service would be an attractive target since an attacker could gain a lot of valuable data with one breach (as opposed to trying to break one person's vault).
The fact that you can access your passwords in a web browser is concerning; at the very least that means that someone might be able to imitate the web site and gain access to all your passwords (SSL has some major security problems, for example the people who issue certificates are not always trustworthy).
Sorry this is a little vague; there are a lot of factors here. Maybe it would be clearer if you told us what services you were using?
posted by danielparks at 11:39 AM on March 23, 2013 [1 favorite]
If gaining access to the cloud service gives access to your unencrypted vault, then it makes sense to use the same, longer password — two passwords, even of the same quality, are much less secure because now there are two ways to access the data.
If gaining access to the cloud service just gives you access to the encrypted vault, then you want different passwords, since the real protection is the vault password.
There may be other vulnerabilities that are more problematic than the quality of your password. For example, if the encryption of the vault is not correct, then the cloud service might have access to your passwords. Such a cloud service would be an attractive target since an attacker could gain a lot of valuable data with one breach (as opposed to trying to break one person's vault).
The fact that you can access your passwords in a web browser is concerning; at the very least that means that someone might be able to imitate the web site and gain access to all your passwords (SSL has some major security problems, for example the people who issue certificates are not always trustworthy).
Sorry this is a little vague; there are a lot of factors here. Maybe it would be clearer if you told us what services you were using?
posted by danielparks at 11:39 AM on March 23, 2013 [1 favorite]
Lastpass, right?
posted by Nonsteroidal Anti-Inflammatory Drug at 12:29 PM on March 23, 2013
posted by Nonsteroidal Anti-Inflammatory Drug at 12:29 PM on March 23, 2013
I'm also unclear about the relationship between the vault and cloud service.
posted by Dansaman at 9:25 PM on March 23, 2013
posted by Dansaman at 9:25 PM on March 23, 2013
I don't want my password safe's master password stored anywhere except (a) in my own mind (b) in my wife's password safe, which has an equally strong master password that I don't need to know because it's in my password safe. I don't want to have to worry about other people's security gaffes, so I would never re-use my master password* for some other purpose.
Which is exactly why I prefer to use KeePass and manage my password database myself, rather than relying on something inherently cloud-based. As a working sysadmin, I personally find it convenient to keep the authoritative version of my password database (a small single file) on my own ssh server; ms. flabdablet uses DropBox for hers. The server credentials are just another entry inside the password database, whose master decryption password is the only one I need to remember.
This gives rise to a chicken-and-egg problem for new devices that don't already have a copy of my password database on them: I can't log on to the server without the password database, but I can't get a copy of the password database without logging on to the server.
I deal with that by keeping a backup copy on a micro SD card that lives in the Elago Nano card reader attached to the same ring as my car keys†. Every device I've ever needed to use KeePass with has had either a USB port or a micro SD card reader, so this works well. And any time I use the keyring copy to connect to my server, I take the opportunity to update it from the server copy afterwards.
*A randomly generated mix of lowercase letters and digits so I can type it without the Shift key, 18 characters long - this comes out to 93 bits of entropy, or a search space of about 1028, which a brute-force search would take over 320 million years to scan at one trillion tries per second. So it won't ever be guessed; key loggers and shoulder surfing are my only real risks.
†Unlike every other plastic-cased device I've ever attempted to keep attached to my keyring, the Nano is small, light and robust enough not to be killed by my other pocket contents. I've also bored a 1/16" hole straight through the cap where the red dot appears in this photo, then threaded the lanyard through that on its way to the attachment point on the reader itself; the lanyard now holds the cap firmly in place while the reader is in my pocket and stops me losing it when it isn't.
posted by flabdablet at 6:52 AM on March 24, 2013 [1 favorite]
Which is exactly why I prefer to use KeePass and manage my password database myself, rather than relying on something inherently cloud-based. As a working sysadmin, I personally find it convenient to keep the authoritative version of my password database (a small single file) on my own ssh server; ms. flabdablet uses DropBox for hers. The server credentials are just another entry inside the password database, whose master decryption password is the only one I need to remember.
This gives rise to a chicken-and-egg problem for new devices that don't already have a copy of my password database on them: I can't log on to the server without the password database, but I can't get a copy of the password database without logging on to the server.
I deal with that by keeping a backup copy on a micro SD card that lives in the Elago Nano card reader attached to the same ring as my car keys†. Every device I've ever needed to use KeePass with has had either a USB port or a micro SD card reader, so this works well. And any time I use the keyring copy to connect to my server, I take the opportunity to update it from the server copy afterwards.
*A randomly generated mix of lowercase letters and digits so I can type it without the Shift key, 18 characters long - this comes out to 93 bits of entropy, or a search space of about 1028, which a brute-force search would take over 320 million years to scan at one trillion tries per second. So it won't ever be guessed; key loggers and shoulder surfing are my only real risks.
†Unlike every other plastic-cased device I've ever attempted to keep attached to my keyring, the Nano is small, light and robust enough not to be killed by my other pocket contents. I've also bored a 1/16" hole straight through the cap where the red dot appears in this photo, then threaded the lanyard through that on its way to the attachment point on the reader itself; the lanyard now holds the cap firmly in place while the reader is in my pocket and stops me losing it when it isn't.
posted by flabdablet at 6:52 AM on March 24, 2013 [1 favorite]
By the way, when I say "randomly generated" I don't mean "made by mashing the keyboard", but machine generated like this.
posted by flabdablet at 7:32 AM on March 24, 2013
posted by flabdablet at 7:32 AM on March 24, 2013
Response by poster: The services in question are Dropbox and 1Password. The 1P vault is stored (encrypted) on Dropbox. The chicken-and-egg scenario described by flabdablet is exactly the kind of problem I'm trying to work around.
posted by philosophygeek at 10:53 AM on March 24, 2013
posted by philosophygeek at 10:53 AM on March 24, 2013
I'm also a 1Password user and have thought about this. Have you ever actually needed to access your keychain from the browser? I liked the idea that it was available just in case, but in practice I've only used Dropbox to sync passwords across devices.
I'm not comfortable using the same password for my Dropbox account and 1Password decryption key: if my Dropbox password is compromised, so are all my passwords. I'd consider this a huge practical risk—the decryption key is already the weakest part of 1Password, and this weakens it even further. (Consider also that you have posted a question in the clear disclosing that your accounts use the same password. Do you use this username anywhere else?)
You're really trading off two different risks here:
1) If you use a duplicate Dropbox password, it's easy to sync devices and access your keychain from other machines, but increases the risk that an adversary can access all your passwords. (This risk increases as you re-use the password in other places).
2) If you use a strong Dropbox password, your password vault will be much safer, but if all your devices are lost or stolen and you need to access your passwords from a browser through Dropbox, you may be locked out. (This risk decreases as you sync your passwords to more devices).
You have to assess the probabilities of these events and the magnitude of their costs for yourself. In my case, even though Dropbox is pretty secure, the cost of having all my passwords compromised is very high. I'm much more likely to lose my phone or have my laptop stolen, but it's very unlikely that all the devices I use that run 1Password will be stolen at once and I won't be able to recover my keychain.
Choosing a password is a tradeoff, but there are some easy things you can do to mitigate both risks:
posted by ecmendenhall at 5:16 PM on March 24, 2013
I'm not comfortable using the same password for my Dropbox account and 1Password decryption key: if my Dropbox password is compromised, so are all my passwords. I'd consider this a huge practical risk—the decryption key is already the weakest part of 1Password, and this weakens it even further. (Consider also that you have posted a question in the clear disclosing that your accounts use the same password. Do you use this username anywhere else?)
You're really trading off two different risks here:
1) If you use a duplicate Dropbox password, it's easy to sync devices and access your keychain from other machines, but increases the risk that an adversary can access all your passwords. (This risk increases as you re-use the password in other places).
2) If you use a strong Dropbox password, your password vault will be much safer, but if all your devices are lost or stolen and you need to access your passwords from a browser through Dropbox, you may be locked out. (This risk decreases as you sync your passwords to more devices).
You have to assess the probabilities of these events and the magnitude of their costs for yourself. In my case, even though Dropbox is pretty secure, the cost of having all my passwords compromised is very high. I'm much more likely to lose my phone or have my laptop stolen, but it's very unlikely that all the devices I use that run 1Password will be stolen at once and I won't be able to recover my keychain.
Choosing a password is a tradeoff, but there are some easy things you can do to mitigate both risks:
- Enable two factor authentication for Dropbox. This is not as annoying as it appears.
- Store a backup of your 1Password keychain in a physically secure location. You can access it just like the one in your Dropbox if your devices are stolen.
- Use a very long but pronounceable Dropbox password (It's easy to generate these from the browser extension). It will be relatively painless to enter into phones and tablets to set up syncing, and still pretty secure.
- Make sure you can recover your email account in the event that your devices are stolen and you're locked out of your 1Password keychain. This might mean setting up security questions, or adding the account of someone you trust as the backup recovery option.
posted by ecmendenhall at 5:16 PM on March 24, 2013
This thread is closed to new comments.
I will give you my recommendation: Do not, ever, re-use the password you use for your password vault or manager for anything else. Ever.
I will point you to the most often referenced illustration on choosing a password. - XKCD
posted by iamabot at 10:40 AM on March 23, 2013 [1 favorite]