I'm sure most of you have read about the "epic hack" of a (ex-?) Gizmodo employee this last week (http://www.wired.com/gadgetlab/2012/08/apple-amazon-mat-honan-hacking/). It's probably been discussed already on here, I just haven't searched for it. I don't want to discuss this particular hack so much (which is why I didn't search), but rather the implications with regard to Live ID (or Windws ID or what ever name it's getting with the rebranding of everything).
I bought into the Apple account system originally to buy songs at 99 cents a pop, and over the years that same ID has evolved into a single point of entry that controls my phones, tablets, computers and data-driven life. With this AppleID, someone can make thousands of dollars of purchases in an instant, or do damage at a cost that you can't put a price on.
Live ID has already grown to be much the same thing, but it's going to be much worse with Windows 8, where people use it to logon to their computers and control pretty much everything "in the cloud" surrounding apps on Windows 8, Windows Phone and even Xbox. The slogan should almost be changed to "three screens, the cloud, and one set of credentials". This is dangerous and scary, to be honest.
Microsoft needs to address the problems here. Two factor authentication is, I think, a minimum requirement. A solution like Google has already would be a good first step, but it has problems. The necessity to enter in a randomly changing numeric code in addition to your user name and password, and the things you have to do to manage applications (like e-mail programs) that don't understand two factor authentication, make it a pain to use. Any pain (aka friction) here, and you know most users won't use it, and thus are at great risk. We need to make two factor authentication easy and painless for users and developers. This means API support, OS support, software support (like web browser integration) and hardware support. Rather than having to type in those digits, users should be able to use bluetooth, NFC, USB and/or some other mechanism to quickly and easily provide this second factor.
At a minimum, I want to hear that Microsoft is providing some sort of two factor authentication in the very near future. I'd much prefer to hear that they are also trying to address the pain points of two factor authentication for the future... and hopefully are doing so in a way that can be standardized across the industry.
Charles, can we get any kind of feedback from Microsoft about this topic?
I did like what they showed in WP8 with a separate PIN being needed to use the wallet. I think a good way of doing it would be to just require a PIN whenever you wanted to do something related to finance.
Microsoft Accounts already provide the ability to log in via a one time code sent to your phone, which is a step in the right direction.
A pin is just a very insecure replacement for passwords. Not really worth discussing, IMHO.
I wasn't aware that Microsoft Accounts provided one time codes like that. That is a form of two factor authentication that's a step in the right direction, though I think Google two factor authenticatin (via TOTP) is better. However, either form has usability problems that mean people just aren't going to use them. I want to see that addressed.
Edit: actually, after having read about "one time codes", I'm not sure they could be considered two factor, and I honestly don't see how they add much security. The description (found at http://windows.microsoft.com/en-US/windows-live/sign-in-single-use-code) makes it sound like you can obtain the code without using your password. This means it's one factor, not two factor. You authenticate with something you have (your phone) instead of with something you know (your password).
@wkempf: I think the idea behind the one time codes is if you are signing in someplace you don't really trust, such as another person's computer, or on public WiFi.
@kettch: I get that, I just don't think it's a problem with a large need for a solution, and in comparison to two factor authentication does very little to make things more secure.
@wkempf: Right, it really only works for keeping your password off the wire, but the session can still be hijacked, etc.
Are you thinking like an RSA fob or something?
Since you mentioned this, I want to bring up another more serious "daisy chaining" issue - password recovery question.
You see... there's a lot of website providing similar question sets for user to recover their passwords. But AFAIK, while most of the companies stores passwords in encrypted form, more than a dozen of them I know of stores answers to such question in plain text. (So their CS staffs can read them and confirm customer identity on phone).
Remember the 2 big password database leaks earlier this year? What happens if the hackers target these questions instead of these (supposed) difficult to recover passwords?
What's worse? A lot of these companies happens to store the password recovery email address in plain text too! That means if you use similar password recovery questions in the email service you use to receive recovery password, the hacker would know what "question and answer" to use for breaking in that email account.
If you happens to be a developer maintaining such systems, please be sure to at least do some basic two-way encryption to them, or in one of the next waves of network attacks your company would have embarrassing moment. Thank you for your attention.
Nothing to do with the topic title other than Live ID, but I personally, and others I know, think it was a really bad move to incorporate Live ID into Windows at all. For the App Store fine, but not for a Windows login, and the phone number... don't get me started. Luckily you can still create users from Computer Management, but I think this was a major step backwards IMO.
We can debate incorporating Live ID into Windows, but I'm not sure it's that relevant. Yes, it's yet another escalation, but the simple fact is, we've already escalated beyond the point of our ability to be secure. Most of our information is moving online. This has meant the need to secure hundreds, if not thousands, of sites for most people. Dealing with that many passwords is simply not possible, so people looked for other solutions. The easiest thing to do is reuse your password everywhere and to "daisy chain" services, both of which lead to very bad security vulnerabilities. The next thing we've done is "single signon" solutions, which is only marginally more secure, and due to daisy chaining most people are still left very vulnerable.
Two factor authentication is a very simple way to making all of this more secure again. Heck, with two factor authentication you don't even have to store the password (one of the factors) anywhere, ever, totally eliminating one attack vector. The only problem is that using two factor authentication techniques is cumbersome for end-users at the moment. So much so, that most won't use it. What I'm pointing out is that that is a problem that's not difficult to solve... we just need an easy way to provide the second factor (bluetooth, NFC, USB, WiFi, etc.) rather than transcribing a code via the keyboard. With OS and software support you can make it even easier... never prompting the user again after they've logged on once.
@DeadX07: It seems like it's a pretty solid feature to me. It's a guaranteed way to make sure that a user's services are going to Just Work. I've got five Windows 8 machines, and with each one, there's been almost zero configuration. Just log in and everything's there. Machine dies? Move on to the next and you're back up and running with little down time. I just wish there was a way to batch-install (Not)Metro apps when you move between machines.
@wkempf: A NFC/Bluetooth/WiFi enabled phone app that generates the key would work for me. Say, when your Microsoft account detects a login attempt, it would send a request to your phone and you could either bring the phone within NFC range of your tablet or the phone could wake up and communicate directly via Bluetooth or WiFi, or even just prompt you: "Your credentials are being used to sign in from <Computer Name>, do you wish to allow this? Yes/No".
Maybe multiple levels of prompting. For all events such as login, Store purchases, Wallet transactions or any combination thereof.
@kettch: There are devices available today, such as the YubiKey (http://www.yubico.com/yubikey) that take a simple approach. The problem is that they aren't integrated in the system, and so still provide enough friction as to cause most users to not be interested. The OS and software have to know about these two factor devices in order to remove this friction. Here's the UX necessary for users.
Sit down at your computer, where you're prompted to logon.
Tap your "key device" (phone or other device, doesn't really matter) for NFC, plug it in, let it communicate wirelessly or what ever. Details here aren't critical so long as what has to be done is easy. This would provide the users identity and a digital key (TOTP or otherwise... I'm not an expert on the best way to handle security here, I'm focusing on the UX problem).
The OS then prompts for a password (the second factor).
Authentication magic occurs and from that point on the OS knows who I am and has everything it needs to verify me for any other service. If I browse to my bank account the OS should have enough information already to identify and authenticate me, so I wouldn't be prompted again.
I'm not a security expert, so I can't give you the details on how best to implement things behind the scenes, but I know enough to know this is possible. The password and digital key on the hardware device (something I know and something I have) can be combined into a single key for encryption. By using a public/private key on the hardware (the system would be like SSH in this regard) and handshaking protocols it should be possible to make all of this (the initial logon and any subsequent authentication with other services) doable without ever storing a password anywhere. So you get all of the following benefits.
No password storage anywhere, so you never have to worry about stolen passwords. (Public keys would need to be stored, but those can't be hacked like passwords can.)
Two factor authentication, making it very hard for hackers to use social engineering or other tricks to gain access.
Usage is nearly as simple as today, but we get a truly universal single signon.
It's not full proof. There are attack vectors... I'm sure the security experts could point at several ways in which this could be attacked. However, it seems like this has to be more secure than what we have today.
@wkempf: Indeed. Once you add a third party device, the amount of effort people are willing to go to diminishes drastically. Right out of the gate, you'd need to provide phone apps for as many platforms as possible or at least WP, iOS, and Android. Then there's the problem of making sure that a malicious app on the device couldn't compromise the authentication app in some way.
A phone app would be nice, but cuts out a lot of people. A cheaper YubiKey sort of USB device might work better. Of course, ideally you'd support multiple hardware solutions. $5 USB devices, phone apps that communicate with bluetooth, NFC and/or WiFi, watches using NFC, "dog tags" using NFC, pretty much anything and everything you can think of. Just define standard communication protocols and let the OEMs and software developers loose.
The average person doesn't understand the security issue and would view using a secondary auth method to be a hassle. Especially when they just want to log in to Windows to play a game or check Facebook.
Does it even matter, if most people's passwords are "password" or "12345"? Does it matter if people are falling for the fake anti-virus malware popups? I think hackers would be much more productive if they simply sent out an email to all Hotmail users and said "Microsoft will deactivate your account in 7 days unless you reply. Please reply with your login info to keep your account active."
Finally, the Gizmodo employee wouldn't have been hacked at all if Apple support hadn't reset his password over the phone. The blame lies entirely on that Apple tech support employee.
I think the issue really is broader than just what authentication method is used. That incident demonstrated a cavalcade of fail, both on the part of the user and the companies involved. From the weak verification methods used by Apple to recover an account, to the fact that the user had software installed to "find" his various Apple devices, including his desktop, and that software allows you to remotely wipe them with no additional authentication required.
Regardless, the simple reality is that the more complex you make any authentication scheme, the less likely it will be used. And ultimately, the real weak link in the chain was a human being: an Apple employee who granted access to his account even though the person making the request could not answer the "secret" questions.
I don't care how many authentication steps you add or what security devices you use, nothing will protect you from the abject stupidity of another human being who has access and control over your data. And that's exactly what the situation is when you drink the Kool-Aid and put everything in "the cloud". You are abdicating responsibility for your data to a third-party over whom you have no direct control and no ability to verify that they even follow the very policies they claim will protect your information.
When it comes down to it, most of the methods mentioned in this thread are good, and could work. We could all pick one or two that would work for us personally. If there were options, then people could at least have something. The people who are too lazy will stick with passwords, and the rest of us can use another method. If somebody can't be bothered to take their security seriously, then I can't be bothered to care.
Don't focus too much on the current case. It's not only Apple's fault, it's also Amazon's and as the author freely admits, his as well. Plenty of blame to go around, and plenty of failure points as well. What I'm suggesting isn't a way to fix all of those failure points. I wasn't trying to fix any of that. In fact, about the only thing about what I'm talking about that would apply is that Apple probably wouldn't have been involved or able to screw up this badly, because they wouldn't be doing the authentication.
That's not really here or there, though. The problem is simply a problem with passwords. They aren't safe anymore, mostly due to human nature/psychology, but also partly due to the connected nature of the internet, where passwords are stolen so easily now. The answer thus far has been a "single signon" answer (OAUTH), but I think that's actually just putting us at more risk. If we are going to have a single signon, ensuring that authentication mechanism is secured is more important than ever, and that's what two factor authentication does.
As for "drinking the Kool-Aid" and putting all of your data in the cloud is concerned... that's missing the point. I have control over what data I put there, and whom I trust it with. However, if we're relying on a single signon solution to the problem of password management (and with many services now, and more in the future, you have no choice there) there's too much bleed-over. Sites/services I trust with some data can now compromise other data that I didn't entrust them with. So unless you're going to take the stance of putting no data at all in the cloud (yeah, right), there is reason to want a more secure and user friendly solution.
Except that the real failure point (in this particular case, and generally) is in recovery. It doesn't matter what technology you use, if there is a human being involved in the process of being able to recover access to an account or reset credentials, that process can be exploited. We are the weakest link. I would also argue that the stated goals of any authenication process being more secure and more "user friendly" (or frictionless) are diametrically opposed to one another, at least for the immediate future.
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.