Home/ Questions/Q 586473
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T15:06:39+00:00

I have a website (the basic gist of which is described in this question

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0