>>>I am working on an application where there are users and roles. The functionality allowed to a user will be determined by their role.
>>>What's the best way to store user info, ie, UserName, Password? I will want it encrypted, but should all the user data be encrypted in the user table, or just the UserName & password?
>>>
>>>Second, assume I have a calendar module and a documents module (for document management). Some users will not have access to each module. What's the best way to set all this up in the data?
>>>
>>>Thanks
>>
>>
>>Only a partial answer
>>
>>Do not store encrypted passwords in a table - they can be decrypted - and sometimes there is an indication of the length of the password
>
>I don't know about that. I'm doing the encryption in my C# app using RijndaelSimple. The key is stored in the app. Unless the hacker knows the key, how would they be able to decrypt it?


I would not store the key in the app. You can 'make' one depending on the (entered) passwd - eg hash it

>>Instead hash a transformation of the password
>>A transformation, eg
>>- reverse the sequence
>>- append/prepend some chars of the password so that the length > = 32
>
>The only way this could work is if my app knew the characters that were being added, correct? Otherwise, how do you know where the user's password begins and the appended characters start?

Well, the user has to re-enter his passwd to logon or so. So you can do the same with the passwd just entered (as done when the user changed the passwd)

Then to find out whether ther uses has entered the correct passwd, compare the hashed value of the entered passwd with the hashed value stored in the table for that userId

Initial change passwd

userId: greg
passwd: Gregory

do the trick on 'Gregory' and store the hash in the table

Then I log on

userId: greg
passwd : Gregory

If you do the same sequence of things to calculate the hash, then that hash has to match the hash in the table for userid greg




>
>>- encrypt with aes128 or aes 256 CBC with an IV, Key that is derived from the password
>>
>>
>>hash: eg md5 or sha256
>>
>>That way (1) Never an indication of the length of the password (2) cannot be decrypted, (3) hash is always the same length and does not depend on the length of the password
>
>So, assuming all the above, what I was considering was returning all user records, then in the app decrypt each username & password until I find a match - the user is then logged in.
>
>Any issues here?
>
>Also, wouldn't is be prudent to encrypt all the user, roles, and rights data?