Dmitry Frank, an embedded and systems programmer who writes about real-time kernels, C techniques, Go testing, and developer tools such as Nerdlog.
HN commenters cite his U2F token backup write-up as a practical method, and discuss his tabs-versus-spaces piece and Nerdlog's log-rotation limits.
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…
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.
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…
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
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.
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