locked
Password Encryption, Storing and Hashing RRS feed

  • Question

  • User-1757034084 posted

    Hey Everyone!

    I'm currently working on a ASP.NET 4.0 web application and I decided to abandon the idea of using the Membership provider since my Account schema has seventeen tables, they vary greatly from the aspnet_membership schema, and that someone suggested I just create my own methods for managing groups, roles and accounts instead of extending the Membership provider -- something I've never even worked with before.

    I'm looking to store my passwords in a SQL Server table.  As I was reading about the membership provider I saw that ASP.NET is using SHA-1 for storing passwords in the table.  I want to use SHA-2 -- SHA256 at least, with a 16 character Salt.  I'll be storing the password hash in a varchar(64) field, and the salt in a varchar(16).

    Before I code anything, I was hoping someone could tell me if I'm right about these processes.

    User creates a new account...
    1) Create a Salt.  Each record in the database should have a unique salt stored.
    2) Append the salt to the password.
    3) Store the Salt and Password as separate fields in the record.

    User logs into the system...
    1) Email address (account name) is used to lookup the salt.
    2) The looked up salt is appended to the typed in password.
    3) Typed in password is hashed.
    4) Typed in password hash is compared to that which is stored in the database.
    5) If valid, grant access; else, display generic message saying, "The username and/or password is wrong," and increase the FailedAccountLoginAttemptCounter by one.

    User forget's their password...
    1) User is redirected to the password reset form.
    2) User is asked to enter their e-mail address and asked their secret question; if answered right, then the account is 'Locked'...
    3) System sends that e-mail address an e-mail with a reset password link.  (To ensure the link can only be used once, there will be a query-string value appended to the end -- LastLoginDate as a Hash, most likely.)
    4) The user clicks the link and is redirected to a page that will allow them reset their password.  If the query string hash matches the accounts LastLoginDate hash, then the form will load and allow the user to reset their password. 
    5) User types in a new password.  Follows the same password creation proceedure as creating a new account.
    6) After new password has been created, e-mail is sent to the user saying, "Your password has been successfully reset!  Please click this link to unlock your account."
    7) Once the link is clicked, the account will get unlocked and the user will be directed to the login page.

    I think this is the right, logical way to do this... but I'm hoping you guys could poke holes in the process and maybe tell me what I should do differently.  

    Thanks in advance.
     

    Monday, August 27, 2012 11:40 AM

Answers

  • User1191505944 posted

    @Rockstarter

    This is my thought,

    You can create a new DB for just authentication/ authorization and use the default tables

    In your code behind after authentication you may look up your DB for authorization Or

    You can override the authorization methods and look up your DB for custom authorization

    Actually you can mix up and play as you required

    Example in which they used code first instead of sql http://codefirstmembership.codeplex.com/

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, August 27, 2012 11:48 AM