|
No. Yes, a suitably random and therefore 'unguessable' secret is, fundamentally, the underpinning for auth systems, and some of those secrets utilize UUIDs. No to the idea that these are comparable. Those are not -user identifiers-. A user identifier, vs a 'secret', require different perspectives in how they're treated, in API, in UI, etc. For -any- sort of security model you figure out what bits of data must be kept secret, vs what bits of data should be treated as 'known'. A user identifier should always falls into the latter camp, a password or other credential falls into the former. You said it yourself, "usually have a mechanism to regenerate them if you know they are compromised" - you really, REALLY don't want to have to regenerate your user identifiers if they leak out; that's almost invariably going to involve a great deal of complexity, breakages, regressions, etc. You're effectively changing the primary key of every entry in every database you have that this user exists in. Better to just not make them required to be kept secret for your security model. And even -that- assumes that they were -meant- to be secret; no developer is going to assume that about user identifiers, so you better have made that explicit to everyone who ever touched the code, or you just introduced a bunch of avoidable security holes. |