Bitcoin Forum
May 28, 2017, 08:18:57 PM *
News: Latest stable version of Bitcoin Core: 0.14.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2] 3 4 5 6 7 8 »  All
  Print  
Author Topic: [BIP][Draft] BitID - "Connect with Bitcoin" protocol  (Read 21226 times)
renee25
Member
**
Offline Offline

Activity: 74


View Profile
April 10, 2014, 05:54:02 PM
 #21


Yup, when updating to 0.9.0 on my main wallet, I:

  • Checked certificate/signature for bitcoin.org
  • Verified SHA256.asc file
  • Ran the hashing checksum on the tarball


irony mode off


fixed

Don't donate me: donate to nmc re-base development project.
1496002737
Hero Member
*
Offline Offline

Posts: 1496002737

View Profile Personal Message (Offline)

Ignore
1496002737
Reply with quote  #2

1496002737
Report to moderator
1496002737
Hero Member
*
Offline Offline

Posts: 1496002737

View Profile Personal Message (Offline)

Ignore
1496002737
Reply with quote  #2

1496002737
Report to moderator
1496002737
Hero Member
*
Offline Offline

Posts: 1496002737

View Profile Personal Message (Offline)

Ignore
1496002737
Reply with quote  #2

1496002737
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
NanoAkron
Sr. Member
****
Offline Offline

Activity: 252


View Profile
April 10, 2014, 11:04:41 PM
 #22


Yep, that's the problem. Also no websites using bitid:xxx
You need to make your system work with openid, because who is going to add another login scheme to their websites.


Because bitcoin has been featured in newspapers and on TV channels around the world, and OpenID hasn't.

User recognition is everything. If 'login with bitcoin ID' becomes a thing, micro payments will follow, and the ecosystem will grow even further.
schalk
Jr. Member
*
Offline Offline

Activity: 36


View Profile
April 11, 2014, 05:18:04 AM
 #23

I see merit in this idea. However propose the uri format below:

Request Uri:
bitid:auth?bitid_address=1FZp4L1EzCtwLPZxbvopwgqBwVDzox1nxA&bitid_callback=http://example.org/login?name=Schalk

bitid_address is an optional field. If bitid_address is not provided, it will allow the user to select from multiple addresses in their BitID Mobile App repository.
bitid_callback this is a required field and is the uri called after the bitid has done it's crypto magic.

Then the request uri is called, the BitId Mobile App will append a generated a nonce (a random string), the timestamp and the bitid_address to the callback uri yielding a uri like:
http://example.org/login?name=Schalk&bitid_nonce=e15f9428-e24c-4bf5-947f-0941cd604894&bitid_timestamp=1397192899&bitid_address=1FZp4L1EzCtwLPZxbvopwgqBwVDzox1nxA

the BitId Mobile App will then sign that uri and appended the signature to the uri yielding a uri like:
http://example.org/login?name=Schalk&bitid_nonce=e15f9428-e24c-4bf5-947f-0941cd604894&bitid_timestamp=1397193115&bitid_address=1FZp4L1EzCtwLPZxbvopwgqBwVDzox1nxA&bitid_signature=HI/AuQMCo2gC49u+523oqTJDbNTDB/JbsaPZyLHmoYx83f1+fY5OU1zXAuPRD8QW7VLmrtDpKt+G1/oyBeF7+1w=

the mobile phone will then open that uri, which in the above example would open the web browser on the device, but in the case of a uri like:
cointalk:?name=Schalk&bitid_nonce=e15f9428-e24c-4bf5-947f-0941cd604894&bitid_timestamp=1397193115&bitid_address=1FZp4L1EzCtwLPZxbvopwgqBwVDzox1nxA&bitid_signature=HI/AuQMCo2gC49u+523oqTJDbNTDB/JbsaPZyLHmoYx83f1+fY5OU1zXAuPRD8QW7VLmrtDpKt+G1/oyBeF7+1w=

This would launch the CoinTalk application and log the user in.

I introduced a timestamp as then you only need to keep track of a very limited number of nonces. Depending on how the server is setup, it might only allow timestamps which are up to a minute before the timestamp in the request, this means you only have to store the nonces for the last minute. If this timestamp field wasn't there you would have to store all the nonces since the user registered and compare against them each time.
fbueller
Sr. Member
****
Offline Offline

Activity: 412


View Profile
April 11, 2014, 10:37:19 AM
 #24

Do it with a BIP32 extended public key, and you would get a challenge for a different key every time.

Bitwasp Developer.
EricKennedy
Sr. Member
****
Offline Offline

Activity: 360

CEO, Ledger


View Profile WWW
April 16, 2014, 02:16:19 PM
 #25

The demonstration site now integrates the possibility of simulating wallet's response via a curl command.
http://bitid-demo.herokuapp.com/

