browserpass-extension
browserpass-extension copied to clipboard
browserpass
Allow to autofill more form fields besides username and password
A nice feature would be the ability to specify fields by some strategy in order to fill them. For example, I have a number of AWS accounts, and the account ID is not something I remember, but "ProjectA-AWS" is. Having account id, username & password auto-filled would be a big convenience.
My initial thought is that this syntax would work:
browserpass_selector_XXX: input#account
XXX: XXXYYY
Interesting idea, I would also be curious to learn other examples where filling extra fields is useful.
The development is pretty much driven by community now, let me know if you (or someone else) want to try implementing this feature, I might be able to give some hints besides testing and doing code review 🙂
@maximbaz other two examples:
- Credit cards number, expiry date, CVC, and name
- Addresses
I wonder if browserpass should be configurable globally for attributes? Cvc looks for #cvc, #seccode, etc.
On 8 November 2017 16:19:49 GMT+00:00, Ian Liu Rodrigues [email protected] wrote:
@maximbaz other two examples:
- Credit cards number, expiry date, CVC, and name
- Addresses
-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/dannyvankooten/browserpass/issues/187#issuecomment-342869507
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Cool idea, but I'm afraid it would be technically extremely complicated. Websites don't follow one approach to define even such common fields as username and password (just check how much code we currently have now to detect these) - detecting extra fields which are not as common or as standardized would be even more difficult, every website will just use different approach / markup to create such fields.
The initial idea that you suggested is annoying for users to configure, but at least it is relatively easy to implement in browserpass.
I'm happy to be proven wrong, but I'm speaking from experience, it took me quite some time to get detection of username and password reliably.
The extension need not to be perfect. It could try to find the credit card fields and, if it fails, allow the user to copy specific fields of a password. See https://stackoverflow.com/questions/15168261/how-does-chrome-detect-credit-card-fields
Also, this link might become handy:
https://cs.chromium.org/chromium/src/components/autofill/core/common/autofill_regex_constants.cc
It doesn't need to be perfect, but it needs to work reasonably well in majority of the cases. I definitely don't mean to discourage anyone from implementing the feature, I just want to point out that automatic discovery is a difficult task, it took me quite some time to get it right for usernames and passwords. Thanks for the links, they do seem to be useful.
Allowing to copy specific fields to clipboard is another interesting topic, there is a debate #105 on how to implement it for usernames and passwords, extra fields require more thought, for example because one cannot know which fields are available in the file without decrypting it first. Again, I'm just pointing out some complexities 🙂
You don't come across as discouraging, you are making everyone aware of the technical challenges involved with this issue. Please continue!
I think there's two parallel issues here, which could potentially share a solution:
- Per-site unique login fields, e.g. AWS account id, maybe other "enterprise" software with account ids also?
- Additional global fields, e.g. CCs & such.
AWS account id could go into a global field, that only matches on AWS' site or similar.
The per-site fields are definitely an easier problem than 2. However, it seems that some work has been done by the chrome team to do detection, so maybe there is hope for more fields!
I have another idea for you to consider.
Today besides username and password the extension also supports OTP tokens configured in pass, but instead of trying to autofill this OTP token it simply puts it in a top right corner of the page.
The way it works is the following: you select an entry in browserpass, it will autofill username and password (if it can) and then additionally look in the decrypted entry for OTP code - if the file has OTP code, it will show it in such a dialog:
That allowed us to not struggle with detecting fields, and yet make the experience quite usable - there is a Copy button, which puts the number in clipboard in one click, and there is a close button which you click when you don't need that info anymore.
What if we just extend that dialog with more fields? Account ID, CC number, you name it.
Definitely less effort for implementation. There's a very lazy bone in my body which knows that per-site detection is an easier problem than global ones (because the pain is on the user).
Really like the idea of this for global account ids though! Especially as you could split up the CC multiple ways for different sites.
By the way, is this the login form where you want to input account name instead of username? link
Or there is a different form with all 3 fields visible at the same time?
3 fields simultaneously.
On 9 November 2017 13:15:45 GMT+00:00, Maxim Baz [email protected] wrote:
By the way, is this the login form where you want to input account name instead of username? link
Or there is a different form with all 3 fields visible at the same time?
-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/dannyvankooten/browserpass/issues/187#issuecomment-343150991
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Apparently the answer is both!
If AWS has no clue who you are, you are first prompted to enter account id separately. However, if you've logged in & logged out, you will be taken to a page with all 3 simultaneously.
So I can't link the page without it potentially revealing the account id (there's a lot of "stuff" in the URL that I don't really trust).
The thing is, when the form has only one field (the link I shared above), browserpass treats it as a username field. So if that was the only case, I would actually recommend to simply create two pass entries:
amazom.com/user.gpg
<password>
---
user: username
amazon.com/account.gpg
---
user: accountname
That would work for the link I sent, you simply first select amazon.com/account in browserpass, then proceed to the second form and select amazon.com/user in browserpass.
But this won't be as nice in the case with all 3 fields available. If #105 was implemented, it could have been tolerable, you could have selected amazon.com/user to fill the form and copied account name to clipboard from amazon.com/account entry.
What if there were a line, say auto_fill_format:, that could be used for exactly this occasion? It's a convention used by KeePass, and could be flexible enough to take any field. For example
somecomplexlogin.gpg
<password>
user: username
foo: usefulThing
auto_fill_format: <username><Tab><password><Tab><foo><enter>
Very interesting idea, although the browser will limit the possibilities quite a lot, for example I don't think it will allow extension to trigger key presses like Tab. In this regard, providing selectors is at least very easy to integrate in the extension itself.
Hello,
Regarding the very first thought by SevereOverfl0w, I wonder why we would need
browserpass_selector_XXX: input#account
XXX: XXXYYY
Why not simply implement the fact that when an input field matches a line in the pass entry, it is filled with the corresponding value?
The login page for my personal AWS account is https://maccagnoni.signin.aws.amazon.com/console : here we are redirected to the AWS signin page, with "maccagnoni" pre-filled in the account input. But when I log out from my personal account, I am redirected to this page again, then if I want to log in to my professional account, either I must retype the URL with my company name instead of "maccagnoni", or I must type my company name in the "account" field. browserpass could easily do the latter.
For instance, I could have the following line for the AWS login page:
account: maccagnoni
And then browserpass would fill any input field named "account" with "maccagnoni" whenever I select this entry in the pass menu. Easy configuration, easy implementation...
@tiramiseb The name alone isn't always enough to properly distinguish a form input (for example, if there are multiple forms on the page with fields which share a common name, or forms where the fields have no name [e.g. apps which submit the data via javascript and identify the field in some other way]).
The selector could be used as the field name in pass - but then it may have no obvious meaning when viewed by a human; selectors aren't always obvious (for example, something that claims to be //form[2]/input[3] does not have an obvious intent). Using a separate line for the selector solves this issue.
There's the case where some later tool may wish to interpret "account" in a
different, desirable way. By keeping the two separate, you decomplect the
behaviour. The second is that some sites may not even have name="XXX" on
their inputs, especially with newer SPAs.
On 20 November 2017 at 08:46, Sébastien Maccagnoni <[email protected]
wrote:
Hello,
Regarding the very first thought by SevereOverfl0w, I wonder why we would need
browserpass_selector_XXX: input#account XXX: XXXYYY
Why not simply implement the fact that when an input field matches a line in the pass entry, it is filled with the corresponding value?
The login page for my personal AWS account is https://maccagnoni.signin.aws.amazon.com/console : here we are redirected to the AWS signin page, with "maccagnoni" pre-filled in the account input. But when I log out from my personal account and then log in to my professional account, either I must retype the URL with my company name instead of "maccagnoni", or I must type my company name in the "account" field. browserpass could easily do the latter.
For instance, I could have the following line for the AWS login page:
account: maccagnoni
And then browserpass would fill any input field named "account" with "maccagnoni" whenever I select this entry in the pass menu.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/dannyvankooten/browserpass/issues/187#issuecomment-345628271, or mute the thread https://github.com/notifications/unsubscribe-auth/AF2h2p2eoYOaL3YRTam38QobtNmJbgjnks5s4TyCgaJpZM4QPtED .
Yes, I get your point. My suggestion would not be usable in all contexts, but it could be enough for many situations, and it would be easy to implement. However I totally understand it would clutter the browserpass code. The original suggestion looks fine enough for me.
(btw, I hope you have remarked I have given the link for a 3-field page, which SevereOverfl0w could not reveal for security reason. Mine is my name, so whatever....... :) )
@tiramiseb If you feel strongly about it, you could always write a PR that adds this functionality as an option that defaults to disabled. That way people who have a compatible workflow can turn it on, but it doesn't get in the way of everybody else who might see things differently, and it doesn't open up a potential exploit vector for those who receive the feature without realising it via an update.
Well, I have so much other stuff going on, I don't think I would have time to do that :/ It really was just a question/suggestion, moreover I would prefer using a solution that would satisfy everyone :)
@tiramiseb To expand on my security point above - the main potential issue I'm seeing here is increased exposure to XSS attacks. For example, if I can inject a field named 'totp-secret` into the site on which I wish to compromise your account, and browserpass then obligingly autofilled it accordingly...
Again, PassFF has this feature. It's not terribly complicated, and it's incredibly useful indeed.
There are cases where the OTP style copy-and-paste input is more useful and others where the browserpass_selector_XXX querySelector style are more effective.
I've got a site that requires an answer to a randomly picked security question on each login. It'd be very useful to be able to list the 5 or so questions and copy their answers to paste into the box.
~~I might try to make some time to experiment with this and get a pull request.~~
Here is an example of a login page requesting three token for login (Name, Surname and Passord, in German: Vorname, Name, Password):
http://www.abf-iva.de/cgi-bin/db.cgi?auth_logon_screen_op=yes
Another example to add to the list is Dovico: https://login.dovico.com/#Login
It requires a 'Company' field which I always forget which spelling to use for my company :P
Other two examples where this feature would be great:
- The italian "Agenzia delle Entrate" - Revenue Agency requires an username, a password (a secret the user can choose/change), a pin (a static secret provided by government in an envelope), https://telematici.agenziaentrate.gov.it/Main/login.jsp :
]
In PassFF is enough to append "codicepin: 123456789" to the pass file to have it autocompleted, and when you have to access tax online services for several people (i.e. members of a family) is very convenient to have auto-completion.
- A more complex example is MediaLibaryOnline: https://www.medialibrary.it/home/cover.aspx , a catalog of digital contents accessible for registered users of public libraries, where you have a drop-down menu to select the library your account belongs to. I never managed, also with PassFF, to have the drop-down menu entry correctly selected (I fear there is some js that make completion very hard)
