3 ms·
The cons about 2nd-U2F device seem rather odd. Several boil down to "houses aren't secure", but the primary attack vector for the vast majority of users is not
by akerl_ 8y ago
The cons about 2nd-U2F device seem rather odd. Several boil down to "houses aren't secure", but the primary attack vector for the vast majority of users is not physical invasion or destruction of their home. Similar concerns are raised for recovery codes.
For OTP, calling it out as "non-universal" seems strange: far more services support TOTP/HOTP than U2F at the moment, so for most users, even if they use U2F everywhere it's available, they'll still end up with a pile of TOTP codes on their phone.
The proposed solution is even more strange: it still recommends storing the 2nd token at home, but offers to solve registration of new services while abroad. No solution is provided for improving recovery beyond just using two U2F tokens.
- dimonomid 8y agoI don't know what makes you miss the point, but ok, let me repeat. With the regular second U2F device it has to be easily accessible (e.g. at home in my sleeping room). With the proposed solution, it doesn't have to be easily accessible. > it still recommends storing the 2nd token at home In the article I mention that I can either bury it somewhere in the forest or brick up into the wall. Even if we ignore the forest part, do you consider "bricking up into the wall" and just keeping in sleeping room as the same thing, even it's my home's wall? If you do, then ok, sorry for wasting your time, we're not going to agree. Because I believe that making the token really hard to access (like having to disassemble the actual wall a little bit) does make the token a lot more secure. And another important point that with the regular token I have to add it to every new service manually. Which can be not trivial if I'm traveling far from home. And I can just forget, etc etc.
- akerl_ 8y agoIf someone is in my home looking for my U2F key, they've bridged the gap between the threat model I'm concerned with and the model where they're clearly motivated enough that putting the key in brick isn't going to stop them. Furthermore, I don't really like the prospect of having to take a sledgehammer to my wall when I drop my U2F key during a trip. Personally, I have a couple U2F tokens and OTP on my phone, with recovery codes. If I register for a new site when I'm on the road, it gets my travel U2F and phone OTP. When I get home, I pair up the 2nd U2F and drop the recovery codes in the box with the rest of them.
- dimonomid 8y agoFirst, 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 anyone that you have a token in the wall, so even if they came specifically for the token, they can surely look for it in your home (because the majority of people store backup token just at home), but it's a lot less likely that they start break walls (unless they specifically know it's there). So here, the level of security is up to the token owner. As to having to take a sledgehammer: well, losing a token is an emergency situation and I just try hard not to lose it. But if I do, I still have a way out, and breaking a wall a little is still a lot better than losing the access to my accounts.
- nickray 8y agoYes, the vast majority of users just worry about losing or breaking their U2F token. Such a user just wants to be able to log in and replace credentials. The proposed solution, which I find surprisingly elegant, in comparison to regular two tokens offers ease of use: avoiding registering a second token everywhere (and possibly the invalidation of the lost key at first login). Compared to the usual TOTP fallback, it keeps the phishing protection.
- dimonomid 8y agoThanks. 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't mean everyone does the same), or something else?
- nickray 8y agoYes :) Personally, I would just start replacing credentials upon loss in descending order of importance.
- dimonomid 8y agoYeah 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.