LastPass Security Notice
blog.lastpass.com
blog.lastpass.com
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.
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.
- 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.
Source: https://www.dropbox.com/help/27
Whether or not they can break the Keepass encryption after getting your data is debatable but strikes me as "probably yes."
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?
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.
https://nakedsecurity.sophos.com/2011/06/21/dropbox-lets-any...
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.
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.
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.
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.
STRIP supports mobile-desktop synchronization over local wifi or remote cloud (Dropbox & Gdrive).
Right, but the threat model here is exactly the same! Except you're trusting Dropbox and Google instead of LastPass.
"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."
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?)
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.
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.
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.
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.
You might be interested in this:
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.
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.
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?
Anyone who knows better want to chime in?
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 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.
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.
From their statements so far, it doesn't seem that happened, but it seems likely that it could.
If that was the case I'm sure Lastpass would've found out and reported as such.
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.
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.
I think that it is not actually an issue, since the master password never goes out into the wild (see https://news.ycombinator.com/item?id=9722272).
> 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.
For me, at least, this issue is solveable in practice. See https://news.ycombinator.com/item?id=9722276 .
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.
[1] https://support.1password.com/guides/mac/sync-wi-fi.html
I sync across multiple computers just fine using BTSync. I only use Wifi sync to sync from 1 computer to my multiple iOS devices.
They don't build their own browser into which their tool is built, no.
They don't provide you a browser-only solution like LastPass, no.
But they do fully integrate with most of the common browsers.
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.
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.
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 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.
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.
Ugh, that is seriously infuriating. Of all the websites I have accounts with, that's the top of my "Shit I care about" list.
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.
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.
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.
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.
Besides, a simple permutation scheme does not provide good protection if the base password is leaked which is what happens half the time anyway.
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.
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.
you simply can't even conjure that as an alternative because that's completely out of character for you hypothetical situation.
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.
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.
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.
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.
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?
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.
This way you have three or four separate, strong barriers of entry to your KeePass database.
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.
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.
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.
With cloud services hacks, there is no "if"s, only "when"s.
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.
For everything important, there is OTP.
sync is a must have feature for many, myself included.
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.
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.
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).
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.
[1] https://blog.lastpass.com/2014/10/open-sourced-lastpass-comm...
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.
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.
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.
[0]: https://play.google.com/store/apps/details?id=keepass2androi...
https://chrome.google.com/webstore/detail/browsepass/pihdapf...
http://keepass.info/help/base/security.html#secencrypt
Hence, I am reasonably confident that even if Google were to turn over my Drive account to the NSA, they wouldn't be able to crack open the database.
See also: discussion on feasibility of brute forcing a KeePass database:
https://security.stackexchange.com/questions/8476/how-diffic...
And then the NSA is trying to crack it </tinfoil hat mode>
I've put my keepass file in the cloud for extra backup, and I know I can only rely on its cryptographic strength to keep it safe.
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.
http://angel.net/~nic/passwdlet.html
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.
You linked to the old version btw. Updated version is here: http://angel.net/~nic/passwdlet.domain.html
As you note, SHA isn't appropriate for this purpose. PBKDF2-strenghtened SHA, SCrypt, BCrypt and other functions should be used.
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.
> 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")
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.
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!')
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'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.
Sure, it's kind of a pain (I can only sync on my home network) but worth the trade off to me. I mean how often do you have to sync passwords?
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.
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'm reading this as an embarrassing security lapse in general security, so they misdirect by talking in depth about password hashing.
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.
There's a balance between early notification and misstating the impact.
gpg password storage. Synchronization with rsync.
Beats the heck out of proprietary cloud hosted software.
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.
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
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.
"Drain covers in your neighborhood are horny now."
"Faucet dripping? Here's how to earn money from home with it."
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?
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.
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.
http://www.gnu.org/philosophy/who-does-that-server-really-se...
Using just one string of characters to protect ALL of your passwords is insane.
Though even with 2FA, couldn't a sophisticated keylogger grab your password database after you've authenticated and downloaded it?
There is no 2FA with LastPass.
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.
[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?
But if somebody got their hands on one or two of your passwords, they could probably figure out the rest.
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 :)
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.
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.
"Oops! Our servers are a bit overloaded right now.
Please try your password change again shortly, we will catch up soon."
No thank you, I'll trust the encryption to do its job. Don't see how changing the master password is going to help any.
It sounds like the password is still safe enough, but it's a very unfortunate, inconvenient timing indeed.
OTOH I'm not terribly sold on LastPass's UI, either.
I don't know, but I'm going to sleep a few days over it and check out my options on the weekend. This isn't an "everything's on fire" event, anyway.
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.
This is why I use Lastpass.
[1]: http://sourceforge.net/p/passwordsafe/git-code/ci/master/tre...
[2]: https://github.com/scintill/pwsafejs
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?
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.
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.
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?
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.
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.
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.
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 recommend 1Password, if you can use it.
https://discussions.agilebits.com/discussion/38180/vault-1pa...
For my taste that's already too much unencrypted info being synced over Dropbox etc, an attacker can easily see on which sites I have accounts.
While the blog post was nice, it would have been better to directly let subscribers know.
I am a premium subscriber with 2fa enabled.
Just received the announcement at 6:54pm CT:
Dear LastPass User,
We wanted to alert you that, recently, our team discovered and immediately blocked suspicious activity on our network. No encrypted user vault data was taken, however other data, including email addresses and password reminders, was compromised.
We are confident that the encryption algorithms we use will sufficiently protect our users. To further ensure your security, we are requiring verification by email when logging in from a new device or IP address, and will be prompting users to update their master passwords.
We apologize for the inconvenience, but ultimately we believe this will better protect LastPass users. Thank you for your understanding, and for using LastPass.
Regards, The LastPass Team
http://passwordsafe.sourceforge.net/
I use it on:
- Ubuntu
- Windows
- Android
Synchronisation of the password db files is accomplished by storing a master file on Google Drive (Multi-Fac Auth here). I only change passwords on Ubuntu - upload to Drive and download to Android and Company.
I believe the current suggestion is 7 words. It shouldn't be hard to come up with a mnemonic device to match your new password.
I wouldn't mention that if your data has just been compromised. Although it makes is hard to handle that data, it is more info about how the data is encrypt.
In short, more major sites need to implement a Google Authenticator style service.
One thing i noticed: They used quite a few german words ("dennoch", "jedoch", "dann") which i haven't seen used elsewhere up to now.
Is that common? I know that quite a few words are used commonly in English like "kindergarten" for instance, but this is the first time i've seen those in an english blog...
And yes, i've seen the same behavior - getting redirected on first visit and not on the second, so i guess you're right regarding a weird auto-translation bug...
Federated login using OpenID Connect seems like a far better solution. I can't fathom why so many web sites want the awful responsibility of storing your password. Why not leave that to Google, Facebook or Microsoft? Or you bank for that matter...
And yes - you should secure your IDP login with multi-factor authentication.
I use a hand-rolled gpg + git + owncloud for myself, but that's not convenient if you don't routinely have terminal windows open.
It would help protect against any other sites that you use the same password on, with a different 2FA shared secret.
You had one job. And you blew it.
-- the mid-90's Perl CGI scripts are calling and they're laughing at us all.
LastPass' user interface is really badly designed. There's lots of bugs and weird behavior. Experienced web developers can tell it's made without care. You don't want a password manager where the company doesn't care about its product.
There were other weird bugs, like assigning users to teams was finicky. Shared passwords didn't show up.
All this doesn't come as a surprise. The LastPass team didn't know what they were doing.
Every option out there either sucks ass on mobile or only integrates with a TINY percentage of apps and on desktop they aren't much better. How does Chrome (on iOS and OS X) blow every other PW manager out of the water? It "Just Works (tm)" while every other PW manager makes me just through a shit ton of hoops... I want to be safe but I can't be the only one who feels "chore" doesn't even begin to describe what maintaining and using a PW is like. My "Master" PW is secure but I'm not typing that thing every 5 minutes, 1Pass got better with Touch ID but it still makes me want to smash my phone every time I have to use it (Also, 1Browser, yeah how about FUCK NO).