4 ms·

Would hardware security keys protect from this? If you already have a session token on a site (and that site doesn't somehow restrict the session token to only

by foota 4y ago

Would hardware security keys protect from this? If you already have a session token on a site (and that site doesn't somehow restrict the session token to only being used on the machine that generated it? Which afaik isn't possible) then it's too late, yes?

T3OU-736 4y ago
> Would hardware security keys protect from this? If you already have a session token on a site (and that site doesn't somehow restrict the session token to only being used on the machine that generated it? Which afaik isn't possible) then it's too late, yes? Sort of. There are ways to verify both the device being used to access a resource, and the account. This is a good use for TPM. One of the features is attestation, which can be used to do this sort of a thing. For things like crypto keys, this is why HSM (hardware security module) exist. - they make it very difficult to get access to private key (basically, private key doesn't leave the HSM itself, but other cryptographic artifacts based on that key do).
ec109685 4y ago
With WebAuthN it should be possible to require that credentials are frequently refreshed, which can only be done on the original device. mTLS has similar properties. You can also require an authentication loop for each major service, so only services the developer is authenticated to would be vulnerable to credential stealing. And for critical infrastructure network security would help (e.g. a vpn). With hardware tokens required to initiate the connection, the attacker wouldn’t be able to spin up their own connection. Finally, access to user secrets shouldn’t be a default level of access for engineers. Instead, that should require a break glass escalation of privileges, reducing the risk of pilfering.
FreakLegion 4y ago
Correct, the hardware token adds nothing over TOTP in this case. You can use a platform authenticator instead of a roaming authenticator, but that only stops you from authenticating on a different machine; it doesn't stop a stolen session from being used on a different machine. The step-up authentication CircleCI mentions is probably more of a sudo model, with a long-lived baseline level of privilege that can only be elevated for short bursts. This is orthogonal to MFA, but it's at least less of a nuisance with a hardware token than with other options. > and that site doesn't somehow restrict the session token to only being used on the machine that generated it One simple practice for security-critical systems is to bind sessions to the client's IP address during authentication. It's not bulletproof given the assumption of malware an attacker can still tunnel through, but neither is locking the session to the device. You could, but the malware is also on the device and can do anything the user can (this is why it's preferable to test user presence outside the device by e.g. tapping a USB key).
fidgewidge 4y ago
It's interesting cuz they're saying it's a stolen SSO cookie. Chrome on macOS stores cookies encrypted under a key that's stored in the keychain. So does Safari. To get to the key one of three things must have happened: 1. The engineer was prompted to give the malware (PTX app?) access to the browser key, and agreed to this. Big mistake if so. 2. The malware has an exploit for macOS security. 3. The malware has a way to take over the browser cross-process. Hardware security keys don't help in this case. What helps is either users not granting malware access to critical secrets, OR, operating system security being enhanced.

by foota 4y ago

T3OU-736 4y ago

> Would hardware security keys protect from this? If you already have a session token on a site (and that site doesn't somehow restrict the session token to only being used on the machine that generated it? Which afaik isn't possible) then it's too late, yes? Sort of. There are ways to verify both the device being used to access a resource, and the account. This is a good use for TPM. One of the features is attestation, which can be used to do this sort of a thing. For things like crypto keys, this is why HSM (hardware security module) exist. - they make it very difficult to get access to private key (basically, private key doesn't leave the HSM itself, but other cryptographic artifacts based on that key do).

ec109685 4y ago

With WebAuthN it should be possible to require that credentials are frequently refreshed, which can only be done on the original device. mTLS has similar properties. You can also require an authentication loop for each major service, so only services the developer is authenticated to would be vulnerable to credential stealing. And for critical infrastructure network security would help (e.g. a vpn). With hardware tokens required to initiate the connection, the attacker wouldn’t be able to spin up their own connection. Finally, access to user secrets shouldn’t be a default level of access for engineers. Instead, that should require a break glass escalation of privileges, reducing the risk of pilfering.

FreakLegion 4y ago

Correct, the hardware token adds nothing over TOTP in this case. You can use a platform authenticator instead of a roaming authenticator, but that only stops you from authenticating on a different machine; it doesn't stop a stolen session from being used on a different machine. The step-up authentication CircleCI mentions is probably more of a sudo model, with a long-lived baseline level of privilege that can only be elevated for short bursts. This is orthogonal to MFA, but it's at least less of a nuisance with a hardware token than with other options. > and that site doesn't somehow restrict the session token to only being used on the machine that generated it One simple practice for security-critical systems is to bind sessions to the client's IP address during authentication. It's not bulletproof given the assumption of malware an attacker can still tunnel through, but neither is locking the session to the device. You could, but the malware is also on the device and can do anything the user can (this is why it's preferable to test user presence outside the device by e.g. tapping a USB key).

fidgewidge 4y ago

It's interesting cuz they're saying it's a stolen SSO cookie. Chrome on macOS stores cookies encrypted under a key that's stored in the keychain. So does Safari. To get to the key one of three things must have happened: 1. The engineer was prompted to give the malware (PTX app?) access to the browser key, and agreed to this. Big mistake if so. 2. The malware has an exploit for macOS security. 3. The malware has a way to take over the browser cross-process. Hardware security keys don't help in this case. What helps is either users not granting malware access to critical secrets, OR, operating system security being enhanced.