I'm a LastPass user and everything here was pretty much as I expected with one exception - the unencrypted metadata in the vault. That's extremely disappointing. The ECB stuff isn't really used any longer, the OTPs are kind of hacked on, no surprise there. I was willing to tolerate that stuff for an overall decent solution.
But now realizing that they're handling URLs in this way... I just can't use it anymore or recommend it in good faith.
So what do I do?
- KeePass looks nice, has multiplatform support and browser extensions but the crpytography in it is sketchy, custom KDF and stuff going on... mobile support might also not be so great though I'm not positive.
- PasswordSafe has better looking cryptography, though still not up to where I'd like it to be as well as a worse UI, worse browser support, etc. And last I checked I think Linux support was sketchy.
- There are an infinite number of questionable proprietary solutions that have similar problems to LastPass, usually far worse actually...
- and a few open source solutions that look good but completely lack in the UI and integration departments.
So I'm about to take KeePass, gut the crypto, replace it with simple scrypt and AES-OCB or chacha20-poly1305 and hope I can wind up with something I'm comfortable using - anyone have a better suggestion?
I felt the same way until I read the conclusion, "we want to point out that the security team at LastPass responded very quickly to all our reports and lot of the issues were fixed in just a couple days. It was very easy to communicate and work with them."
That is why I use LastPass. Because they aren't perfect, but they realize that their reputation for taking any vulnerability very seriously is the most important asset they have.
I have heard great things about KeePass so if you make that switch good on you.
LastPass does exactly the thing I use it for, does it well, and does it mostly transparently. Allow me to easily use different passwords per site. While my LastPass might be hacked one day, if I reuse passwords, then my accounts will be hacked eventually. Not a question of if, but when.
Whenever news comes around that a particular site got hacked, I don't even pay attention. Who cares if one of my hundreds of passwords gets hacked?
LastPass is somewhat vulnerable, but the architecture of LastPass plus the professionalism of the team means that any threat will be seen coming by anyone paying attention, as reports of an exploit out in the wild. A few people will be caught flat-footed but not everyone.
When that happens, we can take steps to mitigate. If worse comes to worst, I can download a copy of the database, change the most important passwords so they're not in the online database, Gmail, banking and such, manage those manually, and hope my database doesn't get hacked.
If it looks like it's just getting worse and worse, I can spend an evening changing passwords and migrating to a self-hosted solution.
My data is safe in that an adversary would have to break through my personal defenses to get at it. They're not sitting in plaintext on some corporate server somewhere waiting to get hacked.
Yes, because every system has flaws in it. Nothing is perfect and given enough time and resources an exploit will be found. Knowing that, if the team listens and fixes the issue, the product goes forward being more secure and trustworthy.
> PasswordSafe has better looking cryptography, though still not up to where I'd like it to be as well as a worse UI, worse browser support, etc. And last I checked I think Linux support was sketchy.
PasswordSafe is, I think, the current best-of-breed with respect to its crypto. Like you, I have some concerns with it (notably the use of Twofish rather than AES, and a too-low PBKDF2 default), but it's the best you can get without writing your own.
It seemed to run ok in WINE last I tried it, and there're one or two native Linux programmes which can read & write its files.
These days I just use an org-mode file encrypted with gpg: emacs automatically prompts me for my password and decrypts it when I open it up.
> So I'm about to take KeePass, gut the crypto, replace it with simple scrypt and AES-OCB or chacha20-poly1305 and hope I can wind up with something I'm comfortable using - anyone have a better suggestion?
Replace the crypto and data model with a PasswordSafe 'v4' format: scrypt plus AES-GCM plus chacha20-poly1305.
I like a password db format which is portable to different manager implementations on different platforms, and think that passwordsafe v3 is probably a bit better than the keepass format.
(EDIT: and I don't care for integrations with browsers or anything else, they're a bad idea...)
I suppose this is a problem if someone breaks into your home and gets into wherever you keep your notebook and steals it but frankly that's hardly the only problem you have in that scenario.
I've got over 700 passwords in my 1password database, am I supposed to carry a giant notebook with me 24/7 in case I need any of those?
I think this is bad advice - it encourages password re-use, and gives insider threats a perfectly simple vector for credential theft (because you need passwords at work as well as at home).
I think this paired with LastPass would be great. Email and Banking all on paper with a backup at home. Everything that only has my credit card info and my address can be done through a password manager. Because in my mind those can all be recovered through email, and easily opened through LastPass.
Also that advice is from 2005, I wonder if he'd agree with what I said above or disagree.
> We're all good at securing small pieces of paper.
Not true, as it turns out. I created passwords for my users and put them on a laminated card as a courtesy, with instructions to keep it in their wallet, purse, etc. They were turning up stuck to keyboards, shelves next to desks, etc. Some people are really crap at securing small pieces of paper.
I'll bet you if it were the details to their own bank account they wouldn't do that! It's a problem of how much people care, really (or how much they think the organization cares).
I think Schneier's (and my) mistake was assuming people know to value their passwords. It's getting bad when the Head of IT, however, is one of those sticking the password to his desk :(
How many of these sites actually need secure passwords? How much would anyone gain by e.g., impersonating one on a forum site? If that number is close to zero, one could just use the same "standard" password for all low-security-value sites and be done with it. For other, slightly higher-value sites, one could leave one's devices logged in as long as practical, and generate a new 15-character password every time one must use the "forgotten password" email-a-capability-URL feature. For the designated secure email account, and maybe for certain financial sites, one might need to remember or write down a passphrase, but there will be fewer than 363.
I use Password Store -- uses git + gpg to store all of the passwords. It makes it really easy to maintain a synchronized password store across multiple devices including Android
The cryptography in gpg is less than optimal for this purpose and I have to admit I just don't like gpg because it's so big and supports different ciphers, big codebase means more exploitability. But it could work for this purpose, it just seems really inefficient to me.
Is there browser integration or a better UI for it?
GPG is maintained, and well. Even as it supports different ciphers, that attack doesn't apply here. And very little functionality is accessed through this script.
If that's not a tiny attack surface, I don't know what is.
Password Store might be tiny but GPG itself is a huge attack surface - that's the problem.
Maintained, yes, well... I'd question that. I don't think it's very heavily reviewed or anything, and vulnerabilities pop up in it quite frequently, enough that I'm uncomfortable using it for serious purposes.
Many of these vulnerabilities have to do with very important cryptographic code... If you're comfortable with it, that's fine, it's not a bad solution. But personally I'd honestly be more comfortable with plain text files and TrueCrypt, which has no real cryptographic problems even after quite heavy review, the best we've found is a privesc bug in the Windows driver.
Don't get me wrong, I love to take a dump on GPG as much as the next guy, but this argument is a little misguided. If you're decrypting password files that come from a malicious party, you have a pretty big hole in your security model.
Cloud synchronization is a very common use of a password manager. Many people load their password manager files onto Dropbox, GDrive, etc. Assuming authenticated encryption is properly used and care is taken to avoid leaking metadata, this should be a non-issue.
You have linked a list of vulnerabilities dating back to 2006, 10 of which are worth talking about. That's just over 1 per year. Only one allows arbitrary code execution.
Privesc is bigger than all of these combined, especially in a kernel driver.
Getting root or SYSTEM on my machine is no big deal when all the valuable data you can have is already available as my user. Privesc is minor to me, but it depends on your threat model of course. If you're in a shared environment without VM isolation, it could be a much bigger issue for you. I don't mean to downplay it as you're right, kernel mode privesc is bad, it just happens that it's a minor effect on my threat model for personal systems.
Arbitrary code execution that say, a cloud storage provider could modify would be a far bigger problem. Some of the cryptographic issues are also arguably bigger problems for practical usage. As such, to me, GPG is not nearly as worthy of trust as other, far simpler platforms.
> Snowden can use GPG so can you
This just doesn't make sense as an argument to me - one guy who needed strong encryption used it once therefore you should use it forever and ignore or don't try to develop simpler alternatives?
1 vulnerability that's "worth talking about" per year is enough to make me want to run the other direction, especially on something as sensitive as a password manager.
It handles changing a password by keeping a file of the salts, which is theoretically safe to post to a public github (mine's in my dotfiles repo, though it's a private bitbucket repo)
The dictionary is only used once to generate master password. Then it derives site-specific keys with PBKDF2 from it. You can skip pz-master and use your own master password, but make sure it has enough entropy.
Indeed, that's the reason I stopped using my own password generator and switched to password manager. (Also, sometimes I can't remember my username, so password manager is more helpful.)
Self-serving, but I'm working on an open source project which handles password storage using AES using symmetric key with the website password (many other features): https://github.com/myplaceonline/myplaceonline - you can run this locally or test out the beta version online (email me)
It's not a bad approach - it lacks integration, it's easier for malware to grab, but that's about it. Malware can already dump the memory or log the keyboard and mouse to grab what'd be needed to decrypt your LastPass or KeePass, so in the end those solutions are no better than plain text files inside an encrypted container. The lack of integration, generation and other UI niceties is really the biggest loss I think.
Well, WRT to malware, KeePass can somewhat mitigate generalized threats. Say, in-memory encryption to protect against memory dumps, using a secure desktop [1] for the master password, and typing obfuscation during auto-type to protect against keyloggers. Well, keyloggers that aren't written with KeePass in mind, at least. Both of those would give it a modest edge over plain text in an encrypted container.
The whole "secure desktops" thing is a bit of an oxymoron too. If you can gain admin privileges you can steal any desktop and session token you want and keylog it. I've used that trick before to keylog winlogon's "secure" desktop, so surely KeePass would be similarly vulnerable?
Additionally a quick patch or in memory modification of KeePass.exe would easily bypass any protection like this, lookup the KeeFarce tool to see an example. I'd hardly call this an "edge" over plain text files in an encrypted container, considering it does nothing to actually prevent exploitation but simply provides a form of security through obscurity.
Ultimately once a system is infected, all you can do are half-measures and will wind up worthless against even a mildly sophisticated attacker. Unless you run the software in a separate machine, you're dead in the water and it's pointless to discuss what happens post-infection when anything is really possible.
Well, KeePass.exe is signed, which prevents the malware replacing/modifying the exe. I personally run it as Admin and lock my keyfile down to admin accounts, which prevents against an un-elevated user process from stealing anything of value.
I guess if the malware get's admin access I'm hosed, but that's pretty much game over anyway.
> Well, KeePass.exe is signed, which prevents the malware replacing/modifying the exe
Windows doesn't require executable to be signed, strip the signature from the PE file and unless the user verifies it they're still dead in the water. Not good enough? Okay, install a new certificate for code signing the patched PE file and sign it yourself.
As for user isolation, it's a great idea but you could take advantage of this isolation with the filesystem method too simply by making the files only readable by an administrator and running a text editor or search tool as an admin so I'd still say this is not an advantage over the encrypted disk image method.
Could you be more specific? The only issue I've heard about was that in an old format you could see which sites had saved passwords. That's more of a privacy issue than a security leak.
On second glance it looks like you're right, I mis-recalled, they had a problem with the old DB format that's about as bad as LastPass has now. KDF they're using isn't the best, on par with LastPass and it looks like they're using authenticated encryption and everything... so overall, not so bad.
It's another magical proprietary solution though so I can't help but feel like switching from LastPass to 1Password wouldn't be worth the hassle. I'm looking for something more in the open source and dead simple direction.
What I like about 1password is they are proactive and explain their crypto process extensively. They're also small, in Canada and 1password is their only product, so the conflict of interest risk is lower.
There are scripts out there that will take your lastpass dump and convert it into a 1password import file. The process to convert over takes about 30m-1hr.
Main thing I don't like is their custom AES-based key derivation function. I'm also not sure if it does authenticated encryption but if I recall correctly it does not. I'll have to have a look at it again soon.
I agree about the key-derivation (just use the PBKDF built into .NET dammit), but I've checked out the code, and it looks sound. It uses standard Windows crypto libs when running on >=Vista.
Thanks, I'll definitely be keeping an eye on keepass, there's a post around indicating that they're going to add Argon2 (the winner of PHC) when it's finalized. I might just do the switch now...
Authenticated encryption seems to get popular just these last couple years. Besides injecting unwanted data into the encrypted data, what other attacks can be done with it? For encrypted code, injecting unwanted code in the middle of it would be a big problem when decrypted and run. For pure data file like the the password database, would it be just adding extra garbage?
With the recent security issues surrounding LastPass, it makes me wonder, is the bar set too low even for professional products? Does LastPass not do this testing on their own? Does LastPass not reach out to the security community and contract to have this testing done, proactively? I mean, these folks pulled this off in their 10% time...
I don't know, how much is the security bug bounty on LastPass? $1000 according to Bugcrowd [1]. But what would be the right value?
That's the only way we ensure it's economically more viable for hackers to resell their security leaks to LastPass than to pirates. An economic approach would claim that the total available bug bounty scheme must be worth the same as the potential stolen value of the contents, otherwise it's still valuable to exploit the leak rather than publish them. The only savings that LastPass can make is over the gap between insured value and their ability to not have leaks.
I doubt most small businesses could afford a bug bounty that would exceed potential illegal profits from selling an exploit to bad actors. I don't think the economics work at any scale. Could Google, Apple or Microsoft even outbid a nation state seeking to purchase an exploit?
No, but I think as long as the bug bounties pay enough to keep someone comfortable (along with added notoriety/resume padding with it), you'll have enough moral people choosing to reveal them to the companies rather than bad actors. Maybe that's naive. $1k bucks though probably isn't that number. More like $50k or $100k for 0-day level stuff.
States are not really the buyers to be concerned about. In many cases, the state already has tools that give them enhanced access to target data, all the way up to the authority to obtain and execute warrants. The people that are really worrisome are private malicious actors.
LastPass always represented a single point of failure for me, although still bettter than what people usually do - same password across all services.
I recall one interesting method involving no third-party services is a concatenation of a random string combined with some of the letters of the service I'm using. E.g. the first and last letters of the website I'm on. So if the random string is xPv4rz and I'm on HackerNews, the string becomes hsxPv4rz.
The problem is that you don't have control over password requirements, so you'll rapidly accumulate exceptions. What if they require (or assign) a PIN? Security questions? What if they assign a number as your login? Require a special character? Forbid special characters? Require >6 chars? Forbid >6 chars? Forbid your password from matching previous passwords? What if they don't show you the domain? What if the domain changes during login (see: Cambridge Savings Bank)? What if the domain changes over time? What if the company name changes? What if they lock you out after 3 attempts and you burn up all three trying to remember the variation you were forced to use?
I tried the combination scheme for a bit over a year. I was in denial about how poorly it was working until I started getting politely teased by casual acquaintances about being the guy who could never remember his passwords. There are accounts I'm still permanently locked out of. It was bad.
By comparison, LastPass has been great. More secure passwords, less forgetting them. Eventually I want to move to a password archive that's physically separate from the computer, but for now I'm happy with no longer dreading login screens.
Well regardless of your scheme, you should still write down your passwords!
Just because it's not feasible to lug a moleskine with that long long list of passwords to everywhere as a "password manager" solution, doesn't mean that you shouldn't write them in that notebook, which you store in a safe place. Not for quick & easy access, but for backups.
You don't have to do it on paper, but it's a good choice because it's low-tech, easy for anyone to use (bus-factor, next-of-kin) and exactly as secure as your common sense, making it exactly as secure as anything else you can use.
Being unable to access accounts, because you forgot the passwords, that you didn't write down anywhere is equivalent to losing data because you didn't make backups. Which we also tease people about, right?
Have you written down your LastPass master-password anywhere?
The tone of your lecture suggests that you think I disagree. Which is odd, because from where I'm sitting your central claim looks like a corollary to my conclusion.
The main issue with this kind of method (using an algorithm to create a password) is that it makes it very hard to change your password if needed.
E.g, let 's say you use your algorithm for your passwords : Amazon get AnxPv4rz, HN get hsxPv4rz, etc... Now, someone get your password for Amazon one way or another (social engineering, poorly protected website, etc...). You have two choices :
* Change your algorithm for all your passwords. Depending on the number of different websites you use, it will probably be a very heavy process, and you might forget some websites.
* Use a different algorithm for Amazon. If you start going this way, you'll quickly find yourself with 5-6 different algorithm, each more or less complicated. That's pretty much why people use Password managers : they want secure passwords, without having to remember each and every one of them because it gets complicated after the 5th. And if you use a password manager, you might as well use completely random passwords.
Additionally, if a hacker gets 2 of your passwords, they can see that all you passwords are of the form AxxxxxB, from there it is quite easy to get all your passwords. If you have an "algorithm" that is easy enough to remember, then it is most likely breakable by a smart hacker.
It would not surprise me if a single password is enough for an attacker to guess the rest in this scheme. It is common enough to be predictable, and even if it weren't, all your passwords are at most 2 characters different from each other. That's not a lot of entropy.
A possible mitigation of the obvious problem (the pattern itself) is instead to use a hash function on some aspect of what you're trying to log in to: a hash of the main domain, the human name, whatever. That way if a password is compromised, it may look like a common pattern is being used, but the "random" part of one site's password won't do any good on another site.
The challenge being to implement a hash app everywhere you might be that will generate the correct hash. Maybe a very simple mental hash function would be enough; mass attacks would probably be foiled, and individual attackers may be too lazy to bother figuring out the hash.
There remains the problem of changing the password due to some necessity, like policy or compromise.
EDIT: If this was app-based, then each time you change a password, the app would record that fact, and incorporate it into the hashing data, so that a different hash is generated. The problem then being synchronizing that fact among all your installations of the app. And if you were using a mental hash, I don't know how you'd remember this across all your logins; possibly some central piece of data that you could easily look up, to see that you've changed your password one or two or N times, that is easy to incorporate into the mental hash.
This is good brainstorming, but I'm getting tired just thinking about all that mental complexity. I would rather take my chances with Lastpass than keep a complex mental list of how many places I've reset my password at so far.
I've actually been using this approach for the past 12 years. There used to be an old firefox plugin called Password Composer (http://web.archive.org/web/*/http://jlpoutre.home.xs4all.nl/...) which would let you type in your master password into firefox, append the website domain, take a digest of the result and truncate to 8 characters before sending to the website. Over the years, I replaced this plugin with a simple 5-line script so I can reproduce my passwords from anywhere, strengthened the hash function from SHA-1 to bcrypt, and also added a configurable password length so I can gradually grow passwords over time as computers grow more powerful. Here's my solution: http://akkartik.name/pc
Regarding other comments in this thread about managing exceptions to the scheme over time, I have a simple solution: I let my browser save my passwords. I think this is a reasonable trade-off; the dominant threat online today is not somebody gaining physical access to your devices, but random script kiddies brute-forcing passwords using stolen hashes.
Tl;dr - use my script to generate passwords, use your browser to remember passwords, and the complexity is quite manageable.
One potential gotcha I realized recently is that it uses the bcrypt encryption scheme rather than the well-known digesting algorithm. The two share a common kernel, from what I can tell, though there are significant differences. There might by cryptographic implications to using an encryption scheme for digesting; I'm not an expert. Hopefully the fact that this is a bespoke arrangement being used by a tiny population will keep anyone from hacking me :)
It gives me a way to figure out my password on a strange system. Admittedly this use case is growing less common with the ubiquity of personal devices and sync.
So as your browser stored passwords pass through (and rest at) the server, waiting to be synced to another browser or device, you have passwords "up there." Are they in the clear? Are the encrypted well enough?
Your point is well-taken that I'm just replacing one external service with another, so the difference isn't large enough to convince anyone to switch. My original response in this thread was just to point out prior work relevant to the brainstorming above.
> I recall one interesting method involving no third-party services is a concatenation of a random string combined with some of the letters of the service I'm using. E.g. the first and last letters of the website I'm on. So if the random string is xPv4rz and I'm on HackerNews, the string becomes hsxPv4rz.
I don't see this as really that useful -- if someone gets your password from two leaks they can probably figure the pattern out as well as you can.
That seems like a lot of work given the number of passwords attackers get when they compromise a site. But then again there are scenarios where it would be a concern. I actually do use this technique but only for my least secure tier of logins.
Isn't using the same basic string with only a few tweaks to it here and there easy to crack (especially if the delta is information related to the site it's for)? And doesn't it represent its own sort of "single point of failure"?
Well-written article and some things I had thought of myself but ignored. It's not that other systems might be more secure, but reducing attack surface is important. So, is there something that lets me access my passwords on all my computers and phones without having to manually sync? Perhaps something + Dropbox?
I've been using Dropbox/ownCloud + KeePassX/KeePassDroid for years now. Putting the password in is a manual step, but that also means I feel like being more in control. Very happy with the setup.
Speaking of security concerns, you might think twice before continuing to use OwnCloud as a part of your password vault solution. It's had critical security bugs in the past, and I'd wager more in the future.
Part of the value of a service like LastPass (not a fan personally, but for argument sake I think ths still holds for this issue) is that someone is (should be) always on duty to monitor the service for suspicious activity and be ready to respond to security issues in the code base. While you're in class or a meeting or a movie or asleep, they can already be locking ish down and implementing patches / fixes.
Yes, I'm aware of the Ubuntu/ownCloud repository mess, as I was also affected myself. I'm not too worried though -- it's a personal virtual server with a custom ownCloud endpoint, and the password file is encrypted anyway.
These are always a bit of a balancing act on what's good use of third-party services and what's worth handling yourself. Services hopefully have a competent team behind it monitoring it (not guaranteed though!), but at the same time provide a much more lucrative attack target. And in my case at least, in a completely different jurisdiction. Monthly feels, service continuity, learning aspect... There are lots of different points influencing the choices.
All awesome points. I host my own email on pretty much the same line of reasoning. The "more lucrative attack target" is a great point I hadn't factored in.
As someone with very little knowledge of encryption etc. please advise - how safe is dropbox? I would have guessed it would be a relatively frequent target for blackhats.
I would consider it not safe because it was on of the companies mentioned on the NSA slides.
You can still sync your Keepass(x) file with Dropbox if you have a good password (key file is recommended) on the database file.
Instead of Dropbox you can also use https://spideroak.com/
They have a really handy program which let you control a lot of things and they are a "zero knowledge" cloud provider, all your data is encrypted.
Snowden recommends them: http://www.theguardian.com/technology/2014/jul/17/edward-sno...
For $12 dollar a month you get 1 TB, which you can use as a safe off-site backup location.
Note that, while SpiderOak is arguably more secure than Dropbox, they rely on a hybrid security model wherein they still have your encryption key on their server, but encrypted with your local password. This matters because if your password is ever compromised, however briefly—say, by using the mobile app or the website, neither of which are supported in a secure manner (they make this very clear)—then all your data would be permanently compromised, with no way to rotate your keys and re-encrypt your data before someone gets access to it, short of blowing out your account. I get why things work this way, but still, yuck.
Also worth pointing out that neither Dropbox nor SpiderOak are fully open-source, so you are having to place some degree of 'blind trust' in either service. It is in their own best interests to have great security so that customers trust the product, but this cannot be verified by someone outside the company.
I would expect Dropbox to be rather safe (please use two-factor auth), though I did migrate to self-hosted ownCloud myself. Anyway, this is not even a crucial part, since the password file is obviously encrypted with a strong password. The unencrypted data never touches the disk.
Also, for the database file encryption I'm using AES256 with 10 million encryption rounds (configurable in the application), which hopefully slows down any brute force attempts even in case of a data breach.
Of course, all bets are off if your device itself is compromised, but that would be the case with any solution.
Applying AES multiple times/rounds doesn't yield anything. AES is not adaptive (like BCrypt) so the cost of brute-forcing doesn't increase incrementally with the number of rounds.
I'm not expert on encryption, so could you clarify this a bit? If the source data is encrypted multiple times, surely then decrypting needs the same number of passes to get the original?
Interesting. I assume that to mean that the inner decryption loop can be repeated over and over with just a minimal overhead when the same password is being used, compared to the whole process of choosing the next password and setting up the decryption process with that.
Anyway, the slowdown is noticeable on my devices with these applications (it's about one second on my laptop), but then again these obviously are not custom-built AES decrypters. This will have to do now.
Sounds like a valid approach for personal information. I wonder if there's such a solution that would let you "share" passwords with other people, like LastPass lets you do.
+1 for 1Password. I guess it gets no love because it's proprietary, but the security design is public and even when a "flaw" was uncovered a few years ago it was nowhere near this kind of revelation.
I have tried KeePass, but it's just too painful to keep running..especially as a Mac user.
1Password + Dropbox with 2FA makes me sleep a lot better than when I used LastPass.
1Password's UI is so much nicer, too. It's a native, very good-looking app on OS X.
The browser integration looks near-native and performs all interactions inside its dropdown menu. LastPass opens separate tabs to accept your master password or your 2FA token (at least in Safari), and things like editing a site or copying a password frequently takes you away from the tab of the site itself.
Another huge advantage is that unlike LastPass, form field autofill actually works. It will even submit the login form by default, if there are no other fields that need to be filled out.
I have been using Syncthing on my desktop machines to share my KeePass database between them.
My home server keeps a copy available via SFTP, which is accessible using the KeePass2Android app. That saves me the manual process of updating on my phone, allowing me to avoid using Syncthing, there, which would crush the battery.
I have had a good experience with passpack. They use multiple layers of encryption (password for the site, and separate for encrypting passwords). I also have two factor identification set up. Access to the web site to copy paste pws is easy whether you are on a phone or desktop.
I know that this isn't what you asked for but one way to dramatically reduce the attack surface is to not upload your passwords anywhere and not sync them between devices.
Just keep the passwords on your phone (in a password manager) and type them by hand on your computer. It works well enough since you always keep your phone with you (at least I do).
If we choose to still use LastPass, what are the best practices to make these exploits less usable? They have some at the bottom, but I was wondering if they missed any.
Looks like there is an option to disable store dOTP on each machines? Kind of a pain to change on every device, but OK. Sounds like a good idea. What else is there?
There are some good recommendations at the end of the article/presentation, but also note that Lastpass seems to have fixed (at least some of) the issues already.
Its interesting that the unix world outlook of simple tools doing one thing make this simple. My encryption layer is encfs, my storage and sync layer is dropbox (although I used unison a long time ago) and I don't use the browser interface layer so I hand type passwords. At least this way I never forget any. Oh and for password creation I use pwgen for important stuff (the credit union) and silly names for unimportant stuff (social media)
Individually those small simple tools are well optimized and pretty safe. Yet monolithic top to bottom windows style all in one solutions always fail miserably such that it smells impossible to actually implement. Which it might be, for practical, and possibly legal, reasons.
This is interesting because its a real world example of what happens if you let the general public be unix sysadmins.
It is possible, that just like some knowledge is only for the cognitive elite, some computer automations and features are inherently by the complexity of what they do, only for the computational elite. If this isn't a specific example of something on that borderland, its an interesting topic to think about in general.
If an attacker is able to find my storage repo, identify my database file, discover what type of encryption I'm using, and figure out the key to decrypt it, then you know what, they've earned my credentials :)
Could I use multiple services like LastPass, and then have my password be the xor of all of those? That way each service would have to fail at the same time, or I would have time to change the stolen piece?
The XOR of two ASCII password characters tends to produce characters in the control code section of ASCII, which you may have some trouble convincing those services to store. You could define your own XOR based on an enumeration of password characters, but that's getting into a lot of work for this idea... it had better be good.
"What I am saying is that LastPass adds Javascript payloads to your encrypted vault in cleartext. Javascript code that will be injected and run in every page load in the domain’s context. While this is a legitimate feature, it gives LastPass the possibility of stealing all your credentials."
Ouch ouch ouch. How did they think that was a good idea anyway?
LastPass has jumped the shark. Major vulnerabilities were disclosed in 2011 and now 2015. Their purchase by LogMeIn is not inspiring. I closed my account and started using KeePass (by way of KeePassDroid) stored in Google Drive. This way only I control the encrypted data.
Data uploaded to Google Drive is not data only you control. You may believe only you control the unencrypted data, but that is up for you to decide. If you read the entire post the author states:
"To finish, we want to point out that the security team at LastPass responded very quickly to all our reports and lot of the issues were fixed in just a couple days. It was very easy to communicate and work with them.
We have seen media and tweets mentioning that we “hacked LastPass”. We did not hack LastPass. We also don’t feel comfortable with those claims. What we did is find a number of bugs, bad practices and design issues which we used to obtain the vault key and decrypt all passwords in different scenarios. There is no bug-free software and any future research on other password managers would likely have similar results."
... which is doubly worrying if you do not control the data you believe to be securely encrypted.
Product idea: a smartwatch with stored passwords combined with an USB plug-adapter for a keyboard (daisy-chain style). Eventually, computer manufacturers could incorporate the USB adapter into the computer itself.
It may have changed recently, but as of about a year ago, a TeamPass installation on a corporate network was my ticket as a pen tester to go from plugging into the network to domain admin in 4 hours. Not the best of signs.
Whenever an article like that appears about a proprietary password manager, I just wonder if there has been any audit on the popular open source ones like KeePass. In fact I've heard that KeePass has some security issues. Is KeePass more secure?
# this should be a start, it still needs output all permutations of the cipher applied over all possible substrings in the ciphertext because not all parts may have the same cipher applied and it also needs to brute force a salt up to a reasonable length to precede/follow the output text since salting passwords with a memorized constant is common.
def ceasar_permutations(ciphertext):
alpabets = [ascii_lowercase, ascii_uppercase,'0123456789',' ~!@#$%^&*()_+``-=[]{}:";\\\<>?,./]']
for perm in permutations(alpabets):
alphabet = ""
for p in perm:
alphabet+=p
for i in range(0, alphabet.__len__()):
shifted_alphabet = alphabet[i:] + alphabet[:i]
table = str.maketrans(alphabet, shifted_alphabet)
print( ciphertext.translate(table))
A website with rules like "passwords must be 8 characters or less, contain no dictionary words inside them, and cannot have double letters" would put a stop to that pretty quick
I have never had a password stolen and I can retrieve them if I forget my phone and have to borrow someones to visit my password page. This happens a lot since I find my phone to be a anchor and my life is better when I leave it at home.
A few weeks ago I had to return something to Target I ordered online. I didn't have my phone with me but my sister had hers and they wanted a order number that was only emailed to me. So with a pencil and some paper I was able to visit the page with my email password and convert it and login to my email on her phone. It saved a few hours of driving back to my apartment and back to the store.
But now realizing that they're handling URLs in this way... I just can't use it anymore or recommend it in good faith.
So what do I do?
- KeePass looks nice, has multiplatform support and browser extensions but the crpytography in it is sketchy, custom KDF and stuff going on... mobile support might also not be so great though I'm not positive.
- PasswordSafe has better looking cryptography, though still not up to where I'd like it to be as well as a worse UI, worse browser support, etc. And last I checked I think Linux support was sketchy.
- There are an infinite number of questionable proprietary solutions that have similar problems to LastPass, usually far worse actually...
- and a few open source solutions that look good but completely lack in the UI and integration departments.
So I'm about to take KeePass, gut the crypto, replace it with simple scrypt and AES-OCB or chacha20-poly1305 and hope I can wind up with something I'm comfortable using - anyone have a better suggestion?