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.

ELA
  • 13
  • 3
  • 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. – pcalkins May 27 '20 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 May 27 '20 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 May 27 '20 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 May 27 '20 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 May 27 '20 at 22:45
  • The server keeps a record of established sessions and associated information, whatever that is. All the client needs to know to maintain its session is to keep sending the same cookie and the server will know "who" it is responding to. – Pedro May 27 '20 at 22:46
  • I am not sure what you mean by "id=1". Session identifiers are not decoded, they do not contain information themselves, they're just identifiers matched on the server side to a type of database. – Pedro May 27 '20 at 22:47
  • There's different approaches to this... but I think the basic idea is not to use a SessionID to authenticate a user. You are only authenticating the session. The user should have a name/password combination to authenticate. Also, since these ids can be stolen, you should consider re-authenticating when doing tasks like changing e-mail/password/etc... any cross-site theft can still view/impersonate for the time of the session, but they can't take over control of the account. – pcalkins May 27 '20 at 22:51
  • @Pedro Ok, it is much more clear now. So using UUIDs in this scenario will only affect performance on large scale database and not prevent enumeration attacks, because session identifiers are not generated based on the identifiers. Thank you – ELA May 27 '20 at 23:06
  • UUIDs are not good session identifiers, end of. There is no reason why you wouldn't use a plain long random string. I'll try to scribble an answer for you after this conversation. – Pedro May 27 '20 at 23:07
  • @pcalkins Please can you explain or provide a link to these different approaches ? And yes I am authenticating users with username and password. But once they are logged in I just check the session ID, and before any major change they made to their account they are prompted to reenter their password. – ELA May 27 '20 at 23:11
  • Oauth seems very popular these days and if you use a 3rd party for authorization you leave security of user logins in their hands (which tends to be a large company with resources to do that bit properly): https://oauth.net/2/ It also separates the authorization and web site databases/servers. If you don't need a lot of security you can just store the username and password hash as a cookie to have "remember me" functionality. Then start a session after authorizing the user using those values. (And require the user to re-login manually if changing info...) – pcalkins May 28 '20 at 17:56
  • @pcalkins Yes I plan to read more about Oauth and use It in the future as It is the work of a large trusted company. But for now I think It is good practice to implement security and learn the basics before using third parties and relying on their security. – ELA May 29 '20 at 16:05
  • I think the bottom line is that the session can always be stolen... so it's important to alert the user when a new device accesses their account. If the user says it's not them you can implement certain protections such as honey-potting the attacker, having the user change their password, etc... tokens do add some protection for authenticating the posted values are coming from your own site, but they don't guarantee it... someone could still play man-in-the-middle from a phishing site. (read the tokens and use them in their own fake forms...) – pcalkins May 30 '20 at 19:08

1 Answers1

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.

Pedro
  • 3,911
  • 11
  • 25
  • 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`](https://docs.microsoft.com/en-us/windows/win32/api/rpcdce/nf-rpcdce-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. – IllusiveBrian May 28 '20 at 00: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 https://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 May 29 '20 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. – IllusiveBrian May 29 '20 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 May 29 '20 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 May 29 '20 at 16:59