A REG command proposal

Ideas for ADC may be presented here for others to review and point out flaws or further improve the idea.
Forum rules
If you have an account on the wiki, remember to update the ADC Proposals page for new ideas.

http://dcbase.org/wiki/ADC_Proposals_list
darkKlor
Senior Member
Posts: 100
Joined: 30 Dec 2008, 14:59

A REG command proposal

Post by darkKlor » 03 Aug 2009, 01:32

This is designed to allow a common method of registration between client and hub, rather than the current use of hub-specific commands such as +regme.

REG
Context: F, T
REG UPx ME CNx CIx CCx TO data
For x, 1 means true or allow, 0 (zero) means false or deny.

For client to hub: This can only be sent by a user with permission to register others e.g. an Operator.
UPx - (optional) Indicates this message should update the registration of a user i.e. change registration method and/or portability settings, or remove registration. A client may interpret this message to inform the user of the changes to portability.
ME - the method via which the user should be registered. One of ID (Client ID), NI (Nickname), IP (IP Address) or RE (Revoke). If the hub does not allow this registration method, a STA should be sent informing the operator. The hub may strip this parameter before forwarding the message to the user.

The following parameters are portability options, and are for both client-to-hub and hub-to-client communication. If a parameter is not supplied, the default is deny. They are all optional.
CNx - Change Nickname - target user will be able to connect with a different Nickname. Should register internally via Client ID or IP Address.
CIx - Change IP - target user will be able to connect from a different IP Address. Should register internally via Client ID or Nickname.
CCx - Change Client - target user will be able to connect from a different client. Should register internally via Nickname or IP Address.

For hub to client: This parameter is generated by the hub.
TO - (optional) Timeout. The hub may specify how long (in seconds) the registration offer remains valid. If the user does not cancel, the receiving client should cancel automatically after this period.
data - The data parameter is at least 24 random bytes (base32 encoded). Same as GPA.

Info:
Register. This command may be sent by a client to register a user. It allows an operator to initiate the registration process and define the portability of the registered user's account. The client should respond with a PAS message containing the password specified by the user.

Example:
1) An operator selects a user in their client and clicks a Register button. This launches a dialog allowing the operator to nominate a method of registration, and the portability options for the registered user.
2) When the operator presses OK, the client sends a DREG message e.g.:
DREG <my_sid> <target_sid> MEID CN1 CI1 - the user will be registered via their Client ID and able to change their Nickname and IP Address. They will be unable to use a different client.
DREG <my_sid> <target_sid> MEID - the user will be registered via their Client ID, but not able to change their Nickname, IP Address or client.
3) The hub will generate a data parameter. It must store all parameters in it's state until the user replies with a PAS message. It may limit the time it retains this state by appending a TO parameter when it is forwarded to the user. It may also strip the ME parameter, since the client does not require it e.g. DREG <my_sid> <target_sid> MEID CN1 CI1 becomes DREG <my_sid> <target_sid> CN1 CI1 TO60 data, which specifies the offer will expire after 60 seconds.
4) The client receives the message and display a dialog to the user, informing them that <my_sid> is trying to register them, requesting a password, and informing them of the portability options (e.g. via disabled checkboxes). If a TO parameter was included, it should exit the dialog after the time expires.
5) If the user enters a password and accepts the dialog, the client should send a PAS message back to the hub. The data parameter from REG is used as the random binary data in PAS.
6) The hub will register the user with the retained state and the password specified in the PAS message.

Additionally, an operator may want to update or remove the user's registration.
To update, the operator would send DREG <my_sid> <target_sid> UP1 MEID to remove all portability from a user registered with the Client ID method.
To revoke registration, send DREG <my_sid> <target_sid> UP1 MERE with no additional parameters.

Missing: A way for an operator's client to get the registration details of a user. Maybe a REG message with no parameters, or something. Or extra INF flags sent to OP's.

Note: Currently a PAS message is only valid in the Verify state. This would need to change to allow the Normal state too.

Comments are welcome :)

darkKlor
Senior Member
Posts: 100
Joined: 30 Dec 2008, 14:59

Re: A REG command proposal

Post by darkKlor » 03 Aug 2009, 01:34

Oh and this is how I envisage the dialog the user would see, without the red bits: http://img411.imageshack.us/img411/5290/dcregister.jpg

darkKlor
Senior Member
Posts: 100
Joined: 30 Dec 2008, 14:59

Re: A REG command proposal

Post by darkKlor » 03 Aug 2009, 01:54

I think there might be something wrong in the data/PAS mechanism... I gave less thought to that part. Obviously the password needs to be verifable later on, so this should be different to the GPA/PAS approach I think.

I think there's a couple ways of doing it e.g.
1) hub sends user a salt, user sends back base32.encode(password+salt). hub can then go base32.decode(string) and remove the salt to get the original password.
2) Using (1), but replacing the 'password' part with hash(password), then the hub will store hash(password) and verify login's against this. This means the hub admin never sees the real password. The hash function could be anything, but keep in mind that if it's the session hash then the session hash must always be the same for the password to verify.

