Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple Increases Account Security With Optional Two-Step Verification System for Apple IDs
- Thread starter MacRumors
- Start date
- Sort by reaction score
Again, therein is the problem. You are allowing a third party, for which you have no direct controls over, access to one of the layers of authentication being used. If any portion of that gets co-opted, your TFA is completely gone and compromised. Once one portion is gone, all of it is gone. From a security aspect, that is too much of a risk to accept for TFA, especially when it comes down to the compromise of sensitive data.
No-one could guarantee that such an app could not be copied. So best practice and recommendation would be to not use such an app, especially given the sensitivity of such data.
Does not the authenticator app, after the proper code has been submitted, pass your credentials through to other sites? If it does, your password would not be needed. All that would be needed would be the authenticator app, and the means to submit the credentials to get the right codes on your behalf. After that, everything else that relies on the credentials being passed to it are fair game.
BL.
One more thing:
It goes without saying that when using phone-based authentication rather than a key fob, password locking of the phone is absolutely necessary.
Lastly, you're talking about your experiences with enterprise-level authentication via multiple layers, something that is wholly impractical for consumer use.
It goes without saying that when using phone-based authentication rather than a key fob, password locking of the phone is absolutely necessary.
Lastly, you're talking about your experiences with enterprise-level authentication via multiple layers, something that is wholly impractical for consumer use.
NO, it does NOT.
I'm just amazed at all the assumptions you keep making about how this works.
Once again, you need:
(1) Password That Is Unique To Each Site
(2) Time-Based Code (One-Time Use or Generated And Expiring After One Minute)
ALWAYS. PERIOD. FULL STOP.
Are terrorists going to purchase rap on my iTunes account? What nonsense.
Optional now, but Apple likely plans to gradually implement a mandatory multi-tier system and others will follow.
People can't remember all their passwords and so they write them down someplace near or even on their device. This makes them even more likely to be compromised than a simple password that could be easily remembered.
The more layers of this, the more likely there will be a list for a thief to steal.
Optional now, but Apple likely plans to gradually implement a mandatory multi-tier system and others will follow.
People can't remember all their passwords and so they write them down someplace near or even on their device. This makes them even more likely to be compromised than a simple password that could be easily remembered.
The more layers of this, the more likely there will be a list for a thief to steal.
OK, I think I see the problem here. You are confusing 2-Factor Authentication with third-party login services like Facebook Connect or the open source OAuth protocol. The two have absolutely NOTHING to do with each other.
Every site that you use Google 2-factor authentication with still requires it's own unique password. Google has nothing to do with that. Google does not take over the authentication process, it merely augments it.
Every site that you use Google 2-factor authentication with still requires it's own unique password. Google has nothing to do with that. Google does not take over the authentication process, it merely augments it.
If you read my posts, you see where I said that I am assuming, because I'm not familiar with, nor do I want to be, familiar with the authenticator app. That is why I asked if it is anything like true TFA, instead of letting it handle everything on your behalf.
So once again, I ask: Does the Google Authenticator app store your password for use of being passed to the site, or does the password have to be entered in each and every time in addition to this code that it supposedly gives out? If it stores the password and passes it on your behalf after the code is entered, you have a problem if the app gets compromised. If it doesn't, then you don't. It all boils down to how the password is kept and passed, which I mentioned that I do not know how that part of that app works.
Absolutely. Which most commoners won't do, because they'd rather sacrifice security for convenience.
True, but it also goes to show how much security goes on behind the scenes with protecting someone's data, which they don't really appreciate the magnitude of.
I see now. And that makes sense, and again, I assume that Google's Authenticator acts as that service, which runs completely square to how I've had to implement 2-factor authentication for PCI/DSS. I understand now.
BL.
Last edited:
That's why there are apps like this:
https://agilebits.com/onepassword
and this:
http://lastpass.com
You are completely clueless about how two factor authentication works I see.
You have your Username, Password, and the Authenticator App's Rotating Code.
If a hacker in cyberspace hacks your username or password, they can't gain access because they don't have the rotating code.
If a thief steals your handset, bypasses lockscreen, and gains access to your Rotating Code App. They *might* be able to guess username from details in mail settings (assuming your username is email addy), but they have no clue what your Password is.
Great idea, except for the part where numerous studies have found biometric scanners can get outsmarted by gummy bears. I'm not sure where the technology stands today, but gummy bears...
Gummy bears!
And photos of you. (OK, maybe that's only the Android implementation.)
I'm sure Apple can come up with an image analysis algorithm that isn't fooled by gummy bears and photos. They did, after all, acquire Polar Rose in September 2010. And their area of expertise is face recognition. Do the math.
thanks for the personal attack.
Read the above on how I've had to implement it, and tell me how I am completely clueless. Have you ever had to implement TFA for a cardholder data environment per PCI/DSS guidelines and contractual obligations?
If not, you really do not have any room to talk, especially with the environment I work in. Who knows? the database I have to maintain may even have your credit card data in it, and I am charged with protecting it.
But that is neither here nor there, because you don't know the reaches of my job, nor do I know yours. But keep on thinking I am clueless, especially if it makes you feel better.
Same as the SHA512-encrypted fob I have to use to authenticate into our gateway server. Strange, isn't it?
Same as the SHA512-encrypted fob I have to use into our gateway server. Strange, isn't it?
BL.
Your credentials just sound like a lot of hot air politician speak, when you have made several posts clearly demonstrating the opposite.thanks for the personal attack.
Read the above on how I've had to implement it, and tell me how I am completely clueless. Have you ever had to implement TFA for a cardholder data environment per PCI/DSS guidelines and contractual obligations?
If not, you really do not have any room to talk, especially with the environment I work in. Who knows? the database I have to maintain may even have your credit card data in it, and I am charged with protecting it.
But that is neither here nor there, because you don't know the reaches of my job, nor do I know yours. But keep on thinking I am clueless, especially if it makes you feel better.
Same as the SHA512-encrypted fob I have to use to authenticate into our gateway server. Strange, isn't it?
Same as the SHA512-encrypted fob I have to use into our gateway server. Strange, isn't it?
BL.
Try starting here, at google
https://support.google.com/a/bin/answer.py?hl=en&answer=175197&topic=2759193&rd=1
Usage
Has anyone actually used this ?
I can't .... Firstly the phone number field is just an (area code) + 9-digit phone field.
This is too short for mobile numbers. And mobile numbers don't care about area codes anyway.
Tried all possible combinations here, splitting across area code, then phone field is filled in with the rest of the number, but to no avail..... No SMS. (This is where Apple should have an option for call back, much like Google, where its an automated system reading the code) Allot more reliable.
This has gotten to the point, now i cannot set it up, as its blocked me because i've used too many attempts...
Anyone having issues with this ?
Also, is the country code only unique to this setup ? or does it tie in with your iTunes account.. That is to say, you are unable to add an australian phone number for SMS verification with a U.S account, and visa vesa ?
Has anyone actually used this ?
I can't .... Firstly the phone number field is just an (area code) + 9-digit phone field.
This is too short for mobile numbers. And mobile numbers don't care about area codes anyway.
Tried all possible combinations here, splitting across area code, then phone field is filled in with the rest of the number, but to no avail..... No SMS. (This is where Apple should have an option for call back, much like Google, where its an automated system reading the code) Allot more reliable.
This has gotten to the point, now i cannot set it up, as its blocked me because i've used too many attempts...
Anyone having issues with this ?
Also, is the country code only unique to this setup ? or does it tie in with your iTunes account.. That is to say, you are unable to add an australian phone number for SMS verification with a U.S account, and visa vesa ?
By all means. Show and prove me wrong about implementing two-factor authentication using SHA512, or AES encryption with certificate-based authentication.
I know what I do and do for a living each and every day, and I'll back myself by it each and every time. But so far this thread, you've done nothing but criticize/condemn/complain. If that is all you're going to do, then IMHO, you have no credibility to show to me that I know otherwise.
EDIT: It's obvious to me that you haven't realized how I've set this up for an enterprise environment, where you are thinking of this from a consumer perspective, as Negritude mentioned.
BL.
Last edited:
I don't care about your career claims, they are unsubstantiated.
I have made two posts.
1. Outlined how Two Factor works.
2. Provided reference material for you to learn how Google's Two Factor Authentication works.
And now, 3. defend my goal here of being helpful. Take it or leave it. I'm done.
I have two Apple IDs. I had to login with my Mobile Me login and then I was presented with the two step login verification.
I've had credit cards stolen twice. Just call the credit card company and they cancel the card, refund any fraudulent charges, and overnight me a new card. Easy peazy.
Consumer has zero liability for fraud. What's to worry me?
Unfortunately this feature as currently implemented does not prevent that from happening. A bad guy can still log in to your icloud.com account and remote-wipe your devices with just the password. The 2-factor authentication is only used for managing your Apple ID and making purchases at this point. So you should continue to use a secure password.
I too hope that they will add support for offline-generated one-time codes (such as the ones used by Google Authenticator) as an additional option next to SMS and "find my iphone" messages, particularly for situations where the trusted device has no connectivity (e.g. when travelling overseas).
BTW, Google Authenticator does not use a proprietary mechanism by Google, but is based on IETF standards (RFC 4226 and 6238). There are a few other clients that support the same system.
I don't see where you're getting 62^8, which is what your nomenclature depicts (?)
A single 8-character alphabetic password has 26^8 possible combinations.
The password has to be alphanumeric, and at least one upper-case letter, so his math is correct (I think?)