November 13, 2010 at 1:28 pm
Comments posted to this topic are about the item Proving Your Identity
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
November 15, 2010 at 4:07 am
Ouch.
Heads-up much appreciated.
Semper in excretia, sumus solum profundum variat
November 15, 2010 at 6:25 am
I agree that we need better security tools, but I hope that as they are developed we do not lose sight of the one thing that many security tools, systems, and practices simply ignore. That thing? Users. Someone needs to see and work with the data legitimately!
Case in point - years ago I was contracted to do a job out west at a world wide company that will remain nameless. I knew what I needed to get done and had told the client that the work would be easy and probably take only two days. I arrived on site ready to go, and whammo! I first had to fill out non-disclosure agreements. Ok, sure, no problem. I then needed to be fingerprinted because they transited some data on fingerprint protected flash drives. OK.... I then needed to be issued a photo ID badge so I could get into restricted areas. Ok... I then needed logins and passwords setup.... Well, by now, the first day out there had ended and long story short, I didn't get any badge or approval to do the work until late in the afternoon on the second day. In fact, what I thought would be a two day trip turned into an entire week, and I only started on the actual work late on the third day.
While there, many end users joked with me that the company was so secure with their data that few people got any work actually done, and they spent most of their time getting permissions to get to the data they needed. Its a good company, but I left there with the lesson that they probably waste days and days of employee time due to nothing more than security - some of it purely ridiculous.
Security is important, no question. But when it is overdone and kills productivity, well, whats the point? Aren't we trying to stop the "bad guys"? Or is the idea of security both to stop the "bad guys" AND "good guys"? I've seen lots more "good guy" stoppage in my career than "bad guy" stoppage - so I hope whatever they come out with next, someone will keep in mind that someone else - not a criminal, but just a worker maybe - needs to use that data.
November 15, 2010 at 7:31 am
My biggest concern with this is a false sense of security. Between bad implementations or worse, poorly thought out systems, it seems that we're being inundated with 'security' that is yet another emperor in yet another fine suit of clothes.
By now, we should all be quite aware of just how weak fingerprints are for authentication. We've got the 'gummy bear attack', tape on surgical gloves, and we still have scanners in use that are subject to simple 'fogging' (breathe softly on the scanner to fog the scanner the way you'd fog your glasses for cleaning; the differential condensation along the ridges and valleys of the deposited oils will cause the last fingerprint to be read again).
Even when the authentication mechanism itself has been shown robust against attack, there is ultimately one set of bits that needs to be compared to another set of stored bits, and both the storage and transmission of those bits are subject to all the same old attacks.
November 16, 2010 at 5:19 am
For me my biggest bug bear in terms of SQL authentication is the apparent assumption from some quarters that Windows Authentication is always the answer, that there is no legitimate reason to use SQL Authentication, and that just because MS say so it must be true. It's like they've pronounced it as pointless and therefore can wash their hands of it, rather than working to make it more secure.
I remember doing a SQL 2005 course a few years back, with an instructor who was clearly a "well the book says" style of instructor. He pronounced that there was no reason to use SQL Authentication these days... at which point at least half of us in the room pointed out that he was wrong. Not every SQL Server and or Web server is or can be in a domain environment for various reasons, and for that matter, not everyone needing to connect to SQL can be from the same domain or a separate trusted domain.
Personally I'd love to see an option in SSMS if nothing else to allow you to use Windows Authentication to connect, using specified domain, username and password like you can with so many other things. Or failing that, lets see SQL Authentication given something on the lines of SSH capabilities. OK, so it won't really do anything to improve the authentication to SQL, but at least it will stop passwords and data being transmitted in plain text.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply