While LastPass seems to be responding well, I find their entire service exceeds my tolerance for risk.
If you don't use a password manager, you've got 99 problems, but a centralized store of your credentials for everything that's a huge target by virtue of having thousands of similarly centralized users ain't one.
Using a password manager (good idea) and then storing all your passwords on a 3rd party service of which you have no control seems inherently risky. Lastpass is a huge target, and while I believe they generally take reasonable security measures, for many the risk of compromise may be greater than an encrypted stand-alone password database. Use a password manager, please, but keep it offline and don't aggregate it with loads of other people's databases.
This is one area where I feel strongly that the conveniences of 'Cloud' are outweighed by the risks.
But this depends on the alternative. If, instead of using a password manager, uses only one (or even two or three) passwords across all the websites they frequent, then you are still, in effect, trusting numerous third parties to keep your password safe in the cloud--if any one of these sites is compromised, then your password for all (or half, or 1/3rd, etc.) is compromised along with it.
I agree with you that an offline password manager is better in theory. But the problem is that I am aware of no such service that is easy to use across numerous devices, so much so that none has struck me as a viable option given my patterns of usage. Maybe there are people out there who will accept much more inconvenience in exchange for avoiding the risk associated with a cloud-based service. But, for me, the inconvenience is simply too much.
So the choice once more, for me, becomes cloud-based password manager or no password manager at all.
(Though if you've found a good option, that will allow me to easily sync across my home desktop, laptop, office pc, tablet, and smartphone, without using the cloud, I would absolutely love to hear about it! Maybe something Bluetooth based?)
My compromise has been to come up with a password permutation scheme-- I have a long, secure, high-entropy password which I can modify/salt in a way that's predictable (to me) across sites, such that each site's credentials are unique. Obviously this works across all devices, because the scheme is in my head, and it's simple enough to remember. I don't use any password manager, because like OP, that seems like too much of an eggs-and-baskets risk for my taste.
A catastrophic compromise would require an attacker to see actual credentials (not just the hashes) across many sites, and on top of that reverse engineer my specific permutation scheme. This seems much less likely to me than a very public, high-profile centralized cloud service forgetting to cross a T somewhere and getting hacked.
Just how long have you kept this up? When I gave it a go, the sites which didn't accept the base+permutation approach stacked up quickly. Some mandated a length which was too short, some mandated a length which was too long, some required certain special characters, others forbade the same, some required multiple separate passwords (i.e. security questions or pins), some just gave me a password and didn't let me change it (i.e. a serial number), some mandated that I change the password regularly, etc, etc. Trivial modifications were an unsustainable approach. I gave up within a month when I realized that my "exceptions" file was essentially identical to a password database but with poorer compartmentalization against the most likely threats.
Besides, a simple permutation scheme does not provide good protection if the base password is leaked which is what happens half the time anyway.
I've found a length of password that covers probably 85-90 percent of my accounts, and is a good tradeoff between security and portability. Most sites accept special characters, and the ones that don't also tend to be the same ones that have retarded length restrictions. Ironically these tend to be banks, who should know better!
The small subset of sites that don't fit into the scheme get one from a pool of fixed passwords that I just remember-- so if I forget, I just try from the pool until I get in. Or reset, but that happens rarely enough that it's no big deal.
IMO there should be federal regulation about password handling which would render that problem moot: There should be no length restriction, no special character restriction, no storage in plaintext, and mandatory salting. It's arguably a national security issue.
I'd guess that a lot of those sites permit password reset via email verification, in which case a lot of your eggs are in one basket anyway. In fact, considering that SMTP is even less robust versus encryption downgrade attacks than HTTP, while also providing a patient target for DNS poisoning, this oft-forgotten basket is pretty fragile.
It'd be nice if those sites recognized that that security arrangement is massively improved with OpenID, which can piggyback on the authenticator's two factor scheme, server hardening, and whatnot.
I don't actually see the scenario where this becomes a problem.
If foo.com is compromised and their passwords decrypted, I find it unlikely that the attackers are going figure out your password scheme, go over to bar.com, and start trying out usernames that are similar to yours with the password scheme they think you have, while they are in possession of all the other foo.com passwords and usernames, some of whom probably have the exact same username and password on bar.com.
I've been using basically hunter2_foo for all unimportant passwords for some time and never had a problem.
The only thing I can think of is that if one person was on a mission to destroy my life and they managed to compromise a couple passwords to figure out the scheme, but I don't see that happening in a way that would not allow them to vacuum up a good number of passwords anyway.
He never said it was. It could be something like <Base Password><Third letter of URL><Fifth letter of slogan> etc.
Just because it's predictable to him does not mean it's predictable to all. There are ways of keeping predictability while still obscuring it from everyone else.
The goal of security is to make defeating the system too difficult to be worth it.
As such I'm not advocating security by obscurity, just security by "making the job of defeating all my accounts sufficiently involved to exclude me from a en-masse attack"; by far the biggest risk for cloud accounts.
Yeah that would be nice. I actually think browsers should have this as a feature.
But the problem is that not all websites accept long passwords. My bank wouldn't take longer than 8 characters and doesn't even have a second factor auth.
Office 365 wouldn't accept more than 16 characters. I think it was Paypal who wouldn't take more than 10.
Banks also lock the accounts after 3 failed attempts though. The short passwords are to avoid having to deal with phone calls that go something like, "Hello, I forgot my password."
> The problem with using any standard algorithm like that is that the algorithm becomes your password.
That's not true at all. The press released linked in this thread, for example, is very open that they use 100,000 rounds of PBKDF2-SHA256 to encrypt their passwords. That's a very standard algorithm. The security it provides is not its obscurity, but rather that the only way to check against an output hash is the naive brute force method which takes a long time - impractically long for attackers to try to brute force.
Nobody's saying the scheme is perfect, the claim is that it compares well to a centralized password service.
In the situation where someone uses the GP's scheme, to get multiple cleartext passwords attackers have to bypass security on multiple networks to obtain the databases and spend significant computation time reversing hashed passwords. And they have to do it in a time window in which the user hasn't changed their base password or hash.
For a centralized password service, the attacker has to do... pretty the same things, but for only one service! I'd also imagine the situation with regards to cleartext recovery might even be a little easier given that the passwords contained in that database have to be encrypted in a recoverable manner rather than merely hashed. And time window isn't an issue; recovery is going to be simultaneous.
Oh, and in first situation, the attacker still has some limited added security through whatever obscurity their site-specific hashing function brings to the table. If it's something one can do in their head, it's probably not anything that can deflect a clever/determined attacker that got to this point, but it's something.
The flaw in your scheme lies in the fact that "it's simple enough to remember" ... this would imply that if one were to target you they could likely correlate your credentials across multiple leaked PW databases and guess at your scheme. That of coarse has plenty of assumptions...
Yes, a motivated attacker could figure it out. But before they could do so, they would need my password in plaintext for multiple unrelated accounts of mine, which is hard, requires the attacker to target me specifically, and by that point what is lastpass really going to do for me anyway?
By far the most likely way my gmail account would be hacked is that foo.com's database is leaked/cracked, and the hackers spam the credentials for foo.com at hundreds of other sites and see what sticks. My scheme defeats that. And it's one point of failure versus several.
Depends how simple. Obviously "add the domain name to the end of the password" is too simple. But there are other ideas that are equally easy to remember or regenerate.
On the other hand, in the even of your untimely demise, your friends/family may end up in a bit of a pickle without access to some of your accounts. Granted, this is of less concern if you're single and without kids.
I use the same scheme but on top of it I hash it so even if site saves my password in plain text, it doesn't reveal my scheme.
I use a portion of hash for sites which have maxlength constraint otherwise full hash.
1Password can sync your passwords through WiFi [1] without going through some cloud service like Dropbox. This is the main reason I use 1Password, and it so far has met my needs. Caveat is apparently it can only sync with a single computer.
Unfortunately I can't use 1Password at work because it doesn't have a browser client, and I can't install anything I like on my computer (corporate). Sticking to Dashlane for now.
Technically, a 1Password vault contains a "1Password.html" file that essentially loads up a browser interface to your vault. This may or may not meet your needs, depending mostly on whether or not you're cool with carrying around a thumb drive with your password vault on it.
> (Though if you've found a good option, that will allow me to easily sync across my home desktop, laptop, office pc, tablet, and smartphone, without using the cloud, I would absolutely love to hear about it! Maybe something Bluetooth based?)
I don't know if it meets but your needs, but I love PasswordMaker (http://passwordmaker.org). There is no need for sync'ing, because the password is generated from a master password and configureable per-site data (by default, the web-site address; but you can add more data sources if you don't like that). It has an extension for Firefox that auto-completes passwords (configureably, remembering the master password per session so that you don't ever have to type it); there are widgets for Windows and Mac OS; there are Android and iOS apps; and, always, there is the fallback web page, which you can use anywhere that you have a web browser.
EDIT: Since I am trying to indulge in quite a bit of advocacy here, I want to make it clear that I am in no way affiliated with the project. I just stumbled on it a long time ago, and have been delighted with the way that it fills my needs.
I tried to use something similar a long time ago (SuperGenPass). The problem I had with it was that often times the password would not meet the password requirements of the site. Sometimes it's too long, sometimes there weren't enough numbers or symbols. I couldn't use it if I'd have to remember that it didn't work for particular sites (after all, the whole point is not having to remember information for each site). How does passwordmaker fair with that issue?
PasswordMaker allows you to tune the length and character set. You have to remember your site's password requirements, which is not so easy to do (usually they are only made available when you try, and fail, to change your password; in particular, only when you are logged in); but, in practice, I've found that using the default settings, and then using restricted settings (shorter length and A-Za-z0-9 character set) if that fails, works on every site I've ever used. This means that, if you are willing to endure the occasional inconvenience of having to re-enter a password, you don't have to remember anything per-site.
I hate any website that imposes a specific password format on me. I have a fondness for vaguely pronounceable passwords and I tend to use all-lower case for anything I have to enter on a mobile device.
So - reject my 16-character all-lower case password because there's no numbers or punctuation in it and you know better than me? Grrrrrrrrr.
That means one compromised password - your master password - compromises all your sites. That's the kind of risk I can't stomach.
LastPass is a huge target, yes - but (if we trust them) the data is only decrypted client side, so they have no access to it. Which means the only viable exploit is in the lastpass browser extension.
This is one of the things that scares me. If an attacker had access to dump their credential digests, could they also have modified the site to silently log credentials upon entry?
From their statements so far, it doesn't seem that happened, but it seems likely that it could.
It's a whole different cup of tea though, this compromise required the attacker(s) to go in, download data and get out. Your scenario would also require the attacker to have changed their site and go unnoticed for any significant amount of time.
If that was the case I'm sure Lastpass would've found out and reported as such.
> That means one compromised password - your master password - compromises all your sites.
I agree, but it's hard to see how it could be compromised, since it is never entered anywhere public-facing. You can, but need not, have the Firefox extension store it, but only in memory. It is also possible to use the PasswordMaker website (once loaded) without an Internet connection, in case you are worried about it leaking data.
I wrote WebPass ( http://webpass.rkeene.org/ ) for a similar reason. It's extensible with domains having password requirements and does syncing (of parameters for passwords, never actual passwords -- since they are generated). The UI is bare, but it's open source (and aside from the syncing, done entirely client side).
The sync'ing is done with a FIFO, two clients connect with the same key and they each get what the other one POST'd, no data is logged on my side.
Not only do I see this issue groby_b rasies as a huge one but I'm not sure how this is supposed to work for sites that have various password requirements. Most of them don't display the requirements on the login page (or even on the signup page sometimes) so now I need to remember that on a per-site basis which is just as bad as having to remember different passwords IMHO.
> Most of them don't display the requirements on the login page (or even on the signup page sometimes) so now I need to remember that on a per-site basis which is just as bad as having to remember different passwords IMHO.
> Maybe there are people out there who will accept much more inconvenience in exchange for avoiding the risk associated with a cloud-based service. But, for me, the inconvenience is simply too much.
Sure, it's a balance everyone has to find for themselves. As you note earlier, a cloud password manager is better than shared passwords.
I'm certainly happy to accept a bit more inconvenience than most. I only do banking on one device, and one device only. I set up per-device passwords for things like Gmail (and MFA for my primary password), I authorize mobile apps via API keys, and try to avoid services that require I use my password on multiple devices in the first place.
For the most part, devices I use frequently can access things I use frequently without passwords. For web services (like HN) I simply don't need to log in and comment that badly if I'm on an unusual device.
> So the choice once more, for me, becomes cloud-based password manager or no password manager at all.
If those are you're options, you're probably right to go with the cloud option. For many people, even a physical notebook of single-service passwords would be an improvement.
> (Though if you've found a good option, that will allow me to easily sync across my home desktop, laptop, office pc, tablet, and smartphone, without using the cloud, I would absolutely love to hear about it! Maybe something Bluetooth based?)
Not really. It's largely the magic of cloud synching that I don't like. A lot of people run standalone password managers like Keepass or 1Password and store the database in some sort of file synchronization service like Dropbox. I guess that's workable, but it's still not something I'm going to be doing.
I simply don't want a single place where all my passwords are available that isn't hardware physically under my control.
> For web services (like HN) I simply don't need to log in and comment that badly if I'm on an unusual device.
You also don't need to use one solution for every use-case. I use an online password manager (LastPass + 2FA) for relatively high-use, low-value credentials (things like web forums and online shopping sites). For higher-value credentials (investment accounts, banking, email), I use an offline password manager on trusted machines and site-specific 2FA when available.
That's been a good trade off between convenience and security for me.
Seconding multiple solutions. I use LastPass to deal with the volume of credentials required, storing most but not all sites. I memorize the most important sites (bank, primary e-mail), never putting them in a password manager.
A solution I have found that (I think) is relatively secure. Setup a keepass database that requires the use of an unlock password and key file. Sync the database to Google Drive but never sync the key file! Only store the keyfile on a locally ecrypted thumb drive or only stored locally on the devices (preferably encrypted) that you need to access keepass from.
In random time/day intervals reset your key file and keepass password.
The key to this method "working" which should be "secure" barring total ownage by a state actor or well funded individual is to never sync the key file and database to the same service. Additionally, sync up a "false flag" key file if you want some additional level of obscurity.
tl;dr:
1) Setup Keepass database to require password and key file to unlock.
2) Sync database to cloud service but never the key file.
3) In random time intervals (t=60+days) Randomly change both the password and generate a new key file for your database.
4) Keep your key file on an encrypted drive or on the device (preferably encrypted) that needs access to Keepass.
I'm concerned (but not qualified to judge) that changing your password and keyfile may not be as beneficial as it appears.
A password for an encryption key is very different to a password for a server. Once you change your password on a server, there's little harm in publishing it -- it can't be used any more. But the key is a file that may still exist (see also Wikileaks' key being published by David Leigh).
Consider: your database exists as a file. If someone is able to gain access to a copy, that copy remains valid as long as at least one password within it remains unchanged. So you need a strong key, because it's subject to offline bruteforcing. Now they get a second copy of your database, with a different password. If any of your passwords are ever published or cracked, your database is exposed. If you have to change your password regularly, it's going to be tempting to make it weaker, or to store it somewhere less securely. If you're using key files, they only need to get one of your files. It seems to me that the more key material you need to secure, the more difficult it's going to be?
The key it seems to me is by using both a master password and a key file. If a site gets cracked and they find your site specific password that won't help them determine your keepass database master password &/or generated key file that you only store offline and never sync to the cloud.
In order to open the database you need both the correct master password and the correct keyfile. If the attacker doesn't have both, they should not be able to get into the database.
I'm also no qualified to judge, but I would say it's important that in addition to rotating the password and key file used to encrypt the password database, one also rotates the all the passwords in the database regularly. This way, if someone obtains a copy of your database, they have a limited time before all the passwords in the database become useless.
I do something very similar to this, but I sync the key file to a second service (both services have 2FA logins). Keeping it off "the cloud" entirely is indeed safer from a security perspective, but think about how many copies of your key file you have, and what would have to happen to destroy all of them. If you've just got the key file locally on e.g. your laptop and maybe a smartphone, it doesn't take much more than a petty theft to cause you to lose access to every service in the database (in which situation of course you'd paradoxically want access to those services right away!).
> I simply don't want a single place where all my passwords are available that isn't hardware physically under my control.
That makes sense. What would be really nice -- and what I had in mind -- would be some sort of device where the passwords were stored to which my other devices could easily connect to to access the passwords, sort of like a wireless dongle. (Though, really, even the wireless part is negotiable. I'd be happy to plug something in as well so long as it was easy to carry with me and supported the right connectors.)
Seems like a Kickstarter campaign waiting to happen.
If you're using a reasonably trustworthy password manager with a strong master password, your biggest risk is data loss, not mass password compromise. Syncing to multiple devices and cloud backups dramatically reduce that risk while only marginally increasing that of compromise.
I'd make it so that under some very specific and hard to attack circumstances, it would be possible to make a backup of the keyring stored on a device.
Possibly only directly to another device, or maybe dump an encrypted blob to file or straight to paper (bitcoin printable wallet style).
That creates the risk of someone duplicating your thing, but you could have a 'number of times/date of most recent backup' entry obvious in your token UI, and hope people notice abnormal ones.
Protecting from a Chris Tarnovsky[1] level attacker who is probing your silicon is probably beyond the scope of a cheap consumer unit.
The best way I (IANACryptographer) can immediately think of is that your hardware dongle generates an very large internal (never leaves the device) pgp keypair. It can be allowed to back up your internal password database only when encrypted by that key, so it is literally useless except on that single physical device. You could then enroll the pubkeys of your other devices as backups onto it, and the backups would then be multisigned where any one of the associated keys has the ability to decrypt.
The password blob can then be stored jsut about anywhere, but is only decryptable and useable when embedded into the hardware device.
http://finalkey.net/ looks like a step in teh right direction, although I'd prefer to see something a bit more compact, and ideally with an independent user interface.
Something like a smartcard, with an eInk display and membrane keypad, that lets you select a credential and then provide it to the application via keyboard injection, or where possible over using challenge-response over the existing smartcard interface so the secret never leaves the card.
There was a hardware bitcoin wallet not that long ago that was further down this road, I think maybe https://www.bitcointrezor.com/ ?
The biggest problems I can see for usability are:
* what can you do when you don't have it with you? - One answer would be some printable one-time tokens such as the fallback that google auth uses, that you can carry separately.
* Can it be backed up? In theory, the keys are in there permanently, and cannot be accessed by design. Having some Super Mega Master Password that allows a full copy to be made onto a second device that can be kept elsewhere might be sufficient.
* How to handle situations where you can't use USB/NFC for it to communicate. It would need a display to give you a code/your password to enter or something.
A smaller issue would be if you're planning on fully interoperating by generating and storing individual site/system credentials on there, it would have to handle the idiocies of various systems that impose password restrictions like special chars, numbers, maximum length, etc. If it's autotyping as a fake keyboard, would also need to deal with the 'retype your password' field somehow.
All in all, I think it's totally doable, but I'm not sure I'd trust a kickstarter-like project to get the details right, given the general (maybe just perceived) level competence of kickstarted projects. Crypto Is Hard. You can't really start having a 'stretch goal $10M - hire a real cryptographer to check we didn't twiddle our nonces' or something.
A decent and well-reviewed thing like this is probably somethign I'd buy though. I've just got a Yubikey to play around with, and need to start setting that up for SSH and other keys to my more important accounts.
> Something like a smartcard, with an eInk display and membrane keypad, that lets you select a credential and then provide it to the application via keyboard injection, or where possible over using challenge-response over the existing smartcard interface so the secret never leaves the card.
Interesting. I had seen that a while back I think, but totally forgot when writing my comment just now. It's not quite 100% what I was thinking, but it's closer than anything else.
U2f (Universal 2nd Factor) is a standard to have a 2nd factor authentication usb device that uses a different secret for each website/resource. The only problem is that a version 2.0 is being discussed and you can't be sure that today's hardware will work with it.
1. Think of a 'stock phrase' that is simple for me to remember but likely to be unique, such as "angry dogs never jump for joy".
2. Write a simple program to generate 4 words at random, so it might generate "led show joke via" or "dean rock ranch ocean".
3. Generate a password by concatenating first letters of the stock phrase, the first two letters of the site name and the 4 random words. So the password for foo.com would be "adnjfjfo led show joke via" and the password for bar.com would be "adnjfjba dean rock ranch ocean".
4. As I generate the password I write down the site name and the 4 random words on a piece of paper which I keep in my wallet. So in our example I would write the following on the piece of paper: "foo.com=led show joke via; bar.com=dean rock ranch ocean"
The approach is very secure because the owner of foo.com would have no way to discover my password for bar.com. And a thief who steals my wallet will not be able to access either site.
Here's what I have found after several years of using this system:
A) After a few months of use I often find myself memorising the 4 random words for the more commonly used sites, so I often don't need to refer to the piece of paper in my wallet when logging in.
B) Many sites limit the length of the password - in these cases I generate 6 random characters in Step 3 instead of 4 random words.
C) For sites where security is not so important I skip the four random words. So my password for foo.com would be "adnjfjfo"; for bar.com it would be "adnjfjba". This avoids me having to use the paper in my wallet, but still ensures that the password for each site is distinct.
I do something similar in concept. I start off with a base password with numbers, letters, and symbols (to fit most website requirements). Then, I generate 2 random words based on the website name (based on the syllables). For instance, Gmail -> GM -> Green Mollusk or Amazon -> AM -> Aromatic Mitten. I find that it helps with remembering them naturally since the random words form a mnemonic on their own. The solution space is still large enough that knowing the rule should still be secure in real-world applications.
The difference is that a password manager must be able to decrypt a password in order for it to be used, while ideally websites only store one-way hashed passwords which if stolen aren't always useful at gaining access to other sites.
Sure, it's not free but well worth it to me in this case. I also chose not to sync using Dropbox but wifi sync and BTsync instead. So, no copy ends up in the cloud but cross-platform passwords with mostly minimal pain.
This reinforces the general problem that strings of characters are bad candidates for authentication. Users generally fit into two categories: those who will use the same password for everything, and those who won't. The latter half is the more technically savvy - which means they were likely to take the appropriate steps, read the appropriate news, and protect themselves against most classes of attacks. In short: the people who are likely the most vulnerable are also the ones that are least equipped to do anything about it.
It's a general problem with username/passwords as authentication and I think this is an interesting space for new start ups and service providers. Even with standards like FIDO, companies will want to be able to integrate it easily into their systems. The faster we can just kill passwords, the better.
>> (Though if you've found a good option, that will allow me to easily sync across my home desktop, laptop, office pc, tablet, and smartphone, without using the cloud, I would absolutely love to hear about it! Maybe something Bluetooth based?)
I'd like to chime in with another suggestion for a storage solution that I haven't seen mentioned yet: syncthing ( https://syncthing.net/ ) makes for a very good alternative to Dropbox, letting you synchronize your data across your devices but without relying on a third party service to do so. I use it to sync my KeepassX database across Linux, Windows and Android devices.
Disclaimer: I'm not affiliated in any way with syncthing, I'm just a happy user.
I use a password manager along with Syncthing[0] which seems to be the compromise you are looking for. This setup works well as long as your devices are decently often on a wifi that allows local device discovery (since syncthing needs either that or static IPs) and it also keeps your password vault offline (i.e no cloud involved).
I dunno, I did. I used the same password everywhere, and then I got a password manager and started generating passwords. Granted, it may have been the case that it was my desire for stronger passwords that drove me to use a password manager, and not vice versa. I honestly don't remember.
> But this depends on the alternative. If, instead of using a password manager, uses only one (or even two or three) passwords across all the websites they frequent, then you are still, in effect, trusting numerous third parties to keep your password safe in the cloud--if any one of these sites is compromised, then your password for all (or half, or 1/3rd, etc.) is compromised along with it.
Correct me if I'm wrong, I read this as if you're equating hacking a frequented website (and password) as hijacking a % of someone's accounts, if they use the pw there.
Random websites don't know about the other accounts you own, let alone the user ID and password them (if that same pw cracked is workable on the other service).
LastPass, or any cloud password service, has to store the relation between the service, your username for it, along with the password. That is global ownage.
Find my password on some irrelevant site, you may not even be able to link it back to me. If so, that doesn't mean you know which services I'm signed up to, let alone my user ID or password.
You understand that all the passwords/data are encrypted client side and only the encrypted blob is stored in the cloud?
This is exactly what users of Keepass et al espouse when they talk of having their 'locally encrypted database' and syncing it over dropbox etc.
You, at least, are identifying the benefit of physical security, but if we are to place any trust at all in encryption then we must accept such a scheme (local encryption, cloud sync) as being robust, if correctly implemented.
Under this scheme, obtaining the encrypted blob (which hasn't happened in this case) would still not be a cause for alarm, if we are to trust the strength of the encryption scheme.
There comes a point that you must trust 'something'. That choice for me is in encryption.
yeah... the synchronization for these services should be zero-knowledge. though maybe not the best idea, my vault should remain secure even if available publicly, right?
sync is a must have feature for many, myself included.
Encryption is as good as it's independent proofs. Even then, the proofs are only as good as the attention it gets from qualified, quality cryptographers. And again, only when used in a library that can independently prove it's algorithm and implementation is sound - open source.
You're stating truisms really. And you trust OTP (quite rightly) - ergo you trust encryption. My personal trust point is properly implemented AES-256 with a slow hashing function.
Correct. I wanted to qualify that you can't just 'trust encryption'. You must know what you're trusting, top to bottom; otherwise I would say that the trust is misplaced.
high (email, banking): Just memorize a unique password for each
medium (sites that might have my credit card info): Lastpass + salt, which I memorize and manually insert (last pass doesn't have it)
low (everything else, e.g. hacker news): I trust lastpass (w/ 2f) for these sites.
I feel that this strikes a good balance between security and convenience for me, without putting too much trust in the central store. I don't think LastPass is the weak point in this system (I am).
Super interesting to hear I'm not alone. I'm finding it works extraordinarily well, and even in situations where my Lastpass details are compromised (like today), it's not necessarily a disaster, just an inconvenience. But in return, almost complete peace of mind and liberation from passwords.
I understand your take on the problem, but one of the features of those services is that they are precisely online: I can get my passwords on my phone, tablet, desktop, laptop, abroad or at work. If my password manager is offline, it's safer, but it's also a poorer experience.
Maybe if there was a way to deploy our own personal password manager server on a dedicated server that would help the "one big target" issue.
You could roll out your own. But I personally trust the specialized team at Lastpass to monitor and look for these sorts of breaches a lot more than I trust myself.
That coupled with convenience makes it so I'm going to stick with an online password manager.
Even under a worst case scenario, I could change my major passwords fast enough with lastpass that I wouldn't be worried about loosing my online presence to anyone. It'd be a pain, but I'm confident that the LastPass team would keep me informed if that was necessary.
If you are using "off the shelf" software, then that means i have something to scan for, and a vulnerability in the software means that i have tons of targets. Most of which won't be as secure as LastPass servers might be, and probably won't update immediately.
Only if the software itself has a vulnerability - and it isn't that hard to secure a website or server that can't be accessed at all without a password, as opposed to one that needs to provide some level of service to anyone. Centralized services are also at risk of generic attacks such as convincing the hosting service/domain registrar/a company employee/etc. that you're authorized to change things, while pulling this off for many independently hosted site instances is considerably more difficult.
I think if lastpass just allowed use of an out-of-channel external file as an additional encryption layer (as keepass can) then you should be able to worry about keeping that external file secure rather than worry about what's in the cloud.
STRIP (https://www.zetetic.net/strip/) is a mature offline password manager that has been around since the late 1990s, available on iOS, Android, Windows and OSX. It uses the open-source encryption extension to SQLite, https://github.com/sqlcipher/sqlcipher, developed by the same company.
STRIP supports mobile-desktop synchronization over local wifi or remote cloud (Dropbox & Gdrive).
"When initialized with a passphrase SQLCipher derives the key data using PBKDF2 (e.g. OpenSSL’s PKCS5_PBKDF2_HMAC_SHA1 on some platforms.) Each database is initialized with a unique random salt in the first 16 bytes of the file. This salt is used for key derivation and it ensures that even if two databases are created using the same password, they will not have the same encryption key."
The LastPass database is encrypted client side too. Only the encrypted blob is synced to the cloud. Are people under the impression the passwords are stored up in the cloud in a for accessible to LastPass or otherwise unencrypted?
Only if you want to use that approach for syncing; you can also sync strip with local files, then delegating cross-device accessibility to network share, btsync, or something else.
Lastpass is a huge target, and while I believe they generally take reasonable security measures, for many the risk of compromise may be greater than an encrypted stand-alone password database.
Couldn't you frame that same basic belief around any large 'nearly-monolithic' web service, like Google, Apple, or Facebook?
I agree, passwords are a risky business (you're storing security tokens for other people for chrisakes), but the power that access to someones Facebook or Google account is pretty equivalent - people run their worlds on those services.
By the way, I happen to agree with your stance. We rely on singular entities far too much on the net.
Yes, and I'd consider Google, Apple, and Facebook huge targets with major compromise risk as well. People tell me Google security is absolutely without equal, but when it's hacked, I, for one, will be unsurprised.
With cloud services hacks, there is no "if"s, only "when"s.
>This is one area where I feel strongly that the conveniences of 'Cloud' are outweighed by the risks.
I wish this was true, in fact with at least 3 devices I use daily, having an offline password manager means I need to type in manually "difficult" passwords on 2 (n-1) devices (at least that's assuming how password managers and username-password auth work today). Call me lazy but that's already above threshold for me, I'd rather use same password everywhere than do that. Am I missing something?
I've taken to using Keepass which is an encrypted, open source offline password manager, plus Dropbox for sync between all of my devices. While I can't control the security of Dropbox, I can at least control the level of encryption on my Keepass database. Keypass lets you use a "key file" (in addition or instead of a password) which you could copy to each of your devices once, which would make for a very secure password database at-rest.
It's still not perfect but I think it's a better than LastPass or 1Password. And if you have a more secure file sync (maybe AeroFS?) you could use that instead.
You can also use another encryption mechanism like GPG or something akin to TrueCrypt's (not sure how people feel about using TrueCrypt 7.1a these days) encrypted hidden containers to hold your KeePass database on your cloud storage, which itself would also be encrypted and need a key file.
This way you have three or four separate, strong barriers of entry to your KeePass database.
Not sure I'm with you on the "responding well" part. Why blog about it before even notifying your customers? And Joe's whole post seems fairly low-key given that this was a security breach and security is their entire business.
In the comments, they indicate that they're in the process of sending out emails to users. Sending lots of emails takes some amount of time; hopefully those are arriving in inboxes now.
It's low key given the impacts as they understand them now, but seems reasonable unless there's more to it than it currently known. We'll see how things develop in the coming days - just being forthcoming days after it was detected and providing guidance on how to respond is commendable though.
I use Keepassx and the only thing I use the cloud for is to store the password file which is encrypted by either a pass phrase or key file. LastPass always struck me as a dumb thing to use.
The investigation has shown, however, that LastPass account email addresses, password reminders, server per user salts, and authentication hashes were compromised.
Great so maybe you can't attack the stolen hashes (at least not all of them) but you can use this information for social engineering which narrows things down.
In my case, you'd have to break into SpiderOak and steal the passwords.kdb file and attack the hash, but at least that would only attack my passwords; you wouldn't have a target-rich environment.
Well not exactly. A few key ones I have memorized, and a few throw away ones I rotate between for when a site requires an account and I'll never be back. But my rare use passwords for important things are physically recorded in a locked notebook. Anyone who could get access to that could've just installed a keylogger into my computer.
My problem with a password manager in general is that once your computer is compromised, all of your passwords are compromised.
People may laugh, but for many people that's a huge step up. I've tried explaining password managers to family members, and I've failed. The usability just isn't there for many classes of user, and as noted elsewhere in this thread losing access to that database is catastrophic.
Getting them to use unique passwords per-site, even if those passwords are written down and stored in their desk drawer, can be an improvement.
I'm far less worried about someone breaking into my (grand)?parent's house and stealing their password diary then compromises their bank account than I am someone popping some random site and re-using the compromised password.
Now for enterprise credentials where the (physically) stored credential and the service to which it's applicable have a closer proximity there's a higher change of this kind of meatspace targeting. But then, the 'common local admin password across all domain-joined machines' problem persists too.
I'm just not facing any meatspace targeting with my current businesses. Security is about considering reasonable defenses against potential threats. For me a virus on my computer is a far more likely threat.
I couldn't agree more with your first point, but rather than recommend a local password manager, I recommend using a password algorithm of sorts. For instance, start with a password base (8 chars), a site specific "salt" (could be the domain or something simple like "email"), and a small per-site password or a pin (4 digits). With this, you can easily remember 1 password base for all your accounts, a convention for the "salt" (you don't have to remember each salt if you have a strong convention), and the only site specific info you'll need to remember is a 4 digit pin, which should be different per site. If you can remember a really small password or 4-digit pin, this method affords you all the protection you need. I use this method, but my passwords are 20-30 chars in length, because I'm paranoid.
Whenever the cloud fails to live up to its popular reputation as bulletproof and resilient, I cannot resist suggesting that the "cloud" as it exists today distracts us from alternative forms of computing that I feel would be superior. I've routinely proposed a theoretical I call personal application omnipresence or PAO [1], wherein user applications run on a personal application server and are made available to all devices via multiple views (in a manner similar to responsive web design).
Ultimately, I think a principle failure of modern computing is our collective inability to deliver secure, private networks (what we currently call "VPNs") in a form that is easily digestible by laypeople—or even semi-technical people, for that matter. With today's mess, configuring a VPN properly takes an enormous amount of attention to detail. VPN technologies are mired with a proprietary and confusing lexicon alongside a continent-sized minefield of potential configuration errors. Of all the R&D being sunk into the cloud, I am not aware of significant R&D investment in making personal private networks that are trustworthy and easily configured.
The inability to give individuals and families omnipresent private networks makes their multi-device lifestyles an all-too-convenient target for the facile omnipresence of today's plain cloud. The plain cloud offers omnipresence while forcing acquiescence of privacy, self-control, and even knowledge of how your data and information about your actions is being used.
It also centralizes sensitive data into especially juicy targets like Lastpass.
I'm not suggesting a distributed model is definitely more secure, but a plurality of implementation approaches, perimeter firewalls, and the tiny size of individual networks makes each target less interesting.
For the time being, I use a Keepass database on a file server I operate that I reach via an IPSec VPN from all of my devices. I am not a network professional, so my IPSec VPN may have been configured improperly, but I've tried to follow best practices. What I really want—to reiterate—is a high-quality, simple (not stupid but feature-constrained) private network that our proverbial parents could use. That is always on, from all devices I use, providing a secure channel to communicate with my data on my file server anywhere.
What I have, however, is the monster that is IPSec which forces me to think about concepts like SA lifetime, IKE, Key Groups, and certificates.
I use LastPass and KeePass extensively in the setup you outline.
Why do people use LastPass? Convenience, and you aren't really gaining any extra security (except through obscurity) when using those other services.
LastPass encrypts and decrypts client side, their cloud only synchronises the encrypted blob. This is what is happening in the KeePass + Cloud service scenario too.
You gain a little security through obscurity as you'd probably need to be attacked as an individual, but mass breaches are not unknown (Dropbox for example) and at that point you have no more security than LastPass.
KeePass does have the keyfile feature, which is a particularly nice version of two-factor authentication, but LastPass offers various options - including One Time Passwords (Sesame), YubiKey and even good old fashioned offline paper grid method (arguably more secure as you have a an air-gapped authentication method).
LastPass has fantastic apps and plugins that make using unique high entropy random strings for your online accounts absolutely painless. The plugins are better and more widely available than the KeePass versions.
I've said it in another comment, but it comes down to trust in the encryption method. If the method is properly implemented then the overall scheme is secure (save for other attacks like keyloggers which both would be susceptible to).
My problem with LastPass is that the Android app is not for free (ok to me) but I find the price too high (I haven't compared with others and Spain economy is right now pure shit, just my situation).
That's the only reason I'm gradually moving to localy stored Keeper.
The use of LastPass on mobile is part of the Premium suite which is $12 a year. I'm just a normal user (though I seem to be commenting a lot on this particular story I know!) and I think it's a fair offering.
Therein lies the rub, I don't think it is - the main plugins aren't anyway. There is an open source CLI version though [1].
So it's on trust.
I trust them to have correctly implemented it based on the logic that their entire business' existence is build on the security of the platform.
If it fails, they fail, so I trust them to have put the work in and to do continual monitoring.
I have to trust KeePass too, I don't have the skill to audit it myself and the fact it's Open-Source is no guarantee of security (Heartbleed anyone?) so it's all about where your trust point/compromise lies.
A centralized store is however unavoidable if you want to share and manage passwords inside an organization.
Although I share you discomfort, looking at it rationally I prefer to trust a specialized service, who's very existence and reputation depends on it, more than the alternatives.
The other alternative for sharing is stuff like 1Password over Dropbox, which is imho the worst of both worlds.
Why is 1Password over Dropbox the "worst of both worlds"? Seems like it's potentially safer, because it's encrypted with your passphrase and also your dropbox credentials. Sure, the NSA can probably get it, but J Random Hacker can't.
I'm not even convinced the NSA can get it. There are no side-channels to exploit here (which we know the NSA is good at) and cooperation from online services won't work either. The protocols used to encrypt this are fairly simple and well-understood and we should not assume that the NSA is capable of breaking the underlying (strong) primitives.
I'm not sure how encryption will stand up when you have a set of all deltas from V1... Vn of the encrypted file.
From my admittedly small knowledge of encryption I would assume that such a set of data could be used to greatly decrease the size of the search-space for the decryption key.
There are a few people experts who post here, anyone care to comment?
1Password actually stores new data in new files, presumably to make synchronisation work properly. For example, I have approximately 600 such files in my Dropbox. Interestingly, some metadata such as the login URL and the creation date is not encrypted, so it would be possible to build a list of the sites I have stored passwords for.
Formally, if your cipher would weaken in a way that makes practical attacks possible as more data is encrypted, it would be considered broken. Furthermore, it is possible to work around this by rotating keys and just encrypting the keys in a master file. 1Password definitely uses encryption keys that are fully independent from your master password, although I don't know if they periodically use new keys for new data.
- Dropbox files at rest are encrypted using 256-bit Advanced Encryption Standard (AES).
- Dropbox uses Secure Sockets Layer (SSL)/Transport Layer Security (TLS) to protect data in transit between Dropbox apps and our servers; it's designed to create a secure tunnel protected by 128-bit or higher Advanced Encryption Standard (AES) encryption.
But don't they provide the "I forgot my password" option?? Doesn't that mean tjey have enough info to decrypt your data whenever thy want to, let you change your password, and encrypt it again with that new one???
Looks like the same problem to me in the fact that any Dropbox worker can take anything you upload.
Moreover, Condoleza Rice hired??! Wtf.
1Password only stores encrypted files in Dropbox. The encryption is done offline. Assuming the encryption is done properly, it is difficult to conceive of a way to attack it even assuming that Dropbox is compromised.
Actually that's how LastPass works (they move around an AES-256 encrypted database, and decrypt it on the client/browser).
The problem LastPass has, is that they re-use the same master password for two distinct things:
- Authenticating to login to your account.
- Encrypt your password database.
So in situations like this the loss of the authentication hash is relevant. I'd prefer to have a different password for the account than the database, but they don't offer that as far as I know.
In general I am broadly happy with LastPass's security. But it could be a little better for power users.
I find this design kind of baffling. Why go through the trouble of storing data encrypted only to snatch defeat from the jaws of victory by demanding that the client provide a secret derived from the encryption key just to log in?
I finally managed to convince my mother to start using LastPass recently; if I'd had to convince her to use two "master" passwords-- one for the encryption key, one for the service-- I'm fairly sure she'd still be using Google Contacts to store her secrets. :-\
Exactly. Why is why I entirely understand LastPass's reasoning for not doing that by default. But it would be a nice "advanced user" option (like 2F and all the other toys hidden in the account settings advanced tab).
I suppose they need to ensure that the person logging into the site, or interacting with the site via the browser extension, actually created the encrypted archive. Without a passphrase-derived authentication token (which they say is something like pbkdf2(encryption_key + passphrase), where encryption_key itself is pbkdf2(email + passphrase)), how could they ensure that?
Without that connection, if they had a totally separate secret S for web logins, anyone with S (and your 2-factor token if you have it enabled) could change your server-stored archive with no knowledge of how to decrypt it. Wouldn't that be a denial of service attack, if the next time you login to lastpass your local encrypted password archive is overwritten? You'd then have to rely on whatever other backup solution you (hopefully) use, to get an old local copy of the encrypted password archive.
That's true, but you have a local copy by default. I'm not sure what happens if the local and the server copy get radically out of sync - I don't know if it would purge your local copy or not.
See quite a few nods to 1Password in here, which is good, although I tend to favor KeePass myself, given that it's FOSS.
It also has a way better Firefox add-on than any of the others I've seen (which is my main browser), and the Android apps, if unofficial, aren't bad either [0]. Importantly, they feature the ability to either pull from a local Keepass DB or to get it from a connected Google Drive account. I've taken to using the latter to make sure my database is synced across all my devices.
At this point it works fairly well across everything I use, with the one exception that trying to keep the database synced on my Windows box requires an extension that looked a tad shady to me [1], so I opted to simply manually upload a new version each time instead.
I don't understand why 1Password's approach to the cloud - syncing via Dropbox or Google Drive - is considered that much more secure than LastPass. If anything relying on Dropbox has always seemed to me to be a huge liability
It's a matter of target payoff. Dropbox, Drive, etc. are not specific to just storing password DBs.
If my account is compromised, the attacker has one DB for their effort. If a cloud storage is compromised, the attacker has to scan through everything looking for DB files.
LastPass cloud storage is meant only for storing password DBs, so an attacker knows that within a single target lies a large trove a specific type of data.
I don't understand this. So LastPass could increase their security by including a bunch of pictures of puppies in their folder for me? Why not do it then?
I don't really buy it but I've heard the theory expressed that LastPass is more of a target because an attacker knows that a compromise could get millions of valid logins but something like Dropbox is less of a known quantity with more things to sift through.
I'm skeptical that a) our hypothetical attacker couldn't search for files to get all of those synced 1Password files or b) that such a complete compromise wouldn't turn over enough interesting personal docs to make the potential resale value quite lucrative – “They got my tax return but fortunately not my nytimes.com password!”. In either case, pure worst-case analysis isn't terribly useful without some concept of relative likelihood.
According to other comments here, your LastPass master password is used both to encrypt your stored passwords and as the password to log into their cloud storage. So someone compromising the login processing would also get the keys to the password encryption for the compromised accounts.
With 1Password and Dropbox the 1Password master password and the Dropbox login password should be unrelated. My Dropbox password, in fact, is a long password generated by 1Password's password generator. If someone gets a hold of it by compromising Dropbox, they might then get a copy of my encrypted passwords, but they get no clue to my 1Password master password.
There is some unencrypted non-password data in 1Password's data, so I'd not be happy if Dropbox were compromised, but it would not be a disaster.
Storage is unnecessary. LastPass, 1Password... every one of them has centralized storage. No one needs a central server, but a central server is the only way a "service" can sell itself.
There are multiple problems with this approach. SHA is way too fast, some site is always going to have Auth requirements that won't be the same as the ones you have set (one service wants mandatory special characters, one wants mandatory alphanumeric only), and, most importantly, you can't change the passwords unless you change the master password and remember which you used where.
Fair point. But proper key strengthening is a well-known solution to this well-known problem. The general methodology of using password-safe hash + master password + domain name is useful.
As you note, SHA isn't appropriate for this purpose. PBKDF2-strenghtened SHA, SCrypt, BCrypt and other functions should be used.
How do you generate a different password after that one's been found to be stored in plaintext and the admin resets all of the passwords?
Or, and more to the point, having generated a different password how do you remember which sites need a V1 password and which need V2?
When sites introduce silly rules around password structure, how do you make sure your passwords conform?
And even if you could guarantee you'll never hit any of these issues, shouldn't you be using a key-derivation function, rather than a hash?
I entrust my passwords to KeePass, as I trust its authors to have more of a clue than me and it lets me store arbitrary data rather than restricting me to a specific class of generated password. That file can then be replicated to enough of my devices that it's available when I need it, without a third-party having enough access to the data to be able to issue even the kind of security alert we see here.
> Or, and more to the point, having generated a different password how do you remember which sites need a V1 password and which need V2?
> When sites introduce silly rules around password structure, how do you make sure your passwords conform?
Store _THESE_ rules in a central database. Not the passwords. Those rules can be public at no cost to security to the end user.
But LastPass, KeePass, OnePass and all sorts of Password generators store the actual friggen password, instead of salts or public information (like "5th password on gmail")
I use LastPass to also store the username I used, which is handy given that:
1. Some sites use email, others use username (and sometimes your usual username is taken), and a handful of sites assign you something (eg: with an old VoIP provider I used to use, I had to log in with my customer number instead of a username)
2. I use a unique email address on every site, in the form "domain-i-am-logging-into.com@something.mydomain.com", though occasionally I have "companyname@something.mydomain.com" (eg: I use "amazon@" because I my account works with both amazon.ca and amazon.com)
LastPass remembers all this crap for me, and it also lets me keep other notes, password history, etc, as well as being quite convenient.
I've considered this before. It's a nice idea, but it suffers due to the arbitrary length and complexity requirements that many sites place on passwords.
Use lowercase hexadecimal as the "baseline" password. From there, truncate to the length requirement, and add symbols to the end to guarantee complexity requirement.
For example, "masterpass gmail.com" will md5sum to "194b52e5". If a password requires symbols, add a "!" to the end. If it requires a capitol letter, add "A" to the end. Add in the order of "number->letter->symbol". So... a site that requires numbers, capitol letters, and symbols would be:
"194b52e51A!". (The hashed password, followed by '1A!')
That does't sound simple, because I'm not going to remember the site specific password requirements for each of the 250 logins I have within my password manager.
I have a sftp account on my server for my keepass data, I can sync it from anywhere and I don't have to worry about google drive having access to my (encrypted) data. I like it.
There actually might be a difference in favor of LP. LastPass knows, semantically, what encrypted password archives are, and can monitor for statistically unusual traffic related to an attacker downloading them.
Google has no no way to know, if 10k people are storing their encrypted keepassx archives in gdrive, and if those 10k archives are accessed in rapid succession, that it's an attack. It's lost in the noise of gdrive traffic.
That blade cuts both ways: the keepassx archives would be lost in the noise of all the other files on Google Drive/Dropbox/etc. On Lastpass, you know you're getting password archives. To me: advantage KeePass.
It depends on your threat model. If you are more afraid of the government than of a random script kiddie, the vastly bigger resources of Google do not matter as your (encrypted) database is just a NSL away.
And then the NSA is trying to crack it </tinfoil hat mode>
Well if I put on my tinfoil hat, then there is no protection from the NSA. So, now I'm only trying to protect my password/identity from criminal elements, I tend to side with Google as knowing what they are doing. It doesn't mean they will also be mistake free, but it is something they deal with and have been dealing with before LastPass was even an idea.
The point of using a locally-encrypted password database like KeePass is that you don't have to trust Google (or DropBox, or Microsoft). You trust the encryption instead.
I don't use LastPass, but one thing that impresses me about their blog post: they didn't hide behind "your passwords are hashed" or something equally weaselly, but instead said exactly and clearly how passwords are hashed. Every online company should take note.
I would also appreciate more detail, but that shouldn't be their first priority.
They note that they discovered the breach on 'Friday' so I imagine they have an ongoing Incident Response right now. They may not have or be ready to share this information at this time, and that's fine. They might be working with law enforcement, further hardening systems, and continuing to confirm their findings to date to ensure they've mitigated the full impacts.
What's important now is conveying how users are impacted and what steps they should take to protect themselves; hopefully the rest comes in time.
Another pain point is the delay from Friday's discovery to Monday's disclosure. While it's better than the sometimes weeks other companies have taken, it screams of the discovery happening at 4pm on a Friday, and everybody then saying "bah fuck it, go home for the weekend, we'll work on it Monday". A security compromise like this should have been made known by Saturday at the latest, and worked on over the weekend. 3 days is a long time for leaked passwords to go unnoticed to users, regardless of the encryption scheme being used.
Yeah people really need to take the time to read this before everyone freaks out and shouts, LastPass is broken switch to <xyz> service today before you are pwnd by hackers!
It really is a great post and they always have action items for their users to protect their security. I have really enjoyed using them and will continue to do so.
I get why they can't provide details. But a close read of that incident report doesn't answer whether they even know how it happened. Did I miss something?
With these types of incidents, you want to make sure you have the facts before you make claims. They are probably doing tons of investigation to figure out what actually happened. This could be difficult depending on the level of sophistication of the attackers.
If LastPass says "Attackers took everything" when the attackers only took a few non-identifiable pieces of info; it will be a huge non-recoverable media event about attackers taking everything even if it's not true.
If LastPass say "Attackers didn't do anything" but stole a lot of sensitive info, then it makes LastPass look incompetent.
This is really a situation where they need to understand the scope of the situation before making a detailed comment.
I've been using LastPass for a while now, but I was recently evaluating the landscape for something more open. I came across Mitro[0], and it looks like it fits the bill. Unfortunately it doesn't look like it has been much maintained since its open-sourcing last year.
Mitro checked a lot of boxes on my checklist, so it's a bit disappointing that it has a smaller community.
Sandstorm made setting up a private gitlab about a 5 second thing. I'll just checkin gpg encrypted textfiles once more.
There's a bunch of shell scripts called pass http://git.zx2c4.com/password-store/ which know about gpg, git and this format of text files.
There's browser and android plugin as well. Amusingly it has basic import/export from every other password manager.
I exported from lastpass and now all I have to do is switch to a new gpg key and buy all new hardware
I just deleted, regenerated, and re-associated Google Authenticator and then altered the number of iterations from 10,000 to 10,001 (causing it to re-encrypt the database). None of this is really required but it has invalidated much of the information they could have stolen.
The thing that really bugs me about this, is the email address. I have a very low spam level on that account (sub-1 per day on average) and I want to keep it that way. Last thing I need is someone to dump this theft onto a Pirate Bay-like site and then to get spammed by everyone and the kitchen sink.
I presume he is under the assumption that the secret seed to the OTP algorithm was compromised.
By disabling / deleting your OTP token and re-adding it, you are essentially re-generating this seed.
I am not sure I understood the comment "altered the number of iterations from 10,000 to 10,001 (causing it to re-encrypt the database)", care to elaborate @Someone1234?
LastPass double-hashes (ignoring iterations) master passwords. It has a client component based on PBKDF2 and a server component (per this article) also PBKDF2 based.
If the bad guys stole the hashes after they were hashed by LastPass's servers then changing the client iterations wouldn't do a damn thing. However because LastPass have an unknown network compromise one could worry that the bad guys intercepted LastPass client-hashed passwords between the client and server.
IF they modified the LastPass client, they could have it send LastPass's servers the already client-hashed password and therefore login even without knowing someone's plain text master password.
By altering your account iterations even by 1, you've now effectively forced them to decrypt the client hash (to plain text) before they could use it to login to LastPass's servers.
Again this only helps if they intercepted network traffic on LastPass's internal network.
PS - The OTP thing is as you said.
PPS - A better idea is just to change your master password.
I've learnt a lot reading this thread. Thank you all.
But I can't believe almost everyone here, talking about security, is talking about Dropbox even as a hypothetical cloud option for storing password related info.
- Dropbox (and most of the other cloud storage services) do not encrypt your data, or if they do now as they claim, with SHA256, I'd say they must be able to decrypt it whenever they want to, as they give you the "Did you forgot your password" option to change it, so they have to be able to decrypt it and encrypt it with your new password o whatever they use to encrypt) and they hired ¡Condoleeza Rice! for their board of executives (she puts "national security" over any privacy so...), so you can count any worker at Dropbox can peep at everything you upload whenever they want to.
Of course you'll think: "I'm not a terrorist, I don't care." Well, if a worker can take a look, and you don't even know him... The threat is quite clear to me.
MEGA, for example, does encrypt everything you upload taking as seed some derivation of your password, but they DO NOT store your password, so they can't ever decrypt it for themselves. Probably no one could know even the names of the files you have uploaded unless they already had your password (of course, if you lose it, you lose all of the files uploaded!!! Beware!!!).
I rather trust MEGA than Condoleeza's (big-brother government) Dropbox, seriously.
There must be other cloud storage services which encrypt data not storing enough info to decrypt it without your input. I just stumbled upon MEGA and liked the synch app.
If you are using LastPass without 2FA (YubiKey, etc), people attacking LastPass itself is really the least of your problems. I'd be much more concerned about keyloggers grabbing your password. BeEF can pop up a LastPass phishing prompt if you just happen to load the wrong javascript file.
Using just one string of characters to protect ALL of your passwords is insane.
If you got a keyloggers on your machine, you are already fucked, and 2FA won't help you. The keyloggers can simply steal your passwords straight from the browser when LastPass fills them in.
> If you are using LastPass without 2FA (YubiKey, etc), people attacking LastPass itself is really the least of your problems. I'd be much more concerned about keyloggers grabbing your password...
Though even with 2FA, couldn't a sophisticated keylogger grab your password database after you've authenticated and downloaded it?
Don't believe me? Set up a LastPass account and turn on 2FA. Go log in on an untrusted browser. Enter your password. At the 2FA prompt screen, there is a giant red "If you lost your Google Authenticator device, click here to disable Google Authenticator authentication" link.
That's right. They give the attacker the option to disable 2FA for your account.
Slightly off-topic: am I naive to believe that my personal system of password management is just about as good something like 1Password or LastPass? Hear me out. My passwords are generated as follows:
[Low|Med|Hi] + [Key] + [Initials] + [Number]
Low|Med|High = One of three keys based on how sensitive the site is. High: banking / work / email, Low: I don't trust the site, Med: other.
Key = Random string that only I know, with the most important accounts having a unique string
Initials = Initials of site name based on domain name + TLD, with the initials moved up x letters (for example, capitalone.com -> COC -> DPD)
Number = One of three random sets of numbers I use. Sometimes I forget which number I use for each site, but I can figure it out after a few incorrect attempts.
This means a unique password for every site generated by a system that only I know with no central storage except my brain.
What is wrong with this? What would be the advantage to using 1Password / LastPass over this?
> What is wrong with this? What would be the advantage to using 1Password / LastPass over this?
My Keepass database currently has 221 entries in it. Some of these I only use once per year. There's no possible way for me to manage that without a program to help me record them.
1) Your scheme is open for all sites where you use it. So they can analyze it and get all of your passwords to other sites by this scheme.
2) You can forget "Key", especially unique keys for important sites. I have few hundreds records in KeePass, I can't imagine how to remember all of them or "keys" to them.
3) TLD can be changed and some secrets doesn't have TLD (databases, for example).
4) You can't remember all digits of all your credit cards. If you can - or you don't have credit cards or you kidding.
5) Sometimes you need to store very long license keys. No, license.txt is not the most safe way :)
Honestly the only problem with your scheme has been sharing it. If your hackernews account can be used to find other accounts of yours online, you've just made writing a custom brute force script for your accounts much easier.
I imagine you've done more than most people who customize passwords based on the site/domain name, but you should never share the specifics of your algorithm. It reduces brute force effort against you from nearly infinite to possibly hackable.
I tried a system like this for a while, but it became too complicated to keep track of. How to classify a website? What happens when one site gets hacked? Etc...
I am sure they are just overloaded with legitimate requests. But it that would be pretty interesting if the attackers first stole data from their servers and promptly followed this attack with a DDOS attack to their password reset endpoints!
Oh great, just the day before yesterday I finally jumped to LastPass (because obviously WinKee is not compatible to my new Lumia phone), using my best password (long, no real syllables, memorized).
It sounds like the password is still safe enough, but it's a very unfortunate, inconvenient timing indeed.
I've been using them for over a year. Their UI's are just the worst. They look like they've been designed by someone who has only seen Window's 95 software. Other than that, though, the service and underlying software seems pretty solid.
I have it generate passwords on new sites and any site where I need to change a password due to breaches and whatnot. I haven't known my facebook password for over 12 months. It's some random bunch of characters, and that makes me feel good.
I've enabled 2FA with Google Authenticator and it sounds like, after this breach, any new device that tries to get on my lastpass account has to be authorized over email.
They really appear to take security seriously. I guess they should since that's really their only game.
Hi, creator of StrongBox Password Safe (https://itunes.apple.com/us/app/strongbox-password-safe/id89...) here. I think LastPass have done a pretty good job of being upfront and honest about their techniques and have a handy little product. Comments above mention the centralised nature of storage and indeed it is an issue as it becomes a real bullseye for hackers. Ultimately it’s a tradeoff between convenience and security. For what it’s worth my app uses the standard Password Safe format (http://passwordsafe.sourceforge.net/), designed by Bruce Schneier. It can store your encrypted password databases locally on device or on Dropbox or Google Drive. This can be easily exported or imported. An added bonus is you can store other tidbits of information in there, notes of any kind, not just passwords. Might be useful for those of you with more stringent security in mind, or more general encryption requirements. It’s also free.
I like Bruce. I trust Bruce. However, as far as I can tell, this is a black box. There is no documentation on formats, protocols, and similar. I have no reason to trust the security of this system. The closest I could come would be to read the source code.
Sorry, should have mentioned a bit about that. The Password Safe format is public, open, and available here [1]. There's also plenty of code/libraries you can use to write your own clients, e.g. Javascript [2], Java [3], Python [4]. For what it's worth the core data encryption is done using the Twofish cipher. Hope that helps.
That both does and doesn't help. There is the format, which looks sensible. There are the protocols around it, key generation, salt generation, overall design, etc. which are not.
What actually scares me about the design is if my machine is compromised, an attacker can grab my Password Safe file (plus keylogs or whatever) and has access to all of my passwords. The design seems not very robust at a designs+protocols level.
(In contrast, right now, if a machine is compromised, it only compromises the passwords I've used from that machine).
"[W]e have found no evidence that encrypted user vault data was taken, nor that LastPass user accounts were accessed. The investigation has shown, however, that LastPass account email addresses, password reminders, server per user salts, and authentication hashes were compromised."
So, a breach of LastPass itself but not a breach of its users' non-LastPass per-website passwords/data.
*Unless it's your email password or your bank password, basically.
People have been scared into this "unique password for every site", but let's be honest: My Hacker News password getting hacked doesn't cost me anything. Why does it need a unique password with some random other forum I comment on that has no personal information on it?
The LastPass blog won't let me post any comment that mentions KeePassX, so I'm mentioning it here.
Other security folks might recommend other password managers that they prefer (e.g. 'tptacek likes 1Password). Generally, you should listen to them over me.
KeePassX is open source and NOT cloud based, so if those are two points on your mental checklist, it's worth checking out.
I understand 1Password's security design, it makes sense to me, and it has a fairly minimal attack surface. It's not perfect, but it's a sound design of a very conventional cryptosystem.
I do not understand LastPass's design; the shared authenticator/decrypting key, the website with HTML form fields for my master password, the public key crypto in Javascript with JSBN. Also, Steve Thomas doesn't like them, and found a vulnerability in their client/server protocol a while back.
I also like that in an emergency I can log in to Dropbox (one of four passwords) I remember, and open the HTML 1Password implementation (another I remember), and start to reaccess my services if all my devices get stolen.
I use 1Password for personal/family stuff. It's a much better interface and has many fewer bugs.
I manage a Last Pass Enterprise instance at work. I love/hate it. The interface is terrible and buggy. However, it's the only tool I've found to manage passwords across many users (some medium to non-technical) who need access to shared accounts within an organization. 1Password doesn't really do this, and sharing vaults over Dropbox doesn't really cut it. Despite all the bug pain, it's so much better than what we were doing before, sharing passwords via email and other embarrassing methods.
How can there really only be one company doing what LastPass Enterprise does? There must be other systems that I just can't find in my research. Any recommendations for other managed password stores for organizations?
Hi, creator of Turtl here (https://turtl.it). Turtl is not a password manager per-se, and is still fairly early in development, but is a client-side encrypted note-taking tool. It could conceivably be used as a primary password manager service.
Some features that are useful: client-side crypto (key is derived from username/password, ALL data is encrypted by default), sharing between accounts via asym encryption, open source client & server means it could be run completely in-house if required (as opposed to using the hosted service).
It doesn't have mobile apps right now, but those are coming pretty quick (either end of June or in July).
One of our slated features is a password note type, and possibly eventual integration with browsers.
Might be worth a look. Like I said, Turtl is new and is missing a lot of features you'd want in a pure-password-manager solution, but it has the potential to grow into this space a lot due to its security, sharing, and hosting features.
I'm currently a LastPass user but considering 1Password for about the same reasons...
1Password seems much more consumer friendly. Annoyed at bugs and crappier interface. 1Password also recently started integrating with some apps which I found particularly useful.
Switched to LastPass from 1Password a year or so ago because of linux support. Haven't minded. I like 1Password more (just because of the prettier UI), but LastPass is good enough.
Yes, 1password have official android and ios apps that are working quite well. It's possible to enter passwords without placing them in the phones paste buffer.
I've not used LastPass, but I chose 1Password because it has the ability to sync with my iOS device over wi-fi. So I don't need to store anything in the cloud, but still get syncing between devices.
It also has options for using DropBox or iCloud, so if you do sync in the cloud, it's still your own account on a different service. So there's not a single point-of-attack like there apparently is with LastPass.
For my personal use, I feel more comfortable with 1Password and having full control over my data.
For company wide use, LastPass Enterprise is a better fit. Centralized management is essential when dealing with larger numbers of not particularly tech savvy and security conscious users.
And despite this incident, I trust a specialized operation like Lastpass more with keeping the data secure 24/7 than myself or company IT.
Manual, so the number of accounts will determine your pain. That said, 1Password has an OSX client + Chrome extension. Day to day is much easier to use.
Does it have extensions for safari and firefox on osx at least? Yes I use all three browsers on osx, and linux too sans safari obviously. If there is a safari extension too so my iphone can form fill too that would be good. Otherwise I'll stick to my normal new passphrase every 6 months and new passwords for each site every year approach. Tonight I'll be doing the yearly update of passwords, which is a pita but not too bad with lastpass as long as I have a show to watch.
If you don't use a password manager, you've got 99 problems, but a centralized store of your credentials for everything that's a huge target by virtue of having thousands of similarly centralized users ain't one.
Using a password manager (good idea) and then storing all your passwords on a 3rd party service of which you have no control seems inherently risky. Lastpass is a huge target, and while I believe they generally take reasonable security measures, for many the risk of compromise may be greater than an encrypted stand-alone password database. Use a password manager, please, but keep it offline and don't aggregate it with loads of other people's databases.
This is one area where I feel strongly that the conveniences of 'Cloud' are outweighed by the risks.