A theme of this work is vulnerabilities in the "internal browser" some of the mobile password managers provide. Mobile password managers have internal browsers because it's not easy to extend the standard mobile browsers, and password managers want to automate the entry of passwords into form fields.
Don't use the internal browser of your password manager, no matter which one you use. There's too much that can go wrong, and the small convenience just isn't worth it.
Which way of passing the password to the browser is better?
If I use the clipboard, many apps can read it (there's no foreground-only clipboard permission on Android).
If I let the password manager be my accessiblity service, I've given it power to do literally anything on my phone, and introduced a new interface between it and other apps (which can try to exploit it by producing confusing screen layouts).
If I let it be my keyboard, I'm giving it everything I type. This might be the least bad option of the three.
On iOS, 1Password uses an app extension [0] (requires app must support extension, Safari, Chrome, Opera mini do). It uses a keyboard or accessibility service (for auto-fill) on Android so I guess Android doesn't have something equivalent to iOS app extensions. I find this odd since inter-app communication is supposed to be something Android has over iOS.
Some Android apps use a keyboard to implement this [1]. The web view extension is specific to Apple's browser implementation so it works on "other" browsers such as Chrome and Opera on iOS.
In any case, it is a nifty feature that I think more Android apps should support.
If it's your keyboard, it has access to anything you type * using that keyboard * right? So if it doesn't actually have keys, just the password browser thing, it already has all the information that it could intercept.
(Speculation; I haven't built a mobile password manager before)
I've resorted to switching my password manager to generate "memorable" passwords, i.e. a combination of 4 or 5 words with some digits and a separator. Then I just manually type them. It sucks the least, and at least on iOS, I can mostly use Safari autofill and I've decided to trust iCloud Keychain. So mostly this is for when I need to type the password into an app.
FWIW, I'm using the horribly klunky PasswordWallet because to this day, it's still the only app I know which has auto-type in macOS which I prefer to an extension or copy/paste.
There is a mod of KeePassX 0.43 that had auto type, which I was using. Now there is KeepassXC, which has auto type. One notable UI difference: You have to select the Root node in the tree to do a global search.
If I use the clipboard, many apps can read it (there's no foreground-only clipboard permission on Android).
There should be a capability or access control to let apps securely pass data to a specific other app. Does this already exist in another form on iOS and Android?
Even where there is, there isn't a standard "put this in the password field" API. You'd need to modify both apps to cooperate, which is basically a no-go unless you control both.
But I would love such an API, for reasons like this. Clipboard / custom keyboard / etc are horrific alternatives when you could e.g. do an oauth-like app-redirect. Both sides can validate each other, and the user just has to hit yes/no/choose the account.
This is what I do with Keepass2Android. However, on my Nexus 6P the keyboard switcher appears on my action bar so there's no friction to switch input methods. I have had some phones where it was much more cumbersome since they had physical buttons.
The mobile browser could provide a public key that the password app could use to encrypt the password, then transmit the password over copy-and-paste, the mobile browser could then decrypt the password, then the browser could put the password into form.
I think a lot of people (myself included) use password managers to manage very long and random passwords. Typing in 100 random characters every time I need to login to something (especially on a phone) would be pretty annoying.
I wonder if anyone has a formula to convert estimated $ loss if a password is cracked to a suggested level of password entropy.
In other words, you could probably calculate that a given password format (say, 8 random characters with about 70 possible values each) would require X CPU cycles, with Y% certainty. Then, you could convert the CPU cycles to an estimated opportunity cost to crack that password. That would be the maximum value that this password format would be sensible to protect. Drop a couple orders of magnitude if you want to err on the safe side (or adjust Y). I expect you'd reach a number beyond all economic activity on Earth before you hit 100 characters, 15 probably exceeds most people's net worth, and 8 characters probably suffice for the majority of sites requiring a password.
I think the bigger win of using a password manager is being able to use different random passwords for each site, rather than using particularly long ones. That alone gives you sufficient entropy to beat brute force attacks and isolation of your other accounts from a single site leaking your password from their end.
Yes. Additionally, if your bank is at all competent, they will enforce rate limits that prohibit online guessing attacks. If an attacker has your bank password hash to perform an offline attack, it's reasonable to assume they also owned the rest of the bank and have a copy of any session cookies, "security" answers, etc. you provided, and probably don't need the password. If a site has been compromised, the site has been compromised. Unique passwords are the best way to contain the damage.
Fair enough. I erred low due to many sites restricting symbols. Also considered leaving out symbols entirely and going with 62 for that reason. Fewer possible symbols just means extra characters, and probably doesn't even have a huge impact on that number. Nine alphanumerics (62 possibilities) beats eight characters with 95 possible values, and if you want something easy to type manually, could be preferable. Depends on usage and site requirements.
In principle one shouldn't need a password manager on Android: the accounts manager should be able to do its job for apps, and your browser should be able to manage its own passwords.
Unfortunately, Firefox can't be trusted with passwords (its password store is secured by your password, which Mozilla can snarf if they wish, or are compelled to do).
I don't normally use a password manager on Android, but when I do I use the clipboard, because I have very very few apps installed, and I mostly trust them. But I'm not happy about it.
Having a unique, strong password for every online account you have is not a task for your browser to handle. Or for your operating system for that matter.
> its password store is secured by your password, which Mozilla can snarf if they wish, or are compelled to do
If you're talking about the Firefox Sync password, it's being derived and what Mozilla gets is not your password. Locally Firefox encrypts those passwords using a "Master password" you have to set and which never gets transmitted.
And any password manager can "snarf your password", all it takes is a targeted update, which on present day mobile devices will be automatic. If you can't trust an open-source application managed by a reputable non-profit, then you definitely can't trust your operating system either, in which case it is better to not have a smartphone at all.
I don't trust Firefox with my passwords either, but that's because ensuring the security of that database isn't what Mozilla sells and browsers have been known to be very insecure in handling those passwords. The first thing I do whenever I install a new browser is to disable the "Remember logins for sites" settings.
> If you're talking about the Firefox Sync password, it's being derived and what Mozilla gets is not your password.
Derived by JavaScript served by … Mozilla. They can, at any time, serve JavaScript which submits your unhashed passphrase straight to them.
> If you can't trust an open-source application managed by a reputable non-profit, then you definitely can't trust your operating system either, in which case it is better to not have a smartphone at all.
There's a difference between trust once and trust always. An OS is downloaded once; an application is downloaded once; JavaScript is downloaded every time you need it (modulo caching, of course): Mozilla can be compelled to suborn that JavaScript at any time in order to target someone.
Many password managers also offer a few alternative methods, including a custom keyboard or a notification with copy buttons on it. This is pretty good, so long as you don't go launching an app that spies on your clipboard.
Firefox for Android is also capable of running the LastPass extension for anyone using that combination.
I've been struggling with trying to select a new password manager to migrate from one I adopted a few years ago. I am happy to type uid's and pwd's.
The reason I want to migrate is that what I've been using used to have no cloud storage component at all. You could synchronize your devices over your local network and that was that. I never wanted any of this data on the cloud. Well, these guys decided to --without giving users a choice-- migrate data to the cloud.
As issues with the top password managers have come up from time to time on HN I have hesitated to migrate to any of them. Frankly, it's confusing.
All I want is secure encrypted LOCAL password and data storage. This includes typical password type applications but there are other bits of data one might want to store, for example, your passport number, company legal information, etc.
I don't want any of this data on the cloud. Nobody wants to wake up to a data breach that could potentially expose your data for hundreds of websites. Every single one of my logins is different, this would be a nightmare scenario. If the data isn't in the cloud the likelihood of that nightmare breach is reduced exponentially.
I feel the same way you do. I couldn't find a commercial product that I liked. I'm on OS X, and I made an encrypted disk image that holds a plain text file with login credentials and important numbers/info. I made a couple AppleScript scripts that will open the file upon entering the decryption password, and then automatically dismount the disk after a certain amount of time (because I often forget to). I backup my password file by periodically emailing the encrypted container to myself.
I know one of the KeePass apps has an option to have an offline only mode and I want to say you can even set it up to use your own sftp server for transferring the encrypted file containing passwords between devices.
The folks over there work really hard and care a lot. I'm sure that's the same with all the password managers too, but I know personally having worked at LastPass how much the founders care.
Hard-coding the symmetric encryption key used to store your master password isn't just a minor slip up. This is the kind of mistake that I for one wouldn't do and I'm no security expert.
At least for proprietary apps, security is about trust. Given their other slip ups in the past, along with present design choices like making certain administration tasks available only through the web interface, I wonder how people can trust LastPass.
Of course, it's better than not using a password manager at all. But one has to admit the bar for that is pretty low.
I get baffled at how such basic security mistakes are made. Either who did them doesn't care or doesn't know, of which neither is good for - at least - applications that store such sensitive information.
To be fair, unless I misunderstood, the symetric key is only used when you save your master password (so you don't have to re-type it) and use a PIN instead.
I believe LastPass app encourages you to NOT do this.
This obviously doesn't excuse the implementation (it shouldn't of gotten past CR). Just pointing out the attack vector is not as severe as it seems (at least from the issue's title).
Without a strong master password, encryption is useless. It's recommended to have a master password of at least 16 chars including digits and special characters. Otherwise a global enemy with the right resources, like the NSA, can brute force it from a distance.
My password is 24 chars in length, includes digits and special characters and isn't made of dictionary words. Typing such a password on my laptop with a normal keyboard is fine, because I touch type, but typing it on my phone every time I need it is simply not doable. Using a PIN on the other hand is easy and should be fairly secure if the app is designed to fallback to the master password after X failures, preferably with hardware support.
So in all fairness, not only did they screw up a basic feature, but this also encourages people to use weaker master passwords.
Really impressed ever since LogMeIn have bought Lastpass. Loads of much needed UI improvements have started to take place and it's slowly becoming less clunky.
I disagree with that. In my experience the apps and extensions have gotten much clunkier. The UI is inconsistent across iOS and Android, and on Firefox and Chrome. If I want to look up a password on my phone I will get logged out of the app two or three times before I finally get to the item I'm looking for.
I was a premium member up until my subscription expired last week. It used to be required in order to use the mobile app. Now it's not, apparently, and given the mobile app experience I've been having lately it's not worth it. I've been passively looking for a self-hosted alternative I can switch to.
I second your opinion and experience. I have been an Enterprise users for many years, but it has been getting in the way of getting work done. the Firefox plugin keeps losing passwords, takes forever to pop up and is a completely different UI from Chrome. Evaluating alternatives.
It's file-based. If you have a copy open in one location, open a copy in a second, save the second, then make changes in the first and save the first, you can override the second copy's changes.
That said, KeePass 2.x (which came out in 2010/2011, but some people still use the old version) has synchronization built-in, and on top of that, there are plugins to make it keep backups or update a secondary database. It's the KeePass clones that have their own implementation of the internals where you can run into problems.
IT does what it says on the tin; it's a password manager. However synchronisation is extra (I use sync to sync the file, and because I'm on iOS I have to manually import the file into the app).
The recommended iOS app (MiniKeepass) doesn't support Touch ID to unlock the database (a PITA with a long master password, which I already have to unlock my device), so I'm using keepass touch, which is a MiniKeepass fork, but with ads, and they've been ignoring my requests for source code (MiniKeepass is GPL).
Browser integration is a pain; you haveto install an extension to Keepass, and then to your browser, and set them up correctly. Steps are at [0]
It works, but is a lot more hassle (which as a result means I'm more likely to skip it and use an insecure password) than Lastpass was.
That is great, however, it is still worrying since we have no chance to know if bad actors had already exploited the vulnerabilities. I am still very sceptical with regard to password managers as SaaS in the cloud – all eggs are in one basket and this basket is often not well enough protected.
The write-up indicates that both of the exploits to get to the Master Password would have required physical access to the device, and one required a root exploit.
One of the 1Password ones (https://team-sik.org/sik-2016-040/) about leaking URLs is marked as fixed, however, that's a little misleading. It's fixed if you use their newer vault format, which has limitations, and is not selected by default when you create a new vault. I wrote this about it a while back: https://myers.io/2015/10/22/1password-leaks-your-data/
yea, but still the problem is that all users who created a vault before Nov 2015 never got any message neither is their database upgraded automatically. They will unknowingly keep using the old database format.
Seems alarming for a company who's business is security/privacy.
> and is not selected by default when you create a new vault.
I was clearly only responding to this part, which is still useful information. Nowhere I said there is no issue, there is no need to always nitpick on everything. I'll go back to not commenting on anything for another year.
This is why I still go to the trouble of PGP encrypting a file with my passwords, rather than relying on a password manager. I keep wanting to switch, but damn it, I just can't bring myself to have that much trust in them.
Edit: Thanks for the informative replies, the links, and the advice. I'm going to explore all of my options and re-think this.
1) I'm not sure how well using a PGP encrypted file would fare in this sort of analysis. I suppose it depends heavily on the details on how it is done.
2) The analysis was done for Android applications, I suspect that on desktop the situation is generally bit better. I doubt you are doing PGP encrypted files on Android..
3) KeePass is notably absent from the list. I suppose its presence on Android might be bit smaller than on desktops, but considering how well-known it generally is I find the omission bit surprising.
4) Continuing with KeePass, afaik it has been fairly thoroughly scrutinized and the findings I've heard of have left a positive impression
You may want to look at pass, which is pretty lightweight scripting around gpg to store passwords in multiple files. Some tradeoffs required, but works well and fully auditable
Pass¹ is very nice, and you can even share a part of your password library with someone else by using their GPG public key (encrypting just those files with both your keys) and sharing the shared directory via some sharing utility such as SyncThing².
Pass also supports using git for change management.
Because with git you have to explicitly push. Both have their valid uses; I use the git solution for a devops password database shared with a small number of colleagues. I use SyncThing to share a common subdirectory of a private password database with my partner.
SyncThing has the benefit of transparently handling the synchronisation behind the scenes for me. Whenever I place something in pass in the 'shared' subdirectory, it will end up in her database as well as soon as both our devices are online.
How do you get to the unencrypted data? Do you decrypt to a plain text file? Launch it into Notepad or vi? How do you deal with the temp files the editors create? Do you clear the clipboard after copy and paste the passwords?
I have a GPG file in Emacs, too. Just want to see what flow people use to deal with encrypted passwords.
I used to do something similar, but a local password management solution like KeePassX is much easier/more convenient and can be configured to function similarly. It can be used without a browser extension and obviously, it doesn't require the user to upload anything to anyone's cloud.
One more thing about Password Store: You can integrated it with a NFC-equipped Yubikey on Android so you don't just have a GPG key floating around. It took a little while to set up, as I was a Yubikey newbie at the time, but it works really well for me now.
The good thing about PasswordSafe is that the file format is well documented, so there are several implementations of password managers using this format, which should all be interoperable. For Android, there is the app PasswdSafe. It also offers its own keyboard for entering passwords. Sad to see they didn't test this one...
Me too. While I'm still not using the mobile app I use their desktop one. Would prefer to know if there were any overall security audit of Enpass or some expert has some thought. But if their android app is good it would at least give some idea of their competence.
I posted it on here the other day but it didn't go far. It's like youtube-dl but instead of downloading videos it changes your password on various online services. If you get your password compromised by vunlerabilities or whatnot it makes it easy to mass-rotate your passwords. Could use some help adding support for more websites if you're interested.
I looked at the LastPass ones (all for Android) and they look relatively minor. The only real wtf is https://team-sik.org/sik-2016-022/ - hardcoding keys should be a big nope. Still, it happens only if you use a PIN rather than your master password; I hope this does not happen in iOS if you use TouchID...?
I have such a strong password that typing it repeatedly on a mobile device isn't doable. And so I use PINs or fingerprints, depending on device. I find this acceptable because I worry less about physical access to my device, versus somebody gaining access to my encrypted database, which is also stored on Dropbox.
But I still expect that storing the master password locally is secure, otherwise why the fuck am I paying them for?
Speaking of LastPass, I've noticed them doing stupid things like this in the past and the problem is that I feel those bugs wouldn't have been discovered and made public if they weren't so popular. And I expect such a company to take security seriously, because this is what they sell. Hard-coding a symmetric encryption key isn't a minor slip up, this is the kind of mistake that I for one couldn't do, even though I'm no security expert. If they could do such an obvious mistake, then I can't trust them, regardless of their response time.
iCloud and iCloud keychain are not really the same thing. iCloud keychain is designed not to disclose user passwords in the event of an iCloud account compromise, for example, among other things. The iOS Security Guide[1] has more details on this topic, starting on page 45.
That's not to say other solutions can never be as secure, but it's a fairly good design nevertheless.
Is this like a "belief" in the healing power of crystals, or of the bumps on your head being indicative of your personality, or do you have something substantial to share?
Seriously though, I'm more interested in the assertion that any password manager can never be as secure as iCloud, even ones which don't upload data to the 'cloud'.
That's what I currently use as well. I would have liked to see some mention of it -- whether or not they tested it, or if they couldn't find any vulnerabilities using the same tests they did for other applications.
We need the same kind of investigation for iOS, this kind of research was so much needed because after all this is where we store all of our entire internet identities, good job!
Just my brief experience of 2-3 hours with LastPass today. Broken javascript errors when trying to import. Searched for customer support, couldn't find any! How do I file bugs? Sign up and post to their web forum?
I noticed their website is made entirely in php. Not that php is bad, but this is possibly the worst choice for a web platform that holds secrets. At only $12 a year, they probably aren't trying very hard.
Don't use the internal browser of your password manager, no matter which one you use. There's too much that can go wrong, and the small convenience just isn't worth it.