131–140 of 148 posts
Earlier quoted context omitted.
> user experience for mobile devices becomes terrible Cant have Your cake and eat it too > client fingerprinting is easily duplicated. Far from it.
> Cant have Your cake and eat it too Or we could just use credentials that can be tied to the hardware, and then we have stronger security assertions than tying to IP, and without any degraded user experience.
Earlier quoted context omitted.
> Cant have Your cake and eat it too Or we could just use credentials that can be tied to the hardware, and then we have stronger security assertions than tying to IP, and without any degraded user experience.
What is this protocol called and who supports it?
Earlier quoted context omitted.
I like a good rant as well as the next person, but had some issues with this one. > What if we have a scenario where a third party authenticates the client (by verifying that they have a valid token issued by their ID provider) and then uses that to issue their own token that's much longer lived? He might as well be complaining about car keys. Yes, if I leave my car key in the door of my car, bad things will happen.…
> If you issue a long lived bearer token, bad things will happen. I can issue a short lived bearer token, and another service I don't control can then decide based on that to issue a long lived one and I have no generic way to gain insight into that.
But that's a bit like saying:
I have a metal key that I only give to trusted people, but someone I trust can make a copy of that key and give me back the original. Therefore I can't trust metal keys.
I guess I'd want to dig in a bit more to understand the use case. Who is deciding to use the other service? Who is accepting the long lived token? (you? If so, why? The issuer? Well then, they made that choice.)
So don't set the token to expire after the "heat death of the universe", make the user reauthenticate after an appropriate time for the service being used.
A big limitation is forced early expiration. If you need to do that then you end up needing to share expiration information and therefore need to share something that might as well be a password hash. So for example it's not great to use instead of a session key. You could design a system where you have, say, 6 API endpoints and instead of the API endpoints needing access to the authentication db, you use bearer toke…
I grant that this can happen at scale, e.g. Dropbox, or for sensitive systems that give mutating access to financial instruments, but for the _vast_ majority of businesses, this is a completely hypothetical problem.
Earlier quoted context omitted.
> If you issue a long lived bearer token, bad things will happen. I can issue a short lived bearer token, and another service I don't control can then decide based on that to issue a long lived one and I have no generic way to gain insight into that.
Fair, by using bearer tokens you don't have full control over how they are used by downstream parties. But that's a bit like saying: I have a metal key that I only give to trusted people, but someone I trust can make a copy of that key and give me back the original. Therefore I can't trust metal keys. I guess I'd want to dig in a bit more to understand the use case. Who is deciding to use the other service? Who is ac…
Here's an example scenario. One of my users runs Github Desktop and clicks "Sign in". This process involves them performing extra authentication in order to gain access to our enterprise organisation, which is handled by my identity provider. I can hook into that authentication process in order to verify device identity and state, and I can issue a short-lived token. Github will then happily take this short-lived token and provide a long-lived token to the Github Desktop app which will grant access to my organisation's source code without any further authentication, and which is not bound to the device in any way.
Why does the author assume we want to associate a bearer token with hardware at all? When my services issue a JWT, I am issuing a right to talk to my service. If you want to take that token and move it to your phone, neat good for you. If someone steals your laptop and dumps the secret, that's sure as hell not my problem to solve. The application layer is not the appropriate place to apply a mitigation for a user's l…
Sounds to me like the author is essentially bemoaning a presumed lack of an invalidation mechanism, and thus declares "Bearer tokens considered harmful".
Bearer tokens are no different to a password in that way. Netflix is currently battling shared passwords, and people regularly have their passwords stolen by a site impersonating the other end.
Invalidation is only useful if you know the bearer token has been stolen or compromised so it doesn't solve them problem. It's no different to demanding your users change their passwords after a leak has been publicised. And besides - it's already possible to keep a registry of invalid tokens, just a it's possible to set a "password must be changed at next login" flag, so invalidation is possible now.
But - the article seems to totally ignore the improvement short lived tokens makes to the situation. If the token only live for 15 minutes, the damage it can do is presumably limited. Still, the point remains - if you could replace a bearer token with something that did mutual authentication on every exchange it be much more secure.
Conceptually, it's not even that difficult. IPSec effectively does it now for every packet sent. You "just" need to build IPSec like mechanisms into every exchange. Actually it's not that hard - with a standardised protocol app developers could use it without much change. But there doesn't appear to be much movement in that direction.
Somewhat harder is "mutually authenticate with what". If the threat model is "someone hacks your computer, and steals the credentials", then it has to be tied to something unhackable that needs to be physically stolen to get any improvement. IPSec doesn't address the problem. Sure, you can authenticate against a certificate, but unless someone has going to the trouble of using a HSM that certificate is really just another long lived bearer token that can be stolen.
That can be fixed. One can imagine a person using a FIDO2 key to authenticate themselves, but all the FIDO2 key does is authorised the TPM in their device to act on their behalf for a while, and the TPM establishes a trust relationship with the servers HSM and somehow tying that all together so every packet exchanges is authenticated with that trust relationship. But now we are talking real complex multilayer protocols.
Such protocols would be far better than what we have now security wise, but it's a huge job. If mjg59 wants that world he would probably be better off doing some social engineering and collecting together a group to write a spec everyone can stomach, not whining about it on the internet.
Earlier quoted context omitted.
Legally it depends on the service that was stolen. Was this a banking or credit website where some consumer protections might apply or do you have any contractual limitations on cost that may protect you? But generally you will be liable for the costs incurred from items stolen from your custody. You must then recover those costs from whoever stolen from you
> Was this a banking or credit website where some consumer protections might apply Let's assume not. > or do you have any contractual limitations on cost that may protect you? I guess in this hypothetical case the person whose laptop was stolen cancels the credit card before the charge is made. > But generally you will be liable for the costs incurred from items stolen from your custody. Right... but who was the vict…
If you refuse to pay and they sue you then they will win and a court will force you to pay, even if it means a sheriff comes to your house and takes your things to sell at a public auction to come up with the money.
You will have to recover from the thief if you want to be made whole. It's possible that if you know who the thief is and can serve them, you can join them to the suit the provider brings against you. Then the court will adjudicate the whole thing together and the thief will directly pay the provider. But that still starts with suing you and action on your part to find and sue the thief.
Earlier quoted context omitted.
> Was this a banking or credit website where some consumer protections might apply Let's assume not. > or do you have any contractual limitations on cost that may protect you? I guess in this hypothetical case the person whose laptop was stolen cancels the credit card before the charge is made. > But generally you will be liable for the costs incurred from items stolen from your custody. Right... but who was the vict…
The short answer is that there are lots of caveats but the service provider will recover the bill from you. If you refuse to pay and they sue you then they will win and a court will force you to pay, even if it means a sheriff comes to your house and takes your things to sell at a public auction to come up with the money. You will have to recover from the thief if you want to be made whole. It's possible that if you…
Earlier quoted context omitted.
It isn't until it is. And wherever you store it is a juicy target.
Wouldn't you just store it in the same place you're storing the main authentication data (eg. password hashes)? [edit] I guess that database would get hammered pretty hard on every request, unless you use caching... which might be what you're getting at.
Earlier quoted context omitted.
> in the absence of that it's legitimate for the issuer to assume that when the client asserts that a key was generated in hardware that it was telling the truth You want the credentials to be non-extractable. The client wants to extract the credentials and use them somewhere else. Blind trust in an unsupported assertion from a client with diametrically opposing goals is not much of a security model.
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.