Bitcoin Forum
April 23, 2024, 07:27:55 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 [5] 6 7 8 »  All
  Print  
Author Topic: [BIP][Draft] BitID - "Connect with Bitcoin" protocol  (Read 22684 times)
ALL IN
Newbie
*
Offline Offline

Activity: 16
Merit: 0


View Profile
August 05, 2014, 01:35:23 AM
 #81

Of course, remember that if you're writing Bitcoin software, it's really easy to be in a situation where millions of dollars worth of value are controlled by your software. That's why the Bitcoin sourcecode and binaries are protected by both OpenPGP and CA's.

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

And I do not see a reason not to check the website certificate, even if it's the simplest/weakest security on offer. You want every assurance you can get if it's where most of your coins are stowed. Should really go to the CA website and try to find fingerprints to compare with manually, but I think the browser is doing that automatically anyway, so it would be a peace of mind thing more than anything.

i think it will automatically when evertime connect and some defense for big bucks in cold walletthats important to . to save money in the right place
1713857275
Hero Member
*
Offline Offline

Posts: 1713857275

View Profile Personal Message (Offline)

Ignore
1713857275
Reply with quote  #2

1713857275
Report to moderator
1713857275
Hero Member
*
Offline Offline

Posts: 1713857275

View Profile Personal Message (Offline)

Ignore
1713857275
Reply with quote  #2

1713857275
Report to moderator
1713857275
Hero Member
*
Offline Offline

Posts: 1713857275

View Profile Personal Message (Offline)

Ignore
1713857275
Reply with quote  #2

1713857275
Report to moderator
There are several different types of Bitcoin clients. The most secure are full nodes like Bitcoin Core, but full nodes are more resource-heavy, and they must do a lengthy initial syncing process. As a result, lightweight clients with somewhat less security are commonly used.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
fran2k
Hero Member
*****
Offline Offline

Activity: 784
Merit: 500


View Profile WWW
August 07, 2014, 01:58:47 AM
 #82

This is awesome, great work.
Razick
Legendary
*
Offline Offline

Activity: 1330
Merit: 1003


View Profile
August 10, 2014, 02:58:27 AM
 #83

I'm really happy to see this. I came up with a similar idea on my own and am planning to implement it in a project I am working on. The fact that some of the work has already been done for me is terrific.  Grin

ACCOUNT RECOVERED 4/27/2020. Account was previously hacked sometime in 2017. Posts between 12/31/2016 and 4/27/2020 are NOT LEGITIMATE.
Rassah
Legendary
*
Offline Offline

Activity: 1680
Merit: 1035



View Profile WWW
August 14, 2014, 04:32:31 AM
 #84

Can someone please explain why SQRL was not sufficient, and what BitID fixes over that?
gweedo
Legendary
*
Offline Offline

Activity: 1498
Merit: 1000


View Profile
August 14, 2014, 04:47:41 AM
 #85

Can someone please explain why SQRL was not sufficient, and what BitID fixes over that?

SQRL and BitID, are basically the same thing, just one uses bitcoin addresses. Also since bitcoin addresses are becoming more ubiquitous it would be a better way.

Technically we could also ask the question why not use PGP keys?
EricKennedy (OP)
Sr. Member
****
Offline Offline

Activity: 360
Merit: 250

CEO, Ledger


View Profile WWW
August 14, 2014, 06:18:36 AM
 #86

BitID is SQRL scoped to the Bitcoin realms.
The main advantage is that if all wallets implement BitID then everyone will benefit of the possibility to sign in with their address.

Rassah
Legendary
*
Offline Offline

Activity: 1680
Merit: 1035



View Profile WWW
August 14, 2014, 01:27:39 PM
 #87

Then how come people on the Internet's are saying that SQRL is superior to BitID, and BitID has some bugs, security issues, or shortcomings that SQRL does not?
EricKennedy (OP)
Sr. Member
****
Offline Offline

Activity: 360
Merit: 250

CEO, Ledger


View Profile WWW
August 14, 2014, 03:05:18 PM
 #88

It doesn't make a lot of sense to compare SQRL and BitID in terms of who is superior to whom. Outside of Bitcoin realm, BitID doesn't make any sense ; so yes you could say that SQRL is "better".

Anyway BitID is not trying at all to compete with SQRL.

About security issue, I guess they are the same than SQRL (middle man attack). I'd be glad to answer more precisely on specific questions.

Rassah
Legendary
*
Offline Offline

Activity: 1680
Merit: 1035



View Profile WWW
August 14, 2014, 03:38:34 PM
 #89

It doesn't make a lot of sense to compare SQRL and BitID in terms of who is superior to whom. Outside of Bitcoin realm, BitID doesn't make any sense ; so yes you could say that SQRL is "better".

