[AccessD] SQL Server Encrypted field

Martin Reid mwp.reid at qub.ac.uk
Fri Jun 8 06:58:32 CDT 2012


John

Just reading this on the web

The business logic which I used is that, when a user is added through my web application, on form submit event, I first get the user's information from the form fields, encrypt the employee's password and then submit the entire information into the user registration table. The password information is encrypted in the user registration table. Now, when the user enter into the application, provides userid and password, I just encrypt the user provided password and match it with the employee table's password, so I don't need to decrypt the database stored password again and again.




-----Original Message-----
From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman
Sent: 08 June 2012 12:50
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] SQL Server Encrypted field


 I don't understand why you wouldn't want to do an entire column and just be done with it.

 Encrypting on a record by record basis for one column as needed seems more trouble then it's worth.

Jim. 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Friday, June 08, 2012 12:54 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] SQL Server Encrypted field

I just want to discuss ideas of how to do this at all.  The built-in SQL Server methods appear to be aimed at entire tables or columns.  Obviously for what I want to do I need to encrypt each field of a specific column.  Fairly different.

John W. Colby
Colby Consulting

Reality is what refuses to go away
when you do not believe in it

On 6/7/2012 9:54 AM, Charlotte Foust wrote:
> So do you want to discuss how to do this using the built in SQL Server 
> features or through encryption/decription at the UI level?
>
> Charlotte Foust
> On Wed, Jun 6, 2012 at 10:08 AM,
jwcolby<jwcolby at colbyconsulting.com>wrote:
>
>> I need to store sensitive data in specific fields of specific tables.  
>> I find things like:
>>
>>
http://msdn.microsoft.com/en-**us/library/ms179331.aspx<http://msdn.microsof
t.com/en-us/library/ms179331.aspx>
>>
>>
>>
>> Which discusses creating a certificate etc.  Hmm... what happens if 
>> the database is backed up?  What happens if I need to move the database?
>>
>> And of course my favorite SQL guy (Pinal Dave):
>>
>> http://blog.sqlauthority.com/**2009/04/28/sql-server-**
>> introduction-to-sql-server-**encryption-and-symmetric-key-**
>>
encryption-tutorial-with-**script/<http://blog.sqlauthority.com/2009/04/28/s
ql-server-introduction-to-sql-server-encryption-and-symmetric-key-encryption
-tutorial-with-script/>
>>
>>
>>
>> In the end however what I want do (in this case) is to allow specific 
>> information to be encrypted / decrypted on a user specific basis, i.e.
>> based on something user specific.
>>
>> Assume that users need to store their own Email Address, username and 
>> password in my database and then use that to send email "on their behalf"
>> from my system.  The database is used for generating Community 
>> Volunteer passes, and when the pass is created it is printed to PDF, 
>> attached to an email and mailed to one or more email address at a 
>> specific prison.  I
have
>> created a new GMail account with a username and password but it would 
>> be nice to allow each user to enter their own email address / 
>> username / password to send from so that if there are issues and the 
>> prison replies
to
>> the email, it gets back to them directly.  Using my current system it
would
>> come back to my general address.  Of course I can do a "do not 
>> respond to this email" kind of thing but I have already been asked if 
>> they can get responses.
>>
>> Obviously if I am going to store a user's email address, username and 
>> password it has to be encrypted, but furthermore it has to be 
>> retrievable only by that user.
>>
>> --
>> John W. Colby
>> Colby Consulting
>>
>> Reality is what refuses to go away
>> when you do not believe in it
>>
>> --
>> AccessD mailing list
>> AccessD at databaseadvisors.com
>>
http://databaseadvisors.com/**mailman/listinfo/accessd<http://databaseadviso
rs.com/mailman/listinfo/accessd>
>>
>>
>> Website:
http://www.databaseadvisors.**com<http://www.databaseadvisors.com>
>>
>>
>>

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



More information about the AccessD mailing list