Ok, so I work with a certain program which has a wide open back door into it's data tables. As a program administrator i can go into the actual program and change details of other users etc. However here's what i need to do...

A certain users security level needs to be reduced from administrator to a lower level. If i do that within the program it will automatically require that i change that users password, which i don't know.

The user is not to know that their access level has changed.

Backdooring the database through MSQuery and hunting online a little i found how to update information...

UPDATE User
SET Security = 4
WHERE UserID = 4

This works fine, however the users password is then scrambled, until an administrator edits their password for them.

The password itself is encrypted within the database.
Appearing something like "99171821E244877B4201003E0519EEA7"
It appears to be hexadecimal, but hey, i'm no system engineer. Strange thing is. that encryption represents the password "bill". When i execute the change on security level, the password "bill" becomes invalid, yet the encrypted string remains exactly the same.

What i need if at all possible is a how to... on forcing the database to not change the password field when the security level is updated. Any other suggestions would be most welcome. And of course plain english with syntax explanations would be nice as i am very much a junior, this has been my first SQL code execution, aside from queries.

Cheers,
Oosters

Unfortunately for you, this seems to be an application issue.

If it were a DBMS problem, then I would assume you are not using ORACLE RDBMS; such problems only occur in mediocre DBMS like SQL Server and others.

Application problems seem pretty indiscriminant about what engines they affect to me. If an app uses SQL, and that SQL breaks, it breaks for any database that implements SQL at the same level. If an app uses database engine specific code (Oracle, Microsoft, DB2, etc), then that app will probably only run on its target database engine, but that is a failure in the application, not the database.

I think that the problem that Oosters has found is that multiple columns within the users table are used to derive (actually decrypt) the password. It would appear that the application designers wanted to prevent exactly the kind of change that Oosters is trying to make.

-PatP

Indeed.

And yet you felt it was imperative to squeeze that into your post regardless.

Quality.


Would you pretty pretty please proceed to regal me with unsolicited opinions and stories about how linux cured your stepdad's brother's cousin's dogs' nephew's sister's case of terminal cancer, or perhaps the one about Microsoft releasing OS's laced with mind control algorhythms that only appear at a particular resolution and refresh rate?

In the midst of these response all i basically understood, was that the application designers didn't want me to do it. Why couldn't they just stop me backdooring the application in the first place.

Meanwhile I think i know what's happening with the password. I think instead of the database automatically changing the password when i update the security level of a user, there may be another field to lock the password when i update security level, and this will only unlock when another password is offered. I can't even get around it by feeding the database it's own encryption string, which should force it to recognise a password change. I'm off to hunt for a password locking field.

I could destroy the integrity of the entire database at the touch of a button, but i can't change a single users security level.

Because controlling access to your database server probably isn't their job. Who is going to keep the database running if everybody is completely locked out of it?

One of the really fundamental elements of good security design is to limit the damage that can be done without detection. A fundamental way to achieve this is to require some form of intervention from one or more of the affected parties whenever a change is made. The example you've got is when a security level is changed, make that change require a password change.

This has little to do with the database. It is a fundamental requisite for good security management.

While I'm sure that it frustrates you, I see it as a good thing in the larger context because it makes an otherwise unannounced change visible to the affected party. While it might not be politically expedient, you shouldn't be able (from a systemic point of view) to take away (or grant) administrative privledges without the knowledge of the user.

-PatP

Yes, In an ideal world, in an ideal database i shouldn't be able to change user security levels without their knowledge. This being said...

<RANT>
Considering the sensitivity of information as this is a financial database representing the business of the whole company, I shouldn't be permitted to backdoor and alter financial information, and yet as long as i make it balance, which can take a bit of figuring, the database security allows such changes.
</RANT>

No need to respond to this, thanks for the knowledge people.

regards,
Matt