dimonomid

10 ms·

61.
by dimonomid 6y ago
The yet another external dependency is way more than Now() though. Mocking just Now() is trivial, but most of the time it's by far not the only function which I personally use from the time package.
62.
Mocking time and testing event loops in Go(dmitryfrank.com)
2 points by dimonomid 6y ago|0 comments
63.
by dimonomid 7y ago
Meanwhile here's a real way to disable it right now: https://github.com/kfahy/slack-disable-wysiwyg-bookmarklet/ Thanks a lot to Kevin for sharing that, you're savior.
64.
Android intentionally delays Gmail notifications(reddit.com)
5 points by dimonomid 7y ago|0 comments
65.
Would injecting my key material in FIDO authenticator undermine its attestation?
1 points by dimonomid 7y ago|0 comments
66.
by dimonomid 8y ago
> you won't notice that i have gained access. If I lose my primary token, how can I not notice that? I look at it a few times per day, and I use it not rarely either, so I can't see how I can not notice if I lose it (even if it
67.
by dimonomid 8y ago
> in short, MCUs are not secure devices I doubt there is 100% secure device, you know, it's all about tradeoffs. Given enough time and resources, nearly anything can be hacked. By the way, if an attacker has gained physical access t
68.
by dimonomid 8y ago
> you can just sniff the i2c bus to learn the keys RMASK and WMASK, which smelled not useful to you, are there exactly to prevent this from happening.
69.
by dimonomid 8y ago
> my main point of contention with you is that in your threat model, a lost phone is a security problem, yet a lost u2f is not I realized that I could explain my concerns better in the article. My biggest issue with the phone is not that
70.
by dimonomid 8y ago
I apologize for being inconsistent in my arguing; indeed, I "switch tack". That's because it's actually hard for me to constantly keep the full picture in my head, and sometimes I start thinking like "omg what I&#x2
71.
by dimonomid 8y ago
First, I agree that there certainly are ways to do that more secure, like generate keys on-chip so that nobody knows them, but as I mentioned, together with security we have to think about a good recovery plan, otherwise one has to come up
72.
by dimonomid 8y ago
I'd actually appreciate if you could elaborate on this. Which features of ATECC508A are not used, but should be used to make the whole thing more secure?
73.
by dimonomid 8y ago
Thanks! Yeah Conor mentioned that to me; I think the real benefit (at least personally for me) would be not being able to buy pre-made matching pairs of tokens, but being able to easily write my own key material plus the counter boost value
74.
by dimonomid 8y ago
> The primary device contains the key, that the attacker can possibly extract and use, setting any arbitrary counter he/she wants. Again, not saying it's impossible, but with the existing implementation, it takes considerable a
75.
by dimonomid 8y ago
> An attacker in possession of the primary device can increment the counter, making the primary still working In the article I explain how to make it impossible to just "increment the counter" of the primary token, see this sec
76.
by dimonomid 8y ago
Ok cool, so whenever you register on a new service, you have to add all 4 of them, which means going to "other safe places", picking tokens, adding them, and placing them back. Also I doubt your safe places are as safe as bricking
77.
by dimonomid 8y ago
Yes sure, once the primary token is lost, the backup should be used to login into all of the services we used the primary one for. But it's not worse than if we had a regular U2F token as a backup: we'd have, again, to login to al
78.
by dimonomid 8y ago
I'm not sure if you've read the article. > If the primary is lost or stolen, the key should be invalidated Exactly. > and thus the backup device is useless. The article mentions multiple times that the backup is set up in su
79.
by dimonomid 8y ago
> Once you attack the device, it's absolutely trivial to use any counter value you care to, not at all connected to the (yes, secure-enough) counter internally stored in the ATEC5508A. Could you elaborate more on that? How exactly I
80.
by dimonomid 8y ago
Yeah sure, I mentioned in the article that the purpose of the backup is to enroll a new token and revoke the old one. It would be a bad idea to keep using backup for a long time anyway.
81.
by dimonomid 8y ago
Thanks. What do you mean by "possibly" though? > and possibly the invalidation of the lost key at first login Do you mean that some service might disregard the counter value (the fact that Google and Github respect it doesn&#x2
82.
by dimonomid 8y ago
No, of course not. In backup, we basically use this as a counter: `hardware_counter_value + 2000000000`. We don't care that `hardware_counter_value` cannot be larger than `2097151`; the value we use for calculations is 32-bit, so effec
83.
by dimonomid 8y ago
I just realized that there IS a reliable solution to this issue with the counter. Accordingly to ATECC508A datasheet, its counters can count only up to 2097151, but the whole range of U2F counter is 0xffffffff (which is more than 4 000 000
84.
by dimonomid 8y ago
> No site is doing anything useful with the counter. What do you mean? In the article I mentioned that at least Google and Github refuse to authenticate if the counter is less than the last seen value. So using backup token does invalida
85.
by dimonomid 8y ago
> The ATECC508A is not used correctly. It is used as a RNG and for it's crypto functions, but not for key storage. Where did you get that idea from? Preparing a device consists of the following steps: - Flash temporary configuration
86.
by dimonomid 8y ago
Ah ok, I see what you mean. So can we use the PKI solution today to use as a second factor for, say, Google?
87.
by dimonomid 8y ago
First, if the token is easily accessible, then they can steal it even if they don't actually look for it. Like, steal "accidentally". Second, obscurity here is an important part of the security: you don't have to tell an
88.
by dimonomid 8y ago
> Having a duplicate of the U2F key is a bigger problem for security than those outlined here. So, what security problems come to your mind if we consider a duplicate token buried at 1 meter somewhere in the forest (and nobody really kno
89.
by dimonomid 8y ago
Not that I'm aware of. I wrote to Yubico and surepassid, both said it's not possible.
90.
by dimonomid 8y ago
There's no easy way to increment the counter, so one would have to invent some automation for sending authentication challenges to the token and pressing the physical button every time. The time it'd take should be enough for me t

More ›