5 ms·

> Web programmer? Don’t make account IDs easy to guess. In an otherwise secure system, account numbers that go 1,2,3… shouldn’t be a problem, but why make it ea

> Web programmer? Don’t make account IDs easy to guess. In an otherwise secure system, account numbers that go 1,2,3… shouldn’t be a problem, but why make it easy? Is that the best advice to web programmers they can give based on this story? That's the "obscurity" part in the security by obscurity scheme. If you've got your security otherwise nailed down fine, some obscurity on the top doesn't hurt: security-in-depth, people seem to call that. But use only the obscurity, and only one person has to find out how your scheme works, and it's game over. I'd, you know, recommend to think about authentication. Your authentication state is not "logged in", it's "logged in as user X". So the code that decides whether a client can see a specific page can and should (!) depend on what specifically you're authenticated as. Oh, and yes, this company has proved that they don't know the least thing about security. But that was clear already.

filleokus 8y ago
Of course your authentication scheme should be secure even if someone knows how the user IDs are generated. With that said it might be a good idea to exposing something like GUIDs to the user anyways, for example if you are worried about a competitor getting an exact count of registered users / products / orders (which the competitor would get by themselves doing the action and observing the created ID). https://tomharrisonjr.com/uuid-or-guid-as-primary-keys-be-careful-7b2aa3dcb439 https://tomharrisonjr.com/uuid-or-guid-as-primary-keys-be-ca...
mcintyre1994 8y ago
> Tapplock user? Get and install any and all patches provided. Apparently, the company has now addressed the most obvious web portal holes (guessable account IDs and no HTTPS), but we assume an app update will be needed as well. It sounds like they still have this flaw, you just have to guess someone else's account ID now.
- dmurray 8y ago
  The recommendation is a lot kinder than the reasonable one of "throw the lock in the garbage and never buy anything from this company again".
friendzis 8y ago
> Your authentication state is not "logged in", it's "logged in as user X". So the code that decides whether a client can see a specific page can and should (!) depend on what specifically you're authenticated as. "the code that decides whether a client can see a specific page" should not care about authentication, this is authorization issue. I see these things conflated too often. Identification, Authentication and Authorization are three different beasts. Separate identification seems unnecessary complication, which it is in simple web app, but in a more complicated case where ID is not user supplied (login over external service, read ID from smart card, etc.) it can become a necessity, which can be embedded into authentication mechanism. Authentication mechanism should only provide "authenticated" and similar (e.g. "authentication security level") flags, because authentication at its root is a mechanism to establish trust that client has control of certain ID, nothing more.
- phito 8y ago
  Sometimes I wonder how technology can work, when so many people working in the field are unable to grasp the basic concepts of it
  - chii 8y ago
    Either the competent pulls way more than their weight, or luck.
    - yjftsjthsd-h 8y ago
      Also the really bad stuff sometimes dies under its own weight. Natural selection occasionally works.
- Double_a_92 8y ago
  Have you looked at recent at auth tutorials for NodeJS and related frameworks? You (a potential beginner) have to basically implement everything yourself or use some 3rd party service. There just aren't any good libraries available. I once tried some random framework I found where the example auth project that they provided had exactly the problem you described. You could log in and then do everything if you called the api endpoints manually... Deleting and editing other users profiles? No problem.
JeremyBanks 8y ago
“Security by obscurity” has become so misused... it doesn’t apply to this situation at all. There’s nothing illegitimate about having a secret token for your user ID. By the same logic, a password is false security. “Security by obscurity” refers to the obscurity of the security scheme, not identifiers!
- cptskippy 8y ago
  > “Security by obscurity” refers to the obscurity of the security scheme It's not even that specific. It's obscurity of the workings of the system which may or may not have any security in place.

filleokus 8y ago

Of course your authentication scheme should be secure even if someone knows how the user IDs are generated. With that said it might be a good idea to exposing something like GUIDs to the user anyways, for example if you are worried about a competitor getting an exact count of registered users / products / orders (which the competitor would get by themselves doing the action and observing the created ID). https://tomharrisonjr.com/uuid-or-guid-as-primary-keys-be-careful-7b2aa3dcb439 https://tomharrisonjr.com/uuid-or-guid-as-primary-keys-be-ca...

mcintyre1994 8y ago

> Tapplock user? Get and install any and all patches provided. Apparently, the company has now addressed the most obvious web portal holes (guessable account IDs and no HTTPS), but we assume an app update will be needed as well. It sounds like they still have this flaw, you just have to guess someone else's account ID now.

dmurray 8y ago
The recommendation is a lot kinder than the reasonable one of "throw the lock in the garbage and never buy anything from this company again".

friendzis 8y ago

> Your authentication state is not "logged in", it's "logged in as user X". So the code that decides whether a client can see a specific page can and should (!) depend on what specifically you're authenticated as. "the code that decides whether a client can see a specific page" should not care about authentication, this is authorization issue. I see these things conflated too often. Identification, Authentication and Authorization are three different beasts. Separate identification seems unnecessary complication, which it is in simple web app, but in a more complicated case where ID is not user supplied (login over external service, read ID from smart card, etc.) it can become a necessity, which can be embedded into authentication mechanism. Authentication mechanism should only provide "authenticated" and similar (e.g. "authentication security level") flags, because authentication at its root is a mechanism to establish trust that client has control of certain ID, nothing more.

phito 8y ago
Sometimes I wonder how technology can work, when so many people working in the field are unable to grasp the basic concepts of it
- chii 8y ago
  Either the competent pulls way more than their weight, or luck.
  - yjftsjthsd-h 8y ago
    Also the really bad stuff sometimes dies under its own weight. Natural selection occasionally works.
Double_a_92 8y ago
Have you looked at recent at auth tutorials for NodeJS and related frameworks? You (a potential beginner) have to basically implement everything yourself or use some 3rd party service. There just aren't any good libraries available. I once tried some random framework I found where the example auth project that they provided had exactly the problem you described. You could log in and then do everything if you called the api endpoints manually... Deleting and editing other users profiles? No problem.

JeremyBanks 8y ago

“Security by obscurity” has become so misused... it doesn’t apply to this situation at all. There’s nothing illegitimate about having a secret token for your user ID. By the same logic, a password is false security. “Security by obscurity” refers to the obscurity of the security scheme, not identifiers!

cptskippy 8y ago
> “Security by obscurity” refers to the obscurity of the security scheme It's not even that specific. It's obscurity of the workings of the system which may or may not have any security in place.