Ask the RWTH to allow you to publish the Client Identifier

[ekiwi]

Reading the OAuth2 RFCs one has to realize, that the client identifier was never meant to be secret.

This is why the RFC6819 says the following:

The authorization server may issue an individual
client id but should require that all authorizations are approved by
the end user.

Sync-my-L2P is a public client and therefore does not contain a client secret (see RFC6819 5.2.3.1).

Putting a secret into a public client is considered nonsense 4.1.1. Threat: Obtaining Client Secrets

So to use the words of RFC6749 2.2. Client Identifier:

[...] The client identifier is not a secret [...]

and therefore there is absolutely no reason for the RWTH to treat it as such.

On the contrary it actually hurts Sync-my-L2P as an open source project, because it makes it impossible to test most modifications and thus makes contributing harder than it should be.

Therefor I ask you to please talk to the RWTH again and try to convince them that trying to keep the client id a secret is rather silly.

If they want to make sure that the Datenschutz is payed attention to, I'm all for that. However, the only way they can make sure that people can chose to use a program approved by the Datenschutzbeauftragter is by distributing a Version of Sync-my-L2P on their own website that they compiled themselves. Maybe they could even sign it or at least put some sort of hash on their
website in order to be able to verify if you have the verified by the Datenschutzbeauftragter version.

But none of these privacy concerns will be solved by keeping the client id a secret.

quick reminder

[...] The client identifier is not a secret [...]

RFC6749 2.2. Client Identifier

[claell]

Agree to that, hopefully the RWTH does change it's opinion. For now they should just be a bit faster with verification, so the program works at least.

[RobertKrajewski]

I already tried it twice and never got any response.
So you can try your luck.

Nevertheless it is no secret that anybody can sniff the ClientID in 5
minutes or less by using tools like Fiddler.

2015-02-06 11:46 GMT+01:00 Electronic Kiwi [email protected]:

Reading the OAuth2 RFCs one has to realize, that the client identifier
https://tools.ietf.org/html/rfc6749#section-2.2 was never meant to be
secret.

This is why the RFC6819 says
http://tools.ietf.org/html/rfc6819#section-5.2.3.2 the following:

The authorization server may issue an individual
client id but should require that all authorizations are approved by
the end user.

Sync-my-L2P is a public client and therefore does not contain a client
secret (see RFC6819 5.2.3.1
http://tools.ietf.org/html/rfc6819#section-5.2.3.1).

Putting a secret into a public client is considered nonsense 4.1.1.
Threat: Obtaining Client Secrets
http://tools.ietf.org/html/rfc6819#section-4.1.1

So to use the words of RFC6749 2.2. Client Identifier
https://tools.ietf.org/html/rfc6749#section-2.2:

[...] The client identifier is not a secret [...]

and therefore there is absolutely no reason for the RWTH to treat it as
such.

On the contrary it actually hurts Sync-my-L2P as an open source project,
because it makes it impossible to test most modifications and thus makes
contributing harder than it should be.

Therefor I ask you to please talk to the RWTH again and try to convince
them that trying to keep the client id a secret is rather silly.

If they want to make sure that the Datenschutz is payed attention to,
I'm all for that. However, the only way they can make sure that people can
chose to use a program approved by the Datenschutzbeauftragter is by
distributing a Version of Sync-my-L2P on their own website that they
compiled themselves. Maybe they could even sign it or at least put some
sort of hash on their
website in order to be able to verify if you have the verified by the
Datenschutzbeauftragter version.

But none of these privacy concerns will be solved by keeping the client id
a secret.
quick reminder

[...] The client identifier is not a secret [...]

RFC6749 2.2. Client Identifier
https://tools.ietf.org/html/rfc6749#section-2.2

—
Reply to this email directly or view it on GitHub
#27.

[claell]

What would happen, if you published the program (ID) without their permission?

[RobertKrajewski]

Any released ID will instantly be deactivated.

2015-02-07 22:13 GMT+01:00 Claudius Ellsel [email protected]:

What would happen, if you would publish the program (ID) without their
permission?

—
Reply to this email directly or view it on GitHub
#27 (comment)
.

[claell]

Ok, so unfortunately that is not an option.

[ekiwi]

Nevertheless it is no secret that anybody can sniff the ClientID in 5 minutes or less by using tools like Fiddler.

Yes, or you can run something like strings app.bin on any app that uses OAuth2 to connect to the l2p and look for something that looks like a client id. Maybe there is even some sort of pattern that you could use in order to grep for it.

What bugs me is, that, for someone who wants to distribute an application, extracting a client id only needs to be done once and is not a big deal (but this is, as I understand, something the RWTH wants to prevent). On the other hand, people who want to contribute to Sync-my-L2P and test their changes (which should be a legitimate use case for having to know the client id), will have a hard time doing so. They will need to make sure not to commit the client id they are using, might not know how to get hold of a valid client id or might be afraid to do so.

Maybe you could ask the RWTH to give you a second client id which will be associated with a special name e.g.TestId FOR TESTING PURPOSES ONLY. Thus if someone was to distribute an application using this client id, the user would know, that this is not a legitimate client id, since the correct app name won't show when authenticating the application. So the RWTH should not have to worry if this id is shipped with the source code of Sync-my-L2P for testing purposes.

Just to make this clear: The RWTH is still wrong in trying to prevent you from including the client id with this source code. RFC6819 explicitly mentions this case:

For open source projects, secrets can be extracted directly from source code in their public repositories.

and

Secrets can be extracted from application binaries just as easily when the published source is not available to the attacker. Even if an application takes significant measures to obfuscate secrets in their application distribution, one should consider that the secret can still be reverse-engineered by anyone with access to a complete functioning application bundle or binary.

and anyway:

[...] The client identifier is not a secret [...]

But there is no use in insisting on the standards if the RWTH won't acknowledge them. Maybe we can work out a compromise as suggested above.

TL;DR
"bad" guys can always extract the client id; good guys however will be kept from contributing; maybe the RWTH can issue a client id for testing purposes

[Credics]

Hey there
although this issue is quite old, I assume that it is still relevant. I wanted to play around with the app, and this was one of the first problems coming up to me.
So imagine I was able to extract the client ID from the binary using a tool like strings. Would it do any harm to the project or the contributors if I used the ID in a build I compiled by myself, possibly with some modifications, which might not work properly?

[auxua]

Hey Credics,

At the moment, IT Center is very restrictive with that. In case Logfiles, User reports, etc. show, that the ClientID was extracted and is used for another project, the ID may be revoked. By that, nobody will be able to use the Sync-My-L2P at all until the case is discussed an the SML2P is published with a new ClientID.
Therefore think about what your suggestion may lead to in consequences for many users having nothing to do with programming/your testing.

If you want to compile/build/alter such a project on your own, please request your own ClientID (It is very easy - it is just one email - [email protected]). By requesting it there, you will not only get a ClientID but also API-Updates (e.g. more methods, changed functions, etc.), contact infos and more stuff. (Of course you can also mention the current problem of testing IDs in this mail to remind everyone of this...)

• The API Guy :-)

P.S.: Talking about doing something forbidden in public including references to corresponding tools might not be the best idea....

P.P.S.: This post is my personal opinion and does not need to match the position of RWTH/ITC at 100%

[Credics]

Thank you for the quick response :)
Actually it sounded like getting an ID was quite difficult. That's why I had this idea in the first place. Of course I am not interested in doing any harm to the project or its users - especially as I am one of them. So I am going to request my own ID and definitely remind them of the problem with developing and testing.