How to autofill OpenID

[mcnesium]

Are there any clues on how to store an OpenID identifier in the passwordstore so that Browserpass can detect and autofill the URL into the form?

Examples: Gitea, OSM, Stackoverflow, GNUSocial

[max-baz]

We could treat OpenID URL as username, with such change you can store url in the user: part of your passwordstore entry.

I even put OpenID as the first priority, so if this field is present, it will be filled-in first, otherwise the "username" field will be filled in - this is to help with sites like Stackoverflow, where both OpenID URL and username are visible at the same time.

What do you think?

[mcnesium]

That sounds like a good workaround for now.

But for the long run it feels wrong to have something in the store that is labeled user but is not a user in fact. Isn't it possible to have an openid field in the file?

$ pass www/stackexchange/mcnesium
1234567890XYZ
user: mcnesium
openid: https://id.mcnesium.com
urls:
  - stackoverflow.com
  - askubuntu.com
  - superuser.com
# hypothetical example, do not use! #

This way it is possible for sites to keep both user/pass and OpenID provider in the same file

I know the YAML list syntax is rather offtopic here and not supported by browserpass (yet). But if browserpass would be able to detect urls this way instead of from the file path, we could have one file with the openid in it and then just add sites where it should be used.

[max-baz]

Retrieving yet another field is not a problem at all, the parsing is here:

https://github.com/dannyvankooten/browserpass/blob/1e464970a3a3b00a5679482177db7b3d5fe98a95/browserpass.go#L176-L187

But then this data needs to be propagated to the browser extension, and then there is some work needed to make openid fields filled with openid values. All in all I must warn you, it's not a trivial change 🙂

I don't think I'll have time to implement it, would you like to make a PR?

Alternatively we can close this issue by making openid part of the username, until someone arrives who wants to implement openid as a separate field.

---

Support for urls in your example will likely never be implemented, because in order to retrieve these urls browserpass will have to decrypt every single file in your repository. This is just too long and inefficient. You might have an SSD and decrypting entire .password-store takes only a few seconds, but a few seconds is still a long time, and external security devices (e.g. YubiKey) are much slower at decrypting. I have a YubiKey myself, and I measured once, decrypting my entire .password-store (which has ~100 files) takes a few minutes.

[mcnesium]

I see, that sure is a problem. It was just a thought that came to my mind while typing that. So go ahead and openidify the username part. That should be fine for now…

[max-baz]

I tested #210 on your 4 examples, the results are:

• Gitea: good, since URL is the only visible field
• OSM:
  • if you don't click on OpenID, fills in login and password (as expected)
  • if you click on OpenID, fills in OpenID and password (which is acceptable), but focus is on the wrong button (there are two submit buttons). A little bit annoying, but this would be hard to properly implement anyway even if OpenID was treated as a separate field. If you have autoSubmit enabled in the options of this extension, you may want to disable it.
• Stackoverflow:
  • if you don't click on OpenID, fills in login and password (as expected)
  • if you click on OpenID, fills in OpenID and password (which is acceptable). There is only one button, so everything works as expected.
• GNUSocial: good, since URL is the only visible field

Is this acceptable behavior to resolve this issue? Do you have more examples to test? Feel free to test yourself:

• chrome-browserpass.crx.zip
• firefox.zip

[max-baz]

Also, related: https://github.com/dannyvankooten/browserpass/issues/187

[mcnesium]

Sorry, I missed your last request. I guess your implemented behavior is fine, given the heterogeneous environment situation. Unfortunately, very few sites and services make use of decentralized SSO solutions these days, but I will report if I discover more of them.

Thank you again for your great work!

[max-baz]

https://ticket.coreboot.org/login is an example of why current implementation is not perfect, I'm reopening to reconsider supporting a dedicated openid field in v3.