I'm working on the security aspect of a project and need some suggestions. The project will be web based. I'm creating a 'SecurityUser' class similar to a Windows User. It's basically what I will use as a user logon account.
Here's my scenario: When I create a new SecurityUser class, I need to assign a password. A password is required. When the user saves the object for the first time, the password info (salt/hash) gets sent to the database with the other user info. However, the password info gets sent back and forth if I continue to modify and save the object. With that, the password info is getting saved in the session state.
Is this a security vulnerability? I usually do WinForms programming and not web-based stuff. Or am I overthinking the issue? At this point, I'm working on just a foundation for future apps that I create, but I want the best possible security model.
Thanks in advance,
Todd
Have you considered using the ASP.NET MembershipProvider?
Microsoft already did all this work for you, and it was done by people with deep understanding of security and associated ramifications, and it is designed to work for the web.
I guess I understated it a little bit: I'm writing the app for Web and WinForms. However, at this point, I don't have much understanding of the ASP.NET security side of things yet.
Also, I'm making the security very granular. I've already built the database stuff, along with SecurityUser and SecurityGroup to be allowed Access/Deny on Read/Write/Execute, etc on whatever objects that I create within my app. Objects can be added to Users, Users can be added to Groups, Groups can be added to Groups, etc. ....auditing password history, allowing custom password complexity rules...you name it. There's probably more--but you get the point.
I guess my question regards the best practice for transferring password info back and forth--and whether or not to hold that stuff in memory on the client side. If anything, the password info is always transferred at least once, when logging in. I just don't want to give a "man in the middle" access to the info unecessarily. I just don't want to play the odds.
In short, the password should not be retained on either client
or server, and the user credentials should be passed using an encrypted channel
like SSL.
Once the user’s identity has been established, you can
maintain the principal/identity objects, but they won’t contain anything
like the user’s password or even the hashed value – just the
username, roles, etc.
Rocky
Thanks Rocky.
That's what I kinda figured. I'll have to separate the password info from the SecurityUser class so that it's not hanging around.
Todd
Copyright (c) Marimer LLC