2

All,

I'm currently designing a user account system in ASP classic...don't judge, it's what I'm comfortable with ;). I have several of the components built already, including the UI, database table, CRUD database ASP pages and a generic mailer. I'm curious as to some of the best practices for implementing secure login systems for ASP. Searching the web yields a ton of "simple ASP security" solutions, which I've used before, but this is my first time time building a robust and truly secure solution. The final implementation will be used for a job application system, so it definitely needs to be secure due to the content.

So far, I have:

  • Password recovery/reset goes only to the e-mail account on file
  • Hash stored passwords in the database
  • Do not set an expiration on session cookies so they are only stored in memory (read this somewhere today)
  • Get a certificate for the server and use https

A couple general questions that I have...

  1. Submitting the password in a form passes it through the query string. Do I need to hash this somehow prior to submitting the form?

  2. On a related note... If I am using https, since it is already secure, can I do the hash on the ASP page that handles the write to the database? I'm using AJAX to parse the query string from the sending form and pass it to the ASP page which connects to the database and does the CRUD operations.

livetoski78
  • 73
  • 9

2 Answers2

2

Password recovery/reset goes only to the e-mail account on file

Make sure your send a reset link expires after a certain time or after it has been used whichever comes first

Hash stored passwords in the database

Use salts instead of plain hashes. Hashes of most common passwords are as simple to break as a google search.

Do not set an expiration on session cookies so they are only stored in memory (read this somewhere today)

This will make sure that the cookies are wiped out when the user closes the browser. In addition to this, also consider a timeout on the session cookie on the server side which will timeout the user session after x minutes of inactivity.

Get a certificate for the server and use https

At the minimum, the login credentials absolutely need to be passed over SSL. It will also help to have the entire website on https instead of just the login page. SSL is no longer computationally expensive anymore. Having the entire site over SSL prevents any sslstrip attacks. Make sure your server doesn't support SSLv3 to prevent the recent poodle attack.

Submitting the password in a form passes it through the query string. Do I need to hash this somehow prior to submitting the form?

  1. Please don't pass credentials over querystring. Login form should always be POSTed. It'll get cached in server logs (and any proxy logs) if tacked to the URL as a querystring.

  2. If you are posting the form over https (which you absolutely should), you do not need to hash before submitting the form. If you are not using https, there is no way to pass the credentials to server securely.

On a related note... If I am using https, since it is already secure, can I do the hash on the ASP page that handles the write to the database? I'm using AJAX to parse the query string from the sending form and pass it to the ASP page which connects to the database and does the CRUD operations.

Hashing should ALWAYS be done on the server side. If you hash the password on the client side and send it in plain text over http, a MITM might not be able to reverse the password from the hash, but he can always use the same hash to log on to the user's account. The hash essentially becomes the plain text password of the user in this case.

CodeExpress
  • 2,202
  • 1
  • 20
  • 16
  • 2
    I would only add a link to this SO post http://stackoverflow.com/questions/323200/is-an-https-query-string-secure just to elaborate on why not to pass passwords via querystring. – KHeaney Nov 20 '14 at 16:53
  • I'm particularly interested in the part about always posting login info (no AJAX). I had no idea, and I'm sure that will save me a lot of headaches! In regards to doing salts, what could you recommend as a good ASP function? I'm also sending the passwords back to an admin visible user table, so I guess as long as I'm in https, I'd be alright desalting on the server side before sending it back? I'm currently doing this with AJAX in the "unsecure" version that I have working. As it's just plain text in a div, I guess this is still alright? Sorry for all the questions! – livetoski78 Nov 20 '14 at 21:31
  • Hash is a one way process, so there is nothing like desalting. The way salted hashing works is that you take a password, add a random string (salt) to it and then hash it (look up SHA1 implementations for ASP). Note you'll be storing both the hash and the salt in the database. Next when you have to verify a password provided by the user, you do the same thing to users password, i.e. fetch the salt from the db, append it to the password user has provided and hash it. If the resultant hash matches to what you have in db, then the password is correct and you let the user in. – CodeExpress Nov 23 '14 at 15:45
  • Excellent, I got the salt/hashing working as suggested. The only exception I made, was that I'm using a single salt for the system and storing it as an ASP variable in the code (a global encryption key). As long as the server-side code is secure, I don't see this being a problem and it simplifies the process since the salt is always the same and I don't have to track it by user in the table. I'm currently writing the login portion and will do it via POST, as suggested. I also have a a user admin page where the user can change their password, and I need to re-write that to POST, as well. – livetoski78 Dec 03 '14 at 20:45
0

Always use HTTP POST with SSL for sure.

Protect your asp code against sql injections.

Storing a local cookie with an encrypted token to keep your users logged in after they close the session/browser - or use asp sessions for a single login that could expire in 20 minutes after last request or when closing the browser.

Protect your cookies for cookie/session hijacking. (http://en.wikipedia.org/wiki/Session_hijacking)

Also, you can use finger prints of your users by requesting/storing/validating the server variables like (a part of) the user agent.

Bas
  • 1