Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

Same or Different? Expand / Collapse
Author
Message
Posted Thursday, September 17, 2009 9:14 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 12:50 PM
Points: 33,073, Visits: 15,187
Comments posted to this topic are about the item Same or Different?






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #790079
Posted Thursday, September 17, 2009 9:39 PM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Today @ 12:01 PM
Points: 841, Visits: 2,303
For service accounts it is the same username on most servers I beleive, but the password is changed once a year.

Administrators have a user accounts used to do day to day but the "Admin" permissions are seperated to a different account that is not used to logon with unless necessary to perform a task.

If the company or organization is truly concerned with security and desires to keep a strict policy (especially if you have HIPA or PCI compliance to deal with) you will have a security person(s) on staff that, that is all they do.

I did pick up a good script from a SQL Saturday event for setting the SA password to a random 20 something character password. It "sets it and forgets it", meaning you do not know what it is set to. The speaker said his customers that deal with HIPA, the auditors love this setup. I will have to find the DVD I saved it on cause the download site I believe has been taken down already. It was from the Steel City SQL Saturday 7 in Birmingham, AL.


Shawn Melton
PS C:\>(Find-Me).TwitterURL
@wsmelton
PS C:\>(Find-Me).BlogURL
meltondba.wordpress.com
Post #790085
Posted Thursday, September 17, 2009 10:06 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Thursday, May 15, 2014 5:11 PM
Points: 6,067, Visits: 5,283
Our company does something similar, an additional sa like account is created. The rationale is that the sa account is well known. The password gets periodically reset and nobody knows what it is..

I would tend to say user/pass for most instances. I would consider a different one for any server that be considered special for maybe HIPAA or PCI reasons. At some point the more servers you have the harder it is and keep in mind that those servers will probably interact with other servers or file systems it makes maintenance more and more difficult..

CEWII
Post #790095
Posted Friday, September 18, 2009 8:20 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Thursday, July 24, 2014 8:44 AM
Points: 56, Visits: 200
More of a personal take than a systems one, this..

I got fed up with remembering a load of passwords for various things..email accounts, server login, workstation logins..

So what I did was generate a random 16 digit hex string. This took me about two days to actually commit to memory. writing it down, typing it back in over and over.

Anyway, once this single thing is firmly lodged, you can use parts of it depending on how secure you need to be in a given situation.

With 16 digits to play with you can do things like First 4, last 4, third 4 etc Middle 8, first 8 last 8. So remembering one long password actually gives you a whole slew of shorter ones you can use.


DBA (Dogsbody with Bad Attitude)
Post #790424
Posted Friday, September 18, 2009 9:22 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Thursday, July 24, 2014 10:26 AM
Points: 77, Visits: 166
So they know the user name to attack is "sa". Big deal. If God wanted to make your life harder and he gave the first two letters of your password to your enemies, you'd just make a password two more letters longer and be just as secure as before. This is why God usually doesn't mess around like that and sends plagues, frogs, plagues of frogs that eat backup tapes, and the angel of death, instead.

Since these days a compromised password means that your entire database and credit card number are copied to Peking and Moscow in about 500 milliseconds, I don't quite see the point of changing it once a month, although I think someone explained it to me once.

On one set of systems (UNIX) I set "random" hexadecimal numbers of just 3 bytes, 123abc, each different, and since the systems had some funny ideas about acceptable passwords I used 0qz123abc one month (I do it even if I don't believe in it) and 469cadqz0 next month, turn about. And for site visits I remotely changed it to "convenient" instead - or to something which I forget now.

In a recent discussion here, someone was insisting that for user security the thing to do is to rely on Windows authentication to SQL Server. Well, maybe.

What we don't do, but I'd like to, is use bar codes for the passwords - then there's a physical object but it doesn't matter how very hard the magic word is to type, because you don't. I'm not sure what the current price tag is on a bar code scanner, but since you can get a webcam for less than $20 it should be pocket money. I did look once for "read bar codes on web cam" software. It appeared that somebody someplace like Chile, somewhere rather volatile in Central or South America I mean, had put one such online, as college project prototype, then disappeared. I wondered if he'd been rubbed out by the international consortium of bar code reader manufacturers. Or he just left college, more likely. I hope so, anyhow.

I have an RSI-type disability and one possible alternate computer input method is an array of barcodes that I can point a scanner or a camera at. As it is, I'm getting on pretty well with a touchscreen product called Fitaly.
Post #790472
Posted Friday, September 18, 2009 10:08 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 12:50 PM
Points: 33,073, Visits: 15,187
Barry,

That's interesting. I might give that a try.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #790521
Posted Friday, September 18, 2009 10:22 AM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Monday, November 2, 2009 8:46 AM
Points: 875, Visits: 313
One classified project I worked on used a program to generate a random password which you then used to access the system. It changed every time you accessed the data, even the email system. Since it was classified, however, I never had an opportunity to look into the code to see how they managed the implementation.
Post #790531
Posted Friday, September 18, 2009 10:31 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Monday, July 21, 2014 4:57 AM
Points: 1,049, Visits: 3,002
I must admit I still prefer different passwords for different systems. However, we do have a few things that make our lives easier.


  • We do implement a password database; all passwords encrypted, those with access grouped and visibility limited according to those groups

  • Password expiry periods vary depending on the system. Test and Dev instances don't need to be changed as frequently as Live. Databases containing Financial or HR data certainly need tighter security than the telephone directory DB.

  • We give an administrator appropriate rights to their AD account so that most changes appear in the log under their name, thereby being traceable. The SA and machine admin accounts can then have far more complex passwords since they're rarely used (and rightly so, in my opinion).



I realise the potential issues surrounding a database of passwords, and I'm certainly not going to discuss our implementation. However, I will say we've tried to break it in enough ways (that haven't worked) that we can have confidence in its strength. It's certainly not the weakest part of our security portfolio.


Semper in excretia, sumus solum profundum variat
Post #790536
Posted Friday, September 18, 2009 11:01 AM
Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Friday, July 25, 2014 11:18 AM
Points: 3,193, Visits: 2,289
At present we have separate AD accounts for services on 'logical' groups of servers. These AD service account passwords are changed annually or when staff changes. We are moving further to eliminate 'interactive login' and 'terminal services login' for these accounts as well. As for the sa password, it is 32+ characters long and changed every 30 days.

By about the end of the first or mid second quarter of next year our planned security hardening changes should make thinks extremely secure.

One AD service account for all SQL Server services per physical server or virtual Windows server in the case of clusters. This AD service account will only be allowed login authority on that server only, in addition to having 'interactive login' and 'terminal services login' disabled. Now on to the AD service account password ... it will be 32 characters and be changed every 24 hours !

As for the sa login - well it will be 32 characters and be changed every 24 hours as well.

Sounds like a tall order but it will totally automated in conjunction with password vaulting software for our 2005 instances.

Additionally, Windows Administration and key service and domain functions that require AD service accounts will fall into the same criteria described for the SQL Server AD service.

Oh - just the SQL Server AD accounts hardening affects 270+ instances !!!




Regards
Rudy Komacsar
Senior Database Administrator

"Ave Caesar! - Morituri te salutamus."
Post #790557
Posted Friday, September 18, 2009 12:39 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Thursday, July 24, 2014 7:55 PM
Points: 6,582, Visits: 8,860
DBAs have multiple accounts: Regular accounts are in a security group that has SA rights on the servers in that domain. Each DBA has a service account in each domain. This is the only account that can be used to remotely log into a server.

SQL has a service account in each domain. All sql servers on that domain use the same account. PW is changed every 60 days. Each domain has a different password.

SA logins are different on all servers. The DBAs use sa to log into servers on other domains than their root account.

Passwords are stored in KeePass, with a medium-strength password that by now we have all memorized.

When anyone with a service account leaves, all sql service account passwords are changed. If a DBA leaves, all SA passwords are also changed.


Wayne
Microsoft Certified Master: SQL Server 2008
If you can't explain to another person how the code that you're copying from the internet works, then DON'T USE IT on a production system! After all, you will be the one supporting it!
Links: For better assistance in answering your questions, How to ask a question, Performance Problems, Common date/time routines,
CROSS-TABS and PIVOT tables Part 1 & Part 2, Using APPLY Part 1 & Part 2, Splitting Delimited Strings
Post #790628
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse