SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


We Need to Learn Encryption


We Need to Learn Encryption

Author
Message
Steve Jones
Steve Jones
SSC Guru
SSC Guru (249K reputation)SSC Guru (249K reputation)SSC Guru (249K reputation)SSC Guru (249K reputation)SSC Guru (249K reputation)SSC Guru (249K reputation)SSC Guru (249K reputation)SSC Guru (249K reputation)

Group: Administrators
Points: 249275 Visits: 19809
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
My Blog: www.voiceofthedba.com
jay-h
jay-h
SSCertifiable
SSCertifiable (6K reputation)SSCertifiable (6K reputation)SSCertifiable (6K reputation)SSCertifiable (6K reputation)SSCertifiable (6K reputation)SSCertifiable (6K reputation)SSCertifiable (6K reputation)SSCertifiable (6K reputation)

Group: General Forum Members
Points: 6033 Visits: 2443
"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 --
chrisn-585491
chrisn-585491
SSCertifiable
SSCertifiable (5.9K reputation)SSCertifiable (5.9K reputation)SSCertifiable (5.9K reputation)SSCertifiable (5.9K reputation)SSCertifiable (5.9K reputation)SSCertifiable (5.9K reputation)SSCertifiable (5.9K reputation)SSCertifiable (5.9K reputation)

Group: General Forum Members
Points: 5932 Visits: 2649
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...
Mike Dougherty-384281
Mike Dougherty-384281
Ten Centuries
Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)

Group: General Forum Members
Points: 1192 Visits: 944
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?
TravisDBA
TravisDBA
SSCarpal Tunnel
SSCarpal Tunnel (4.9K reputation)SSCarpal Tunnel (4.9K reputation)SSCarpal Tunnel (4.9K reputation)SSCarpal Tunnel (4.9K reputation)SSCarpal Tunnel (4.9K reputation)SSCarpal Tunnel (4.9K reputation)SSCarpal Tunnel (4.9K reputation)SSCarpal Tunnel (4.9K reputation)

Group: General Forum Members
Points: 4896 Visits: 3069
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.:-D

"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
Carl Grant
Carl Grant
SSC-Enthusiastic
SSC-Enthusiastic (172 reputation)SSC-Enthusiastic (172 reputation)SSC-Enthusiastic (172 reputation)SSC-Enthusiastic (172 reputation)SSC-Enthusiastic (172 reputation)SSC-Enthusiastic (172 reputation)SSC-Enthusiastic (172 reputation)SSC-Enthusiastic (172 reputation)

Group: General Forum Members
Points: 172 Visits: 205
Vormetric offers a very interesting and easy to manage product.
www.vormetric.com



Steve Jones
Steve Jones
SSC Guru
SSC Guru (249K reputation)SSC Guru (249K reputation)SSC Guru (249K reputation)SSC Guru (249K reputation)SSC Guru (249K reputation)SSC Guru (249K reputation)SSC Guru (249K reputation)SSC Guru (249K reputation)

Group: Administrators
Points: 249275 Visits: 19809
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
My Blog: www.voiceofthedba.com
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (380K reputation)SSC Guru (380K reputation)SSC Guru (380K reputation)SSC Guru (380K reputation)SSC Guru (380K reputation)SSC Guru (380K reputation)SSC Guru (380K reputation)SSC Guru (380K reputation)

Group: General Forum Members
Points: 380315 Visits: 42968
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.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
sturner
sturner
SSCrazy Eights
SSCrazy Eights (9.4K reputation)SSCrazy Eights (9.4K reputation)SSCrazy Eights (9.4K reputation)SSCrazy Eights (9.4K reputation)SSCrazy Eights (9.4K reputation)SSCrazy Eights (9.4K reputation)SSCrazy Eights (9.4K reputation)SSCrazy Eights (9.4K reputation)

Group: General Forum Members
Points: 9436 Visits: 3259
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.
TravisDBA
TravisDBA
SSCarpal Tunnel
SSCarpal Tunnel (4.9K reputation)SSCarpal Tunnel (4.9K reputation)SSCarpal Tunnel (4.9K reputation)SSCarpal Tunnel (4.9K reputation)SSCarpal Tunnel (4.9K reputation)SSCarpal Tunnel (4.9K reputation)SSCarpal Tunnel (4.9K reputation)SSCarpal Tunnel (4.9K reputation)

Group: General Forum Members
Points: 4896 Visits: 3069
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." :-D

"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum







































































































































































SQLServerCentral


Search