June 14, 2012 at 10:21 pm
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?
June 14, 2012 at 10:59 pm
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
June 15, 2012 at 1:39 am
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.
June 15, 2012 at 5:35 am
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?
June 15, 2012 at 5:42 am
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
June 15, 2012 at 5:45 am
Seems the only option now doesn't it, thanks Lowell.
June 15, 2012 at 5:54 am
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
June 15, 2012 at 5:58 am
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
June 15, 2012 at 6:20 am
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.
June 15, 2012 at 6:32 am
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