|
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. |
|
This is similar to @Martin's answser, but all the work has already been done for you. You could use TLS encryption, and make sure that the machine that's running the server is the only one with the identity file. The TLS protocol makes sure that the server you're connecting to is the one that has the server's certificate. It also prevents man-in-the-middle attacks, where another machine pretends to be the server's machine and connects to the real server itself to find out the "secret", passing it on to the clients, who then think it is the real server. |
|
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. |
|
Create a special file in the filesystem as an indicator for the valid machine and use CREATE SERVER statement to create a directory access server, then you can easily check with a proxy table and a simple select if your "license file" exists on the database server machine. Very easy to break ;).
(14 Dec '11, 05:24)
Dmitri
Replies hidden
Correct, but on the same level as cheating the MAC-Address
(16 Dec '11, 05:21)
Martin
|
|
Well, I'm trying to find an answer myself but nothing came to my head simpler than this yet: call xp_cmdshell('getmac > tmp_mac.txt'); select cast (xp_read_file('tmp_mac.txt') as long varchar) into @s; // parse @s If you suspect malicious users, they surely are able to check which files your database is using (say, with SysInternals monitoring tools), and it might be not too difficult to replace the file with one with the wanted MAC address...
(16 Dec '11, 03:10)
Volker Barth
Replies hidden
Most network drivers allow you to set the MAC-Adress explicitly, much easier than changing the file.
(16 Dec '11, 05:22)
Martin
Well, thank you for all your answers. This kind of evaluation policy will be rejected.
(19 Dec '11, 01:58)
Arthoor
|
To clarify: Are you trying to prevent
I.e. is it your task to give every server instance some unique property, or is it the customer's task?
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.
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...
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?
OmniIdentifier is changed between engine starts, so restart dbserver and you get a new one
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?
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.
Yes, the trial version would be given to users with DBA permissions.
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...