I work on encrypting movies for distribution, so there's a spectrum of attacks we try to consider.

1. Beginner opening Firebug / Devtools - use UUIDs for all the things, don't make anything guessable. Scrypt/bcrypt passwords on a separate Oauth system for all passwords / logins, manage all sessions with access tokens that are checked on each operation, allow immediate revocation of all open sessions.

2. Novice / Amateur attacks on the API or backend - make sure as much security as possible is in global middleware on the application, on by default, opt-out explicit. Long random access tokens, use either DB checks or constant time comparison to verify, do rounds of self and third party testing to make sure there's no cross privileges or escalation.

3. Protect against ourselves going rogue / being compromised - all keys in a HSM, the HSM also has the list of certificate chains it will trust, only modifiable by N of M keycards held by top execs, assume compromise at every stage and design the systems to mitigate impact. Ideally design so catastrophic attacks are impossible without collusion among top level company execs, and all other attacks, even when successful are downgraded to inconveniences, preferably minor.

> 1. Beginner opening Firebug / Devtools - use UUIDs for all the things, don't make anything guessable.

Is that actually necessary/useful?

> Scrypt/bcrypt passwords on a separate Oauth system for all passwords / logins, manage all sessions with access tokens that are checked on each operation, allow immediate revocation of all open sessions.

why Oauth instead of just a regular user table, login POST form, and the rest as you describe?

Not disagreeing, btw. just curious.

In this case oAuth is more because we have multiple products, might have done without it for just one, but it somehow seems to make more sense to have a separate system with isolated human data anyway, what with GDPR and all. The actual application has only the user UUIDs, can null or pseudoanonymise the references as necessary. This is B2B so slightly different rules apply for auditing etc.

And yeah, obscurity is not security but is useful in itself. Smaller attack vector (can’t leak info by iteration) less competitive info leakage (you’ll never figure out how many customers we have unless we tell you). Also has advantages with regards to database replication, backup restore and sequence management, but that’s another topic.

Not my post but my answers would be:

> Is that actually necessary/useful?

Yes, removes guessing, incremental attacks and off by 1 errors/attacks. Obfuscation is bad encryption but good policy.

> why Oauth instead of just a regular user table, login POST form, and the rest as you describe?

Sessions are fixed and can last an indefinite amount of time as an example.

But [token based system X for client/server or some kerberos variant for semi-trusted or m2m] will fill this void as well.

They should have paid for code audits, penetration testing, and the whole nine yards before putting anything in a customer's hand. The whole point of this company is based around a physical security device with online controls, to not do any of that is a downright folly in my opinion.