0

I want to create Angular 9 + Spring Boot application with strong security complaint to PCI-DSS security standard.

Which security protocol is preferred for user sessions in order to have high security when we use Angular and Spring Boot:

  • Session cookies
  • OAuth2
  • OAuth2 + JWT
  • JWT

for now I'm thinking to secure the application using JWT. Can you share what issue might I have using JWT and is it a good choice?

Peter Penzov
  • 131
  • 2
  • 1
    The standard generally doesn't specify any particular technology, so any of these could probably work. PCI compliance is more about who you let log in in the first place, and what you let them do once they're in. Is this application you're building for customers to log into and provide their cc number (order things)? Or for employees to log into and type on card numbers from the phone (moto/call center)? Or for employees to log into and see previously-stored card numbers? – Bobson May 24 '20 at 14:45
  • PCI-DSS compliance applies to the whole system, so non of the technicks violates PCI-DSS if this is a question. – aholbreich Jan 19 '21 at 18:05

2 Answers2

1

The only requirement that directly relates to session management is 6.5.10 which is very general:

6.5.10 Broken authentication and session management.

Secure authentication and session management prevents unauthorized individuals from compromising legitimate account credentials, keys, or session tokens that would otherwise enable the intruder to assume the identity of an authorized user.

The best PCI-type resource is the new Software Security Standard. https://www.pcisecuritystandards.org/documents/PCI-Secure-Software-Standard-v1_0.pdf

which recommends threat modelling and then selecting your authentication and session management based on this.

Community
  • 1
withoutfire
  • 1,000
  • 4
  • 7
  • Thanks for what about the security scans? Is there any method from the above list which will fail the security scans? – Peter Penzov May 24 '20 at 17:20
  • @PeterPenzov none of the above 4 methods shall flag in security scan. penetration testing might show some results, if the methods are not applied properly. – Arpit Rohela May 24 '20 at 17:30
0

The comments and other answer already covered the PCI-DSS side of this, so I'll briefly address the JWT vs. (random) session token vs. OAuth side. As a side note, this is not generally what's considered "authentication mechanisms"; that would be things like passwords vs. magic links vs. biometrics vs. WebAuthN vs. client certificates vs. etc. OAuth and OpenID Connect (built on top of OAuth, which is actually focused on authorization) can also be used for delegating authentication to some other party, but if the other party is another system you control, you still need to decide how to do authentication there.

In any case, this question seems to be about authentication (or session) tokens, and by extension about session management.

Mostly, it comes down to what you need from your environment.

The advantages of JWTs is that they're scalable (no per-user server-side state needed, reduced database lookups), can carry user and session data within them in a trusted way, and that the issuer and verifier can be different systems (even with the issuer not trusting the verifier). As such, they're popular for highly-distributed systems, high-traffic systems, microservices, and anything with external SSO. The downsides of JWTs are that they're non-revocable (you'll want short lifetimes and thus either refresh tokens or very short sessions before reauthentication) and there's a "key to the kingdom" that, if leaked, can be used to generate arbitrary tokens that will validate successfully. As such, they are sometimes less preferred for very high-sensitivity systems that require precision control over session creation and duration and avoidance of single points of failure.

Random session tokens (stored in RAM, external cache, or DB) are arguably the most secure option, but they require synchronization/cache coherency, extra server resource/extra DB queries, and are generally not practical with any sort of federated or external authentication. They are generally best for simpler, smaller-scope projects, or for ones with very strong security requirements.

Both systems have security pitfalls (JWTs need to be validated correctly, random tokens need to be generated and stored correctly), but only JWTs have a catastrophic failure mode (exposure of the key) in a way that doesn't require fully compromising the server or the sessions table of the database. Indeed, random tokens can be made secure even against compromise of the sessions table (by hashing the client-stored token with an HMAC using a secret key stored outside the DB, and storing the MAC rather than the token in the DB). However, in many cases, the scalability of JWTs makes them the only viable choice; they are still quite secure if implemented correctly.

OAuth, by itself, doesn't really touch on either of these. In theory one could design an OAuth system that had to perform the OAuth flow every time any access-controlled operation was attempted, but in practice this would be intolerable to the user if the protected action(s) were at all frequent. Instead, upon completion of the OAuth flow, the user is typically issued a token of some sort. Most commonly, this is either a JWT + a random refresh token, or a random session token.

CBHacking
  • 40,303
  • 3
  • 74
  • 98