Support multiple fields beyond username/password

[dragon788]

I couldn't find another issue outlining this, but with eg the LastPass browser plugin I can define additional fields and data to fill or alternate names for the elements so what one place calls identity another place calls username and another place calls email. Changing what the username is named in the YAML per site doesn't bother me, but in some cases I need multiple pieces of information across 3+ fields to actually authenticate with a service, with a specific example being https://signin.aws.amazon.com where you need to supply an Account ID or alias in addition to your username and password, or when filling a site that has an MFA/2FA field and gopass is configured to sync with that and could potentially fill that field as well.

I would hope that storing my information with matching names to the input field or div containing one would work.

SuperSecretP@ssw0rd
---
account: myBusinessUnit
username: myUserName

Snippets I pulled from the page with Chrome DevTools XPath //*[@id="input_account"] Selector #input_username OuterHTML

<div class="textinput" id="input_password">
                          <label for="password">Password</label>
                          <input id="password" name="password" type="password" autocapitalize="off" autocorrect="off" comment="....snipped large base64 blob"; background-repeat: no-repeat; background-attachment: scroll; background-size: 16px 18px; background-position: 98% 50%; cursor: auto; border: 3px solid blue;">
</div>

[martinhoefling]

First of all, thx for the idea. AWS is so far my only site where I have the same issue. One thing that should help in the future is the ability to display "secret details", as described in #26.

Concerning additional fields to be filled in: So how would you store the information in yaml? XPath Selector + value?

fields:
  - selector: //*[@id="input_account"]
    value: my-account

Does that make sense?

[dragon788]

I think the XPath stuff could maybe be hard coded into the extension or in the extension options rather than repeating across every site entry and then if a YAML key name matches an ID on the page that the XPath finds and a k:v like additional_fields: true exists that the extension can check to avoid filling in random form fields unexpectedly.

This could pay the groundwork to maybe expand the bridge into a kind of form filler as well, but that's beyond the scope of this initial request.

[martinhoefling]

OK, got it. This would only allow to input fields that have an id, right? https://github.com/martinhoefling/gopassbridge/blob/master/web-extension/content.js already has some methods to deal with non id fields. Would it make sense to just use the key instead of loginInputIds? Further, I still would prefer to explicitly list "additional fields". How about:

login_fields:
  input_account: myaccount

Those fields can be sent from gopass in addition to the normal username and are can be written last by gopassbridge. @dragon788 what do you think?

[dragon788]

The extra YAML structure could definitely be handy for both enabling the feature as well as providing the data to be filled in. Brilliant thinking!

[dragon788]

Coupled with https://github.com/justwatchcom/gopass/issues/785 this will make life a lot easier for those who log into sites that require more than just a username and password.

[dragon788]

What could be even cooler (way down the road) is the ability to use the OTP generation of gopass to fill in the 2nd factor fields as well, since it is more likely they could get your username and password from somewhere (keylogger/sniffing) but won't have your 2FA.

[martinhoefling]

@dragon788 my personal opinion is that the 2nd factor (secret to generate totp token) should not be stored alongside with the first one. But I don't mind supporting the case if someone want's to implement it, as gopass is supporting it as well.

[martinhoefling]

https://github.com/gopasspw/gopass/releases/tag/v1.8.5 has been released with gopass api changes

[ghost]

Is OTP support enabled in the Bridge?

[Pharb]

@Spass1966 Yes, TOTP codes should be shown in the detail view of a gopass entry which has the "totp" attribute set (click this icon to expand it). The code should be shown as "current_totp" and you can click on it to copy it to your clipboard. Currently it will not be auto-filled into a website.

You need gopass v1.8.3 or newer for this to work (gopasspw/gopass#975). See also #87.

[espoelstra]

I just ran into an issue today where the gopass create flow that offers to help store an AWS Access Key entry is incompatible with gopass-bridge due to the wizard using the first line "password" field for the SECRET_KEY instead of the password. I'd hoped adding a password: entry might be preferred by gopass-bridge to the first line, but it doesn't appear to be the case currently.

@martinhoefling what are your thoughts? I'm debating whether to suggest to the gopass devs that they should store the secret key differently, or could gopass-bridge search for a password: in the entry and prefer that to the 1st line secret? In my opinion I'd rather either have the access/secret keys as a separate entry anyways, and I thought it was odd they still prompted for a username since the secret keys provide access without requiring a username, but some people may prefer to keep them together, though that makes it much harder to rotate the secret portion with gopass generate aws/accountid/youraccount.

For now my workaround will be to move the SECRET_KEY to a secret_key: entry and put the password on the first line, and then I can just env AWS_ACCESS_KEY_ID=$(gopass show -o aws/account_id/myaccount access_key) AWS_SECRET_ACCESS_KEY=$(gopass show -o aws/account_id/myaccount secret_key) aws s3 ls or export the variables for the duration of my session.

[espoelstra]

Aha! It just struck me, having the SECRET_KEY as the first line "password" doesn't make any sense, because you can NOT run gopass generate aws/accountid/youraccount because the SECRET_KEY is supplied by AWS as well as the ACCESS_KEY, so it would be better to put them as access_key: and secret_key: and leave the first line for your account password.

[leogott]

To merge Issue #196 into this one: Gopass-Bridge should be able to handle the specific case when one secret contains e.g. both email and username fields, but different login-forms sharing the same secret only ask for one.