12

I searched for other questions in this topic but i found not an answer to exatly this. So tell me if i'm wrong. I'm new in this topic and you can correct me with pleasure. Here is what i think at the actual moment:

I surfed arround the web for 2 days now, figuring out what is the actual state of the art to authorize a webrequest. Now what i figured out quickly is that OAuth 2.0 seems to be the most common standard. But OAuth 2.0 itself is everything other than standardized. Out of my sight it's a mess of different customizations for every greater company. But anyway there are two techniques to exchange authorization information: Mac-Tokens and Bearer-Tokens.

In my opinion Mac-Tokens offer way more security. So why is it not widely implemented? The only reason i could find is because its a little bit more complicated. And i heard say several times that Mac-Tokens are not recommended, if the client is not 100% trusted, because the client has to store the secret. But where is the difference? The client has to store a Authorazation-Information anyway. In my opinion it doesn't matter wheter its a bearer-token or a mac-secret. But what makes a difference is that the mac-secret (rather than the bearer-token) is not submitted over the wire on every request.

So can you tell me a sane reason why not using mac-tokens? (apart of having a litte more effort) Am i missing something? Or have i missunderstood the two token techniques.

Thanks for reading and your help.

Daniel
  • 486
  • 4
  • 19

6 Answers6

4

The danger is that if the client proceeds without insisting on the SSL/TLS certificate being valid - which is a step that many clients fail to take - then the bearer token is susceptible to a man in the middle attack.

The Mac token is not susceptible to this attack; it may be correct to say that the Mac token provides some authenticity in the absence of SSL/TLS, or indeed when it is not being used correctly.

The Mac token strengthens a known weakness of the Bearer token.

A client should not be trusted with a MAC key that is shared. A new key should be generated for each client. It is no more of a security risk to trust each client with its own key, than it is to trust them with bearer tokens.

I think the problem comes when exchanging the Auhtorization Grant for the Access Token. For the Mac key, this returns a symmetric secret key. If the client is sloppy about checking SSL/TLS certificates, then this too is susceptible to a MITM attack.

In short, the Mac token may be less favoured because it is more complicated but you still need to do SSL/TLS right to make it secure, and if you do that then the Bearer token will also be secure.

