[BIP][Draft] BitID - "Connect with Bitcoin" protocol

[Falkvinge]

Some feedback - this part was not clear to me:

POST the signature, the URI and the public key to the callback URL

Specifically, in what standard format are the parameters passed? Using Json? Http headers? Encoded onto the Uri? What? A tangible example of the exact HTTP POST request sent from the client, byte by byte, would have been enormously helpful here. As is now, I'm blind on the server side - I don't know what data to expect and have to guess how the client sends its data?

[1713986603]

1713986603

[CIYAM]

I had also considered this exact idea (being a fan of QR codes) - IMO the main thing to really help this to happen would be the software to be available for smart phones and a smart phone that can be *permanently disconnected from all normal comms*.

I have read about (more or less) transparent Faraday cages so I am thinking that an inexpensive approach might be to use an old smartphone and such a Faraday cage to create an authenticator that never needs to be online.

[trasla]

I had also considered this exact idea (being a fan of QR codes) - IMO the main thing to really help this to happen would be the software to be available for smart phones and a smart phone that can be *permanently disconnected from all normal comms*.

I have read about (more or less) transparent Faraday cages so I am thinking that an inexpensive approach might be to use an old smartphone and such a Faraday cage to create an authenticator that never needs to be online.

I don't get it... How should me phone authenticate me to some server without contacting that server?

[CIYAM]

I don't get it... How should me phone authenticate me to some server without contacting that server?

It's really quite simple - to "sign up" your phone creates a public key that it displays as a QR code and you use the camera on your PC to *scan it*. Then it sends back a public key (for your account) along with a one time message as a QR code that you then scan with your phone. Your phone then *signs a message* with its private key for the public key (and the one time message) and displays that as a QR code - you now again show your phone to the camera and you are done.

When signing in at a later stage you first enter your username - it will then display a QR code that is the public key and one time message. You scan this with your phone and then it creates a QR code of the *signed response" which lets you "log in".

So your phone never needs internet access to do this (just needs a camera and a display).

It is not that much more difficult than a traditional login (especially if you consider 2FA) and it is 100% secure (getting people used to this idea is going to be the hardest part).

[trasla]

This makes the whole process more cumbersome plus forces me to have an offline phone just for signing in. People willing to take these hurdles could as well use a dedicated hardware device or some of the long available complicated options for secure authentication.
The beauty of bitid is that it requires only a mobile wallet and a very simple step. It's easy and get it for free if you use a mobile wallet anyway.

You could of course proxy the callback with some software reading from a QR code on the phone. But, you know, complicated more secure systems which don't get used improve  security less than systems which get used cause they are easy and still a hell lot better than this username  plus password crap we have today.

[EricKennedy]

Specifically, in what standard format are the parameters passed? Using Json? Http headers? Encoded onto the Uri? What? A tangible example of the exact HTTP POST request sent from the client, byte by byte, would have been enormously helpful here. As is now, I'm blind on the server side - I don't know what data to expect and have to guess how the client sends its data?

If you go here :
http://bitid.bitcoin.blue/login
And click on "manual", you'll get a curl example showing exactly how to POST on the demo server implementation.

[Falkvinge]

http://bitid.bitcoin.blue/login
And click on "manual", you'll get a curl example showing exactly how to POST on the demo server implementation.

Thanks, but that's not what I need. I'm trying to write a server-side implementation. I need to know what the client is sending to me, and to be honest, that's not specified. I'm in the blind. I'm trying to use a BitID client and just see whatever it is sending by pushing debug code out to production (accessible) servers. That's not how any development should be done but I'm given no choice right now.

In a spec, I'm expecting, and asking for something like this:

SAMPLE CLIENT LOGIN REQUEST

POST /Security/BitId HTTP/1.1
Host: bitid.example.com
Content-Type: application/json

{ "addr":"1dsfagahigaeguropiaasdazd","sign":"ÖIUYFQ(Et5yn9se8hgs8f9dghjf","callback_uri":"https://bitid.example.com","bitid_uri":"https://login.example.com" }

SAMPLE SERVER RESPONSE

200 OK
(a HTTP response)