This verifcation method works better if it's in addition to matching Client ID's. Or ADCS could just change the game completely

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

Re: A REG command proposal

Post by Pietry » 03 Aug 2009, 07:29

This idea could make things easier for hub admins and users, might be a way to make registrations more simple and without knowing too much about adc technical background.
However, the password sending implies a small problem
darkKlor wrote: 1) hub sends user a salt, user sends back base32.encode(password+salt). hub can then go base32.decode(string) and remove the salt to get the original password.
There is no point in encoding base32, since the encoding is reversible. What's the purpose of sending the password encoded? And what's the point of the salt ?
darkKlor wrote:2) Using (1), but replacing the 'password' part with hash(password), then the hub will store hash(password) and verify login's against this. This means the hub admin never sees the real password. The hash function could be anything, but keep in mind that if it's the session hash then the session hash must always be the same for the password to verify.

This verifcation method works better if it's in addition to matching Client ID's. Or ADCS could just change the game completely
Hashing the password makes no difference in security, and makes the password unusable, since the hub requires the password plain text to validate ( hash(password+salt) )

The only idea that comes to my mind is to send the password plain text.
Just someone

Pretorian
Site Admin
Posts: 214
Joined: 21 Jul 2009, 10:21

Re: A REG command proposal

Post by Pretorian » 03 Aug 2009, 17:11

First of all, I just want to say that Pietry is right; you need to send password in clear text.

Having said that, I have some comments;
  • It's prettier if the command is REG required_parameters optional_parameters. It just feels odd to have some optional parameter before a required.
  • It might be better to use an combined integer instead for parameter ME and the C* parameters. That is, the same as for INF CT.
  • It may be beneficial to use -1 for TO, for "forever" (well, til session ends), since that is used in QUI. Also, perhaps changing TO to TL to be consistent.
  • INF CT levels might be useful to include in the parameter set, since otherwise you're just registering the user (via nick/CID/IP) without supplying their level of power. (Though, this might just be for informational purposes in the client.)
  • What happens if you are registered and receive a REG that does not contain a UP, while ME is not 'revoke'? Ignore? Re-register?
  • Revokation should perhaps be another parameter, that could mean (among complete revokation) demotion of power (from super operator to normal operator [whatever their power may be].)

darkKlor
Senior Member
Posts: 100
Joined: 30 Dec 2008, 14:59

Re: A REG command proposal

Post by darkKlor » 04 Aug 2009, 03:28

Firstly, RIP Daywalker :(

Pietry wrote:Hashing the password makes no difference in security, and makes the password unusable, since the hub requires the password plain text to validate ( hash(password+salt) )
Perhaps its better if I state my goal. I want it to be the case that when a client and hub negotiate an extension which includes this REG command, that the hub will only store a hash of the password. Something like a SHA-256 hash would do nicely.

So, keep the GPA/PAS the same, EXCEPT the client passes the hub SHA(password) wrapped within the other stuff, so base32.encode(session.hash(sha(password)+salt)) and the hub verifies against sha(password), not password.

I guess if this isn't all wrapped in an SSL connection then somebody can still read sha(hash) being passed over the wire via the REG process and thus break the GPA/PAS sequence. Still, it is an improvement in security in that the actual password is not stored on, nor seen by, the hub, only a hash.

So yes, effectively this command would be sending the 'plain text' from the point of view that what is sent can be used to break the GPA/PAS process, but that 'plain text' would actually be a hash of the real password, so that the hub only stores a hash.

Hopefully some part of that made sense :)

@Pretorian: thanks for the suggestions :)

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

Re: A REG command proposal

Post by Pietry » 04 Aug 2009, 06:50

darkKlor wrote:so that the hub only stores a hash.
The hub needs the password in plain text for further authentication, so keeping only a hash is useless....
Just someone

darkKlor
Senior Member
Posts: 100
Joined: 30 Dec 2008, 14:59

Re: A REG command proposal

Post by darkKlor » 04 Aug 2009, 11:14

No, it doesn't. Why would it, if the client only ever sends a hash? I'm suggesting that in the REG command the only step taken is to hash the password. A client supporting REG would send PAS as normal, EXCEPT that it would create a hash of the password before doing the rest of the PAS operations.

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

Re: A REG command proposal

Post by Pietry » 04 Aug 2009, 13:24

darkKlor wrote:No, it doesn't. Why would it, if the client only ever sends a hash? I'm suggesting that in the REG command the only step taken is to hash the password. A client supporting REG would send PAS as normal, EXCEPT that it would create a hash of the password before doing the rest of the PAS operations.
It doesn't only if it can add the salt later on to the hashing engine.

However, what's the difference between sending the password plain text or hashed ? Also what difference does it make if you do the hash of the password before the rest of the PAS operation ?
Just someone

darkKlor
Senior Member
Posts: 100
Joined: 30 Dec 2008, 14:59

Re: A REG command proposal

Post by darkKlor » 04 Aug 2009, 14:13

My goal is that the hub does not, and cannot, see the original password. That is all.

Post Reply