1

I read that uuid does not bring any security advantages

But I can't find why It doesn't bring a little bit of extra security in the scenario below ?:

Consider that right now the session id is encrypting the auto-increment id (no uuid is used). If someone manages to know how the session is encrypted, then he can impersonate all the users: encrypt "1" and set the value as sessionID, encrypts "2" and set the value as sessionID, etc.

Also consider that ids are not exposed.

Now if we were using uuid in place of auto-increment id, it is harder for the attacker to attack all the users as he can hardly guess the IDs present in the table, unlike with auto-increment id where he knows that ids are sequential. So It would prevent enumeration attacks.

14
  • The session should be tied to the user server-side, not client side. If you allowed the client to change the user associated with a session, you'd have trouble no matter what method you use. Commented May 27, 2020 at 22:01
  • session identifiers work if they're random, they can't be calculated or derived, only guessed. so using randomly generated uuids instead of randomly generated strings brings no advantage of disadvantage considering they're of the same length (dashes ignored).
    – Pedro
    Commented May 27, 2020 at 22:19
  • @pcalkins I am authenticating users by their session ID. So a user can only change or view content if his session ID matches any id in the users table. Is there any other approach ? Thank you
    – ELA
    Commented May 27, 2020 at 22:37
  • @Pedro That is what is confusing and worrying me. Ex: If id=1 then the server response will send a set-cookie: PHPSESSIONID="_randomString". when the user make a request again sending that cookie. How does the server know that this"_randomString" was originally 1 if PHPSESSIONID is totally random and not the value 1 encrypted using some algorithm ? I am using PHP. Thank you
    – ELA
    Commented May 27, 2020 at 22:39
  • OK, let me try to explain. 1. client connects for the first time - there is no session id involved. 2. server generates a random session identifier, sends to client and keeps a copy associated with some data pertaining the session (inc for example user name after authentication, etc). 3. every time the client presents that session identifier, the server can reference its data and maintain state between requests;
    – Pedro
    Commented May 27, 2020 at 22:45

1 Answer 1

1

I read that uuid does not bring any security advantages

This entirely relative to a given context. So it's neither true or false.

Consider that right now the session id is encrypting the auto-increment id (no uuid is used). If someone manages to know how the session is encrypted, then he can impersonate all the users: encrypt "1" and set the value as sessionID, encrypts "2" and set the value as sessionID, etc.

Session identifiers work if they're long random pieces of information. They do not encode or encrypt any information, these tokens are used by the server to locate information pertaining the established session.

In a typical scenario, client A connects to server B for the first time. They have no information or session id at this point. Server generates a new session id and sends it to client. Potentially authentication occurs and some data is stored on the server pertaining that particular session. Every subsequent request from the client carries this identifier so that the server can match the data relevant to that particular client during this particular session. Notice the data is stored on the server, all the client does is issue requests of whatever kind and tack on the session identifier as a way to maintain state in a stateless system.

Simultaneously other clients are doing the same. The server can maintain multiple states since every client uses their own unique session identifier. If the sessions weren't random or easily guessable, then an attacker could calculate or guess them and hijack established sessions.

So a randomly generated UUID is no better or worse than a randomly generated session identifier for the same length of random data.

5
  • 1
    This answer is correct in theory but in practice you need to be very sure you've generated a UUID using a method that employs random numbers. I checked the documentation for C#'s NewGuid method, which calls UUIDCreate. The documentation on that page does not specify that the function generates a random UUID. I'm not an expert on this and it could be that it does generate a random one, but if you just securely generated random numbers yourself it wouldn't be an issue. Commented May 28, 2020 at 0:03
  • @IllusiveBrian I am using PHP, do you know If I can execute that NewGuid C# method in bash and get the output, or If there are some other method to get that UUID in my PHP code? I found this PHP library github.com/ramsey/uui but It is giving me an error (PHP Fatal error: Uncaught Error: Class 'Ramsey\Uuid\Uuid' not found) and I can't seem to solve so I will try to get the UUID from your C# method. But for security reasons I won't rely on UUIDs any more, I may end up using them if I want to expose them and not reveal the number of customers in the database.
    – ELA
    Commented May 29, 2020 at 15:42
  • @ela I wasn't recommending that class, it's just the one .NET has as a standard so I was giving it as an example of why using a UUID generator makes it diffucult to know the entropy guarantee of the output. Commented May 29, 2020 at 16:01
  • @illusivebrain yes I assumed uuids were generated randomly with as much entropy as a similar length string. I don't know the specifics of whether this is possible, but I used it nonetheless for the sake of comparison.
    – Pedro
    Commented May 29, 2020 at 16:58
  • @ELA you don't want to have PHP run bash code to pull up a random uuid, that will do you more harm than good.
    – Pedro
    Commented May 29, 2020 at 16:59

You must log in to answer this question.

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