Do you see where I'm coming from? It just says that four specific parameters are submitted as part of an HTTP POST. It doesn't say anywhere how those four parameters are encapsulated and encoded. I need to know that in order to implement this. (In this example, I wrote the spec part as if they were submitted using Json, which I don't think they are, but you get the point.)

Cheers,
Rick

[laurentmt]

Here's my notes, written while working on the python library. Hope it helps.

/callback

Request sent by the browser or the wallet as a response to a challenge Request can be sent in two formats: json or html form

Request

    Http method: POST

    Parameters:
        uri : string - required - bitid uri used as the challenge
        signature : string - required - signature of the bitid uri
        address : string - required - address used for authentication

    Headers:
        Content-Type : string - required = "application/json" if request sent by a wallet, otherwise server should assume a manual signing submitted via an html form (see demo)

Response

    Process completed

        Response format:
            address : string - required - address used for authentication
            nonce : string - required - session id associated to the authentication

        Http code: 200

    Process failed

        Response format:
            message : string - required(?) - message describing the error

        Http codes / messages:
            Invalid adress
                Http code : 401
                message : Address is invalid or not legal
            Address is valid but not associated to an existing account
                Http code : 401
                message : Address is invalid or not legal
            Invalid BitId uri
                Http code : 401
                message : BitID URI is invalid or not legal
            Invalid signature
                Http code : 401
                message : Signature is incorrect
            Illegal nonce
                Http code : 401
                message : NONCE is illegal
            Expired nonce
                Http code : 401
                message : NONCE has expired
            Server error (pb with db, ...)
                Http code : 500
                message :
            Misc error (specific to implementations by websites)
                Http code : 401
                message : [...]


/auth

Request sent by the browser to check if authentication has succeeded

Request

    Http method: GET

    Parameters: None

    Headers Cookie: stores the session id

Response

    Process completed

        Response format:
            auth : int - required - 1 if authentication successfully completed, otherwise 0

        Http code: 200

[Falkvinge]

Here's my notes, written while working on the python library. Hope it helps.

Thanks, it does! I found at least one reason my server doesn't pick up the response.

/callback

Does it have to be this (partial) URI, or is it just a header describing this section? That's unclear. I have been using a different URI, as I'm using the [WebMethod] feature of Asp.Net that lets you embed a Json-callable function on any page.

   Parameters:
        uri : string - required - bitid uri used as the challenge
        signature : string - required - signature of the bitid uri
        address : string - required - address used for authentication

Can we lock down that the parameters come IN THIS ORDER? That's not explicitly written, and some implementations (like C# which I'm using) are or can be order-sensitive, even with parameter names supplied.

Testing again now.

Cheers,
Rick

[laurentmt]

Sorry for the late answer. Was musing in the french subforum  

Does it have to be this (partial) URI, or is it just a header describing this section? That's unclear. I have been using a different URI, as I'm using the [WebMethod] feature of Asp.Net that lets you embed a Json-callable function on any page.

The uris "/callback" can be something else. The client should only rely on what it has received in the bitid_uri.
I think we've all followed a kind of implicit norm by reusing the same "/callback" uri but the protocol does not state any such rule.
EDIT: Here is an example of a different callback uri used in my 2FA demo (uses a "/tfa_activation_callback" uri)

   Parameters:
        uri : string - required - bitid uri used as the challenge
        signature : string - required - signature of the bitid uri
        address : string - required - address used for authentication

Can we lock down that the parameters come IN THIS ORDER? That's not explicitly written, and some implementations (like C# which I'm using) are or can be order-sensitive, even with parameter names supplied.

Ooops. That sounds like a more serious issue.
On its side, BitID protocol does not state any specific order for the parameters.
Main problem is that such a rule would have a direct impact for wallets developers.
Thus, I think it's better if Eric answers this point.

I may be wrong but to my knowledge, there's no notion of order in json. A lib forcing an order for json content seems to me like a bad implementation of json.

[Falkvinge]

Ok, now I know exactly what the HTTP request from Onchain looks like (which works against the BitID demo). No wonder I couldn't get it to work. The phone app doesn't use Json at all, but does a full webform post.

This is what I was asking for in the spec as a sample:

