SQL Server - Logins

  • I'm dealing with a product that pre-creates it's databases, creates its logins and as apart of the installation it changes the sa password and then uses it for the application.

    The connection string is hard-coded into the application itself.

    The vendor is refusing to give out the sa password, which is absolute rubbish. I'm trying to find out a way of cracking the sa password to find out what it is. I can script out the creation of the sa login and get the encrypted sa password but have no idea how to un-encypt it.

    Anyone got any ideas on how to do this?

  • if you manage the environment then why wasting time to dig the old password. Reset it with something else and let vendor chase you :w00t:

    ----------
    Ashish

  • Password encryption is one way, once its encrypted it cant be unencrypted. When you log in, it takes the password, encrypts it then matches the stored encryption against the login generated encryption if a match you login, if not you get a failed login attempt.

    But I'm with Ashish on this, if its your server just change the SA password, then wait for the vendor to kick and scream. Apps shouldnt be using the SA account in my opinion.

  • Thanks guys.

    Unfortunately, this is a new piece of software that the company I'm working for requires, so I can't simply break it. Any other options for getting to the bottom of what the password is?

  • bump it to the groups that handle the contracts and RFP's;

    for example bring the issue up with the contracts/legal department; check to see if the contract explicitly states they get to take over the sa user/password, and that they get full sysadmin access to everything on the server.

    i doubt it's in the contract...that "sa" kind of programming style comes form developers who don't understand security, only convenience from their perspective.

    get them to hold all payments to the vendor until the issue is resolved.

    Lowell


    --help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!

  • Seems the only option now doesn't it, thanks Lowell.

  • with all the concerns about losing customer data, it's a pretty big liability hole;

    how about putting them on a seperate SQL instance,instead of that production server, and that would be the only database on the isntance?

    that would minimize the issue quite a bit in my eyes.

    Lowell


    --help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!

  • or even better:

    I've only done this for testing,but not in production:

    research a little deeper on how to rename the sa user to something else, and create a regular user named "sa" instead.

    Lowell


    --help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!

  • I've done that, all those databases are on their own dedicated SQL Server where no other databases sit.

    I've also created another sysadmin sql user so in the event of something going really wrong, I can use that one.

    These two things certainly help but it still bugs me about the sa account. Really is a piece of crap application.

  • Do you have any good network admins there? If so, ask them to do some packet sniffing on the wire. Since it is SQL Authentication, the authentication usually comes in with username and password in clear text.

    -Roy

Viewing 10 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic. Login to reply