You need to click on login to get a nonce and you can then build the callback :

Code:
curl -X POST http://bitid-demo.herokuapp.com/callback \
  --header "Content-Type: application/json" \
  --data '{"uri" : "bitid://bitid-demo.herokuapp.com/callback?x=6d9a980a07911624",
    "address" : "xxx",
    "signature" : "xxx"}'

The message to sign being for instance :

Code:
Bitcoin Signed Message:
bitid://bitid-demo.herokuapp.com/callback?x=6d9a980a07911624

When you send the POST to the callback URL, the front end will autolog.
The UX is very smooth.

What we need now is to have a first wallet implementing BitID.

Eric

EricKennedy
Sr. Member
****
Offline Offline

Activity: 360

CEO, Ledger


View Profile WWW
April 17, 2014, 12:39:38 PM
 #26

A ruby gem implementing challenge and signature management (for the back end) has been released today :
https://github.com/bitid/bitid-ruby

btchip
Hero Member
*****
Offline Offline

Activity: 628

CTO, Ledger


View Profile WWW
April 18, 2014, 05:08:17 AM
 #27

Starting to look into it as discussed, I have a minor concern with what's getting signed


The message to sign being for instance :

Code:
Bitcoin Signed Message:
bitid://bitid-demo.herokuapp.com/callback?x=6d9a980a07911624


because we end up considering the magic "Bitcoin Signed Message:\n" twice, once in the message we plan to sign, a second time by the wallet itself (which will sign specifically \x18 | Bitcoin Signed Message:\n | message size coded as a bitcoin varint | message) so it might look a bit confusing to the implementing party, and signing the URL alone looks closer to what you expected. What's your take on that ?

also, you can disregard the comment I made earlier during the discussion regarding the message length - this is now different in Armory and obviously a brainwallet brainfart  Smiley

EricKennedy
Sr. Member
****
Offline Offline

Activity: 360

CEO, Ledger


View Profile WWW
April 18, 2014, 08:42:09 AM
 #28

because we end up considering the magic "Bitcoin Signed Message:\n" twice, once in the message we plan to sign, a second time by the wallet itself (which will sign specifically \x18 | Bitcoin Signed Message:\n | message size coded as a bitcoin varint | message) so it might look a bit confusing to the implementing party, and signing the URL alone looks closer to what you expected. What's your take on that ?

Yes you are right. Another reason is that the content of the QRcode must starts by bitid:// otherwise the intent wouldn't be fired.
If this is confusing, it's because of the manual process, where I have to give to the user the exact text to sign using the message signing feature.

Where can I find more documentation about the "\x18 | Bitcoin Signed Message:\n | message size coded as a bitcoin varint | message" specifications ?
Cause I didn't know about the \x18 and the varint.

Also, do you know why it is not used when you sign a message in Bitcoin Core for instance ?
What is in fact the use case of adding "Bitcoin Signed Message" etc ?

Eric

EricKennedy
Sr. Member
****
Offline Offline

Activity: 360

CEO, Ledger


View Profile WWW
April 18, 2014, 10:58:31 AM
 #29

Ok, I cleaned all the confusion about "bitcoin signed message" stuff.
The BIP draft as well as all the code is now much clearer.

So basicaly what you always need to sign is the URI :

Code:
bitid://bitid.bitcoin.blue/callback?x=9b494d01b5034ed3

The "Bitcoin Signed Message" is integrated into the signing procedure (wallet side) and verifying (back end side).

Thanks for clearing this mess Smiley

Eric

EricKennedy
Sr. Member
****
Offline Offline

Activity: 360

CEO, Ledger


View Profile WWW
April 20, 2014, 07:15:56 PM
 #30

Android Bitcoin Wallet has a first implementation of the BitID protocol :
https://github.com/bitid/bitcoin-wallet

A short video showing the user flow :
https://www.youtube.com/watch?v=3eepEWTnRTc

Mitchell
Staff
Legendary
*
Offline Offline

Activity: 1456


Verified awesomeness ✔


View Profile WWW
April 20, 2014, 07:40:08 PM
 #31

Congrats dude! I really hope that more wallets implement it and that websites are going to use it.

NanoAkron
Sr. Member
****
Offline Offline

Activity: 252


View Profile
April 20, 2014, 07:42:05 PM
 #32

Android Bitcoin Wallet has a first implementation of the BitID protocol :
https://github.com/bitid/bitcoin-wallet

A short video showing the user flow :
https://www.youtube.com/watch?v=3eepEWTnRTc

Very good demonstration of a very good idea.

How are discussions progressing with the Core developers to get this pulled into an upcoming version as an additional Core functionality?
dewdeded
Legendary
*
Offline Offline

Activity: 924


Monero Evangelist


View Profile WWW
April 20, 2014, 08:40:20 PM
 #33

Where is the problem for this solution?

There are more then enough avaible (or dead) auth methods/projects. No need to bloat the Core(!) client with this and no need to waste the time of the core devs.

Code your own tool/client/fork whatever IHMO.
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2268



View Profile
April 20, 2014, 09:17:30 PM
 #34

Did you consider using a stealth address instead of the public address for the initial connection request (which is in plain text) ?

EricKennedy
Sr. Member
****
Offline Offline

Activity: 360

CEO, Ledger


View Profile WWW
April 20, 2014, 09:51:50 PM
 #35

Did you consider using a stealth address instead of the public address for the initial connection request (which is in plain text) ?

If the address is created on the fly at the initial connection request and is therefore not linked to anything, what would be the benefit of using a stealth address ?
I may not correctly grasp the concept of stealth address but I can't see how they could add any privacy advantage in this particuliar setup ?

NanoAkron
Sr. Member
****
Offline Offline

Activity: 252


View Profile
April 20, 2014, 10:35:49 PM
 #36

Where is the problem for this solution?

This has the potential to bring 2FA-level security to every login, without the need for a centralised service.
EricKennedy
Sr. Member
****
Offline Offline

Activity: 360

CEO, Ledger


View Profile WWW
April 21, 2014, 10:58:43 AM
 #37

There is now a Python implementation of the back end library :
https://github.com/LaurentMT/pybitid

Presentation of BitID metadata (leveraging BIP70, allowing 2FA, ...) :
https://github.com/bitid/bitid/blob/master/bitid_metadata.md

ecrick3
Newbie
*
Offline Offline

Activity: 23


View Profile
April 21, 2014, 11:01:55 AM
 #38

any1 try Python implementation yet?
laurentmt
Sr. Member
****
Offline Offline

Activity: 386


View Profile
April 27, 2014, 05:41:11 PM
 #39

any1 try Python implementation yet?
Hi ecrick3,
laurent here (the guy who started to wrote the python implementation). Since the first release on github, I've done some more tests and modifications to strenghten the library. Moreover, there's now a python implementation of the demo app written by EricKennedy in ruby. You can get the code here. I've tried to comment the code as much as possible to illustrate the different steps of the protocol. If you're a python developer and interested to participate in the development, you're also very welcome ! Smiley
gacrux
Newbie
*
Offline Offline

Activity: 22


View Profile
April 28, 2014, 04:27:22 AM
 #40

A big problem on the internet today is the cheapness of identity. Many sites struggle with a constant influx of trolls and sock-puppets. We attempt to address this with:
* Forum reputation systems - but there's still no easy way for a new user to prove they have anything invested in their identity.
* The ubiquitous CAPTCHA, just to establish that a visitor is a human - the very lowest bar we can put up, and even that is constantly being eroded, and causes problems for visually impaired users.

If I'm using a bitcoin address to sign in to a website, the site now has some extra information about me:
* the amount of BTC I control with that address
* the coin age

Or, put another way, the site can predict:
* the number of "Bitcoin Days Destroyed" that would occur if I were to hypothetically move the coins to another address I control in a self-payment.

So an address with 2 BTC in it for the last 5 days gets a score of 10, an address with 0.5 BTC in it for the last 21 days gets a score of 10.5, etc.

If this score is high enough you don't need to bother me with a CAPTCHA. You can also initialise forum reputation based on this score, etc etc. It'd be useful for all kinds of applications where anonymous identity is desired but the cheapness of identity creation causes problems (eg. distributed markets?)

Of course, I don't want to keep a significant balance in a wallet accessible by my browser. But I could:
* sign my BitID address with my main (perhaps offline) wallet address(es)
* provide these signatures to the server while negotiating BitID login

The server could then establish a score for my identity (coins in signatory addresses * coin age) - the higher the score, the less likely I am to be engaging in abusive behaviour. If I do engage in abusive behaviour then:
* the server adds all the signatory addresses to a blacklist (either internal, or perhaps shared with other sites somehow)
* assigns a zero/negative score to any BitID that provides any blacklisted signature upon login in future

If I wanted to dodge the blacklist and continue to engage in abusive behaviour, I'd need to move the coins to a new address. This effectively resets my "Bitcoin Days Destroyed" score to zero, and I need to wait for it to accumulate again, thus braking (rate limiting) my behaviour.

How high the bar needs to be (score of 5? 100? 0.1?) would be established by individual site operators for their own sites through trial and error.

Please consider extending your BIP to cover this. It would provide an additional factor to motivate adoption of your authentication scheme for relatively little added cost.

PGP:  *Link Removed*
Pages: « 1 [2] 3 4 5 6 7 8 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!