Apple really needs two passwords, not one for everything(martijnpannevis.nl)
martijnpannevis.nl
Apple really needs two passwords, not one for everything
http://martijnpannevis.nl/blog/2012/12/10/apple-really-needs-two-passwords/
26 comments
There are better ways to do "two factor authentication" than TOTP/HOTP, if you control the client device.
Apple could much more properly do something with embedded keys on the iPhone (and next-gen Macs), in addition to passwords, email, and KBA. I'd consider it acceptable if Apple restricted some actions to Apple client devices, if you've got an apple client device registered, at least as an option.
Twitter is unforgivable, though. They have a fucking mobile client and are pushing that hard (at the expense of their developers). They are fairly neutral and non-hated by both Apple and Google (and probably Microsoft and RIM too). They are pushing Twitter logins to services. They borged one of the best cryptographic software developers (Moxie). They have users in places like Syria where compromise of an account can lead to torture and death.
It would be so obvious to turn the Twitter mobile client into a key management app and security tool, both for Twitter and for services using Twitter login.
(Facebook could do the same, modulo some hate from Google and Apple).
Apple could much more properly do something with embedded keys on the iPhone (and next-gen Macs), in addition to passwords, email, and KBA. I'd consider it acceptable if Apple restricted some actions to Apple client devices, if you've got an apple client device registered, at least as an option.
Twitter is unforgivable, though. They have a fucking mobile client and are pushing that hard (at the expense of their developers). They are fairly neutral and non-hated by both Apple and Google (and probably Microsoft and RIM too). They are pushing Twitter logins to services. They borged one of the best cryptographic software developers (Moxie). They have users in places like Syria where compromise of an account can lead to torture and death.
It would be so obvious to turn the Twitter mobile client into a key management app and security tool, both for Twitter and for services using Twitter login.
(Facebook could do the same, modulo some hate from Google and Apple).
If you control the client device, it's not really suitable as a second factor in a two-factor authentication system.
To elaborate: on a PIN debit payment, for example, there are two factors - something you have (the debit card) and something you[1] know (the PIN). In the case of authorizing the purchase of an app, you obviously have physical access to the device, or else you wouldn't be able to get to the checkout screen. For an actual second factor in a MFA scheme, it would be necessary to have a _different_ device that only the user with authority to make a purchase would have access to.
One could argue that if the device is PIN-locked, this is sufficient; however, in this case, you're replacing a physical factor (having the device) with a knowledge factor (knowing the unlock code). Combined with the account password [2], you still only have one-factor auth, it's just two steps. This is like most banking logins: there's a single authentication factor - knowledge - but two different pieces of data are necessary.
Worse yet, that "mother's maiden name"-type info tends to be a) relatively easy to access as an unauthorized user and b) used to authorize password reset, thereby reducing the security of a possibly-great password down to your facebook account's privacy settings.
Suffice to say, proper MFA support when the device often used as the physical factor is part of what's being authenticated is non-trivial, and almost by definition requires additional hardware. Perhaps some sort of NFC/RFID tag that you'd keep in your wallet, or a less clumsy equivalent of an RSA keyfob (which is where TOTP came from in the first place). But the key takeaway here is that you cannot use the device being authenticated as part of the authentication scheme.
[1] and only you, I hope! otherwise there's no point. [2] or worse, not, as some have suggested for free or even paid apps
To elaborate: on a PIN debit payment, for example, there are two factors - something you have (the debit card) and something you[1] know (the PIN). In the case of authorizing the purchase of an app, you obviously have physical access to the device, or else you wouldn't be able to get to the checkout screen. For an actual second factor in a MFA scheme, it would be necessary to have a _different_ device that only the user with authority to make a purchase would have access to.
One could argue that if the device is PIN-locked, this is sufficient; however, in this case, you're replacing a physical factor (having the device) with a knowledge factor (knowing the unlock code). Combined with the account password [2], you still only have one-factor auth, it's just two steps. This is like most banking logins: there's a single authentication factor - knowledge - but two different pieces of data are necessary.
Worse yet, that "mother's maiden name"-type info tends to be a) relatively easy to access as an unauthorized user and b) used to authorize password reset, thereby reducing the security of a possibly-great password down to your facebook account's privacy settings.
Suffice to say, proper MFA support when the device often used as the physical factor is part of what's being authenticated is non-trivial, and almost by definition requires additional hardware. Perhaps some sort of NFC/RFID tag that you'd keep in your wallet, or a less clumsy equivalent of an RSA keyfob (which is where TOTP came from in the first place). But the key takeaway here is that you cannot use the device being authenticated as part of the authentication scheme.
[1] and only you, I hope! otherwise there's no point. [2] or worse, not, as some have suggested for free or even paid apps
A hardware-managed asymmetric (e.g. x509) key on device, combined with a passphrase which can't be saved to the device (and is entered by the user each time) would be two factors.
If you trust the hardware enough, I'd even accept on-device pin checking (i.e. a 4-8 digit numeric passcode), verified inside the secure element, instead of a password which went to the remote server. It would be two factor local, and one factor to the server (operations proving control of the private key).
For this all to work, you need to 1) prevent users from saving the passcode (easily enforced by the mobile OS, and pretty safe for a 4-digit passcode) and 2) protect the key using a hardware secure element, and prevent users from copying it willy-nilly. Otherwise it could become a single factor ("saved key + saved passcode", stored in the same place) very easily. Depending on your system, you may have a mandatory requirement to prevent that technically, or do it through policy, or let users do it.
It's kind of a philosophical argument at what point something becomes something you know vs. something you have, if it's just a long number.
If you trust the hardware enough, I'd even accept on-device pin checking (i.e. a 4-8 digit numeric passcode), verified inside the secure element, instead of a password which went to the remote server. It would be two factor local, and one factor to the server (operations proving control of the private key).
For this all to work, you need to 1) prevent users from saving the passcode (easily enforced by the mobile OS, and pretty safe for a 4-digit passcode) and 2) protect the key using a hardware secure element, and prevent users from copying it willy-nilly. Otherwise it could become a single factor ("saved key + saved passcode", stored in the same place) very easily. Depending on your system, you may have a mandatory requirement to prevent that technically, or do it through policy, or let users do it.
It's kind of a philosophical argument at what point something becomes something you know vs. something you have, if it's just a long number.
I think you missed my point: phones can be stolen. If you watch me type in my passcode by looking over my shoulder on the train (knowledge factor is now compromised), then steal the thing and run off as the train is departing, then you have full access.
Go ahead and steal my RSA token, and see what good it does you on its own. None, right? Not unless you bludgeoned my password out of me first.
All of the "have" factors that I've seen are, fundamentally, just a big number that's hard to get at or copy (with the exception of a physical, metal key). There's some math done on that number to generate a one-time-use code and do it in such a way that you still can't access the big number, but if an attacker were to compromise the number, then yes, that factor is broken. The theory is that the device cannot leak the number, and therefore it will only ever be known by the authenticating party. Or, more accurately, that the knowledge contained within should only ever be able to exist in two physical places (one each with the party being authenticated and the party performing the authentication).
I'm guessing we're talking about slightly different things and use-cases, but it's impractical to know that without a lot of diagramming and back-and-forth.
Go ahead and steal my RSA token, and see what good it does you on its own. None, right? Not unless you bludgeoned my password out of me first.
All of the "have" factors that I've seen are, fundamentally, just a big number that's hard to get at or copy (with the exception of a physical, metal key). There's some math done on that number to generate a one-time-use code and do it in such a way that you still can't access the big number, but if an attacker were to compromise the number, then yes, that factor is broken. The theory is that the device cannot leak the number, and therefore it will only ever be known by the authenticating party. Or, more accurately, that the knowledge contained within should only ever be able to exist in two physical places (one each with the party being authenticated and the party performing the authentication).
I'm guessing we're talking about slightly different things and use-cases, but it's impractical to know that without a lot of diagramming and back-and-forth.
Yeah, it's fair to say the unlock passcode on your phone is more vulnerable than a specific authentication password used during a web login. But other than length and how frequently it's exposed, it's not fundamentally different from shoulder-surfing that password and then stealing your keyfob. In both cases you can try to deactivate the account before the next login.
Biometrics are probably the best way to prove identity and control of your phone, locally. They already have a high-quality CCD. Biometrics are unpopular as something sent to remote devices for a variety of reasons, but should be much more palatable if they remain local-only.
Biometrics are probably the best way to prove identity and control of your phone, locally. They already have a high-quality CCD. Biometrics are unpopular as something sent to remote devices for a variety of reasons, but should be much more palatable if they remain local-only.
Duo Security has a tested module for OS X: https://www.duosecurity.com/docs/duounix
This doesn't help at all for Apple ID, though.
This doesn't help at all for Apple ID, though.
I'd be very leery of running any unofficial two factor authentication. Heck, even 1Password urged their users to wait out the initial Dropbox TFA rollout.
http://blog.agilebits.com/2012/08/27/dropbox-two-step-authen...
http://blog.agilebits.com/2012/08/27/dropbox-two-step-authen...
I'm sure it's not there for usability reasons.
That is no excuse for not providing basic TFA for users who know how important it is, however miserable the user experience may be.
That is no excuse for not providing basic TFA for users who know how important it is, however miserable the user experience may be.
I don't think TFA works well for securing mobile devices, because the entire premise is that it sends the second authentication token to your mobile device.
While not really applicable to any of the situations he described; I really wish more applications/companies/etc would use 2-factor authentication. It really baffles me that more applications DON'T use it, such as banking applications where I personally consider 2-factor auth a must.
Low user opt-in adoption.
Low demand.
Licensing costs from third party authentication providers.
Increased support costs.
Early adopter status of the technology.
Skepticism as to utility (to wit, malware that captures token keys or output).
Integration with non-interactive logins, APIs, mobile software.
Don't get me wrong, I like two factor auth, but there are lots of practical reasons it's not universal.
Low demand.
Licensing costs from third party authentication providers.
Increased support costs.
Early adopter status of the technology.
Skepticism as to utility (to wit, malware that captures token keys or output).
Integration with non-interactive logins, APIs, mobile software.
Don't get me wrong, I like two factor auth, but there are lots of practical reasons it's not universal.
Bank "security" = forced < 8 digit alphanumeric code that can be overridden on the phone if someone knows my birthday. I know because I hacked into my own bank account anonymously and was able to transfer funds. Best I can do is refresh my password regularly and hope nobody finds out my birthday :P (there's more to it than that, but that's the gist of it)
I also have found that carrying around cash is a lot more secure than using my debit card. My debit card has been copied, and money stolen from my account, 5 times. To date I have never had my wallet physically taken from me nor lost any money that way. Cash is compatible with every system I interface with in-person and it carries no service charge. This seems backwards to me. Banks really need to get with the program.
I also have found that carrying around cash is a lot more secure than using my debit card. My debit card has been copied, and money stolen from my account, 5 times. To date I have never had my wallet physically taken from me nor lost any money that way. Cash is compatible with every system I interface with in-person and it carries no service charge. This seems backwards to me. Banks really need to get with the program.
So long as there's an option available that doesn't require a smart phone (or worse, a specific OS), I agree completely. As a quick example, Blizzard has had an inexpensive device [1] in addition to phone apps.
[1] http://us.blizzard.com/store/search.xml?q=authenticator
[1] http://us.blizzard.com/store/search.xml?q=authenticator
Good point. Worth noting that there already are two passcodes (potentially)... one is the account password and the other is the unlock PIN. It'd make sense if they required the unlock PIN for free/cheap apps.
Actually, this brings up an interesting idea - why not allow people the option of disabling the password entirely if their phone is locked with a passcode? Apple already does this with the Find iPhone and Find Friends apps, they could easily extend this to free/small purchases, etc.
This used to be case - there was a setting to not require the password until a bit after the App Store launched. They removed the option after bad press/complaints from parents re:their kids purchasing things - I believe the iamrich app, which cost $999 for a picture of a gem was the app that got the most press.
Or simply add an option to disable passwords for free apps. Having two passwords will confuse average people, so of course Apple won't do that.
Apple doesn't want it to be easier to buy a free app than a paid app. They want you in the habit of entering your password to iTunes, so you're more likely to buy a paid app in the future.
I'm a little late to this, but my wife and I share an iTunes account since we have shared devices. The fact that the same password is used to download a free app and to REMOTE WIPE my primary business machine is terrifying. I would like that nuclear password to be 20 random characters and symbols, please, not one that I have to type in on my iPhone whenever I download the new Cut the Rope.
It's just upsetting to think back to the story of the gentleman who had every single device wiped remotely after someone called into Apple support and impersonated him with publicly available information from his Amazon account. Yet very little has been done.
It's just upsetting to think back to the story of the gentleman who had every single device wiped remotely after someone called into Apple support and impersonated him with publicly available information from his Amazon account. Yet very little has been done.
+1,000,000!
Apple's myriad of logins and passwords is so frustrating to me. I had an iTunes ID for years and can't use it for anything anymore because it is not an email address. It is such a pain in the ass to do anything. I have two apple ids, an icloud account and a game center account.
The edge cases (10% of users who would use multiple icloud/gamecenter accounts) are making things a huge pain in the ass for 90% of users who are the only person that uses their iphone for app downloads, icloud, music and game center.
Apple's myriad of logins and passwords is so frustrating to me. I had an iTunes ID for years and can't use it for anything anymore because it is not an email address. It is such a pain in the ass to do anything. I have two apple ids, an icloud account and a game center account.
The edge cases (10% of users who would use multiple icloud/gamecenter accounts) are making things a huge pain in the ass for 90% of users who are the only person that uses their iphone for app downloads, icloud, music and game center.
I recently bough an ipod and set it up with a new apple id. I didn't have access to a computer at the time, and my god, it was such a pain.
Not only are the password requirements utterly stupid (at least one digit, one capital letter, you know it), I was continously prompted to set up three security questions to make my account safer. The one I'm just trying to set up so I can download some free apps (I didn't have any sort of payment options associated with the account at all!). Of course it isn't enough that I have to input my Apple password separately to every single app that might use it - Facetime, iMessage, iCloud backup. When I download a free app, it still prompts me to input my password. Why? What's the risk here?
All in all it took about 20 minutes only to be able to download a news app. Not exactly user-friendly.
All in all it took about 20 minutes only to be able to download a news app. Not exactly user-friendly.
> When I download a free app, it still prompts me to input my password. Why? What's the risk here?
Kids buying several hundred dollars worth of Smurfberries.
No, really, that's why they set it up that way. That really happened. So everyone has to suffer for that.
Kids buying several hundred dollars worth of Smurfberries.
No, really, that's why they set it up that way. That really happened. So everyone has to suffer for that.
Are you talking about in-app purchases? Those are password protected. What's the point of password-restricting free apps?
Forget two passwords.
Apple needs to accommodate two IDs. Single ID is a problem.
I have my ID for whatever is "mine": stuff which I wish to exclude everyone else from. I need another ID for my family: stuff which should be shared among others who have a practical right thereto by relationship. Next I need another ID for work: identifying me, but shared with my company and which I renounce access to should I leave. All of these would overlap, recognizing that data in my life is compartmentalized in Venn diagram fashion.
Apple needs to accommodate two IDs. Single ID is a problem.
I have my ID for whatever is "mine": stuff which I wish to exclude everyone else from. I need another ID for my family: stuff which should be shared among others who have a practical right thereto by relationship. Next I need another ID for work: identifying me, but shared with my company and which I renounce access to should I leave. All of these would overlap, recognizing that data in my life is compartmentalized in Venn diagram fashion.
Agreed, Apple's authentication system is obnoxious. Compounding this is the fact that they force you to reset your password if you enter it wrong more than once, ensuring that you're never going to remember it. I basically have to answer my security questions and pick a new 8-char password with upper and lowercase letters and numbers every time I want to download a new app.
Why even bother asking for a password for free apps? That's stupid.
It might be for fairness between free and paid apps. If it were so much easier to install a free app, everyone would do free apps with ads and IAPs. Apple likely prefers having apps show their price up front, for good store UX.
I assume it's due to the free apps ability to make in-app purchases and if you have a child using your phone they could rack up lots of charges without ever identifying if there was no password to download the app. If the password was when making in-app charges it would be more of an annoyance than entering once up front.
In app purchases require a password anyway. I really dont see the need for passwords for free actions. Android hasn't needed a password in those cases.
[deleted]
It's unfair to paid apps. I think during iOS 6 beta they tried no-password-asking-for-free-apps policy, paid app developers didn't enjoy.
I suspect it ensures you authorized the app to be on your phone should any liability, or other legal issues arrise. Buddy downloads OKCupid onto your phone, Wife sees OKCupid and files for divorce and takes everything thanks to pre-nup. Man sues Apple for allowing app to be added to device without his consent.
Buddy could add a shortcut to http://OKCupid.com to friend's iphone home screen and accomplish the same thing, without password.
The password isn't just about accessing your account information (making a purchase), it's about authorization to use your hardware.
OSX does the same thing: want to install something? Enter a password.
I agree that there should be a better form of authorization than password, though.
OSX does the same thing: want to install something? Enter a password.
I agree that there should be a better form of authorization than password, though.
Apple already allows this and more, though it is not obvious and there is no free/paid app distinction.
http://gigaom.com/apple/how-many-apple-ids-should-your-famil...
http://gigaom.com/apple/how-many-apple-ids-should-your-famil...
Having 2 passwords does not really solve the problem. I understand where the writer is coming from, but it is a gray area to define what is considered "high risk" vs "low risk". Using two factor authentication for selected task seems to make more sense.
Agreed. Although certain actions would seem to be pretty black and white. Wiping a device is high-risk, and should obviously require a strong password. Downloading a free app is low risk (unless I'm missing something important about the permissions system on IOS). As for actions that are in the gray area, either let the user configure which password is used, or just err on the safe side and use the strong password.
Also, a really killer feature (admittedly for power users only) would be an API for password manager apps to integrate more deeply into iOS. I love my password manager's browser extensions. If I could have password auto-filling on iOS like I do in the browser, downloading free apps would be much, much easier. For that matter, visiting password-protected websites in iOS would be a lot easier, too. You'd still have to type your crazy master password on the finicky touchscreen. But it's a step up from what we have now.
Apple really should improve this aspect of the user experience. As it stands, I can only assume it leads a great many users to pick a weak password.
Also, a really killer feature (admittedly for power users only) would be an API for password manager apps to integrate more deeply into iOS. I love my password manager's browser extensions. If I could have password auto-filling on iOS like I do in the browser, downloading free apps would be much, much easier. For that matter, visiting password-protected websites in iOS would be a lot easier, too. You'd still have to type your crazy master password on the finicky touchscreen. But it's a step up from what we have now.
Apple really should improve this aspect of the user experience. As it stands, I can only assume it leads a great many users to pick a weak password.
I completely agree! Users should be better educated about the risks they put themselves to, but we all should also be aware of the crazy social engineering exploits that we expose are precious machines to.
This article made me certainly think twice about my password policies: http://www.wired.com/gadgetlab/2012/08/apple-amazon-mat-hona...
This article made me certainly think twice about my password policies: http://www.wired.com/gadgetlab/2012/08/apple-amazon-mat-hona...
Judging by the sheer difficulty normal people experience with iCloud and App Store logins when they use iOS devices, Apple should try to figure out a way to have zero passwords. Its support must get a ridiculous number of calls from people who locked out their phones or iCloud accounts and then forgot their passwords. I suspect that an interesting solution to this problem is brewing behind closed doors in Cupertino.
Tangential, but I am a little frustrated that I can't sign into one of my google products without being signed into all of them. I get so nervous any time I sign into google music somewhere that I'm not necessarily actively monitoring because it means someone can just type "mail.google.com" into the browser and basically unlock my whole life.
(I'm not making any statement on apple or apple vs google)
(I'm not making any statement on apple or apple vs google)
Why not use multiple IDs? one very simple passworded for purchasing apps, one complicated password for master syncing, phone deleting functions?
that's exactly how i use an recommend to anyone - one appleid for things which need purchasing and are shareable across a family ( basically iTunes and the Mac App Store) and one for individual services such as iCloud, facetime and iMessages.
something like
A single shared [email protected] which every family member uses for iTunes and MAS on their iDevices and Macs
while each person uses their own [email protected] as Apple ids for Facetime, iCloud and iMessage.
something like
A single shared [email protected] which every family member uses for iTunes and MAS on their iDevices and Macs
while each person uses their own [email protected] as Apple ids for Facetime, iCloud and iMessage.
This hits the nail on the head. As the OP says, having to use the same password for purchasing $0.99 apps (where something as simple as a pin number would suffice) and tracking/erasing an entire device (where anything but a strong password would be crazy) just doesn't make any sense.
I use separate accounts for iCloud and iTunes (and Developer, and Support Forums), which seems to solve this. It wasn't on purpose -- I had a nice short 3-letter MobileMe username that I didn't want to give up, and a lot of existing iTunes purchases.
I agree with this; I feel distinctly uncomfortable using the same password for both my developer account and "Free" app and family downloads. The appleid system really needs an overhaul.
I would prefer a possibility to enable a PIN code to work as the default password for all stuff on my iOS devices. After three invalid PINs, ask for the regular password. Simple.
Great point. Easiest solution would be to just separate the Apple ID password and the Device password.
You can use any random email address for iCloud and use a different one for iTunes. It works fine and that way you can separate them cleanly.
Really good point. s/Apple/everyone/, of course -- Google suffers from the same issue, but it's less worrisome thanks to two-factor.
Having two passwords seems very un-Apple like. Simplicity, minimalism. And you can just use two separate accounts today anyways.
I'm not so sure about this idea. If you have trouble remembering one password, you're definitely not going to remember two.
hey guys - you know, there is life beyond Apple
Sorry, you have just infringed Apple Patent #2323232323. Hide. Now.
Somewhat related, if anyone wants to get two factor auth working for their OS X login, instructions are at the bottom of this page:
https://code.google.com/p/google-authenticator/wiki/PamModul...
Though I can't speak to how well it works (if at all) it at least makes me hopeful someone will implement it more sensibly at a later date...