Anyway BitID is not trying at all to compete with SQRL.

About security issue, I guess they are the same than SQRL (middle man attack). I'd be glad to answer more precisely on specific questions.

Sorry, I meant, could someone explain why we couldn't just implement SQRL itself with bitcoin keys, and needed to come up with something different like BitID?
laurentmt
Sr. Member
****
Offline Offline

Activity: 384
Merit: 258


View Profile
August 14, 2014, 04:57:25 PM
Last edit: August 14, 2014, 06:20:35 PM by laurentmt
 #90

It doesn't make a lot of sense to compare SQRL and BitID in terms of who is superior to whom. Outside of Bitcoin realm, BitID doesn't make any sense ; so yes you could say that SQRL is "better".

Anyway BitID is not trying at all to compete with SQRL.

About security issue, I guess they are the same than SQRL (middle man attack). I'd be glad to answer more precisely on specific questions.

Sorry, I meant, could someone explain why we couldn't just implement SQRL itself with bitcoin keys, and needed to come up with something different like BitID?
People like to say that nobody should reinvent the wheel and that one should support the existence of standard protocols. That's without any doubt a good engineering principle. I agree with that. The problem is that it's a pure technical vision of things which doesn't take into account incentives provided by a technology. As far as I know, Eric never claimed that he had invented a new authentication schema. He has come up with a damn simple protocol and a nice implementation which offer strong incentives to integrate this schema in consumers product (wallets, websites, ...).

It's not a secret that our digital life is filled of kinks (see "Motivation" chapter in this document) even if:
- technologies allowing "anonymous" authentication with public/private keys exist for decades
- PGP exists for decades
- SQRL exists for almost one year

After its announcement, in less than 3 months:
- BitId is supported by different languages and platforms (cms, wikis, ...) thanks to independant devs who spent a little time to develop libs and plugins
- some people (who are not devs) start to offer bounties to have bitid integrated in their favorite tools
- BitId has started to been integrated in "consumer products" (dark wallet, mycelium)
- BitPay has open sourced its own version of a similar schema after announcements by dark wallet and mycelium

This was made possible because BitId offers strong incentives to developers:
- it's easy and fast to integrate in existing products
- it relies on the crypto stack already used by bitcoin
- efforts done to secure the coins also secure the authentication keys
- security can be easily reviewed
- It's an open protocol. Everybody is welcome to participate

At the end, the important point is not which protocol is used but the fact that people can experiment by themselves that digital life is not doomed to be a perpetual privacy leak. And the more people experiment this reality, the more developers will be incentivized to expand BitId or integrate others protocols like SQRL in their products.

IMHO, the most important strength of BitId is that it provides the needed incentive to initiate the "avalanche".

On the technical side, here are a few points:
  • internet is full of people who like to criticize ideas. Critics are good and necessary. But always ask them this simple question : did you read specifications, source code of the thing you criticize ?
  • all things which can be done by SQRL can be done by BitId
  • BitId is versatile:
    • you can generate keys for each website/system you want to sign and get "anonymous" authentication
    • you could use future systems like SINs which establish your online identity and sign in with this unique identity
    • as proposed by some people in this thread, you could link authentication rights with some bitcoin address used for a transaction or owning some coins. Basically, your authentication rights are linked to a proof of stake or a proof of payment. Definitely something which can't be achieved with SQRL
wbaw
Member
**
Offline Offline

Activity: 62
Merit: 10


View Profile WWW
August 16, 2014, 03:52:39 AM
 #91

Sorry, but NameID does both, you're repeating work. You can log in using NameID to prove you own the Namecoin address linked to your Namecoin ID information. That's how it has worked for a while.
You're right but there's an important difference between NameId and BitID:
  • NameID relies on OpenID which is a nice system but requires a third-party (the identity provider) to let you authenticate.
  • With BitID, no third-party is required. It's just your wallet and the website.

Both systems have their strengths and their weaknesses. It's a matter of choice.

No, you're still misunderstanding, nameid.org just uses openid as an example, it doesn't rely on openid at all, it relies on Namecoin ID. The php source code for nameid.org is open, you could use that auth mechanism on your own website as is, without openid, or reimplement it in another language. It sends a message, you sign it with the key used for your namecoin id, the site checks the signature & logs you in. It works almost exactly like BitID, but pre-dates it & allows you to link it to your ID information stored in Namecoin.

laurentmt
Sr. Member
****
Offline Offline

Activity: 384
Merit: 258


View Profile
August 16, 2014, 04:59:24 PM
Last edit: August 17, 2014, 12:31:48 PM by laurentmt
 #92

Hi wbaw,

No, you're still misunderstanding, nameid.org just uses openid as an example, it doesn't rely on openid at all, ...
I fear I can't agree with you on that point. OpenID is not just an example used by NameID. It's a core component of its concept. That's clearly stated in the FAQ and on the homepage