POST http://dev.swarmops.com/Security/BitId.aspx HTTP/1.0
Content-Length: 272
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip
Host: dev.swarmops.com
User-Agent: android-async-http/1.4.4 (http://loopj.com/android-async-http)

signature=H2ooalc68rfcS%2FnEIrrCH2zUKYvjIuj%2Bp9DoQoVVkW39R3wVfNnbO7Pmd4UdkNf6FpQ%2FUGV3pfm4vrE9541za%2Fg%3D&uri=bitid%3A%2F%2Fdev.swarmops.com%2FSecurity%2FBitId.aspx%3Fx%3D4b593383a4674b83b31d066e0e87e60f8d1c1df565f568f%26u%3D1&address=14fRQCbR62EGzjPQks9XRAVRiqWhftn3dA

And here I was trying to interpret Json and wonder why the server did absolutely nothing...

[Falkvinge]

Ooops. That sounds like a more serious issue.
On its side, BitID protocol does not state any specific order for the parameters.

I may be wrong but to my knowledge, there's no notion of order in json. A lib forcing an order for json content seems to me like a bad implementation of json.

I would agree with this and I'm not certain this is even the case. I'm on a wild goose chase for bugs at this point to find out why my implementation isn't responding.

Cheers,
Rick

[cbeast]

Do we have any idea (best wild-ass guess) when bitID may be available in the mainline Android client, something even marginally better than "between yesterday and in two forevers"?

In the case of Mycelium, we have a working demo in our dev build, but we are going to hold off until we get HD wallets finished. Reason is that without, your BitID will only be tied to a single address, and with HD you will be able to have a different ID for different sites, all coming from the same seed used for your bitcoin addresses.

This is big.

[trasla]

This is big.

It is enabled in the mycelium testnet app, if you want to try.

[laurentmt]

Ok, now I know exactly what the HTTP request from Onchain looks like (which works against the BitID demo). No wonder I couldn't get it to work. The phone app doesn't use Json at all, but does a full webform post.

Interesting. I thought that all wallets were using json format to send these parameters but it's true that it's not a requirement made by the protocol.

This is what I was asking for in the spec as a sample:

POST http://dev.swarmops.com/Security/BitId.aspx HTTP/1.0
Content-Length: 272
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip
Host: dev.swarmops.com
User-Agent: android-async-http/1.4.4 (http://loopj.com/android-async-http)

signature=H2ooalc68rfcS%2FnEIrrCH2zUKYvjIuj%2Bp9DoQoVVkW39R3wVfNnbO7Pmd4UdkNf6FpQ%2FUGV3pfm4vrE9541za%2Fg%3D&uri=bitid%3A%2F%2Fdev.swarmops.com%2FSecurity%2FBitId.aspx%3Fx%3D4b593383a4674b83b31d066e0e87e60f8d1c1df565f568f%26u%3D1&address=14fRQCbR62EGzjPQks9XRAVRiqWhftn3dA

If you have some time, send me a PM with your comments/fixes about the draft in my previous post. I'll gather everything and send it to Eric to get something on github.

And here I was trying to interpret Json and wonder why the server did absolutely nothing...

Arfff. I know this feeling when you spend time looking for the causes of a bug and finally notice that you didn't look at the right causes. I fear it's the curse of all developers. 
By the way, it's great that you work on this integration of BitId with C#. It's a great platform and I expect we see more .NET bitcoin projects thanks to efforts like yours or NBitcoin.

[Falkvinge]

Two things:

It works.

It's wonderful.

I love this. I'm logged in to Swarmops (my current project) before my phone has even confirmed it has transmitted the signed nonce. This is as smooth as Lastpass' autologins, except 2FA since it combines what you have with what you know (your phone's password, in this case).

If anybody wants to copy my C#/Asp.Net code, feel free. The relevant parts are easy to extract from Login and BitId here:
https://github.com/Swarmops/Swarmops/tree/master/Site5/Security

They may still be a little unstable with regards to threading on Mono (which sometimes cuts a request short and strange things like that), but the code works at a prototype level.

Cheers,
Rick

[laurentmt]

They may still be a little unstable with regards to threading on Mono (which sometimes cuts a request short and strange things like that), but the code works at a prototype level.

Not sure it will help with your issues but you may have to send additional headers to solve a problem specific to I.E. (I.E. caches XMLHttpRequest responses).
From my souvenirs, the problem was with the '/auth' call.

'Last-Modified' = '<DateTime.Now>'
'Cache-Control' = 'no-store, no-cache, must-revalidate, post-check=0, pre-check=0'
'Pragma' = 'no-cache'

[lonelyminer (Peter Šurda)]

libpam-bitid: A PAM module to use a bitcoin address for credentials.

This is a linux PAM implementation of the BitID protocol. Linux system access is granted using just a bitcoin address.

After a long fight, I managed to add QR code output and http callback to Jay's libpam-bitid. Now you can use your mobile phone to authenticate a ssh session. It works for sudo as well, and probably anything that can output the QR code into the terminal. It probably wouldn't work for a graphical session manager / screensaver.

You can find the fork at https://github.com/PeterSurda/libpam-bitid

Cheers,
Peter

[lonelyminer (Peter Šurda)]

After a long fight, I managed to add QR code output and http callback to Jay's libpam-bitid. Now you can use your mobile phone to authenticate a ssh session. It works for sudo as well, and probably anything that can output the QR code into the terminal. It probably wouldn't work for a graphical session manager / screensaver.

I made a youtube video to show how cool it is: https://www.youtube.com/watch?v=U6I4HuzSTM0.

[marcus_of_augustus]

After a long fight, I managed to add QR code output and http callback to Jay's libpam-bitid. Now you can use your mobile phone to authenticate a ssh session. It works for sudo as well, and probably anything that can output the QR code into the terminal. It probably wouldn't work for a graphical session manager / screensaver.

I made a youtube video to show how cool it is: https://www.youtube.com/watch?v=U6I4HuzSTM0.

this is pretty cool.