search

delight-im / PHP-Auth

Authentication for PHP. Simple, lightweight and secure.
MIT License
1.11k stars 236 forks source link

Is having predictable user ID's a good idea? #271

Closed timbatt closed 2 years ago

timbatt commented 2 years ago

Hello! I love this library so far! But one thing has me thinking... is it wise to have predictable user ID's? If the "bad guys" find out that each user's ID is incremented by 1 from the last, it would give them more knowledge about the app than they need to know, and could potentially help with user enumeration. Would it make more sense to have each user's ID be a UUID or do you think it's not much of a problem? I would love your thoughts on this, thanks!

maietta commented 2 years ago

Hi @Jammin-Coder. Glad you are enjoying the library. If you are referring to the first field of the user table called "id", then no, there's nothing to worry about. Most relational databases like MySQL, etc have to have a unique index key field that is unique to guarantee the correct record is loaded for manipulation. That's mostly what this is for. If a "bad guy" can do anything with those ID's, then your database and/or application was already compromised.

nssnl commented 2 years ago

Fully agree with @maietta, should not be a security issue by itself.

However there might be other (non-security) reasons you may want to mask the ID’s of users, when you need to reveal these (depends on your app; in many cases won’t be relevant). In that case you may want to look at this library: PHP IDs, also from delight-im!

timbatt commented 2 years ago

Thanks for your responses, @maietta and @nssnl! I understand that would have to be other issues with your app for someone to take advantage of knowing DB info, but at the same time I was still kinda concerned 😅. Thanks again for replying!

ocram commented 2 years ago

Yes, internally, these predictable IDs are no problem at all.

Externally, in publicly accessible web services, with a UI or API, this is not a security issue, but you often still don’t want others to enumerate all entries – especially if that’s user records. But instead of hiding things by means of unpredictable IDs, you should implement rate limiting or throttling where you want to protect records from being enumerated. This library right here has a method for this which you can call.

Apart from that, as mentioned, you can use something like our ID obfuscation library to achieve what you wanted to do with UUIDs. Internally, you’d still have the predictable and useful integer IDs, but externally, people would only see your obfuscated IDs. This is a good idea, for example, if you want to prevent competitors from easily counting (or enumerating, in addition to rate limiting being applied) objects in your application. But you have to do this everywhere, by consistently only sending IDs to your (HTML, API, etc.) output after encoding them via one simple method call. When accepting IDs from user input, you have to decode them again. If you miss one place, others can count/enumerate there.

Anyway, all this is not about security measures but instead just about obfuscation (against competitors, etc.) – apart from rate limiting, which is a valid security measure to prevent enumerating, scraping, etc.