Results 1 to 12 of 12
  1. #1
    Join Date
    Jul 2008
    Posts
    14

    Unanswered: How far can we trust SQLServer Security?

    There are some "busy" guys advertising a PASSWORD RECOVERY/HACKING tool for SQLServer. The tool is is priced less than USD150.

    If something like this is freely available on the Internet then our SQLServer installations cannot be judged secured.

    Below is text of the advert with url to the site where the tool can be purchased.....

    ----------------------------------------------------------------------
    http://www.elcomsoft.com/purchase/bu...r&ref=ORDERTXT


    Advanced SQL Password Recovery
    Get instant access to password-protected SQL Server databases - guaranteed! Advanced SQL Password Recovery can change any user or administrative password protecting databases in Microsoft SQL Server 2000, 2005 or 2008 formats. Advanced SQL Password Recovery works with or without SQL Server installed. The password recovery tool accesses the master.mdf file directly, whether or not SQL Server is running or installed.


    Price in your currency: $ 129

    --------------------------------------------------

    I tested a trial version of this tool on my SQLServer installation and it worked.

    Please is there any protection from this tool and others such as it? Please share with me.

    Many thanks

    Vie
    @ImaTools, Abuja

  2. #2
    Join Date
    Jan 2003
    Location
    Massachusetts
    Posts
    5,800
    Provided Answers: 11
    Windows authentication?

  3. #3
    Join Date
    Jul 2003
    Location
    San Antonio, TX
    Posts
    3,662
    How can you say that it works if you ran an eval version? Also, the word "Recovery" in the name is a joke, because the tool does not recover the password, but rather allows you to set a new password for a selected SQL account. Other things:

    1. Whether SQL is installed or not is absolutely irrelevant to the tool's ability to access MASTER.MDF. The only thing that is relevant is where the file is open or not;
    2. If SQL is running, the tool doesn't even try to associate the MDF to a specific instance, or even to a type of service to stop. It just lists all services that have SQL in their names, including the ones that can't even access master database to begin with;
    3. Paying $129 to just see if it really works is definitely not worth it, unless you're so desparate to gain access to the data that you never had to begin with.

    To protect yourself from this type of tools is simple, - keep SA disabled, and limit the level of privileges for other standard accounts to a minimum. The tool can only retrieve accounts from a closed file, and only if the user has access to the location of the file.
    "The data in a record depends on the Key to the record, the Whole Key, and
    nothing but the Key, so help me Codd."

  4. #4
    Join Date
    Jul 2008
    Posts
    14
    many thanks Rdjabarov. Sorry I have been "off-line' for some time.

    Please get the scenario.

    As a developer you deliver MSSQL based solutions to a client organisation - specifically for use in the Accounts dept. For good reason you have to use Win/SQL-Server Authentication. To keep ICT staff (that always have admin rights to the host server computer) you remove or disable the builtin accounts (together with sa acct) so that the only route of entry to the sql-server is via sql-authentication.

    Now the ICT staff have access to the server-computer so they can always access the mdf file of your application. You are just an ISV developing and deploying your commercial products to variuos sites. It is the ICT staff of these clients that manage the hardware and you want to protect the sqlDatabase from their power for intergrity of the data.

    Simple you want to ensure that the only access to your sqlserver db is via your code. you dont want some body resetting or retrieving the password of any account.

    Please find time to assist.

    many thanks again

    Vie
    @Imatools Abuja

  5. #5
    Join Date
    Jan 2003
    Location
    Massachusetts
    Posts
    5,800
    Provided Answers: 11
    Bottom line, if you do not trust your computer department, you fire them. If you are a vendor, and you do not trust your customer, be honest, and do not offer them support.

    Do you suppose the exchange administrator does not have the ability to read all of the CEO's correspondence?

    Or perhaps you do not expect the database to be backed up (and possibly restored to another instance of SQL Server)?

    Then of course there is the whole issue of whether the USERS should have any access to the data. There is data security, and then there is outright paranoia.

  6. #6
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1
    Quote Originally Posted by Imatools View Post
    It is the ICT staff of these clients that manage the hardware and you want to protect the sqlDatabase from their power for intergrity of the data.

    Simple you want to ensure that the only access to your sqlserver db is via your code. you dont want some body resetting or retrieving the password of any account.
    Whoever administers the sql server machine will have full access to all databases on that server. Are you willing to shoulder the full burden of all administrative tasks related to sql server, the operating system, and the hardware it runs on? If not, then you need to get used to the fact that the need to administer and protect an entire environment trumps your desire for "data integrity" for your application... which really means "black box/vendor lock-in" in this scenario. Even if you ARE willing to shoulder those responsibilities, you're still stuck with addressing user authentication.

    If you're uncomfortable with this, consider embedded database solutions or an SOA approach.


    Also, you mention using windows authentication "for good reason" and then go on to say you intend to force sql authentication only. Which is it?
    Last edited by Teddy; 04-02-10 at 11:20.
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

  7. #7
    Join Date
    Jul 2008
    Posts
    14
    Quote Originally Posted by Teddy View Post
    [A] Whoever administers the sql server machine will have full access to all databases on that server...

    [B] Even if you ARE willing to shoulder those responsibilities, you're still stuck with addressing user authentication.

    [C] Also, you mention using windows authentication "for good reason" and then go on to say you intend to force sql authentication only. Which is it?

    [D] If you're uncomfortable with this, consider embedded database solutions or an SOA approach.
    ------------------Response:
    <A1>: To MCrowley I say this. I turst my clients and my clients trust my organisation. some of our apps drive MicroFinance Institutions. Now understand that we do not operate in same environment. I want us to remember that a loyal staff (of & to my client) today may choose to become disloyal tomorrow. So am just trying to see how far I can go to protect the owners of the business using my solution from possible disloyal staff that were once trusted.

    <A2>: To Teddy. i do not contest control of the host computer. The ICT staff have that. They also control all other database on that machine. For my application
    ...I install a named instance of sql2008.
    ...set it to win/sqlserver authentication.
    ...create a new sysadmin acct
    ...(NB) DELETE the BuiltIn\Administrators login

    <B>: To Teddy: My apps come with
    ... custom backup, restore and other utilities for basic management of that single db my app needs.
    ...backup utility creates PASWORD protected backups. ( I hope this is safe)
    ...in built role based password system for controlling access to functions of the application

    <C>: To Teddy: SQLServer has only two options -Win authentication or mixed mode. So I take mixed mode but DELETE the BuiltIn\Administrators login

    <D>: Finally Teddy. Thank you for offering me a way out. However I assume we all are adminiting that sqlserver security may have a hole open to a once loyal staff that decides to become somewhat disloyal. For example in my environment, dubious CEOs can commit fraud and set a whole public building on fire.

    thank you friends... And to MCrowley specifically please bear with me - we operate in somewhat dissimilar environments.

    While we brainstrom this (hoping you will still indulge me) enjoy your easter holidays...

    Warm regards
    Vie
    @ImaTools Abuja

  8. #8
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Provided Answers: 54
    Do you need to protect your data from unauthorized changes (INSERT, UPDATE, DELETE) or from any access at all (even SELECT)? These are two very different problems and require radically different solutions.

    If you need to protect against changes, then a simple CRC will do that nicely. Treat any row with an invalid CRC value as suspect. Depending on its impact, you can either exclude the row from being processed, or abort the transaction when a corrupt CRC is found (indicating that something or someone other than your application changed the data). This option is horrifically expensive and often embarassing to support for those companies that use it.

    If you need to protect the data from even being viewed by your clients, then the only real choice I know of is to host the data yourself. Write your application as either a SOA based application or better still as a web site. This gives you 100&#37; control of all of the data that your users decide to process using your application. Let me know how that works out for your sales team!

    These are both amazingly bad choices. They are difficult to design and support. They indicate a nearly complete lack of trust in your customers and a "Big Brother" attitude toward managing the companies that use your software. You're looking for ways to hurt yourself and your company badly, and these approaches will definitely help you achieve those goals.

    -PatP
    In theory, theory and practice are identical. In practice, theory and practice are unrelated.

  9. #9
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Provided Answers: 54
    Just as a side note, you don't need SQL Authentication. You can delete the BUILTIN\LocalAdministrator account in any version of SQL Server. It isn't even installed with SQL 2008.

    -PatP
    In theory, theory and practice are identical. In practice, theory and practice are unrelated.

  10. #10
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1
    Quote Originally Posted by Imatools View Post
    ...protect the owners of the business using my solution from possible disloyal staff that were once trusted.
    Whose? Yours or theirs? If it's yours, then this makes no sense. If it's theirs, then you can't shoulder that responsibility. Sensible employee exit procedures are the only reasonable way to address this. Furthermore, I'd be surprised to come across a client with a reasonably sized IT department who would interpret these measures as a feature for their own benefit. Most of us are intimately familiar with the consequences and intentions of third party vendors attempting to "black box" applications or databases.

    SQLServer has only two options -Win authentication or mixed mode. So I take mixed mode but DELETE the BuiltIn\Administrators login
    Do you understand enough about security to realize that this will in no way prevent domain adminstrators from accessing the MSSQL installation? I'm not sure how you believe this will insulate your one database from manipulation by properly credentialed staff.

    For example in my environment, dubious CEOs can commit fraud and set a whole public building on fire.
    Again, I fail to see how deleting the local administrator account will somehow avert such a crisis. This scenario is addressed by way of a regular off-site backup procedure.

    However I assume we all are adminiting that sqlserver security may have a hole open to a once loyal staff that decides to become somewhat disloyal.
    Any and every system that involves credentials is open to this "hole". I don't understand in what way you feel SQL Server is more or less vulnerable than any other credential-secured asset. These issues are addressed by the exit procedures mentioned above. If a highly privileged (and disgruntled) employee is let go and their privileges are not revoked and monitored, the environment is compromised. At that point, your application is the least of that company's worries.

    My apps come with
    ... custom backup, restore and other utilities for basic management of that single db my app needs.
    Let's try this again... In order to prohibit access to "that single db your app needs", you will ALSO have to prohibit anyone from having administrative control over the ENTIRE COMPUTER. As such, nobody will be able to administer ANY of the databases on that computer. It will be your responsibility to administer the single database of interest, the instance of sql server on which that database is located, the operating system on which that instance has been installed, and the hardware on which that operating system relies.



    Anywho...

    As Pat is echoing, a remote data repository or completely remote application (eg: Website) is the only sensible way to address this "issue". If you absolutely require total control over any one piece of your application, then you need complete unfettered control over both the physical hardware and all access to services running on that hardware. The only way to achieve this is to host those services yourself.
    Last edited by Teddy; 04-02-10 at 16:56.
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

  11. #11
    Join Date
    Jul 2008
    Posts
    14
    Thank you gentlmen - MCrowley, Pat Phelan and you Teddy. I appreciate all of you for the time you spend attending this. You sure have helped to sort some things out. (meanwhile I hope you all had a great Esater and none of you is a ManU fan).

    Permit me and indulge me this time also.

    Earlier today I had to see the CEO of one of our clients. The organisation is a micro-finance bank. This bank, like many their size, manage to engage only one hand to oversee IT services. Most times the hand is a school leaver or 2yr diploma graduate.

    Well this CEO reminded me that the 'IT' staff was only to oversee the health of the hardware. ... was never to be given access right (not even that of printing report especially Bank Statement) to the banking software.

    Friends, if this CEO or any of the other Micro_Finance_Banks using our product ever imagine their IT staff can lay hand on a software that can give them access to the back-end db, they will summon me to a serious meeting and demand assurance I can seal that 'hole'.

    So I am not interested in the owners of the business NOT having access to their data but am just trying to satisfy them. They rely on us to build applications they can 'safely ' deploy for their employees to use. To them employees (including so called IT staff) must access the solution only via the front-end.

    Last week the Executive Head of the Accounts unit for another major (big) client got angry with us for submitting a report that indicated the DB for an accounting app we made for them was going to be hosted on a server that is located with the IT unit. This time the IT unit is manned be graduate staff. my coy was imeadiatedly instructed to liase with the head of IT to either relocate the server to within the accounts department or go ahead to procure another server for accounts if the current server could not be relocated for any reasons.

    May be we have to re-educate these clients. The bottom line is that the owners of these coys prefer that all employees have a front-end only access to corporate applications. Any password for back-end db access should be left with the business owner (who may not even know how to use it).

    Do you three see the source of my worry about those 'busy guys' I talked about earlier?

    Now, Teddy on this your contribution ---
    Quote Originally Posted by Teddy View Post
    Do you understand enough about security to realize that this will in no way prevent domain adminstrators from accessing the MSSQL installation? I'm not sure how you believe this will insulate your one database from manipulation by properly credentialed staff.
    I have this experience:
    When I install an instance of MS-SQL-Sever and delete or disable the BuiltIn\Administrators login , you will not be able to use trusted account to login to that instance. This means that your windows credentials should not be able to get you in. You must have a sql-server login id. Remember that b/4 I do this I set the instance to mixed mode authentication and create a new sysadmin login that will be used to manage the instance. IT staff retain their rights over the hardware and any other SQL-Server instance on the host computer.

    Again I say thanks to all of you for the help so far!

    Vie
    @ImaTools, Abuja
    Last edited by Imatools; 04-08-10 at 14:05.

  12. #12
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Provided Answers: 54
    There are ways to do this, but in order to provide that level of security/control you really have to host the data yourself. If the customer's admin has any access at all to the machine hosting your application (either administrative access to the operating system or mere physical access to the hardware or the backups), then there is some risk to the data.

    -PatP
    In theory, theory and practice are identical. In practice, theory and practice are unrelated.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •