Dmitry Frank

With a sufficiently programmable hardware key, yes, you can back up the secrets. See an enumeration of methods in [0]. Be careful if you plan on doing this; make sure the tradeoffs make sense to you. You probably want to do the programming from an airgapped, trustworthy Linux machine. Beware that if you do this and lose your primary key, or if it is stolen, then an attacker can impersonate you. Setting up multiple unique keys is probably more useful in general, even if it's more cumbersome. [0]: https://dmitryfrank.com/articles/backup_u2f_token

In principle, there is a way for you to have U2F backup keys. Here's a great write-up https://dmitryfrank.com/articles/backup_u2f_token The basic idea is to have two U2F devices with with the same device_secret but one of the devices (the backup) is pre-programmed to add a large offset to the so called counter value. Upon login the service must check the counter value and ensure that the received value is greater than the one it's seen previously. If you happen to lose the first key, you can use the second key to log into all of the affected online services and upon doing so, the service would accept the new larger counter value and thereby invalidate the lost key.

By the way, as an author of the article, I'd like to ask the HN community to send me an invitation to Lobsters: I want to be able to share my publications there as well. Before deciding whether to send an invitation, you might want to check other articles on my website ( http://dmitryfrank.com ). Thanks.

One of the main drivers for spaces is alignment, which you should never attempt to do with tabs (except in contexts which normalize tabstops, which generally excludes programming). Aligning within a line can and should be done with spaces. There's good reasons against alignment in such cases -- for example, it creates git blame/git diff noise when reformatting due to having to update alignment on a bunch of other lines just because you introduced a variable one character longer than the others. Irrelevant, though; such alignment is perfectly fine to do with spaces in a context where you indent with tabs. The other type of alignment is beginning-of-line alignment, which is indeed not doable with spaces. Some people recommend doing such alignment with spaces despite the tab indent (cf. http://dmitryfrank.com/articles/indent_with_tabs_align_with_spaces). It's a valid argument but I feel it's too much of an aberration to be taken seriously. I personally find such alignment generally repulsive anyway. Take a look at the following code and tell me which method looks better: http://sprunge.us/ZFHJ Too many times have I seen such function calls where the space between the parenthese and the soft wrap leaves <10 characters to work with. And here we go with one small argument per line, every argument preceded by 70+ spaces. I know programmers who could fit video games in the bytes used for just a single function call like that.

I definitely intend on playing around with this later! I see that [gzipped log archives aren't supported](https://dmitryfrank.com/projects/nerdlog/article#depends_on_the_log_fi… minimizing the use case for me personally. You've at least thought enough about that to bring it up as a limitation you think people will call attention to -- any plans to eventually support it?

> We're still getting users that want hierarchy though. I'm not sure what I want to do here. Have you considered hierarchical tags? As an example: https://dmitryfrank.com/projects/geekmarks/article I use it for my bookmarks, and I find it is a suitable balance between having some kind of hierarchy, while allowing for resources to be classified under several categories.

"Indent with tabs, align with spaces" (e.g. [1]) would be my strong preference in a perfect world. In addition to its "ethereal" benefits, some languages which support HEREDOCs have nice "tab ignoring" versions (e.g. <<-). That said, in the imperfect world we live in, I always use spaces. "Indent with tabs, align with spaces" is obviously not rocket science, but its just too opaque unless you have a strong code review process. [1]: https://dmitryfrank.com/articles/indent_with_tabs_align_with_spaces

re: your thread. Today the backup practice is to enable 2 keys in all accounts: one that you keep with yourself, the other that you leave in a safe. There's been some experiments of creating copies of the master secret, e.g. [1]. Today you can do so either w/ u2f zero or with its upgrade solo hacker (note the hacker version), but we currently don't support it officially. My personal advice as of now is to always have security key(s) + totp code. The security keys protect you against phishing, so if you click on an email link and get prompted for login, you're either safe (if you use the security key) or at least reminded about the risk (if you're used to use the security key but you don't have it with you at the moment). Viceversa, if you're directly logging into a website and you typed the url yourself, then totp offers the same security, so it's a totally valid alternative. Hope this makes sense. [1] https://dmitryfrank.com/articles/backup_u2f_token

We played with RIOT for a couple of months. For our current product, (and I would think a lot of IoT apps), power is king. We run on batteries, and getting back to idle/low power states as often as possible is crucial. I've found that a lot of the embedded RTOS often have tickless modes as an "add on." We had problems getting RIOT to a happy point with that for our chip (samd21). Like some of the other commenters, I've grown a real distaste for embedded RTOS frameworks that try to provide all kinds of layers. In order to be generic/cross platform, they always come up short in capability. The functionality that I'm looking for, is simply getting the basic threading/sync primitives to work well and right. Past that, I'm fine doing the chip IO parts myself. At the time, there was a debate on whether priority inversion was a problem RIOT should worry about or not. After FreeRTOS, and then RIOT, I found TNEO (https://dmitryfrank.com/articles/how_i_ended_up_writing_my_own_kernel)… It's been a dream and rock solid for us. It does not come with a large make/build system. It's just C code. You tweak a couple of things, include one or two bits, and I was off to the races. Coupling it with Unity for testing and then writing ~200 unit tests that stressed all of its functionality was straightforward, helped me understand it even better, and gave me a high degree of confidence in its abilities. It's been super solid for us since. It does the one thing I need it to: MicroKernel for…

USB/NFC tokens and phones/computers are all "loseable". There are cool ideas about backup tokens https://dmitryfrank.com/articles/backup_u2f_token but IMO they can't be the only way to sign in, there should be some way to restore access from nothing (I guess my specific paranoia is about being locked out :D) There are many specific auth "factors": - valid signature from an extrernal hardware token (U2F/WebAuthn via e.g. YubiKey) - valid signature from a device's embedded token/TPM (something like Touch ID / Windows Hello / Android keystore thing) - … as a WebAuthn implementation - … in response to a push notification on another device (Twitter, if they still have that) - … in response to a QR code (SQRL, Yandex.Key) - one-time code via push notification to another device (Apple) - one-time code generated from a shared secret key (TOTP) - one-time sign-in link via email (Tumblr) - passwords - secret questions (like extra passwords but worse) - behavior pattern analysis (IIRC Google showed an Android demo that looked at keyboard typing patterns and whatnot) A good auth system should combine multiple factors in a correct way to minimize both impersonation and lockout chances, and maximize usability. How? That's the challenge…