I have a quick question. I'm building a web portal that uses the .Net membership provider and was wonering if there is a way to encrypt the email address, and possibly the username columns. I know that the password column is already encrypted but thought
why not the others that are equally as sensitive.
I read that a major site was hacked into and the database compromised and thought that if the username andor email columns are all encrypted then this would not be a problem.
There's nothing built-in, but you could use a custom membership provider that encrypted the data on the way in to the database and decrypted it on the way out. While it sounds like a hard task, it's pretty easy. For a start, there's a video (http://www.asp.net/web-forms/videos/how-do-i/how-do-i-create-a-custom-membership-provider),
plus if you search for "Custom ASP.NET Membership Provider" you'll find a ton of resources. Also, the source code for the existing providers is available from Microsoft at download.microsoft.com/download/a/b/3/ab3c284b-dc9a-473d-b7e3-33bacfcc8e98/ProviderToolkitSamples.msi,
so you can just download the code and modify the appropriate bits of it.
Oh really, I was afraid of that. I have a web application with about 30,000 exisiting members already and was hoping I wouldnt have to write a custom membership provider, then migrate all the members, etc, etc.
Naturally, the #1 fear that most web stake holders have is the security of their information; but assumed that this could simply be taken care of either by encrypting one's database as a whole or the specific tables that holds sensitive info.
But even as I research this now, it appears that Microsoft now offers that? No?
Here's an except from the MSDN Library:
Summary: With the introduction of transparent data encryption (TDE) in SQL Server 2008, users now have the choice between cell-level encryption as in SQL Server 2005, full database-level encryption by using TDE, or the file-level encryption
options provided by Windows. TDE is the optimal choice for bulk encryption to meet regulatory compliance or corporate data security standards. TDE works at the file level, which is similar to two Windows® features:
the Encrypting File System (EFS) and BitLocker™ Drive Encryption, the new volume-level encryption introduced in Windows Vista®, both of which also encrypt data on the hard drive. TDE does not replace cell-level encryption,
EFS, or BitLocker. This white paper compares TDE with these other encryption methods for application developers and database administrators. While this is not a technical, in-depth review of TDE, technical implementations are explored and a familiarity with
concepts such as virtual log files and the buffer pool are assumed. The user is assumed to be familiar with cell-level encryption and cryptography in general. Implementing database encryption is covered, but not the rationale for encrypting a database.
Introduction: Encrypting at the Database Level
Transparent data encryption (TDE) is a new encryption feature introduced in Microsoft® SQL Server™ 2008. It is designed to provide protection for the entire
database at rest without affecting existing applications. Implementing encryption in a database traditionally involves complicated application changes such as modifying table schemas, removing functionality, and significant performance degradations. For example,
to use encryption in Microsoft SQL Server 2005, the column data type must be changed to
varbinary; ranged and equality searches are not allowed; and the application must call built-ins (or stored procedures or views that automatically use these built-ins) to handle encryption and decryption, all of which slow query performance.
These issues are not unique to SQL Server; other database management systems face similar limitations. Custom schemes are often used to resolve equality searches and ranged searches often cannot be used at all. Even basic database elements such as creating
an index or using foreign keys often do not work with cell-level or column-level encryption schemes because the use of these features inherently leak information. TDE solves these problems by simply encrypting everything. Thus, all data types, keys, indexes,
and so on can be used to their full potential without sacrificing security or leaking information on the disk. While cell-level encryption cannot offer these benefits, two Windows® features, Encrypting File System
(EFS) and BitLocker™ Drive Encryption, are often used for the same reasons as TDE—they provide protection on a similar scale and are transparent to the user.
I'm not really an expert in SQL Server itself, especially at that sort of level. For detailed answers on that your best bet is to hit one of the SQL specific forums.
Essentially I was just thinking at the provider level at what it does, which is offer basic membership facilities. The premis is that if you want anything beyond that you can implement it yourself as the model is extensible.
jaghadiuno
Member
19 Points
43 Posts
Encryption question
Feb 01, 2012 07:12 PM|LINK
Hello all,
I have a quick question. I'm building a web portal that uses the .Net membership provider and was wonering if there is a way to encrypt the email address, and possibly the username columns. I know that the password column is already encrypted but thought why not the others that are equally as sensitive.
I read that a major site was hacked into and the database compromised and thought that if the username andor email columns are all encrypted then this would not be a problem.
Any ideas anyone. Thanks!
Dave Sussman
All-Star
37716 Points
5005 Posts
ASPInsiders
MVP
Re: Encryption question
Feb 02, 2012 07:29 AM|LINK
There's nothing built-in, but you could use a custom membership provider that encrypted the data on the way in to the database and decrypted it on the way out. While it sounds like a hard task, it's pretty easy. For a start, there's a video (http://www.asp.net/web-forms/videos/how-do-i/how-do-i-create-a-custom-membership-provider), plus if you search for "Custom ASP.NET Membership Provider" you'll find a ton of resources. Also, the source code for the existing providers is available from Microsoft at download.microsoft.com/download/a/b/3/ab3c284b-dc9a-473d-b7e3-33bacfcc8e98/ProviderToolkitSamples.msi, so you can just download the code and modify the appropriate bits of it.
jaghadiuno
Member
19 Points
43 Posts
Re: Encryption question
Mar 13, 2012 08:41 PM|LINK
Oh really, I was afraid of that. I have a web application with about 30,000 exisiting members already and was hoping I wouldnt have to write a custom membership provider, then migrate all the members, etc, etc.
Naturally, the #1 fear that most web stake holders have is the security of their information; but assumed that this could simply be taken care of either by encrypting one's database as a whole or the specific tables that holds sensitive info.
But even as I research this now, it appears that Microsoft now offers that? No?
Here's an except from the MSDN Library:
Summary: With the introduction of transparent data encryption (TDE) in SQL Server 2008, users now have the choice between cell-level encryption as in SQL Server 2005, full database-level encryption by using TDE, or the file-level encryption options provided by Windows. TDE is the optimal choice for bulk encryption to meet regulatory compliance or corporate data security standards. TDE works at the file level, which is similar to two Windows® features: the Encrypting File System (EFS) and BitLocker™ Drive Encryption, the new volume-level encryption introduced in Windows Vista®, both of which also encrypt data on the hard drive. TDE does not replace cell-level encryption, EFS, or BitLocker. This white paper compares TDE with these other encryption methods for application developers and database administrators. While this is not a technical, in-depth review of TDE, technical implementations are explored and a familiarity with concepts such as virtual log files and the buffer pool are assumed. The user is assumed to be familiar with cell-level encryption and cryptography in general. Implementing database encryption is covered, but not the rationale for encrypting a database.
Introduction: Encrypting at the Database Level
Transparent data encryption (TDE) is a new encryption feature introduced in Microsoft® SQL Server™ 2008. It is designed to provide protection for the entire database at rest without affecting existing applications. Implementing encryption in a database traditionally involves complicated application changes such as modifying table schemas, removing functionality, and significant performance degradations. For example, to use encryption in Microsoft SQL Server 2005, the column data type must be changed to varbinary; ranged and equality searches are not allowed; and the application must call built-ins (or stored procedures or views that automatically use these built-ins) to handle encryption and decryption, all of which slow query performance. These issues are not unique to SQL Server; other database management systems face similar limitations. Custom schemes are often used to resolve equality searches and ranged searches often cannot be used at all. Even basic database elements such as creating an index or using foreign keys often do not work with cell-level or column-level encryption schemes because the use of these features inherently leak information. TDE solves these problems by simply encrypting everything. Thus, all data types, keys, indexes, and so on can be used to their full potential without sacrificing security or leaking information on the disk. While cell-level encryption cannot offer these benefits, two Windows® features, Encrypting File System (EFS) and BitLocker™ Drive Encryption, are often used for the same reasons as TDE—they provide protection on a similar scale and are transparent to the user.
etc, etc
Dave Sussman
All-Star
37716 Points
5005 Posts
ASPInsiders
MVP
Re: Encryption question
Mar 13, 2012 10:10 PM|LINK
I'm not really an expert in SQL Server itself, especially at that sort of level. For detailed answers on that your best bet is to hit one of the SQL specific forums.
Essentially I was just thinking at the provider level at what it does, which is offer basic membership facilities. The premis is that if you want anything beyond that you can implement it yourself as the model is extensible.