Authenticating an Archicad user in a 3rd party system

[BenjiDev]

Hello, I know it is possible to get the user id of a user:

https://community.graphisoft.com/t5/Developer-Insights/Introducing-new-user-identification-to-the-AP...

But is it possible to verify it?

Let's say I make an Add-on that I sell. 

ACAPI_Protection_GetGSIDUserId 

Seems like a good identifier to tie a license of the Add-on to, because it represents an Archicad user.

So to purchase a license for the Add-on the user just has to provide this ID (or if purchase is done in the Add-on it can be retrieved) and stored on a license server.

Then the Add-on can retrieve the same ID and check if it exists on the license server to verify that the user "has" a license to the Add-on. 

Problem is that I don't know how to verify this ID on the license server, how can the license server (or other 3rd party systems) know that the id it gets is a valid Graphisoft user ID?  

Is it possible to get a signed graphisoft user id that can be verified. Or a token of some sorts, that a 3rd party system can verify with a graphisoft controlled server?

Paid Add-ons I've seen often requires the user to register separately in their system with traditional email + password. But if you where able to trust the Graphisoft user id (and additionally the organization id) you could make a system where the user can access their 3rd party Add-on licenses through their Graphisoft account. 

[Ralph Wessel · Accepted solution]

I don't believe there is any way to obtain information about an ID from Graphisoft. But if you support purchasing through an add-ons, presumably you can be confident that the ID it submits to your server is legitimate?

[BenjiDev]

Thanks for the answer. Yes I can trust the Add-On but the license server cannot be confident that what it receives was submited from the add-on.

A technical user could submit (using tools separate from the Add-On) the graphisoft user id of another user to get access to their Add-On licenses. They could also circumvent any 30 day add-on trial by sending random strings as user ids (interpreted as new users on the license server).

The Add-On could sign the user id before sending, but that requires distributing a private key with the Add-On. Would be nice if assurance could come from Graphisoft.

[Lingwisyer]

Is it possible to request the device name? Basically a second point of identification to make spoofing more of a hassel?

Ling.

[BenjiDev]

Yeah, but a legitimate user could use different devices with the same account. So the server cannot know that an unrecognized device ID for a specific Graphisoft user ID is illegitimate or not.

[Lingwisyer]

Much like Adobe, you could allow two or three devices with request to the server required for a reset. Unless a person hotdesks, they are probably not working on more than three devices. It would also reduce trial time limit circumvention as the user would need to change their device name as well each time which could cause other inconveniences.

Ling.

[scottjm]

What if you also sent a hash of the gsid, generated using a secret seed embed in the addon?
Once it arrives at your licence server you can rehash the gsid sent a gain using the secret seed and ensure it matches the hash created by the addon. 
Anyone trying to spoof a licence by sending a licence request with tools outside Archicad would be unable to generate a valid hash of their gsid (or anyone else’s) as the don’t have the seed.
Probably an extra step would be to incorporate a timestamp into the hash seed is worth while, so a users hashed gsid doesn’t stay as a static hash.  You’d just need to accomodate for timestamp drift between user and server, but I’m wondering if you could actually send this timestamp with the request safely. 

As for trials. I reckon require a registration for a trial through your website. 

[BenjiDev]

Thanks, something like:

Add-On sends: GSID, timetamp, HASH(GSID + timetamp + embedded secret key)

Server calculates the same hash with provided GSID, timestamp and internal secret key and checks that the hash provided by the Add-On matches, also checks that the timestamp is within some allowed range. 

I think sending the timestamp should be safe then because any change to it would give a different hash and rejected by the server.

[BerndSchwarzenbacher]

Hi Scott,
Hi Benji,

Not sure if I understand Scott's idea correctly, but I'd be very careful with embedding any "secrets" in an Add-On. Such a "secret" can usually be extracted from a binary quite easily. In general I'd assume any data processed on one machine is visible to the owners of that machine and this includes compilation artifacts and thus your Add-On.

I'm using a different approach for my licensing mechanisms. This doesn't necessitate another account for your users.
It needs an asymmetric signing algorithm. RSA for example. But I'd recommend to just go with libsodium.
With asymmetric algorithms you have a keypair consisting of a public and a private key. Then you can sign messages with the private key and everybody with the public key can verify that only you would be able to send such message.
With that in mind, here's my approach:

1. You get the GSID from your users (found on companymanagement.graphisoft.com).
   You "don't care" if users submit a wrong GSID here.
2. You sign a message with your private key on your server. The message includes their GSID.
3. Send the message to your users (e.g. per mail, make a license installer for them, something like that)
   This message can in principle be given to "anybody" (you might need to be careful about Data Protection guidelines since a GSID might be considered personal identifiable information.)
4. In your Add-On you receive this message somehow (e.g. user stores a file) and the add-on can verify with the public key, that the content of the message was signed by you.
5. Compare the current GSID of the Archicad Environment with the GSID in your message.

Hope this gives you a rough idea 🙂

The difference here is, that the used public key was never intended to be a secret. So it can be extracted by "malicious" users without any damage to you.

Edit: Also you with this approach you "don't have to care" whether the ID submitted by your user is a valid ID associated with a Graphisoft Account. When they submit a wrong one, than the last step will fail.

Best,
Bernd

[scottjm]

Bernd's idea of using a proper private/public key combination is much better.  😊
My idea was the baby version, with a potential security exploit if someone knew how to decompile the apx binary and expose the hash secret.