2

I am working on a project where users have accounts and log in using their username and password if they are correct the code returns a session id. Next time they open the app or visit the site it gets the stored session and sends it to the database and returns the user's data.

My problems are what if someone finds a way to enter fake session id's and then visit my site and if they keep trying they are bound to get a valid session.

In the app's user data and webpage cookies besides storing the session token should I also store something such as their user ID? Then when they visit the site I get both the session and user ID to check if they match making it way harder for someone to just type random sessions since they have to find a session and correct user id (which is 120 characters long).

Improve this question
5
  • This question is actually pretty broad in that there are many attacks that can be made against sessions (including the brute-force attack you described). Are you working with an application framework (ie. ASP.net, Rails, NodeJS and Express)? There is usually a common way to implement sessions that accounts for many of these concerns, but depends on your software stack.
    – nbering
    Commented Apr 14, 2018 at 20:20
  • @nbering The app uses C# in Xamarin.Forms which loads data through a webpage using PHP that works with a database in MySQL and PHPMyAdmin
    – Dan
    Commented Apr 14, 2018 at 20:42
  • The place where your data is stored is the part that needs to be protected most. Are you using an application framework in PHP, like Laravel, or CodeIgniter? It's a lot easier to handle all the security use-cases if you're not writing your own authentication and authorization code.
    – nbering
    Commented Apr 14, 2018 at 20:56
  • And in case you do want to program your own authentication and authorization mechanism, why not bind the user's IP to the session identifier? I know that this could still give security issues when users access your application using (corporate proxies) but still....
    – Jeroen
    Commented Apr 14, 2018 at 20:59
  • You don't mention what platform you're using, but most web app platforms already have session management. If you have such an option available, it's probably best to use it.
    – Neil Smithline
    Commented Apr 15, 2018 at 1:08

1 Answer 1

Reset to default
9

You are right that you need to make sure that your session ID's can not be brute forced. The trick is to make the session ID long and random (and when I say random, I mean securely random). If the session ID comes together with a user ID it would be harder to brute force, since the attacker would need to guess ID's for one user at a time. That means the session ID could be somewhat shorter. But since it doesn't cost you anything to have a long session ID, there is no need to try to shorten it.

If you use 64 bit session ID's and have a billion users, an attacker would have to make on average 264/109 * 1/2 ≈ 1010 guesses before she gets one right. Without causing any performance problems you could double it and use 128 bit session ID's, and you will have a ridiculous margin.

So, there is no harm in sending the user ID together with the session ID. But if you use long enough session ID's, there isn't really a need. If you do opt for the user ID solution, remember this:

  • Obviously, you need to actually check the user ID server side, and not blindly trust the client.
  • Assume the hacker knows all user ID's. That means that the session ID still needs to be long and random.
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .