Password requirements less stringent & CashID

Administration
#1

I received external feedback from @JonathanSilverblood (assuming future alias) about the forum’s minimum password length, which is set by default to 10 characters.

He recommended two options (non-exclusive):

  1. Make password requirements less stringent (8 characters).
  2. Implement CashID, so users don’t need a password.

About the first option, I would recommend checking these both links first:


About the second option, it would be great to have CashID implemented at the forum, but we need someone with the skills to do it. @JonathanSilverblood mentioned he could be available to assist and review involved code.

I just wanted to mention here both proposed options and get forum’s feedback.

#2

What language/platform does this forum use?

I might be able to assist with the CashID implementation.

Edit:
I’m pretty shit at keeping up to date with Social Network notifications, but feel free to reach out on Telegram directly:

1 Like
#3

As will Tobi B (of lazyfox.io), you guys can have a chat. :slight_smile:

#4

Thanks @jimtendo.
Bitcoin Cash Research uses Discourse platform.
Here their Github.
In terms of languages: Ruby and JavaScript.

Thanks @im_uname for the recommendation.

#5

Hi all,

Was speaking with Leandro a bit earlier around this on Telegram.

I’ve been wanting to build a project around CashID for quite some time as I think it’s an excellent authentication method (thank you @jonathansilverblood). One of the difficulties in implementing CashID is that it requires the browser to listen persistently for the “authenticated” message from the server (e.g. long-polling/webhooks). It also requires a place to temporarily store the Challenge Request. Thus, there is some overhead in implementation that might make this difficult for some developers to implement easily.

To simplify implementation, an idea I had a while ago was to build something that could be self-hostable that allowed services to leverage CashID via OAuth/OIDC - as this means it could plug-n-play with many existing platforms (e.g. Laravel or anything else that supports OIDC). For background, OIDC is the protocol that you generally use when logging into third-party services using your Social Network account. The general (and simplified) flow is:

  1. Click Login with {Platform} button (in this case, “CashID”)
  2. Browser redirects to authentication page (in this case, it will show a CashID QR Code and Link)
  3. Upon successful authentication (in this case, user approves the login), user is redirected back to origin page.
  4. User is authenticated via the token provided by the service.

Although I have not thoroughly confirmed that Discourse supports OIDC, I did notice that OmniAuth is used - which appears to be an OIDC-supporting package. This means that the above approach ‘should’ be able to work for this.

The additional benefit of the above is that any other service that supports OIDC could also easily leverage this platform. My hope here is increased adoption by services due to ease of implementation which I hope will consequently lead to increased wallet support of CashID.

I do plan on hosting a publicly available instance of this CashID Authentication platform (e.g. cashid.infra.cash or similar), but the general advistory would be that any serious service should self-host an instance. The reason for this is that if a third-party service is leveraged as an IdP (e.g. cashid.infra.cash), then that service could potentially data-mine any users that authenticated with it (cashid.infra.cash will not do this - but it’s preferable if people did not have to take my word for it).

Before I begin working on this, I wanted to put out a feeler and see if anyone has any feedback and whether there would be any objections to taking this approach. I’ve been very vague on the technical details (some things would still need fleshing out), but can do a follow up to explain in more details (it’s basically just an OAuth/OIDC flow implementing CashID as Auth mechanism).

Thanks all, feel free to reach out on Telegram if any questions also.

#6

Hi all,

Just keeping everyone abreast with developments on this.

I’ve started work on the CashID OIDC Gateway and have made some good progress so far. The basics are working and a demonstration is available here:
https://cashid.infra.cash/oidc/auth?client_id=cashid.infra.cash&redirect_uri=https%3A%2F%2Foidcdebugger.com%2Fdebug&scope=openid%20name%20family%20nickname%20email%20country&response_type=code&response_mode=form_post&nonce=xbd4xjm2a6j&prompt=login

There are a few pieces of this code that still need to be completed, namely:

  1. Terminate OIDC Gateway session after login such that next time the Gateway is used, the user is reprompted for Auth (current work-around is to add &prompt=login, but this is not ideal). I will probably need to contact the author of the OIDC Provider I’m using to see how this can be done. Without this (and the prompt=login workaround), the behaviour is such that the user is remembered and not reprompted for Auth for X Minutes (currently 10m).
  2. The “accounts” (Challenge Response Payload) is stored in memory until the server is restarted - which is a potential security issue. In order to support OIDC “code” flows (whereby the account details are retrieved from the userInfo endpoint AFTER the OIDC redirect flow has taken place), I plan on expiring/clearing these accounts from memory 60 seconds after the OIDC redirect flow. This allows sufficient time for the UserInfo endpoint to be requested as this should happen almost immediately after Redirect Flow completes.
  3. Some security audits (disabling unused features, etc).
  4. Create a Docker Image for easy deployment (parameters like AppID and AppSecret are customizable via environment configs - will document how to deploy in README.md).

I will look at uploading the code to GitHub early next week for this once I have fixed some of the above.

From the Discourse end, what’s needed here is to test the behaviour of the OIDC plugin here:


I suspect the steps required for testing on Discourse should just be:

  1. Install the OAuth Plugin
  2. Point the configuration to:
    https://cashid.infra.cash/oidc/.well-known/openid-configuration
    (Later the expectation is that BitcoinCashResearch.org will host their own CashID Gateway instance)
    @emi_dm think you might be able to give this a whirl at some point?

Thanks all, will post back once I’ve placed the code on GitHub.

Cheers!

#7

I don’t see harm in reducing the password length to 8 if there is throttling on the login API per-username. Alternatively/Additionally, 2-factor can be fairly easy to establish (including compatibility with Google Authenticator)–I am personally a huge fan of 2-factor.

CashID sounds like a great idea as well, especially if the development resources are available to make it happen.

#8

Brief update on work being done available here:

2 Likes
#9

Hi all,

OIDC Gateway is now ready.

@emi_dm think you might be able to install the OpenID Connect plugin on Prod?

Details are as follows for configuration:

I can walk through the config with @Leandrodimarco though if need be.

1 Like