tags:

views:

128

answers:

2

Hi all,

I have a website (the basic gist of which is described in this question), and I want to have some way to store the username and some information about the user consistently while they use the site (ie, upload and download data).

Right now, given a successful login, I was returning the hash of the password as well as any associated information. Anytime a user tries something, their username, hash, and so forth must match what's in the database. If the user logs out, their local Sinatra session has all information flushed.

I realize that this is a very naive approach. Is there a better way to handle user session information? The wikipedia entry on cookies mentions that a session uid is used instead of this other information; what is the advantage of that approach? I suspect that this approach is also vulnerable to other attacks, but since I verify everything that's done as it's done, I'm not sure what attacks I'm leaving myself open to.

Also, if/when I implement ssl, will these transactions be 'automagically' encrypted, or will I need to do something else to make sure that the strings are protected, if they need to be?

+4  A: 

This is actually a very complicated issue. Just to illustrate, you have the problem of account lock-out: If you lock out based on failed attempts, how easy is it for an attacker to DOS your website?

I'll list a few best-practices to get you started:

  1. Store Passwords Salted and Hashed alongside the Username and UserId. (You should also store the salt next to the hash.)

  2. Disallow frequent bad-password attempts. (More frequent than once every few seconds).

  3. If attempts are failing for any given user or any given IP address (more than 3 times a minute) require some form of human-validation, like a CAPTCHA. This allows you to prevent total DOS attacks.

  4. If implementing an auto-login system, use a token authentication system.

  5. For token authentication systems, use a Secure random number generator, send the plain token to the users, but Salt and Hash the token at the database.

  6. Use TLS/SSL if possible, but don't rely on their security once the data is off-the-wire.

John Gietzen
What's a good starting salt value? For instance, should I have my database generate a random number from current system time, salt the password hash, and then return that as the session hash? Next time user logs in, the salt is different, so the hash is different, but it's persistent for that particular login?
mmr
Use a secure random number generator, like the `RNGCryptoServiceProvider` in .NET. You can safely store the salt in the database, alnong side the known-hash.
John Gietzen
A: 

If your website is built in asp.net then you can use dot net securities.. which is really very good. and you can also use principle classes in it to make it more secure..

Rajesh Rolen- DotNet Developer
I'm using Sinatra and ruby, but that's a good tip for other asp.net developers. Thanks though.
mmr