Is this a WTF?
-
Five years ago I did contract work for a manufacturing plant of a major multinational. This week I have started doing some more work at the same location. The sa password (systems administration password for those that don't know SQL server. The equivalent of root access) for their SQL server is still the same as it was 5 years ago. I was a both a bit stunned when saw that, and a bit relieved - as I don't need to ask anyone for access to various systems as I still can get in.
Note that they did have to renew my network and remote access credentials in order to allow me to sign into the network.
-
@OzPeter said:
Note that they did have to renew my network and remote access credentials in order to allow me to sign into the network.
Well at least they are doing some things right, but why are you needing the sa account? I can't think of a reason to let anyone have access to that account.
-
@locallunatic said:
but why are you needing the sa account? I can't think of a reason to let anyone have access to that account.
I'm not saying that I need it now, but I was given it 5 years ago as an easy way for me to the work I had to do then (but yeah .. I know I have been given too much power .. I'm resisting the urge to have a cat sit on my lap while I laugh in that super villain way)
-
TRWTF is that the password was memorable enough for you to recognize it.
-
@joe.edwards said:
TRWTF is that the password was memorable enough for you to recognize it.
I didn't remember it .. I just kept good notes. But then again it is a english word written in l33t speak.
-
@OzPeter said:
@joe.edwards said:
TRWTF is that the password was memorable enough for you to recognize it.
I didn't remember it .. I just kept good notes. But then again it is a english word written in l33t speak.Was it "r00t"? Or "pa55w0rd"?
-
@cheapie said:
@OzPeter said:
@joe.edwards said:
TRWTF is that the password was memorable enough for you to recognize it.
I didn't remember it .. I just kept good notes. But then again it is a english word written in l33t speak.Was it "r00t"? Or "pa55w0rd"?
It was clearly "54", since it was the sa account.
-
@cheapie said:
Was it "r00t"? Or "pa55w0rd"?
Neither of them. But if I told you the company name it wouldn't take long to guess what it was.
-
The WTF is having SQL Authentication on at all. I'm not sure why most programs require SQL Authentication, everything I've ever written works just fine with Windows Auth and is much more secure because of it.
-
@Jaime said:
The WTF is having SQL Authentication on at all. I'm not sure why most programs require SQL Authentication, everything I've ever written works just fine with Windows Auth and is much more secure because of it.
I can think of one reason: it would require extra Windows accounts to have different roles. So that would be down to convenience and laziness, I guess.
-
@Jaime said:
The WTF is having SQL Authentication on at all. I'm not sure why most programs require SQL Authentication, everything I've ever written works just fine with Windows Auth and is much more secure because of it.
Old crap written for something like SQL Server 4.21 whose development team is too horrible to modernize it. (Hi Dynamics GP.)
-
@TGV said:
I don't get it... Why would you need extra Windows accounts to have different roles? If you mean that the app will connect using different credentials depending on the role of the user using the app, well that is stupid and prevents connection pooling. Even if that's what you want, application roles have been available for fifteen years to meet that need. However, the easiest solution to the problem is just to use roles for roles instead of trying to use user accounts to be some sort of role substitute.@Jaime said:
The WTF is having SQL Authentication on at all. I'm not sure why most programs require SQL Authentication, everything I've ever written works just fine with Windows Auth and is much more secure because of it.
I can think of one reason: it would require extra Windows accounts to have different roles. So that would be down to convenience and laziness, I guess.
-
@Jaime said:
@TGV said:
I don't get it... Why would you need extra Windows accounts to have different roles? If you mean that the app will connect using different credentials depending on the role of the user using the app, well that is stupid and prevents connection pooling. Even if that's what you want, application roles have been available for fifteen years to meet that need. However, the easiest solution to the problem is just to use roles for roles instead of trying to use user accounts to be some sort of role substitute.@Jaime said:
The WTF is having SQL Authentication on at all. I'm not sure why most programs require SQL Authentication, everything I've ever written works just fine with Windows Auth and is much more secure because of it.
I can think of one reason: it would require extra Windows accounts to have different roles. So that would be down to convenience and laziness, I guess.They're useful for connecting to the database directly when a user wears different hats. For example I use both a release account and day to day account to access the same database. I shouldn't always have write access.
-
Yes, because it's always best to reinvent the wheel as many times as possible. You can already accomplish what you do by having two Windows accounts, only better. All that SQL Authentication does for this use case is invent another authentication mechanism and create another set of credentials to manage. Tell me, how often do you change the password on your release account?
