61–70 of 95 posts
Earlier quoted context omitted.
Periodically generated seeds, encoded on actual seeds that you and your partner eat for breakfast.
I love it. The tech exists. My neighbor works for a company that does encoding of data on packaging. Goal is that every cereal box on the grocery aisle can be individually tracked.
> TPMs are soldered onto motherboards so they are not portable. Like U2F, they also don’t let you sign arbitrary data. Incorrect! You can use TPM chips to RSA sign arbitrary data, and use that to authenticate SSH: https://blog.habets.se/2013/11/How-TPM-protected-SSH-keys-wo... Even under Windows: https://blog.habets.se/2016/10/Windows-SSH-client-with-TPM.h... The secret is using TSS_HASH_OTHER as the hash algorithm,…
The article has a couple of other weird faults, too:
1. I'm not sure why the author is complaining about FIDO2 having backwards compatibility with U2F/CTAP1. The article even incorrectly claims FIDO2 is "a 3rd incompatible standard" only to counter-argue the point a few paragraphs below explaining CTAP? People not having to throw away their perfectly fine old devices is a good thing in my book.
2. "All FIDO standards are web-centric and aren’t designed with any other client software in mind" the first part is true, the second part not so much. For example FIDO2 supports silent authentication (no user interaction) while WebAuthn explicitly does not[0]. It also supports the hmac-secret extension[1] which is used for offline authentication with Azure Active Directory[2] and IIRC no WebAuthn browser implementation exposes this extension to web apps.
[0]: see e.g. discussion on https://github.com/w3c/webauthn/issues/199
[1]: https://fidoalliance.org/specs/fido-v2.1-rd-20210309/#sctn-h...
[2]: https://docs.microsoft.com/en-us/azure/active-directory/auth...
Earlier quoted context omitted.
I evaluated and purchased a few Thales HSMs. At the time the difference between the FIPS and standard/dev editions was a bunch of cash and the spaces within the device were filled with epoxy and would erase if tampered with. Software was the same, hardware looked the same. The crypto module is validated only with the $$ hardware. Sometimes the non FIPS devices will have other algorithms not on the FIPS list.
Did you ever consider the Yubikey HSM at all as it’s much cheaper?
> TPMs are soldered onto motherboards so they are not portable. Like U2F, they also don’t let you sign arbitrary data. Incorrect! You can use TPM chips to RSA sign arbitrary data, and use that to authenticate SSH: https://blog.habets.se/2013/11/How-TPM-protected-SSH-keys-wo... Even under Windows: https://blog.habets.se/2016/10/Windows-SSH-client-with-TPM.h... The secret is using TSS_HASH_OTHER as the hash algorithm,…
Also relevant: https://developer.apple.com/documentation/security/certifica... and CryptoKit https://developer.apple.com/news/?id=3bwfq45y and https://developer.apple.com/documentation/cryptokit (Note that the Linux version of CryptoKit doesn't get any of the fancy hardware features, you'll need an Apple OS for them.)
Earlier quoted context omitted.
Usually people buy a second Yubikey, enrol both and have the second one somewhere safe. Most services and web sites also give you emergency login codes to print out, though.
For services where no admin can get your access back, like most websites, a 3rd factor should be a compulsory part of 2FA. There's a balance between keeping hackers out and keeping yourself out. The more factors you require, the more optional factors you should also require users to have, not just optional codes but "you must write these codes down, we'll check later to make sure you did" or something like that.
...which people will still not do, or misplace/erase due to disuse, etc.
Security and availability are always at odds with each other. The question that you should always have when choosing a level of security is "does the risk of denying everyone access --- including myself --- outweigh the risk of someone other than myself gaining access?"
Earlier quoted context omitted.
Unfortuately WebAuthn with the native keystores requires Bluetooth, which is a constant source of pain. That's a deal-breaker for me.
I don't think that's true. I just logged into my own WebAuthn implementation via my iPhone with an NFC security key. (Bonus points: the key was enrolled on my PC.) The server operator can choose to reject NFC, but the implementation/standard doesn't require that behavior. Edit: Actually, I don't understand your question. Are you trying to authenticate on a PC using your phone as the security key? If so, I don't know…
For a noob like me, I am thinking to get a Yubikey. What will happen if I lose my Yubikey? Am I essentially out of luck assuming the admins can’t reset my password or associated yubikey device? How do I prevent such scenario from happening? Is there truly a fool proof way of hardware authentication?
You can have other forms of authentication — PostIts with backup OAUTH codes, console passwords, root password etc — but those have to stay at home in the vault because a piece of paper in the outside world is too dangerous to lose.
You want both. You’ll lose your hardware keys eventually.
> TPMs are soldered onto motherboards so they are not portable. Like U2F, they also don’t let you sign arbitrary data. Incorrect! You can use TPM chips to RSA sign arbitrary data, and use that to authenticate SSH: https://blog.habets.se/2013/11/How-TPM-protected-SSH-keys-wo... Even under Windows: https://blog.habets.se/2016/10/Windows-SSH-client-with-TPM.h... The secret is using TSS_HASH_OTHER as the hash algorithm,…
Basically every site will offer to "never ask from this device again" and then I have a key that I haven't used in a long time.
Which, yes, I can use nothing but incognito windows, but that is too extreme and a single time I forget breaks it. Why can't I set it so that I need to use the key once a week?
Earlier quoted context omitted.
You can un-register any of the keys when you're logged in. So if you lose one key, log in using the others and remove it. No need for a master key.
Your idea works well for recovery. But I'm thinking of a revocation scenario, where a key is stolen. In that case the attacker can just remove your keys first.
If the hacker gets your key, and your password it's game over.
But hacking the password will take some time hopefully, and systems usually have retry limits etc. so if you discover your lost key, you hopefully have some time to revoke the lost key.
I personally would not use it for password-less login, as it is only good as a second factor.
If your threat model includes any real likelihood of people capable of stealing your keys and cracking your passwords, then 2FA is only a small part of the opsec you need.
Things like NSA's Zero Trust Security model comes to mind https://news.ycombinator.com/item?id=26549363
If you're at that level, you probably need specialist infra.
But potential compromises don't mean you're not less secure than before, Yubikey would still make you more difficult to hack.