user2800708
  • 1,890
  • 2
  • 18
  • 31
  • Yes i am absolutely with you. You cannot do without SSL/TLS anyway this would be just unprofessional. I think you are right, it's just not used because it's more complicated. Because the Mac-Token is more secure in every aspect. No matter if you can trust the Client or not. – Daniel Nov 04 '16 at 13:12
  • Note that when talking about a "MAC key", this answer is referring to the `mac_key` parameter, which only exists in MAC Tokens and is the real secret. See the [MAC Token specification](https://www.ietf.org/archive/id/draft-ietf-oauth-v2-http-mac-05.txt). – Akaisteph7 Aug 17 '23 at 21:35
  • To clarify, this answer is explaining that a MITM attack is still possible when using a MAC Token but only during the Authorization Grant phase. But a Bearer Token is always susceptible, even when later accessing data, as the `access_token` is its real secret and it will be directly sent in the request (see [example](https://dzone.com/articles/oauth-20-bearer-token-profile)). Therefore, a MAC Token is technically more secure but both are only truly secure when sent over a connection that enforces the SSL/TLS protocol. And when using SSL/TLS, they are basically equivalent in terms of security. – Akaisteph7 Aug 17 '23 at 21:41
3

In my opinion, the answer may be simple: Bearer token mechanism assumes existence of SSL/TLS layer, whereas MAC token tries to replace that. Since SSL/TLS is widely accepted and used, why doing things more complicated than needed?

Yes, as it was recently seen with the heartbleed vulnerability, many things are not really as reliable as expected, but who guarantees that MAC implementation is free of glitches as well?

Another point is, as you mentioned, exchange of symmetric secrets. In absence of absolutely reliable secondary channel it may be tricky. And trusting a client may also be an issue.

The Ancient
  • 382
  • 3
  • 13
  • Okay i understand your point. But i my opinion MAC-Token not forcing to replace SSL/TLS. Best option is using both. SSL/TLS and MAC-Token-Authentication so you have better security than with Bearer-Tokens. Or am i wrong? – Daniel Dec 27 '15 at 16:01
  • Well, I might have been not precise with "replacement". Bearer token value must be protected, normally via SSL/TLS. If you cannot, due to some reason, involve HTTPS, you must not use Bearer token scheme. Still, you can rely on MAC authentication mechanism. The IETF document states explicitly: "The primary design goal of this mechanism is to simplify and improve HTTP authentication for services that are unwilling or unable to employ TLS for every request. In particular, this mechanism leverage an initial TLS setup phase to establish a shared secret between the client and the server." – The Ancient Dec 28 '15 at 13:06
  • 1
    Okay. Yes now i better understand what you mean =) I talked to a security expert and he told me he would never use mac-authentication without encription (HTTPS) and the best option is to use mac-token with encryption. But i know what you mean. – Daniel Dec 28 '15 at 14:14
2

If SSL/TLS was used properly and the client credentials emitted in a confidential and self-service way are no many advantages to adopt MAC instead of Bearer tokens. Only adds complexity. It is client's responsibility to maintain the client_secret confidentiality. Of course there are clients that prefer to use MAC thinking that are improving security.

Anderson Marques
  • 808
  • 8
  • 13
  • I'm absolutely not with you. SSL/TLS is not 100% safe. There is weakness. For example Man in the middle attack. If the user decides to continue anyway. The Security is gone. And if this Security fails there is another reliable mecanism to secure authentication. – Daniel Feb 23 '17 at 09:42
  • with tls correctly used (up-todate tls stack and refuse not verfiable server certificat), token are not more secure than mac... and mac affectively add more complexity... but mac canot be intercepted (depend on the way you transmit the secret) beceause only challenge are transmit between client en server... not the secret... it's like basic auth vs digest auth... plus with mac you can store in secure store(android/ios secure store or tpm on pc) and make challenge without retriving the secret... – Mathieu CARBONNEAUX Jun 17 '22 at 09:11
0

With mac authentification you can store mac secret in secure store in Android device, or in tpm pc device... in that way you are not able to retrieve the secret, but you can make the hmac challenge from this store without knowing the secret... for tls certificate client you must send the certificate to the server and can be intercepted (with mitm) ...

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Mathieu CARBONNEAUX
  • 174
  • 1
  • 10
0

Implementation of MAC token is way more complex than the Bearer token which is why the Bearer token is widely used. If very high security is required or HTTP communication is required between client and server, MAC token is used.

MAC token is issued to a particular token. It is like an airplane ticket. Only the written name on the ticket can use the ticket. Only during the first step when the client requests to get the token, TLS protocol is used. Because the response object includes the symmetric key and we do not want the man in the middle to get it. A MAC token

{
    " access_token " : " HIAV43jkKG " ,
    " token_type " : " mac " ,
    " expires_in " : 3600 ,
    " refresh_token " : " 9xLPXBtZp " ,
    <!-- this is the symmetric key. we dont want man in the middle capture this.  -->
    " mac_key " : " yildij39jdlaska 9ud " ,
    " mac_algorithm " : " hmac - sha - 256 "
}

MAC token has no replay attack protection. You have to implement on your own. https://crypto.stackexchange.com/questions/77827/replay-attack-resistant-mac

In Bearer token implementation, the client does not need to show its id. It is like a movie ticket, whoever has a valid ticket, can use it because there is no identity checked. That is the downside of the Bearer token. Bearer token requires TLS otherwise man in the middle can actually take the token away and can use that token.

Yilmaz
  • 35,338
  • 10
  • 157
  • 202
0

Another perspective:

Assuming TLS is properly setup between Client and Resource Server (which has become almost ubiquitous by now), the remaining advantage of MAC tokens is that the sender is authenticated as opposed to bearer.

However since TLS narrows the attack surface to the Client, a compromised Client would nullify the sender authentication advantage. Moreover, a Client that willingly leaks the access token to a 3rd party is just as likely to share the actual information obtained from the Resource Server with that 3rd party.

To summarise: the ubiquitous availability of TLS has minimised the security advantage of MAC tokens over bearer tokens, whilst one also has to take into account the fact that implementing MAC tokens is much harder than bearer tokens.

Hans Z.
  • 50,496
  • 12
  • 102
  • 115