How do you uniquely identify database server?

[VolkerBarth]

Hello again, Is there a way in SQL Anywhere to uniquely identify the machine that runs the database? Is it possible to get mac address somehow? Or does there exist some server property which is different in every physical machine (and does not change through machine's life cycle)? Or is it possible to get external IP address?

The goal is to generate an md5 hash (password) from a date (system end of life) and some other values and one of these values should be unique so that the password wouldn't work if copied to another instance of the system.

Thanks in advance.

[VolkerBarth]

To clarify: Are you trying to prevent

1. clients from connecting to the "wrong" server or
2. users from copying your system to a second (possibly not licensed) server?

I.e. is it your task to give every server instance some unique property, or is it the customer's task?

[former_SQLA_member1694875]

Generally - the answer is 2. Roughly - we want to give a trial version of our system (PowerBuilder + SA) to new customers. Let's say, server "A" has a "password" for 30 days, server "B" has it for 5 years. Let's say, there is some leakage of information between administrators (they are familiar) - a "password" is copied from "B" to "A". It must not work. So the task to generate these "passwords" is ours.

[VolkerBarth]

A case for a particular "evaluation" login policy? - Unless you must assure that there won't be a working DBA permission copied from B to A...

[former_SQLA_member1694875]

Login policies can be modified by DBA. We need a value that could not be changed by anyone who works with DB (except when hardware was changed or moved somewhere or OS date and time was turned back or smth else). So mac address or at least external IP address would be fine. By the way, what does the server option OmniIdentifier mean?

[MCMartin]

OmniIdentifier is changed between engine starts, so restart dbserver and you get a new one

[VolkerBarth]

There's not much inside a database a DBA cannot modify - even if you store an encryted value in a stored procedure or the like and use SET HIDDEN, a DBA might not be able to decrypt the contents but surely is able to alter the procedure...

---

So you're saying the trial version is given to users with DBA permissions?

[former_SQLA_member1694875]

But in such case DBA must know exactly what the hidden procedure does. E. g. we can create a variable (CREATE VARIABLE statement) in it and after that check if VAREXISTS() in calling application. If the procedure is altered then most likely that variable will not exist.

[former_SQLA_member1694875]

Yes, the trial version would be given to users with DBA permissions.

[VolkerBarth]

IMHO, that requirement does really make it difficult. - As SQL Anywhere databases contain their own user management (and don't share that with other databases on the same engine, for example in contrast to ASE or MS SQL), I would try to encapsulate actions that require DBA authority into stored procedures and the like and grant the trial users only execute permission - omitting the need for them to have DBA authority.

But obviously I don't know your application and system, so that may not be feasible...

[MCMartin]

Based on the comments so far you will have to decide by yourself how much effort is necessary to get to a rational level of security. No lock is unbreakable, it is often more the question of how much effort do I have to invest to break the lock and is it feasible compared to the investment necessary to buy a valid license. As always it is a trade-off. So the suggestions provided to you so far are in my opinion all sufficient to prevent a simple copy and paste attack. Which means using any of them will prevent a normal IT-staff from just copying your system to another server and gaining a duplicate without your knowledge.