4 ms·

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 he

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've done it's so insecure", but then realize that I already thought about it and still decided to use that strategy because of this, this and this. In fact I really appreciate you explaining all these details, and to be honest I need to find a decent amount of time to fully wrap my head around it; hopefully on the weekend I'll be able to. I doubt it will change my reasoning about my personal use case, but learning something new about security is never bad. Thanks for that! Hopefully I'll get back to you after learning more. Also wanted to make 100% sure: are you arguing just about the u2f-zero being insecurely implemented, or the whole concept of backup with the cloned and securely-stored token also being bad? If we imagine that e.g. yubico starts producing matched pairs of tokens (I doubt it would, but still let's imagine), primary and backup with the boosted counter, which are implemented securely enough etc - would it be still bad in your opinion?

jiveturkey 8y ago
Diagrams help me. They do wonders to organize the thought process down to the most core ideas and cement it in your mind. I have planned to try "mind mapper" software to help with it but haven't done so yet. If you produce some kind of diagram I would be happy to review it with you. > are you arguing just about the u2f-zero being insecurely implemented, yes. the concept of a pre-cloned token is a good one. 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. you need to revise your threat model or revise your solution.
- 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 it could get hacked, but that I could just lose it together with my u2f token (because, you know, I always carry both phone and u2f token), and thus get myself locked out of my accounts. So it's not about somebody attacking me specifically to get my 2fa data, but just about some bad luck happening which results in losing both u2f token and a phone which was a backup for u2f token. Instead of Google Authenticator we could use Authy, which synchronizes its database with the server, but Authy account could be recovered with SMS, which is anything but secure. I actually updated the article just now with that point. I really want having a backup which is rock-solid secure and reliable, you know, more reliable than any other 2nd factor I have. So having a token bricked into the wall or something like that would work. > you need to revise your threat model or revise your solution When I have a chance to reimplement the same backup concept having something more secure than u2f-zero, then yeah I surely will revise the solution.

jiveturkey 8y ago

Diagrams help me. They do wonders to organize the thought process down to the most core ideas and cement it in your mind. I have planned to try "mind mapper" software to help with it but haven't done so yet. If you produce some kind of diagram I would be happy to review it with you. > are you arguing just about the u2f-zero being insecurely implemented, yes. the concept of a pre-cloned token is a good one. 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. you need to revise your threat model or revise your solution.

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 it could get hacked, but that I could just lose it together with my u2f token (because, you know, I always carry both phone and u2f token), and thus get myself locked out of my accounts. So it's not about somebody attacking me specifically to get my 2fa data, but just about some bad luck happening which results in losing both u2f token and a phone which was a backup for u2f token. Instead of Google Authenticator we could use Authy, which synchronizes its database with the server, but Authy account could be recovered with SMS, which is anything but secure. I actually updated the article just now with that point. I really want having a backup which is rock-solid secure and reliable, you know, more reliable than any other 2nd factor I have. So having a token bricked into the wall or something like that would work. > you need to revise your threat model or revise your solution When I have a chance to reimplement the same backup concept having something more secure than u2f-zero, then yeah I surely will revise the solution.