[dba-SQLServer] Re: Security & encryption

John W. Colby jwcolby at colbyconsulting.com
Tue May 10 13:17:45 CDT 2005


For my own passwords I use the first letter of a phrase.  For example "My
new Chevy Ventura minivan is 1 seriously nice car" - MNCVMI1SNC.  Pick a
phrase with at least 8 words and preferably a number in there.  Phrases are
much easier to remember than a string of random characters, yet the first
letter of each word of a phrase turns into a string of random characters.

John W. Colby
www.ColbyConsulting.com 

Contribute your unused CPU cycles to a good cause:
http://folding.stanford.edu/

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur
Fuller
Sent: Tuesday, May 10, 2005 1:55 PM
To: dba-sqlserver at databaseadvisors.com
Cc: SQL Server 2k List
Subject: Re: [dba-SQLServer] Re: Security & encryption


I have been giving this subject some thought of late, since despite my 
cautions, I found passwords written and hidden beneath the keyboard, and 
even worse, sticky-notes attached to the side of the monitor!

My admittedly tentative plan is this:
1. Devise an algorithm which every user can follow without error. 2. Make
every element of said algorithm unique to the person in 
question, yet also deducible from known facts.

Let's take a simple example.
Take your mother's birthdate and write it down in yyyymmdd format. For each
"1", substitute "@".... i.e. "a" is the first letter of the 
alphabet but let's disguise it too.
For each "0", substitute "O".
Prefix all this with the initial of the given name of your kids (if 
any), in order of their birthdates.

For practice, write it down 10 times. That ought to be enough to 
memorize it, but even if not, there is no need to write down the 
password. Remember the rules and you can deduce your password anytime.

The proposed algorithm may be too simple or perhaps too complex. The 
salient points are that it should be deducible from knowledge unique to 
the person in question. It's quite possible for a would-be penetrator to 
know one or two of these facts, but I think it unlikely that he or she 
know them all. Thus even if he/she had the formula, it might take a 
while to determine the password.

Arthur

Francisco Tapia wrote:

>So data would only be as safe as the user's memory for their Pwd. So
>Technically the entire columns or rows could be encrypted within the sproc 
>and the user's choice of pwd but also w/o storing the pwd used. 
>
>Thinking more technically on this, the entire HR dept would need access 
>to
>these screens right? or a certain number of people in HR would need access,

>thus 2 or more people would possibly know the pwd, possibly writting it
down 
>in a memo pad and end up storing it under their keyboard... :|
>
>
>
>
>---------- Forwarded message ----------
>From: Gavin <gavin at cobraball.co.uk>
>Date: May 10, 2005 9:33 AM
>Subject: Re: Security & encryption
>To: SQL Server 2k List <sql2k at ls.sswug.org>
>
>You could make it so part of the encryption key was a value that only 
>the
>user knew and had to type in every time they used the application so even
if 
>you had the decryption code and the data in the database you'd never be
able 
>to make clear text again.
> However if they forgot their key and you had no admin user or key then 
>you'd never get your data back, in a truly secure system there's purposely 
>no way around this.
>  This system would allow you to write the front end application but still 
>not read the data it handled.
>      
>----- Original Message -----
>*From:* Francisco Tapia <fhtapia at gmail.com> 
>*To:* SQL Server 2k List <sql2k at ls.sswug.org> 
>*Cc:* roz.clarke at donnslaw.co.uk ; dba-sqlserver at databaseadvisors.com 
>*Sent:* Tuesday, May 10, 2005 5:25 PM
>*Subject:* Re: Security & encryption
>
>Oh, I hadn't thought of that. If it is encrypted at the Front end, as a 
>DBA
>you'd still be able to get to the data tho...
>
>
>On 5/10/05, Gavin <gavin at cobraball.co.uk> wrote:
>  
>
>>It could very easily be done if the encryption is handled purely in 
>>the
>>front end application.
>> While possible to encrypt a whole table you'd need to ask yourself how 
>>you'd join on its columns or write your where clauses and still benefit
from 
>>the client/server model.
>> You could even encrypt everything in your SQL Server database but the 
>>overhead in network traffic and client processing would be huge.
>>     
>> ----- Original Message -----
>>*From:* Francisco Tapia <fhtapia at gmail.com> 
>>*To:* SQL Server 2k List <sql2k at ls.sswug.org> 
>>*Cc:* roz.clarke at donnslaw.co.uk 
>>*Sent:* Tuesday, May 10, 2005 5:14 PM 
>>*Subject:* Fwd: Security & encryption
>>
>>I'm forwarding this message on to this list because I think the author 
>>of
>>the original post would receive a better response from this group... I am 
>>also curious how a dba could encrypt a whole table (or set of tables) and 
>>lock themselves out of it.. :|
>>
>>
>>---------- Forwarded message ----------
>>From: Roz Clarke <roz.clarke at donnslaw.co.uk>
>>Date: May 10, 2005 2:04 AM
>>Subject: Security & encryption 
>>To: 
>>Hi all
>>
>>This may or may not be slightly OT... We have been asked by our HR 
>>department whether it's possible for us to build a storage facility 
>>for confidential data (such as salary information), that is encrypted 
>>and that
>>
>>neither we nor the network administrators could get into once it's 
>>gone live. Ideally it would be integrated with their current 
>>application which is Access 2002 FE / SQL Server 7.0 BE.
>>
>>How do I build an encrypted database that I can then lock myself out 
>>of
>>completely?! Without locking everyone else out too (that I've done 
>>before).
>>
>>Management are willing to spend some money if necessary.
>>
>>TIA
>>
>>Roz
>>
>>
>>    
>>
>
>  
>


-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.8 - Release Date: 5/10/2005

_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com







More information about the dba-SQLServer mailing list