Bearer tokens are just awful • Hacker News Board

Re: Bearer tokens are just awful

#141

Post by dumpsterdiver » Wed, Apr 06, 2022, 3:20 AM UTC

mjg59 wrote: post #120

dzhiurgis wrote: post #119

Earlier quoted context omitted.

That’s why you use platform that already solved IP address and other client fingerprinting. If you are really paranoid - you setup alert policies when users are exfiltrating suspicious amount of info.

IP fingerprinting is unhelpful - the user experience for mobile devices becomes terrible. Any other client fingerprinting is easily duplicated.

Seems like this could be bearable (badum-bum-psh) if it was only enforced during a token refresh (as opposed to every request), even on mobile.

Re: Bearer tokens are just awful

#142

Post by mjg59 » Wed, Apr 06, 2022, 3:34 AM UTC

nybble41 wrote: post #140

mjg59 wrote: post #129

Earlier quoted context omitted.

I'm not the service owner. I care about credentials on my clients being hardware backed, and I have enough control over the platform to have reasonable confidence that they'll make a truthful assertion. Clients managed by other people may have different priorities, and should be able to make their own decisions.

If you control the clients then there is no need to assert anything, truthful or otherwise. Go ahead and store the keys in a TPM if you want—the server has no reason to know or care about that. This does not require any key attestation.

You're the one who claimed this approach required remote attestation, not me?

Re: Bearer tokens are just awful

#143

Post by dzhiurgis » Wed, Apr 06, 2022, 3:54 AM UTC

mjg59 wrote: post #132

dzhiurgis wrote: post #131

Earlier quoted context omitted.

What is this protocol called and who supports it?

The absence of support for a stronger solution is an argument for improving support for a stronger solution, not an argument against criticising the existing solution.

Was genuinely serious

AFAIK iOS provides hardware keys for fingerprinting

Re: Bearer tokens are just awful

#144

Post by zshrdlu » Wed, Apr 06, 2022, 6:42 AM UTC

rstuart4133 wrote: post #136

zshrdlu wrote: post #118

Earlier quoted context omitted.

Sounds to me like the author is essentially bemoaning a presumed lack of an invalidation mechanism, and thus declares "Bearer tokens considered harmful".

I don't think so. He is bemoaning the lack of mutual authentication. Once the token is handed out the server has no guarantee on later uses it's dealing with the thing it's handed to, and in some ways worse on later uses the user has no guarantee it's dealing with the server than gave it to him. Bearer tokens are no different to a password in that way. Netflix is currently battling shared passwords, and people regula…

The device can be snatched along with the FIDO2 key...

Re: Bearer tokens are just awful

#145

Post by ptsneves » Wed, Apr 06, 2022, 7:31 AM UTC

xnorswap wrote: post #49

ptsneves wrote: post #35

Earlier quoted context omitted.

Yes but then you add revocation and you are back at a centrally stored database to check against.

That's correct. There are scenarios where it still makes sense. It's plausible that it would more efficient for some high traffic services to push (the somewhat rare) revocation notices out to endpoints as still being more efficient. For example imagine a whatsapp clone. People send thousands (probably tens of thousands) more messages than they issue password/auth resets. Having the incoming message endpoint maintain…

Then in this scenario it means you will trust the clients to honor the list of bad tokens is it not? Is this not the whole reason bearer authentication is insecure? Either you need to check in the server against a database or you need to trust your clients that they checked against the database..

Re: Bearer tokens are just awful

#146

Post by nybble41 » Wed, Apr 06, 2022, 4:12 PM UTC

mjg59 wrote: post #142

nybble41 wrote: post #140

Earlier quoted context omitted.

If you control the clients then there is no need to assert anything, truthful or otherwise. Go ahead and store the keys in a TPM if you want—the server has no reason to know or care about that. This does not require any key attestation.

You're the one who claimed this approach required remote attestation, not me?

If the service wants to make sure the keys can't be copied then it will need remote attestation for either the whole system or just the TPM (what you called "key attestation") to ensure that the client isn't cheating. If it's only the client that doesn't want the keys to be copied they have any number of options for that and no attestation is needed. I assumed your article was promoting the former as the latter really isn't interesting at all.

Re: Bearer tokens are just awful

#147

Post by ecf » Fri, Apr 08, 2022, 3:19 PM UTC

vbezhenar wrote: post #68

I don’t get this article. How are you supposed to validate hardware? There’s no API for that. You can bind session to IP but that wouldn’t work for modern mobile connections. Ideally hardware should have protected private key with manufacturer signature. And API to sign something. Then you can bind session to hardware. But that’s not available today.

> How are you supposed to validate hardware?

Ah, you’ve discovered the zero trust trap. Don’t worry, advocates will be happy to sell you an ultra expensive security option that breaks more often than it works.

Re: Bearer tokens are just awful

#148

Post by vladvasiliu » Sat, Apr 16, 2022, 8:14 AM UTC

zshrdlu wrote: post #144

rstuart4133 wrote: post #136

Earlier quoted context omitted.

I don't think so. He is bemoaning the lack of mutual authentication. Once the token is handed out the server has no guarantee on later uses it's dealing with the thing it's handed to, and in some ways worse on later uses the user has no guarantee it's dealing with the server than gave it to him. Bearer tokens are no different to a password in that way. Netflix is currently battling shared passwords, and people regula…

The device can be snatched along with the FIDO2 key...

Some years ago there were some guys who implemented FIDO2 on an iPhone (Krypt.co, now bought by Akamai).

Sure, people could steal your phone at the same time they steal your laptop. But it's still somewhat less likely, since the phone isn't designed to be plugged in 24/7 in your laptop's USB port, unlike the YubiKey Nano, for example.