September 13, 2011 at 10:45 pm
Comments posted to this topic are about the item Not on the Same Page
September 14, 2011 at 2:37 am
I don't wish to create an "excuse list" but most of the time I get the developer hitting a screwy problem and blaming 'security settings' stopping him from working out what the problem is. Guess who's forced to give way? And no prizes for working out it wasn't the security settings neither.
September 14, 2011 at 2:57 am
I have a couple of thoughts about DBAs and security.
1. Security is a theme that permeates a company at all levels. In our company, the application of patches, service packs and the like lies in the realm of the sysadmins. We DBAs give our input, but they do it and they are responsible for rectifiying the situation when things go wrong. We DBAs are responsible for security inside the server — (SQL Server) logins, roles, users, data integrity and such. We deal with everyday security problems.
2. In my experience DBAs understand and apply such principles as Least Privilege well.
3. Aside from lazy, naive and stupid DBAs, the greatest preventable threats to DB-security I've seen come from developers. They configure the DB so that it minimises the work they have to do, eg. the default application login must have the sysadmin role and be DB-Owner, they are happy with default configurations when installing SQL Server. I'm painting with a broad brush here, of course.
4. From a security perspective, I often wonder how sensible it is for DBAs to air details of their company's DBs and servers in public fora like this. Let us hope that SQLServercentral.com and Simple Talk Publishing are honourable and trustworthy.
September 14, 2011 at 3:26 am
I agree with your point Steve about management or 'the business' just wanting to get things done at the expense of security. Some months ago I undertook what I thought to be a comprehansive security audit/review of all the SQL Server instances and databases where I work and published my findings and recommendations. The result: almost total indifference!
Application vendors are not terribly helpful either - try finding any documentation where it specifcally states what permission is required on a given object. Most of the time it just says "create a login blah and assign it the sysadmin role.
Regards
Lempster
September 14, 2011 at 6:44 am
Lempster (9/14/2011)
...Application vendors are not terribly helpful either - try finding any documentation where it specifcally states what permission is required on a given object. Most of the time it just says "create a login blah and assign it the sysadmin role.Regards
Lempster
Even MS. Have you ever tried to figure out what rights each security role has using MS documentation. Only uselessly vague descriptions. And nowhere is any description of specific rights needed for other common tasks.
...
-- FORTRAN manual for Xerox Computers --
September 14, 2011 at 7:56 am
In an instance of great irony, a third-party auditing application that I assessed for use in SQL Server 2005 required the use of the sa login. Not even another high-privilege login, but sa itself was hard-coded. I spoke with their tech support, and apparently no one had ever complained about this before I did. I was unable to recommend their product for our use.
September 14, 2011 at 8:30 am
Security is a very specialist area, once you get past the basics. And, like other posters stated, most of the simple measures which should be put in place are often overruled by management as taking (more) time and money, in industries which are not subject to stringent regulation (i.e. where the fines aren't frighteningly large).
On management's side, security does cost quite a bit of money and take more skilled people/team leads across the board, as well as often being seen as quite an imposition by clients and customers, i.e. 'What, I can't use "password" as my password? What about "Password"? No, fine, "Password1"! Gah!!! I swear, if I can't use "Password123" I'm going to buy something else!'*
On the specialist side, once you make it past basic security "No, you shouldn't store cleartext passwords in the database", you get to midlevel security "How should I do so, then?" At this point, most nonspecialists (including Microsoft with SQL Server up to 2008 R2) fail. Microsoft, for example, in UCS-2 "Unicode" (irrelevant) generates a randomized salt (good idea, unknown implementation) of moderate length (eh) and uses SHA1 (bad) to hash it once (ridiculously bad). Single hashed SHA1 passwords can be cracked at a rate in excess of 13 billion tries per second per machine with GPU's... so, for example, if you've managed to get a copy of those hashed passwords, you can take a 500 million word cracking dictionary, and in a hybrid attack append every number between 0 and 1000 to every word in only 38 seconds per account. Worse, if there aren't "complexity" requirements, you can brute force (try every single combination) 8 character lower case passwords in 16 seconds per account. Lower case + numbers, 8 characters long... 217 seconds per account. Upper case, lower case, numbers, 8 characters long... 4.6 hours per account.
The more correct answer is to use a well known, properly implemented** key derivation algorithm such as PBKDF2 and give it as many rounds as possible*** for reasonable performance... which may require buying new hardware, and if you want real security means offloading this to a GPU to get enough rounds to really matter against GPU cracking.
It only gets more complex from here.
*Yes, these are all very, very common passwords... and the last two easily make it past "complexity" requirements, despite being almost certain targets for even pure dictionary attacks.
**Proper implementations of security tend to be very difficult, because even slight mistakes or oversights are major problems.
*** Numbered in, at minimum, thousands to tens of thousands; enough to cause a truly modern CPU core or, preferably, full GPU to be fully utilized for a significant fraction of a second or better.
September 14, 2011 at 9:04 am
jay holovacs (9/14/2011)
Lempster (9/14/2011)
...Application vendors are not terribly helpful either - try finding any documentation where it specifcally states what permission is required on a given object. Most of the time it just says "create a login blah and assign it the sysadmin role.Regards
Lempster
Even MS. Have you ever tried to figure out what rights each security role has using MS documentation. Only uselessly vague descriptions. And nowhere is any description of specific rights needed for other common tasks.
Too true. I do submit issues on Connect, but they've made it much harder than the feedback forms in BOL online to ask for more details.
September 14, 2011 at 9:12 am
I see prioritization of security as the real issue. Time and expense are rarely compromised in favor of focus on the potential risk. Not the DBA's fault - given the priority and, if needed, training, attention to security would be the norm. The same holds true for the developers.
September 14, 2011 at 9:59 am
Nadrek (9/14/2011)
. . . Single hashed SHA1 passwords can be cracked at a rate in excess of 13 billion tries per second per machine with GPU's... . . .
...unless someone is counting and times out the attacking IP address after say three consecutive failed attempts.
September 14, 2011 at 10:53 am
Security is ultimately the responsibility of management. If they don't care or will not fund improvements/training, nothing will change.
September 14, 2011 at 11:01 am
In my experience, good security is a collaborative effort. It is absolutely true that management buy-in is essential, but even a top-down mandate won't matter if the developers, sysadmins, and DBAs aren't on board. I count myself lucky that I am in an environment which has a very active and knowledgeable ISO who has executive-level support, and has brought various technical leads into an SDLC security planning group in order to incorporate best practices at all levels of project and application development.
September 14, 2011 at 11:23 am
Revenant (9/14/2011)
Nadrek (9/14/2011)
. . . Single hashed SHA1 passwords can be cracked at a rate in excess of 13 billion tries per second per machine with GPU's... . . ....unless someone is counting and times out the attacking IP address after say three consecutive failed attempts.
I was speaking of an offline attack, after an insider took the MDF, or the backup file, or used a vulnerability (SQL Injection, a trojan, a botnet, etc.; see Gawker and Sony recently) to obtain a bulk copy of the userids and hopefully hashed passwords, and then attack the hashed passwords.
Online attacks are different, but are also often conducted by botnets, so any one attacking IP only hits one username once. Note that timing out an IP after three consecutive failed attempts can really irk the clients/customers of a public web site if one company/ISP/etc has 20,000 people behind a single external IP address. Timeouts like that are almost always implemented per user account or per user account+IP, etc.
September 14, 2011 at 2:52 pm
I have tried to obfuscate production data for years and always get the same response from developers & management alike: How can I fix problems the users have if I do not have the "exact" production data they are looking at. I've tried explaining the consequences and the same response - we don't have time or we don't care - just give us prod data.
We've purchased a tool that gives us data obfuscation (for free as an add-on too!) and I have been like that drip of water - constantly nagging...
Hopefully I get my way sooner rather than later - when there is a data breach.
September 14, 2011 at 3:15 pm
Nadrek (9/14/2011)
Revenant (9/14/2011)
Nadrek (9/14/2011)
. . . Single hashed SHA1 passwords can be cracked at a rate in excess of 13 billion tries per second per machine with GPU's... . . ....unless someone is counting and times out the attacking IP address after say three consecutive failed attempts.
I was speaking of an offline attack, after an insider took the MDF, or the backup file, or used a vulnerability (SQL Injection, a trojan, a botnet, etc.; see Gawker and Sony recently) to obtain a bulk copy of the userids and hopefully hashed passwords, and then attack the hashed passwords.
That type of defese is IMO the proverbial closing the gate after the horse is gone.
Online attacks are different, but are also often conducted by botnets, so any one attacking IP only hits one username once. Note that timing out an IP after three consecutive failed attempts can really irk the clients/customers of a public web site if one company/ISP/etc has 20,000 people behind a single external IP address. Timeouts like that are almost always implemented per user account or per user account+IP, etc.
Absolutely - we do ID+IP.
Viewing 15 posts - 1 through 15 (of 15 total)
You must be logged in to reply to this topic. Login to reply