11–20 of 31 posts
Everything looks great, except for bluetooth. Can't we use internet instead.?
Something like this https://m.youtube.com/watch?feature=youtu.be&v=YRL0u61dLnM
[0] https://www.buypass.com/?_ga=1.237154944.1017563517.14669318...
Reminds me of the Biometric Open Standard. Link to draft: official one is behind paywall https://www.oasis-open.org/committees/download.php/56664/P24...
> behind paywall
Anyone who's spent time in hotels in recent years knows that since switching from mechanical keys to magnetic keys, sometimes the keys break and the guest is locked out of their hotel room, which of course they never discover until trying to open the door. Then they have to go to the front desk, probably stand in line, and request a replacement key.
Using smart phones as authentication devices suffers from this exact same problem. I can't speak for iOS but every android phone I've had has experienced slow operation, crashes, and other kinds of issues at inopportune moments. When I am trying to log into something to perform a 5 minute task I don't want to be delayed for 15 minutes while my phone chugs away at whatever.
I'm just one geek, but I have spent a lot of time thinking about "alternatives to passwords". I have concluded the password is king. We use passwords everywhere, and we will continue to use passwords everywhere, until someone invents something better. In 100s of years nobody has done that yet (Mechanical keys are a kind of password).
Instead of trying to replace passwords which are reliable and simple to use, with complicated authentication systems which are not reliable and not simple, we should focus our efforts on improving password authentication in our existing apps (no more limitations), building great password tools like keepass.info, and encouraging the average user to use password tools and practice good password habits.
The dependency list is missing "Smart phone". Anyone who's spent time in hotels in recent years knows that since switching from mechanical keys to magnetic keys, sometimes the keys break and the guest is locked out of their hotel room, which of course they never discover until trying to open the door. Then they have to go to the front desk, probably stand in line, and request a replacement key. Using smart phones as…
This. 2FA or "tap to login" is all nice until the phone melts down and - by design - you (normally) don't even have backups, so have to use recovery codes. Which aren't always available.
> I have concluded the password is king.
What about the keypairs?
They are the same as passwords (when done right) - just long "random" strings of data. However, they don't have to be transferred over the wire for everyone to see. And they're more flexible in terms of possibilities on security-convenience spectrum.
There is no SRP standard for web (JS crypto doesn't count), but almost every TLS-aware system (client or server) out there has support for client certificates. The only problem is that browser vendors genuinely hate this (and want to shove users their own inventions), but if someone could somehow persuade them - it would just work.
The dependency list is missing "Smart phone". Anyone who's spent time in hotels in recent years knows that since switching from mechanical keys to magnetic keys, sometimes the keys break and the guest is locked out of their hotel room, which of course they never discover until trying to open the door. Then they have to go to the front desk, probably stand in line, and request a replacement key. Using smart phones as…
> Using smart phones as authentication devices suffers from this exact same problem. This. 2FA or "tap to login" is all nice until the phone melts down and - by design - you (normally) don't even have backups, so have to use recovery codes. Which aren't always available. > I have concluded the password is king. What about the keypairs? They are the same as passwords (when done right) - just long "random" strings of d…
Get a Yubikey and store all your OATH tokens on that, as well as your phone.
Earlier quoted context omitted.
> Using smart phones as authentication devices suffers from this exact same problem. This. 2FA or "tap to login" is all nice until the phone melts down and - by design - you (normally) don't even have backups, so have to use recovery codes. Which aren't always available. > I have concluded the password is king. What about the keypairs? They are the same as passwords (when done right) - just long "random" strings of d…
> 2FA or "tap to login" is all nice until the phone melts down and - by design - you (normally) don't even have backups, so have to use recovery codes. Which aren't always available. Get a Yubikey and store all your OATH tokens on that, as well as your phone.
Easier said than done. Import restrictions on any cryptographic devices in the country I live. :( Russian government genuinely hates civil cryptography.
Last news I've heard, late this spring, some company had managed to negotiate and obtain the necessary certifications and permissions, but they're still setting warehouses and logistics.
Thought of getting an ATECC508A or alike Secure Element IC and make a DIY HSM, but had no luck either. An acquaintance why runs an electronic component retail business said he'll try but these are rare find here, and usually out of stock.
(I wonder if there's a way to buy a Yubikey or Nitrokey token, visiting EU as a tourist... Customs probably won't care checking what some USB stick in luggage is - everyone has flash drives.)
The dependency list is missing "Smart phone". Anyone who's spent time in hotels in recent years knows that since switching from mechanical keys to magnetic keys, sometimes the keys break and the guest is locked out of their hotel room, which of course they never discover until trying to open the door. Then they have to go to the front desk, probably stand in line, and request a replacement key. Using smart phones as…
> Using smart phones as authentication devices suffers from this exact same problem. This. 2FA or "tap to login" is all nice until the phone melts down and - by design - you (normally) don't even have backups, so have to use recovery codes. Which aren't always available. > I have concluded the password is king. What about the keypairs? They are the same as passwords (when done right) - just long "random" strings of d…
Under what circumstance would that be considered normal, expected, or acceptable?
My phone just doesn't do that, and never has. Sure it crashes maybe once a month or so, but then I'm able to use it again within ~15 seconds.
I think that experience is mirrored by most people.
Earlier quoted context omitted.
> Using smart phones as authentication devices suffers from this exact same problem. This. 2FA or "tap to login" is all nice until the phone melts down and - by design - you (normally) don't even have backups, so have to use recovery codes. Which aren't always available. > I have concluded the password is king. What about the keypairs? They are the same as passwords (when done right) - just long "random" strings of d…
> until the phone melts down Under what circumstance would that be considered normal, expected, or acceptable? My phone just doesn't do that, and never has. Sure it crashes maybe once a month or so, but then I'm able to use it again within ~15 seconds. I think that experience is mirrored by most people.
Monthly crashes are no big deal (in fact, I think, my phone crashes only once in a few months). Slight nuisance at most - e.g. if the crash corrupts Android app cache and system boots awfully long minutes, re-compiling the apps. However, I have three different mobile devices (2 phones and a tablet), from different vendors (Nokia, Acer, Samsung) that had suffered a hardware failure after some (5-8) years of use. Three dead eMMCs.
So, I'm sort of wary. It's exceptional, infrequent but happens quite unexpectedly and is very frustrating when it does. Especially if the recovery keys (which are rarely accessed by design) are lost, inaccessible (you're on the road) or misplaced.
I have had support agents come to me and say, "This user was convinced to put his phone into developer mode and attach it to a computer running malware controlled by the attacker." Game over.
Okay, that is colossally stupid behavior. Unbelievable, to most of the audience here. But users will do the damnedest things, and platforms -- whatever their static security failings -- really need to be resilient against coerced or ill-guided user actions as well.
I've worked on platforms that have had very well designed security systems, but they also made very sharp distinctions between what could be done by a developer and a normal user, and for the most part those worlds did not intersect at all.
Android's barrier of "tap seven times here and you're a developer" is very low. It's clever, and good for many reasons, but user security isn't one of them.