Slashdot Mirror
The Internet of Things Is the Password Killer We've Been Waiting For
jfruh writes: You can't enter a password into an Apple Watch; the software doesn't allow it, and the UI would make doing so difficult even if it did. As we enter the brave new world of wearable and embeddable devices and omnipresent 'headless' computers, we may be seeing the end of the password as we know it. What will replace it? Well, as anyone who's ever unlocked car door just by reaching for its handle with a key in their pocket knows, the answer may be the embeddable devices themselves.
This is one of the rare cases where the title doesn't ask the question, yet the answer is still no.
ANd if they want to use their account on multiple devices? On their actual PC? On a PC at a firend's house or library?
And email recovery- laughable. If they lost their phone, which was almost definitely logged into their email, then they've lost everything.
Please name your apps, so I can be sure never to use them.
I still have more fans than freaks. WTF is wrong with you people?
halfway through the article...
[ Don't miss: Welcome to the Internet of Things. Please check your privacy at the door. ]
Anons need not reply. Questions end with a question mark.
Just implant yourself with an RFID tag. As a bonus, it will also reduce the chance that a surveillance camera misidentifies someone as you.
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
In the sense that both 'the internet of things' and 'passwords' can be described as "an egregiously maldesigned and actively user-hostile security clusterfuck; typically bodged together by people who don't know, don't care, or both", I suppose that 'IoT' would be a worthy successor.
In all other respects, what a load of tedious, meandering, bullshit to arrive at some vacuous generalities about a vaguely described non-solution.
Look if your phone gets malware or MITM and skims the logon normally, you're boned. You're boned in many ways since if you have malware you probably have a keystroke logger too. Yet this passwordless style won't ever let them know how to log onto your account. This is no different since your login/password phase of authentication is the same. In fact with the server giving you a quite long randomized password its better than someone's recycled password they use on every site.
If you don't enter an email and verify it, yes, you lose everything! This is why you enter your email and verify it, gain some virtual currency for completing the task. The thing is, it won't prompt you for this for about 10-30 minutes in since you don't have anything worth saving anyway, and no one wants detracted from seeing if the game is cool or not.
God spoke to me
With all the security available in device operating systems, there are better ways to do this:
When the app is created, have it generate a public/private keypair, store the private key in the OS's keystore (called KeyChain in both iOS and Android.) Then, on first authentication to the servers (you are using SSL/TLS for all communication, right?), the central server will store the device's public key's fingerprint. From then on, it functions like a client certificate, and can be optionally used with an app's PIN function for added security.
The benefit of this over a shared secret? Someone hacks the server, a list of key fingerprints will do an attacker no good to authenticate against (because they don't even have the key material that the fingerprint shows), and can be added/deleted per device. With iOS's and Android's keystore functionality, if the device is locked, the keystore is encrypted and inaccessible, providing another layer of protection on top of encrypting /data.
To the user, it functions exactly the same, but it is a lot more secure in virtually every way. The only way it would be less secure is if RSA or the public key algorithm in use was completely broken.
As for bans, you can easily do what Yik Yak and other apps do -- grab the IMEI (if available) and other serials (UDID), and ban by that. Then, even if the app is uninstalled, the phone is still blacklisted.
This is the right basic idea, I think, but I think everything will converge into a single device, either the mobile phone or a wearable. And as it becomes more and more central to everything we do, that device will become very smart about authentication.
The problem with using dedicated embeddable devices is twofold. First, the more of them you have to carry, the more difficult it is to keep track of them. With old-fashioned metal keys we've solved this with the key ring... but that creates its own problem. The more keys you add to it, the more valuable it becomes. Loss or theft become increasingly more problematic. And our metal keys open fewer, and less important, things than our electronic authenticators do.
So, it makes sense to combine the electronic keys in a single device, but then to use the capabilities it has that metal keys do not to solve the theft and loss problems. First, against loss, there must be a way of backing up all of the credentials, securely and automatically, so that in the event the device is lost they can all be recovered relatively easily. Some sort of remote server backup, to which you authenticate with some other mechanism that you protect very carefully (there are lots of options here, but a long, randomly-generated password printed out and stored in a safe place is a good option). That backup needs to be reliable and reliably accessible, but access need not be easy or convenient, since it should be rarely needed.
What about theft? This is where the smart device has huge advantages over dumber devices, because it can authenticate the user. This authentication needn't be particularly strong, but it should have good anti brute-force protections, and it should be smart. The goal is to make something that is extremely convenient for the user, but makes it relatively unlikely that someone else who gets it can use it. How could that work? Google is pushing towards this vision with Android Smart Lock features. The core idea is that the device shouldn't rely on a single signal, because that signal then has to be very strong.
It's worth looking at analogies with meatspace facilities that care a great deal about security. What they don't do is put a bank vault door on the exterior wall and rely on the strong combination lock to keep thieves out. Instead, they rely on layering of defenses, monitoring and active response.
What can your phone do? Quite a bit, probably. Not only does it have a touchscreen for entering passwords, it also has cameras, an accelerometer, GPS, various radios, compass, altimeter, microphones, a proximity sensor and probably other stuff I'm forgetting. In addition, it can know a lot about your habits, your plans (e.g. what's on your calendar) and more. With that wealth of signals, it should be possible for the device to determine with relatively high certainty whether or not it is still in your possession. Where it's uncertain, it can fall back to asking for authentication with, say, a fingerprint or simple PIN to increase its certainty. Or in more extreme cases, it can fall back to an even stronger password. The idea is to make authentication as seamless, transparent and automatic as possible... but as strong as necessary.
Or maybe a smart watch will be a better choice. It has pretty much all the same capabilities as a phone, but the advantage that you strap it to your body, making it harder to lose, and harder to steal. (Actually, I think over the next few years for many of us our phones will migrate onto our wrists; right now the smart watch is an extension of the phone, I think that will flip, with the handheld device becoming an extension of the watch providing a larger screen, aimable camera, etc.).
The "as strong as necessary" bit is important here, too. When the phone is going to use a stored authentication key to unlock something for you, the degree of certainty that it needs to have that you're you depends on what it's unlocking. If I'm using my phone to log me into slashdot on my laptop, I really cou
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Of course, I am leery of the next step above this... having to wait for an ad to play on the fridge before I can open the door, having to pay the stove manufacturer $29.99 a month so I can use the self-cleaning settings, finding my faucet won't turn on because it lost connection with the cellular tower as the telco dropped GSM for pure LTE, getting fined by my HOA because the freezer detected more than the alloted moving things via its camera in the house, and so on.
Then, there is the security nightmare. Think those IoT providers will pay more than lip service to ensuring their devices are not easy prey? Won't happen.
Finally, there are the higher prices. I don't feel like paying hundreds of dollars for a thermostat, or thousands of dollars for a fridge because it is "smart". If I wanted to pay top dollar for a fridge, depending on availability, I would get a propane or natural gas fridge, so my stuff stays cold even if there is a power outage.
If phone makers (and phones are not cheap items) in general won't provide updates for more than a version or two at most, then I doubt IoT device makers would provide much, if any, about updates.
IMHO, the best thing about IoT is to just say no.
There are ways to design IoT devices securely (for example, having them use a hardened, central hub that handles the communication through the Internet, so attacks on individual devices end up having to be physically local), but since IoT is such a "fad", security is at best an afterthought after the product design is rushed out the door, so I expect zero security whatsoever.
Dude, he's not running a f*cking bank. He's obviously talking about a system for some phone toy like Angry Birds. Do you care if I can get into your Angry Birds account? Probably not much.
He's describing a system that is good enough for phone toys and things that require similarly low security. Like apparently Slashdot, which lets you perma-login with a browser cookie and redirects https to http rather than the other way around.
vi ~/.emacs # I'm probably going to Hell for this.