Same or Different?

  • Comments posted to this topic are about the item Same or Different?

  • 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
    Twitter: @wsmelton
    Github: wsmelton

  • 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..


  • More of a personal take than a systems one, this..

    I got fed up with remembering a load of passwords for various 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)

  • 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.

  • Barry,

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

  • 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.

  • 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

  • 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 !!!

    RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."

  • 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[/url], 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.

    Microsoft Certified Master: SQL Server 2008
    Author - SQL Server T-SQL Recipes

    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!
    For better assistance in answering your questions
    Performance Problems
    Common date/time routines
    Understanding and Using APPLY Part 1 & Part 2

  • All of these options are good.

    One useful thing I've been doing a while is using phrase-based passwords rather than some obscure combination of alphanumerics. This isn't suitable for all purposes, but it does come in handy for some accounts and some purposes. And example (a bad one, mind) would be to use a password phrase like: "The Quick Brown Fox, Jumped Over the Lazy Red Hen's Wagon." It not only ends up longer than most passwords, and so a tad more challenging on a brute force attack (so long as it isn't something as obvious as my example), but I find most folks can remember a full sentence easier, will then use punctuation, numbers and case, and actually produce far less annoying flip-flop short passsword combinations. But, as noted, it has its limitations, as some folks detest typing anything that long.

    I saw a real benefit from this when I had an administrative asssitant who ended up using some phrase like:"My dog Fred chases a car with the license plate number XXX-XXX, 3 times a week." This was a woman who had little computer security awareness, but not in a million year's would anyone have cracked that password phrase; and since she typed hellish fast with nary amistake, it wasn't even uncomfortable for her to type.

Viewing 11 posts - 1 through 11 (of 11 total)

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