Worst Practives - Blank Passwords
-
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/sjones/worstpractivesblankpasswords.asp
-
In my environment network administration is a separate function to SQL Server administration so I tend to use NT security and let the network administrator worry about resetting passwords.
The network administrator has set up NT groups specifically for SQL Server development access and also for application access based around functional need.
I grant access via NT Groups rather than to explicit people. Also, I tend to grant access to specific databases rather than generic access to a server.
There is no perfect solution, particularly when http://www.lostpasswords.com exists.
-
Definitely better to use a password, even a simple one, rather than no password. My employer does not have a strong password policy, but before I arrived, a high percentage of the SQL Servers had no password. This changed in week one - primarily to keep nosey developers out of finance databases in the first instance. However, the SQL Slammer virus proved that even a weak password is better than none, as none of our machines got infected, even though some of the passwords are not cryptographically 'strong'. OK, had it used a dictionary attack, we'd have had problems...
On that subject, one scheme I have started using is to use an <adjective><noun><number> combination, similar to that which Yahoo use when first allocating passwords, ie:
redlorry422
greenbird173 etc
Reasonably long, greatly extends the time required for a successful dictionary attack, and relatively easy to remember for the end user. As we have a different password for each server, we keep them in a password protected Excel spreadsheet, which is on a network folder which only the DBAs have security rights to. Not perfect, but definitely better than nothing if you've not got the luxury of running a trusted NT account only environment. In an ideal world, using NT only security would be the aim, unfortunately if you're in a big shop with lots of third party apps kicking around, they invariably used SQL Server security rather than NT, so it's a non-starter - making the SQL Server passwords more secure is the best you can do
With regard to future editions of SQL Server, I'd like to see at least a ban on null passwords, and preferably a minimum length restriction, again to slow up dictionary attacks.
Further out still, it may be that digital fingerprint recognition will become standard - currently standalone devices that perform this cost around $100 (and falling), but Acer and others have had laptops out for a couple of years with a built in fingerprint detector for boot/login purposes. (Guess these things work by generating a long, unique string of digits which represent your personal fingerprint, which is then used to set your password?) There's also a number of mice and keyboards out there with the same devices embedded. However, it does beg the question of what happens if your DBA ends up in an accident and you've suddenly lost access to your only sysadmin account on the payroll database..... probably a good idea not to delete BuiltIn\Administrators just yet!!
Edited by - jonreade on 03/31/2003 05:08:43 AM
Jon -
Blank passwords are horrible and based on the "we cannot comment on Yukon" from MS people, this is being addressed. Soon we should have expirations and possibly lockouts.
We use the same pwd for all SQL Servers but it changes every 30 days. Not sure if this is better than different pwd for all machines and having them longer. We also use PasswordSafe (www.counterpane.com) to store our passwords so they are available to everyone.
A note on biometrics. A number of people have found flaws in here. You only have ten fingers, accidents occur, and it's a digital representation of your finger, not your finger. If it becomes compramised, what do you do? How do you resolve this? It's likely a much bigger issue than a secure valdation. Also, the fingerprint readers have been fooled, a glass with you rfingerprints, a little jelly, and you can lift and reproduce the print.
Steve Jones
-
Lockouts would be good. Seems mad to me that a developer can't get directly into an NT server on the network without asking for trouble, but can set up a simple app to repeatedly bang away at the database until it lets them in. Expirations would definitely be an improvement, as would restricting the hours when an account can be used - maybe have the option to automatically lock users out if their accounts are accessed outside of (admin definable) business hours. Just thinking, being able to attach lockout hours/days to roles would be cool, save a lot of admin effort. Hope you're listening Microsoft 🙂
Jon Reade
Jon
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply