p2p.wrox.com Forums

Need to download code?

View our list of code downloads.

  Return to Index  

aspdotnet_website_programming thread: Suggested improvement to the Accounts module

Message #1 by "Jacques PHILIP" <jphilip@n...> on Tue, 14 May 2002 00:46:08
I came up with some improvements to the accounts module, maybe somebody 
has some comments.

1) The Accounts module uses the primary key constrain to detect duplicate 
entry of email addresses during inserts, but the primary key is an 
autoincrement field so it never raises the exception that we are trying to 
trap, making it possible to enter duplicate email addresses.

2) Sometimes, we want the users to login with a user name instead of the 
email address, the model does not allow that.

3) The password is encrypted with a sha1 hash function, making it 
impossible to retrieve it, for example to email it to a user who lost it.

The solution I came up with:

1) Add a username field to the Users table, same size as the eamail field 
and modify accordingly the stored procedures and Accounts data module to 
do the login by user name.
This allows us implement a loggin by user name or email without having to 
re-compile the data or business modules.
All we have to do to login by email is to copy the email to the username 
field when we insert a user.

2) Add a unique constrain on that username field and change the number of 
the exception to trap to 2627.
This traps duplicate user name or entries (or email entries if we 
implement the email login) 

3) Make the password field a varbinary(50).
Encrypt the password with a RijndaelManaged algo.
For this, we hard code the initialization vertor in our source and we 
store a representation of the key in the Accounts configuration file.
The problem is that if we somehow loose that key, we cannot recover our 
passwords as we cannot remember a 128 or 256 bits binary key.
So we store a master password in our configuration file and we hash it 
into a 256 bits key with a sha256 hash function after preceeding it with 
hard coded random bits to avoid a dictionary attack and to split the key 
between the compiled code and the configuraion file.
We use that key for encryption or decryption of the passwords.
If we don't want to automatically recover the passwords to email them to 
cients, we don't store the master password in the configuration file and 
enter it upon demand when we want to  recover a password from the database.

  Return to Index