I have an implementation for an internal API, the requirement is to implement some sort of basic authentication instead of oauth (generating a token).

Do you think there’s any difference between using just an API key vs using a client id + secret?
For what I see it’d be just like saying “using a password” vs “using a user and a password”.

  • pe1ucaOP
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 year ago

    Oh, yeah, I had forgotten about this kind of attack.

    Do you think this is a concern if the calls are only meant to be done in an internal network?

    • ck_@discuss.tchncs.de
      link
      fedilink
      arrow-up
      9
      ·
      1 year ago

      The modern way of thinking about security of internal networks is to assume there is no such thing (marketing term: Zero Trust).

    • TootSweet@lemmy.world
      link
      fedilink
      English
      arrow-up
      4
      ·
      1 year ago

      I’d consider it a concern if I was in your shoes, yes. Mostly for the reasons jflorez mentioned.

      Major security breaches wherein an attacker gained has access to an internal, private network happen not infrequently. Target (the retail chain) leaked a ton of their customers’ credit card to attackers over the course of (IIRC) months. The attackers couldn’t have done it (at least not in the way they did) without first breaching Target’s private corporate network.

    • jflorez@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      2
      ·
      1 year ago

      Never underestimate the risk of an attack coming from the inside.

      Also once you have an implementation with a certain kind of authentication other devs are likely to copy what you have successfully deployed and then your security assumptions will make it into public facing code without much consideration