Hacker News Reader

Comment by robryk | Hacker News Reader

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.

Are there any other options?

View on HN

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.

[0] https://support.1password.com/ios-extension/

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.

[1]: https://play.google.com/store/apps/details?id=keepass2androi...

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)

At least with Android you can switch keyboards very easily.

Likewise with iOS. There is a key on every keyboard to switch to the next enabled keyboard.

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.

Why not switch the the password manager keyboard just to type the password, and then switch back?

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.

Well you can just have it show you the password, and then enter the characters yourself.

Password management is not equivocal to automated password input. Even if that seems to be the primary feature of many password management apps.

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.

Reconsider how much entropy a password really needs and why?

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.

> about 70 possible values each

The norm is 95 values. That's the all ASCII printable characters, or just count them on your keyboard.

(I'm not sure if that includes the <space> character.)

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.

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.

Memorizing 20 random A-Za-z0-9 and symbols and retyping sucks too, and much smaller than that is too little.

equivocal

That word doesn't mean what I think you think it means.

https://www.google.com/search?q=equivolcal&ie=utf-8&oe=utf-8

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.

> They can, at any time, serve JavaScript...

Firefox Sync functionality is integrated in the browser and not served on demand.

> Firefox Sync functionality is integrated in the browser and not served on demand.

https://www.mozilla.org/en-US/firefox/accounts/

I think the JavaScript which serves the password-related stuff is somewhere in https://www.mozilla.org/media/js/firefox_accounts-bundle.f52..., but I could be wrong.

Reply on news.ycombinator.com