CID, PID ? Authentication or Identification

Here are whitepapers on ADC Features that can give you help.

Do we need the CID/PID pair ?

No, it's useless
We only need a CID
No votes
We need them both
Total votes: 6

Senior Member
Posts: 328
Joined: 04 Dec 2007, 07:25
Location: Bucharest

CID, PID ? Authentication or Identification

Post by Pietry » 23 Jan 2009, 10:24

That's right, this post is very controversial, it's about the CID/PID pair.
Some people hit me with the following question : the CID / PID is completely useless since a hub can easily find them out and impersonate somebody else. That's true, but the CID/PID were never supposed to be an authentication method. ADC uses passwords for that.
On of the NMDC flaws that is addressed by the CID / PID pair is the following: One could not identify a certain fellow user on different hubs. This way, the same user could leech from you on every hub you were both connected. Also, you could have a PM session with the same user on every hub as well.
On ADC, using the CID/PID pair, you have just one connection and one PM, that for smart clients (...)
DC++ for example will display in the title bar all the nicks under the different hubs the user is found in.
Also, registration is made on CID. What does that mean? One can use any nick to connect. This addresses the NMDC flaw where every user is identified by nick solely.

Now the big question is: why not have a single ID, CID, without the PID in the back? Earlier ADC versions ( 0.5 or 0.6 draft ) had this feature. A single CID.
Of what I know cologic had the idea of using the pair, and he had some reasons for using it. I can't remember now of a better reason, but I hope someone will or I will remember and post back.

My guess is: if you want to authenticate on some hub use CID + password. CID alone wasn't meant for that.
Just someone

Posts: 53
Joined: 15 Sep 2008, 21:48
Location: adcs://

Re: CID, PID ? Authentication or Identification

Post by Dj_Offset » 23 Jan 2009, 11:30

I proposed the "GUID" as I called it back in the early days of DCTNG.
There was later concern about the GUID could be "stolen" by others in order to break things for ordinary users, so there became a recommendation that the hub should be able to determine the CIDs validity.
I suggested using RSA/DSA for this, but that was criticised for being too difficult to implement... better keep it simple (and broken).

Lots of things have changed since DCTNG:
* First of all we have file hashes now, so a file is not identified as a tuple of hub+nick+path in order to resume downloads, rather file hashes, so we encourage multi source download, and can search directly for files matching the hash.
* Secondly, we have session IDs, which mean we can allow for things such as nick change etc.
* However, we do not have a means of discovering that too users on two different hubs are really just the same user, and that was one of the original intents of the GUID -- but since we have the first two issues fixed, do we really need this functionality now?

Junior Member
Posts: 16
Joined: 19 Jan 2009, 20:33

Re: CID, PID ? Authentication or Identification

Post by Sulan » 23 Jan 2009, 17:41

Isnt the main reason to use a hidden PID and a CID, that the CID is very hard for some one else to steal/recreate? A hub can ofcourse steal a users PID and CID, but a normal user can not, so i think it adds some security.

Posts: 53
Joined: 15 Sep 2008, 21:48
Location: adcs://

Re: CID, PID ? Authentication or Identification

Post by Dj_Offset » 24 Jan 2009, 19:23

Well, if you use that reasoning then it is broken. Anyone can setup a hub, to collect the PIDs. Just trick someone into visiting your hub, or clicking a link, and the whole "security" aspect is gone.

So, it isn't security - if you want that use RSA/DSA. Then the hub will not need the PID at all to verify it's authenticity.

Posts: 3
Joined: 25 Apr 2013, 18:25

Re: CID, PID ? Authentication or Identification

Post by Emery » 01 May 2013, 15:58

Authentication aside, the PID CID pair does establish that both client and hub have working hash functions. Neither the hub nor client need to explicitly test their hash implementation, connections will simply fail from the start if they don't work.