Quote
Namecoin + OpenID = NameID !
If you remove OpenID from NameID, it's no longer NameID.


It sends a message, you sign it with the key used for your namecoin id, the site checks the signature...
Agree. NameId uses a principle of digital signature like BitID, Bitcoin and many systems before. But it isn't the core value of NameID. The true value of NameID is that it integrates Namecoin and OpenID.


... it relies on Namecoin ID.
...
It works almost exactly like BitID, but pre-dates it & allows you to link it to your ID information stored in Namecoin.
Agree !

Tell me if I'm wrong but I feel that your main interest is not in OpenID but in being able to use a Namecoin ID to sign in.
For now, BitId only supports bitcoin address format (1....) but it would be easy to extend this behaviour to manage additional formats like Namecoin addresses (N...) or SIN addresses.

I think that supporting different address formats is a natural evolution of BitID because there's legit use cases for people wanting to sign in with a unique public identity managed by Namecoin or by a SIN. That sounds to me like a natural complement to the existing behaviour allowing to sign in with bitcoin addresses or "ephemeral ids" (when you want to keep some privacy).

I don't know if Eric and others devs share this vision but if you're interested by the addition of Namecoin ids in BitId, I encourage you to open an issue on github. I'll be pleased to support your request !


Falkvinge
Newbie
*
Offline Offline

Activity: 31
Merit: 0


View Profile
August 19, 2014, 08:25:50 PM
 #93

I really really REALLY want to launch this as the preferred authentication method for a project I'm developing. The ease-of-use is positively outstanding, and in particular, the lack of need to install Yet Another App as it just piggybacks on the bitcoin wallet. 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"?

Cheers,
Rick
Falkvinge
Newbie
*
Offline Offline

Activity: 31
Merit: 0


View Profile
August 19, 2014, 08:45:11 PM
 #94

(I'm assuming here that the Android Wallet fork makes use of the fact that the Android wallet already has an address selection mechanism on the home screen, so it's literally just point-and-you're done for authentication; no need to confirm or select signing address?)
EricKennedy (OP)
Sr. Member
****
Offline Offline

Activity: 360
Merit: 250

CEO, Ledger


View Profile WWW
August 20, 2014, 07:23:48 AM
 #95

The fork of Android Wallet including BitID is not good for release ; it still requires some tests and UI enhancements. Not a lot of work (few hours I guess), but right now I don't have the time.

It is indeed point and confirm for first time; and next time it will auto confirm. No need to select and address, it will be created on the spot.

For a more complete version including metadatas, it would require a few days of work.

I hope to have an Android engineer working on this release beginning of September. If not then I'll set up a bounty to have the work done.

Falkvinge
Newbie
*
Offline Offline

Activity: 31
Merit: 0


View Profile
August 20, 2014, 03:03:12 PM
 #96

It is indeed point and confirm for first time; and next time it will auto confirm. No need to select and address, it will be created on the spot.

I see the privacy gains of not using an existing bitcoin address for authentication.

Will the private keys of this address also be backed up along with the wallet addresses? If not, then some recovery mechanisms will be necessary app-side. I guess that's necessary anyway.

As long as primary UX is point-and-logged-in (no more steps than enabling camera and pointing it at screen), I'm happy. Once this UX is good enough, what are the prospects of getting into the mainline Android client?

Cheers,
Rick
Rassah
Legendary
*
Offline Offline

Activity: 1680
Merit: 1035



View Profile WWW
August 20, 2014, 09:17:03 PM
 #97

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.
laurentmt
Sr. Member
****
Offline Offline

Activity: 384
Merit: 258


View Profile
August 23, 2014, 01:24:30 AM
Last edit: October 22, 2014, 12:19:04 PM by laurentmt
 #98

Hi there,

I've just pushed a new version (r0.0.3) of the python library on github:
- Fixed a problem with urlparse in python 2.7
- Cleaned package structure
- Created a setup script for clean installation (setuptools)

I've also setup a demo server with 2 python demos (authentications with mainnet addresses):
- BitId authentication demo : http://vps90685.ovh.net:8080/
- BitId 2FA demo : http://vps90685.ovh.net:8081/

EDIT:
BitId authentication demo with testnet addresses: http://vps90685.ovh.net:8084/
12Lc7Wxjtpe
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
August 24, 2014, 10:54:34 AM
 #99

A combination of this and onename.io would be great
dillpicklechips
Hero Member
*****
Offline Offline

Activity: 994
Merit: 507


View Profile
September 10, 2014, 07:27:50 PM
 #100

Does BitID support multi-sig? Using SigSafe and a smartphone multi-sig private key would be cool for signing on to websites!
Pages: « 1 2 3 4 [5] 6 7 8 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!