Looks like some Chrome maintainers are proposing a new browser API that improves the security of cookie-based logins on desktop computers. Here is the explainer for the technical details. It...
Looks like some Chrome maintainers are proposing a new browser API that improves the security of cookie-based logins on desktop computers. Here is the explainer for the technical details.
It doesn't get rid of cookies. It makes them short-lived with an automatic refresh mechanism, so they can expire quickly and stealing them is much less useful to attackers. It also seems to be designed to make single-sign-on (having a designated website for logins) easy to do.
The refresh mechanism depends on an OS-level private key, which apparently is increasingly common:
Current data shows about 60%, and currently growing, of Windows users would be offered protections.
The design is intended to avoid making any privacy issues worse:
An important high-level goal of this protocol is to introduce no additional surface for user tracking: implementing this API (for a browser) or enabling it (for a website) should not entail any significant user privacy tradeoffs.
Of course, any website you're logged into knows who you are in some sense, depending on what you did while logged in. That doesn't change.
An alternative way of looking at it is that it makes long-lived sessions safer, so websites can get away with asking you to log in again less often.
(How many websites are you logged into all day? Besides Tildes, I mean.)
I like it. With strong, unique passwords and a security key second factor on my most important accounts, I think cookie theft is probably one of the bigger vulnerabilities I have. Good to see some...
I like it. With strong, unique passwords and a security key second factor on my most important accounts, I think cookie theft is probably one of the bigger vulnerabilities I have. Good to see some thought being put into this area.
I was pleasantly surprised this seemed to be a HTTP extension and not a JS API, after they made WebAuthn a JS API and in doing so made it unusable for any application outside a browser. And then I...
I was pleasantly surprised this seemed to be a HTTP extension and not a JS API, after they made WebAuthn a JS API and in doing so made it unusable for any application outside a browser. And then I got to the JS API at the end. Well, it's better, at least.
"60% of Windows users have it" is... not the amazing statistic they seem to think it is. I am concerned, as usual, about people making websites that require a TPM and locking the rest of us out.
I don’t see anything explicitly saying what happens when the hardware isn’t available. It seems like a website could do whatever it likes, and with limited availability, falling back to ordinary...
I don’t see anything explicitly saying what happens when the hardware isn’t available. It seems like a website could do whatever it likes, and with limited availability, falling back to ordinary login cookies on systems that don’t support it seems pretty reasonable? Those systems won’t be protected against malware that steals cookies, but that’s no worse than it is now.
Windows adoption at 60% means it’s worth implementing, not that the old way has to be removed.
Some organizations might require it for their employees’ computers, though?
To be clear, I agree that websites could do these things. I am skeptical that every website will, and I'll occasionally run into something that refuses to work without a TPM. I have a very...
To be clear, I agree that websites could do these things. I am skeptical that every website will, and I'll occasionally run into something that refuses to work without a TPM.
I have a very pessimistic view of all new authentication technology.
Yes, when the API gets enough adoption then some websites could require it. However, unlike DRM, it doesn't look like there's anything about this API that a web browser necessarily has to...
Yes, when the API gets enough adoption then some websites could require it. However, unlike DRM, it doesn't look like there's anything about this API that a web browser necessarily has to implement in hardware? It could emulate the API, keeping the public/private key pair outside any TPM, and the website couldn't tell.
Automatic tests, screen scraping tools, and so on would probably implement it eventually.
Looks like some Chrome maintainers are proposing a new browser API that improves the security of cookie-based logins on desktop computers. Here is the explainer for the technical details.
It doesn't get rid of cookies. It makes them short-lived with an automatic refresh mechanism, so they can expire quickly and stealing them is much less useful to attackers. It also seems to be designed to make single-sign-on (having a designated website for logins) easy to do.
The refresh mechanism depends on an OS-level private key, which apparently is increasingly common:
The design is intended to avoid making any privacy issues worse:
Of course, any website you're logged into knows who you are in some sense, depending on what you did while logged in. That doesn't change.
An alternative way of looking at it is that it makes long-lived sessions safer, so websites can get away with asking you to log in again less often.
(How many websites are you logged into all day? Besides Tildes, I mean.)
I like it. With strong, unique passwords and a security key second factor on my most important accounts, I think cookie theft is probably one of the bigger vulnerabilities I have. Good to see some thought being put into this area.
I was pleasantly surprised this seemed to be a HTTP extension and not a JS API, after they made WebAuthn a JS API and in doing so made it unusable for any application outside a browser. And then I got to the JS API at the end. Well, it's better, at least.
"60% of Windows users have it" is... not the amazing statistic they seem to think it is. I am concerned, as usual, about people making websites that require a TPM and locking the rest of us out.
I don’t see anything explicitly saying what happens when the hardware isn’t available. It seems like a website could do whatever it likes, and with limited availability, falling back to ordinary login cookies on systems that don’t support it seems pretty reasonable? Those systems won’t be protected against malware that steals cookies, but that’s no worse than it is now.
Windows adoption at 60% means it’s worth implementing, not that the old way has to be removed.
Some organizations might require it for their employees’ computers, though?
To be clear, I agree that websites could do these things. I am skeptical that every website will, and I'll occasionally run into something that refuses to work without a TPM.
I have a very pessimistic view of all new authentication technology.
Yes, when the API gets enough adoption then some websites could require it. However, unlike DRM, it doesn't look like there's anything about this API that a web browser necessarily has to implement in hardware? It could emulate the API, keeping the public/private key pair outside any TPM, and the website couldn't tell.
Automatic tests, screen scraping tools, and so on would probably implement it eventually.