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»»

We Need to Learn Encryption Expand / Collapse
Author
Message
Posted Tuesday, June 12, 2012 11:57 PM


SSC-Dedicated

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

Group: Administrators
Last Login: Yesterday @ 3:05 PM
Points: 31,284, Visits: 15,750
Comments posted to this topic are about the item We Need to Learn Encryption






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1314861
Posted Wednesday, June 13, 2012 6:21 AM
Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: 2 days ago @ 12:36 PM
Points: 762, Visits: 1,947
"not just from hackers and criminals, but from the virtual vandals and bored teenagers that have more time than morals or sense. "

... not to mention governments with more resources than any of the above...


...

-- FORTRAN manual for Xerox Computers --
Post #1315055
Posted Wednesday, June 13, 2012 6:32 AM
Say Hey Kid

Say Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey Kid

Group: General Forum Members
Last Login: Friday, November 21, 2014 6:04 AM
Points: 699, Visits: 1,754
I'm one of two people at place of employment that has even the slightest knowledge of encryption, certificates and PKI. That's sad since it should be a elementry concept in IT, development and management. The barn door remains unlocked...
Post #1315067
Posted Wednesday, June 13, 2012 8:10 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Monday, November 10, 2014 6:19 AM
Points: 262, Visits: 919
http://www.crockford.com/ec/dining.html

While not specifically about database, it's a good story about concurrency and security. It gives the reader a nice introduction into a capability-based access methodology. I wonder if more developers embraced this strategy how differently applications would be built from the ground up. We all agree that security must be built-in from start and not glued-on at the end, right?
Post #1315149
Posted Wednesday, June 13, 2012 8:22 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Tuesday, September 16, 2014 2:03 PM
Points: 1,334, Visits: 3,069
SQL Server has finally got the ball started and rolling with TDE and CLE, but they still got a long way to go yet when it comes to encryption IMHO.

"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ..."
Post #1315164
Posted Wednesday, June 13, 2012 10:04 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, November 5, 2014 11:10 AM
Points: 26, Visits: 198
Vormetric offers a very interesting and easy to manage product.
www.vormetric.com



Post #1315277
Posted Wednesday, June 13, 2012 11:09 AM


SSC-Dedicated

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

Group: Administrators
Last Login: Yesterday @ 3:05 PM
Points: 31,284, Visits: 15,750
Carl Grant (6/13/2012)
Vormetric offers a very interesting and easy to manage product.
www.vormetric.com


That is interesting. One more thing to look at.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1315326
Posted Thursday, June 14, 2012 6:11 AM


SSC-Dedicated

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

Group: General Forum Members
Last Login: Yesterday @ 5:34 PM
Points: 35,609, Visits: 32,200
From the Article
We can't change the way SQL Server, or other vendor technologies, work at a base level, but we can reduce the amount of damage that's done by not being the easy prey for attackers. In my mind, that means we should be securing our data as best we can, including encrypting communications and limiting access rights, as well as encrypting the actual data we store.


Ah... you've hit upon a topic near and dear to my heart.

One of the biggest problems I've found is just how high the priv levels are for application logins. Like it or not, applications shouldn't have more than PUBLIC privs, IMHO. This can be accomplished fairly easily through stored procedures by making it so the procedures have the privs and the users have EXECUTE privs on the procs. The user don't have privs to even read from a table. This has been made a whole lot easier using the "DB_Executor" role which has been made possible as of 2005 by being able to grant EXECUTE privs to a DB role (it seems that a lot of people have adopted the name "DB_Executor" for this role).

Ironically, the use of xp_CmdShell can be a good measure of whether or not your system is actually properly locked down or not. In a properly locked down system, individual users can't even see tables, never mind run xp_CmdShell yet the stored procedures called by the users can use it.

So far as I'm concerned, a system isn't properly secure unless the only people that have any privs other than PUBLIC are the DBAs. I'm not saying that you don't need encryption of things like SSNs because you still have to protect against possible internal threats but there's really no excuse for having the potential of external threats.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1315793
Posted Thursday, June 14, 2012 8:50 AM


Default port

Default portDefault portDefault portDefault portDefault portDefault portDefault portDefault port

Group: General Forum Members
Last Login: Friday, November 21, 2014 12:51 PM
Points: 1,433, Visits: 3,230
Jeff Moden (6/14/2012)

One of the biggest problems I've found is just how high the priv levels are for application logins. Like it or not, applications shouldn't have more than PUBLIC privs, IMHO. This can be accomplished fairly easily through stored procedures by making it so the procedures have the privs and the users have EXECUTE privs on the procs. The user don't have privs to even read from a table. This has been made a whole lot easier using the "DB_Executor" role which has been made possible as of 2005 by being able to grant EXECUTE privs to a DB role (it seems that a lot of people have adopted the name "DB_Executor" for this role).

Ironically, the use of xp_CmdShell can be a good measure of whether or not your system is actually properly locked down or not. In a properly locked down system, individual users can't even see tables, never mind run xp_CmdShell yet the stored procedures called by the users can use it.

So far as I'm concerned, a system isn't properly secure unless the only people that have any privs other than PUBLIC are the DBAs. I'm not saying that you don't need encryption of things like SSNs because you still have to protect against possible internal threats but there's really no excuse for having the potential of external threats.


Well stated Jeff.

As far as the comments that SQL server encryption has a long way to go, I would say it provides all the the basic tools you need to secure information in (and outside of) your database. What it doesn't have is a sophisticated key management mechanism, but there are third party key management systems out there.

Better yet, roll your own key management that meets your own proprietary standards.

The truth is out there.




The probability of survival is inversely proportional to the angle of arrival.
Post #1315955
Posted Friday, June 15, 2012 11:36 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Tuesday, September 16, 2014 2:03 PM
Points: 1,334, Visits: 3,069
I would say it provides all the the basic tools you need to secure information in (and outside of) your database. What it doesn't have is a sophisticated key management mechanism, but there are third party key management systems out there.



Agreed, but my point was that secure database encryption is still in a transition process, and the jury is still out on whether it is the ideal solution at this point. For example this is an excerpt right from a MSDN Technical article on cryptography:

"It often seems that cryptography is employed to solve problems for which it is not really a solution. Even in circumstances appropriate to a cryptographic solution, it is not always the case that it should be deployed by means of the database engine.

When you tell your users that their data is cryptographically protected, you are implicitly assuring them that their data is protected against several kinds of threats. Cryptography is the world of the paranoid (see, for example, Bruce Schneier’s seminal book Applied Cryptography). If data really must be protected, build your systems while planning on a security audit by the most paranoid person you can imagine. It is rather easy to create an incomplete cryptographic solution. If you plan to keep your data “a little bit secure,” it is better to not represent to your users that their data is protected at all.

Just because you need to cryptographically protect your data does not necessarily mean that the database engine is the best place to do it, especially when scalability is a concern. Because cryptography is very CPU intensive, it may be wiser to limit the database to storing data and leave the cryptographic processing to upstream components—like the middle tier—as these are easier to scale."


"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ..."
Post #1316818
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse