1

I want to use a users unique id to save a cookie - so that I know which user is logged in, and then I can change their content to suit.

I am currently just using the usual auto id when a new record is created, but I have heard that for creating user accounts (specifically when you're going to use that ID to change content) that you shouldn't have them 1 after another; e.g. not 378, 379,380 and so on but more like this 138462193, 109346286, 982638192 so it's kind of like a random unique identifier.

How would i achieve this?

Is this a best practice?

Strawberry
  • 33,750
  • 13
  • 40
  • 57
Eli
  • 668
  • 2
  • 13
  • 37
  • 3
    What difference should that make? All it could provide is a false sense of security. Obfuscation cannot offer raised security. If your application allows you to manipulate things using someone else's ID, then you have to fix that privacy gap. Not disguise it. – arkascha Oct 26 '16 at 08:37
  • Ok so use a UUID library – Mulan Oct 26 '16 at 08:38
  • See http://stackoverflow.com/questions/829284/guid-vs-int-identity – Brayn Oct 26 '16 at 08:38
  • Just from a perspective of if someone was going to try and attack it (of course i have the passwords encrypted, and then re encrypted when its stored in the cookie) that they wouldnt be able to cycle through users because there could be a gap of 1 to 100000 difference between their id numbers, if you dont think it will be a problem then thats cool! will make my life easier – Eli Oct 26 '16 at 08:40
  • The public user_id and the internal id don't have to be the same thing, so I'd use auto_increment for the internal PK, and (maybe) something like `MAX(public_id) + RAND()*10` for the public_id - but with appropriate transactional constraints to prevent race conditions - or UUID as others have mentioned. – Strawberry Oct 26 '16 at 08:41

1 Answers1

2

You protect your data against attacks by using ACL, to limit which user has access to to what (and with what data). Foreign key relations to establish ownership between user and data, session ID regeneration at login, CRSF tokens to prevent attacks via other sites, and so forth.
Not to mention logging, to be able to find out what went wrong when things do go wrong.

Only in very special cases do you ever need to worry about the ID of users being sequential. Most of the time this ID will be available to other users, via the web site itself, anyway. As a part of normal operations.
Thus adding a random element to the user ID won't bring anything but a false sense of security. Even if you keep the internal ID different from the "external" user-facing ID, as long as you're using the external ID to identify and change content it's basically the same as the internal ID. Only valid reason for using a dual ID system, in most cases, is for human readability. If you're uncertain about whether your use case is one of the exceptions, it's not.

PS: I see in your comment that you say that the passwords are encrypted. Hopefully you mean "salted and hashed", more specifically by using password_hash () and it's associated functions.

ChristianF
  • 2,068
  • 9
  • 14
  • Okay thanks! Yes they are salted and hashed, passwords on the server using a seperate one to the salted and hashed cookie version. – Eli Oct 26 '16 at 08:47
  • Why are you storing (hashed) passwords in a cookie? They should never leave the server, and I cannot think about one reasonable case where this would be necessary. It's a huge security risk! You're welcome, btw. Glad I could help. :) – ChristianF Oct 26 '16 at 08:48
  • I store it in a cookie so every time the page loads it checks if the user is logged in by decrypting the stored cookie password and uid then running a query to the database to see if the stored cookie uid and password matches the one in the server (thus eliminating people being able to change the cookie data, because if they do the encryptions wont match and the user will be logged out and all cookie information will be deleted) – Eli Oct 26 '16 at 08:52
  • essentially the stored password in the cookie is salted and hashed when its created and stored in the database, and then re-slated and hashed when its in the cookie. So they would have to break 2 very longs salted and hashed passwords which would take a bloody long time as i understand! and thanks for the help :) – Eli Oct 26 '16 at 08:54
  • That's overly complicated, and does nothing to help increase the security of your application. In fact, since you're sending out a hashed password you're effectively decreasing the security level a bit. All you need is a session ID in the cookie, and then save the logged-in state in the session itself. Alternatively, you could do some verification check on using data you've stored in the session or additional cookie. Using some sort of token value, but using passwords for this is a big no. Remember: Keep things simple. That way it'll be a lot easier for you, and others, to keep your code safe. – ChristianF Oct 26 '16 at 09:01
  • Overly complex and "clever" solutions only serve to obfuscate security issues, which might otherwise have been easy to detect. Also, crackers are much smarter than your and I combined, and more plentiful; They _will_ find any security issues, only a question of when. – ChristianF Oct 26 '16 at 09:03
  • Okay ill taken another look at things, its the first time iv ever had to have something go to production so i'm new to the security side of things and that method was just from different methods all mixed togeather. Thanks a lot! – Eli Oct 26 '16 at 09:08
  • You're welcome, and good luck! Please remember to upvote and accept answers. :) – ChristianF Oct 26 '16 at 09:10