| ▲ | drum55 a day ago |
| Seems a little pointless, your keys can't be stolen but they can be instantly used by malware to persist across anything you have access to. The keys don't have any value in their own right, the access they provide does. |
|
| ▲ | Nextgrid a day ago | parent | next [-] |
| The idea with HSM-backed keys is that even in case of compromise, you can clean up without having to rotate the keys. It also makes auditing easier as you can ensure that if your machine was powered down or offline then you are guaranteed the keys weren't used during that timeframe. |
| |
| ▲ | jamiesonbecker 16 hours ago | parent [-] | | Rotating keys is easy with the right software. (I work @ Userify) Agree with the auditing point Token-based keys, to tptacek's point, is that they can be a giant pain once you start scripting across fleets. |
|
|
| ▲ | lxgr a day ago | parent | prev | next [-] |
| That's still an improvement. In sophisticated attacks, attackers might well store stolen credentials and use them at a later, more opportune time. Of course a real secure attention sequence would be preferable, such as e.g. requiring a Touch ID press on macOS for keys stored in the Secure Enclave. Not sure if TPM supports something similar when a fingerprint sensor is present? |
|
| ▲ | Borealid 21 hours ago | parent | prev | next [-] |
| TPMs support setting a PIN without which a key cannot be used. The PIN can be an arbitrary string (password). |
| |
| ▲ | tegmentum 18 hours ago | parent | next [-] | | I wish they wouldn't do that with the naming. It's confusing as hell to call it a PIN (Personal Identification Number) if it's actually a password. | | |
| ▲ | ButlerianJihad 18 hours ago | parent [-] | | Well... it would also be confusing to call them "passwords" because they are not that. In addition to biometric authentication, Windows Hello supports authentication with a PIN. By default, Windows requires a PIN to consist of four digits, but can be configured to permit more complex PINs. However, a PIN is not a simpler password. While passwords are transmitted to domain controllers, PINs are not. They are tied to one device, and if compromised, only one device is affected. Backed by a Trusted Platform Module (TPM) chip, Windows uses PINs to create strong asymmetric key pairs. As such, the authentication token transmitted to the server is harder to crack. In addition, whereas weak passwords may be broken via rainbow tables, TPM causes the much-simpler Windows PINs to be resilient to brute-force attacks.[139]
https://en.wikipedia.org/wiki/Windows_10#System_securitySo you see, Microsoft needs a way to describe an access code that isn't a password, because it's more secure than that, but yet it isn't exactly a number, so what do you call it? "PIN" is perhaps an unfair recycling of an in-use term, but should they coin a neologism instead? Would that be less confusing? | | |
| ▲ | XorNot 17 hours ago | parent [-] | | Secret Code Word. Communicates it is meant to be secret, and can be a short memorable thing. |
|
| |
| ▲ | palata 16 hours ago | parent | prev [-] | | Though if your computer is compromised, then the malware can read the password, right? | | |
| ▲ | Borealid 15 hours ago | parent [-] | | If your computer is compromised while you enter the PIN in such a way that the malware can read your input, yes. If your computer is compromised after you've already entered the PIN, or there is an app running on the computer but it is not sufficiently privileged to sit in between you and the TPM, no. That's quite good protection generally. The defense against this type of attack is to get a smartcard reader with an on-board PIN entry keypad - those do exist, but it's quite a step. |
|
|
|
| ▲ | knorker a day ago | parent | prev [-] |
| Without presence test (e.g. yubikeys touch) it's certainly not perfect. But it does close some real world attacks. Like the key can only be used while your laptop is on. (assuming laptop, here). And keys cannot be stolen from backups. Or stolen without your knowledge when you left your laptop unguarded for 5min. Not every attacker has persistent undetected access. If the key can be copied then there's no opportunity for the original machine's tripwires to be triggered by its use. Every second malware runs is a risk of it being detected. Not so, or not in the same way, with a copied key. |
| |
| ▲ | spwa4 a day ago | parent [-] | | I guess you could implement that on android. | | |
| ▲ | lxgr a day ago | parent | next [-] | | Android actually supports secure transaction confirmation on Pixel devices using a secure second OS that can temporarily take control of the screen and volume button as secure input and output! https://android-developers.googleblog.com/2018/10/android-pr... This is really cool and goes beyond the usual steps of securing the key, but handling "what you see is what you sign" and key usage user confirmation at the OS level, which can be compromised much more easily (both input and output). | | |
| ▲ | tadfisher 18 hours ago | parent [-] | | Protected Confirmation was deprecated a while back, unfortunately: https://android.googlesource.com/platform//system/security/+... Quote: "Android Protected Confirmation is deprecated due to the high
support/maintenance cost for Android device makers and low adoption rate
among app developers. APC requires Android device makers to have a
substantial amount of device-specific UI code running in the trusted
execution environment. That has proven to be expensive to maintain and
non-scalable, as there cannot be a single implementations device makers
can share or use as a reference. Additionally, app developers have not
adopted this feature, as the Android platform offers other mechanisms
for authentication a user's intent. These mechanisms, such as
authentication-bound Keystore keys, are less secure than Trusted UI, but
are more wide-spread. While we explore alternatives to APC that are
viable to the device makers ecosystem, we sunset the APC API." | | |
| ▲ | lxgr 18 hours ago | parent [-] | | Oh damn, I missed that, thank you. I could see how it was a very expensive thing to maintain for an effectively Pixel-only feature. Still, I think this was one of the most ambitious and user-beneficial implementations of trusted computing I've seen so far, in that it theoretically safely allows a completely rooted/user-owned device to still participate in things like online banking or e-government transaction authorization. I hope it'll return in some form. |
|
| |
| ▲ | palata 16 hours ago | parent | prev | next [-] | | Well on Android there is the Keystore that can access the secure element (if present on the device). And it can be secured with biometrics or PIN. | |
| ▲ | knorker 7 hours ago | parent | prev [-] | | Yes. But that'd just be a TPM on a computer, in hand held form. A laptop and a phone are both general purpose computers with "TPM chips", so "you could implement that on android" is as true as "you could implement that on a white computer". There was something about Macs. It took them a while to get a TPM. But I think now they do, so macs can do it too. | | |
| ▲ | spwa4 5 hours ago | parent [-] | | It could require you to confirm with a fingerprint though. So it's an actual second (or third) factor. | | |
| ▲ | knorker 4 hours ago | parent [-] | | Ah, I guess by "that" you meant the touch part, not the uncopiable part. There are many ways to implement this. I think some Chromebooks have FIDO gated on a physical button. If you have an unlocked device with keys usable requiring a mere touch, I'm not sure fingerprint adds much value. A button would be enough. Actually checking with fingerprint only addresses an extremely narrow attack where someone who wants to attack you steals your device (so already physical access, meaning not DPRK hackers) while it's unlocked, and only getting a window of opportunity until you've called your security department to lock your account.
… and yet this attacker would NOT be willing to use force against your person, to make you use your fingerprint. Sure, if that's a threat model that's worth your time, use fingerprint too. Keep in mind that already going from software only (and arguably this includes OTP app on your phone) already means effectively going to zero. Google moved to security keys and says “We have had no reported or confirmed account takeovers since implementing security keys at Google” — https://krebsonsecurity.com/2018/07/google-security-keys-neu... So there are extreme diminishing returns after just security key with touch. An app solution even gets a callout in that article as being not as good. |
|
|
|
|