I have an application that only needs to send E-Mail through my GMail account (git-send-email), another that only needs to write to one specific GMail label (Android SMS Backup), and Google Chrome surely doesn't need access to everything. But you'd get full access to my account if you compromised any of these.
They already have this for the Connected Sites, Apps, and Services. I sent them a feature request for this a while ago but it hasn't been answered (and there's no way to view it online).
Maybe you should use throwaway accounts for these purposes? That is, have a gmail account for github to send your patches through, and have that forward to your main email account?
In the SMS-backup case...how important is it that you access your SMSes in your Gmail account? My first thought is: it's bad enough that someone breaks into my email, nevermind all my SMSes. But I guess if you have a workflow that requires easy access to SMSes with your email, you can still have a separate email account that does nothing but forward it onto your main account.
So your main account, theoretically, has strong security with the two-factor authentication without having to make backdoors for external apps. People can always break into your throwaway accounts, but they'll have no particular inroad into your main account.
And presumably, you'd have a decent window of time to detect an intrusion and administer the throwaway accounts with your main GMail account
Then I can uncheck delete for my chat apps. Edit: And grandparent could uncheck read and delete for a couple of their use cases (which is a pretty big improvement).
Why do you need access to your google account to send email from github? From:-headers are designed to be readily "forged" (or rather, set to whatever you want). Just send email through wathever means you use, optionally adding a bcc to your own account, if you want a copy of the actual email in your gmail folder?
>> Create multiple user accounts in connection with any violation of the Agreement or create user accounts by automated means or under false or fraudulent pretenses
Also, Google gives you the option of managing multiple Google identities from one account.
But, after a few minutes of searching, I can't find any actual promises that google will keep neither your logins, nor your services (eg: gmail) operating -- for any reason.
I guess this is worse if you actually pay them money (did they finally come up with a QOS-statement for paid accounts?)...
However, some type of SMS backup is required: if the Android SMS SQLite db is ever even slightly corrupted (power loss/program crash [usually when db is large]/etc.), Android will silently delete it: http://code.google.com/p/android/issues/detail?id=10127
That being said, two factor google auth wasn't going to save Matt Honan here. Identity, trust, and authentication on the internet are all built on a foundation of sand. We need a new model.
Naturally, it's not a panacea, but I think a lot of people allow perfect to be the enemy of quite good when it comes to two-factor auth.
It's the typical security vs accessibility trade-offs. Accessibility won.
Two-factor is a pain on iOS devices where every Google app needs it's own unique password and frequently need a new one for every update. Android is a completely different story though and adds almost zero overhead.
Now, you've got several passwords that work, instead of 1 and a keyfob. Ugh.
Edit: Apparently, you can't log into the web interface with those passwords. That's a step in the right direction, but still not fully secure.
They are strictly better than using a single password for everything though, in that they are unique and strong (due to being automatically generated and 16 characters long), and easily revocable.
I suppose there is one possible negative consequence to users who opt not to use app-specific passwords: their existence alone removes some of the incentive for client applications to implement 2-factor themselves (which I don't know if Google even has an API for). And sure, it would be nice to have features like access control on a per password basis (e.g., so I could allow Pidgin to access only gchat, but no other part of my account). But the implication that the mere existence of application-specific passwords somehow makes Google's 2 factor auth useless is just wrong.
I finally gave up and turned off 2-factor auth. I'm guessing this is a limitation in 4.1.1, but it really, really sucks.
I used 2-factor auth before on my phone (a much earlier version of android) and didn't have this problem. It's the typical thing with google: being on the bleed edge is just that, a pretty unsatisfying experience. I think next time a new android version comes out, I may wait a few months before I update.
Second, because the mobile authenticator is not feasible for me right now. I do a lot of android development work (well, mostly screwing around, but we'll call it work) on the side, with the result that I'm wiping my phone for romflashes at least once a week. Makes everything going through a mobile app a little useless.
I really wish Google would support a hardware token of some kind.
(Well, I suppose it's tragically normal. I'm sure there is a corporate directive that says every Google service must support 2FA, but Chrome has an exception so they don't need to do it yet.)
In Russia, most social networks these days require that you sign up with a mobile number. You cannot start using your account without receiving an SMS verification code.
There are in fact significant demographics - children and the elderly - where cell phone adoption is rather low. Ironically enough, these are the very groups where enhanced security measures may be most useful.
Actually no, I can't think of anyone. Buy an iPod Touch and install Google Authenticator, you will have all the inconveniences of not having a phone but enjoy the security benefits of two-factor authentication.
But 2-factor does mean there in an expectation you will have to carry some kind of token device.
What's weird is that Google even sort of supports the numbers-on-paper approach, but for some reason they limit it to 10 numbers.
edit: Hmm actually thought of a possible solution. Looking into how hard it'd be to port the Google Authenticator to a non-mobile platform so I can run it on my laptop.
edit2: Although it looks like you can't enable the Google Authenticator method without first enabling the SMS method...
Just install an android emulator, e.g. YouWave, and use that virtual android device to run GA.
I'm not sure about this (it was a while ago when I installed it), but I know you can install it on a new device after previously having it installed on another device (which disables it on the first device) without an SMS.
Yes, two factor authentication is a small hassle. Yes, two factor authentication requires a bit to set up. But do you realize how much actually depends on your email account being safe?
For one, how many times did you use Googles OpenID provider? Yes, that's your Gmail account! Or for how many services did you use your Gmail account as the email address? You know that password resets go to that account, right?
Don't do that? Maybe you use Google Calendar, then. So yes, there is actually a lot of sensitive data in there. If you don't believe me, try to get a hold of a friends calendar, and see what you can guess about that person just from the calendar.
Or should someone just post some slander about you on you G+ profile? Or buy some apps from the Android Market? Of course this things never happen to you...
So just take the time to, besides looking at the time or the latest message on your phone, open that stupid app and type that stupid code in! It's not THAT much work!
Compare the attitude towards security that people have in the physical world with their attitude online. No sane person would ever want to use the same exact key to open their home, car, desk, safety deposit box, etc., because that would obviously be unsafe. Yet most people today will happily use the same easy-to-remember password for all online accounts without giving it a second thought.
Similarly, no sane person would ever lend their wallet and keys to a stranger, because that would obviously be unsafe. Yet most people today will happily walk into an Internet cafe or hotel business center and enter all their online credentials without giving it a second thought.
Providers of online services like Google, Amazon, Apple, etc. will find it difficult to solve the security problem until society has evolved its understanding of, and attitude towards, online security.
Edit: softened the tone of the last paragraph to make it more accurately reflects my views.
Also, note that having different keys means one can give copies of different keys to different persons for different purposes -- e.g., copy of the home key to a baby sitter, copy of the desk key to a co-worker, copy of the home key to trusted neighbors.
People today intrinsically understand that they have to be mindful about whom they lend their keys to, who gets copies of their keys, and where the keys are stored.
(I say apparently because the ease of using things like bump keys is pretty widely publicized but I have never actually tried it myself)
That said, your house isn't directly connected to 2.26 billion people who can make hundreds (or thousands or billions) of bump-key attempts per second.
That said, physical keys are different enough that an analogy breaks down. They're much easier to circumvent (break a window), while their use by a thief is much more impractical (finding the lock and avoiding detection at the location). Criminals in possession of your physical keys will be local (or irrelevant) and limited in numbers. It's easy to get back in your house after a criminal has entered.
one feature that i cannot understand why it hasnt been implemented though is protecting the app itself with a password or pin. some people say to just protect your whole phone, but i dont really want to do that because to me that _is_ too large a hassle. if i lose my phone i can revoke access to my email and other similar apps, but not if the person that finds it opens up google authenticator (which shows the account the id is used for) and logs in to change the password before i have a chance to. even just allowing for it to display an account nickname instead of full login would be a huge step forward
The person finding your phone would have to either have access to your password, your backup email address or the answer to your security question (which you can write yourself).
You can install a standalone app called Google Authenticator (it’s also available in the App Store), so your cell phone doesn’t need a signal.
You can print out a small piece of paper with 10 one-time rescue codes and put that in your wallet. Use those one-time codes to log in even without your phone.
Ghana, Pakistan, Iran, North Korea, Russia, all have 2 factor authentication. Why not Nigeria? This is just another example why being Nigerian is kinda hard on the internet.
Can Nigerians use the Google Authenticator app?
If yes, then the answer is probably high SMS costs.
It is exactly why I put the range of countries above. Can we be in a worse situation than them all?
I've written about this before and so have countless of other techies. A non-techie has not a single clue, making them perfect victims. Any number of scenarios can be imagined: From taking your laptop in for repairs/upgrades to someone gaining physical access to your machine for just a few minutes. And, just like that, your digital life is turned upside-down.
I use Chrome all the time. As a developer I am keenly aware of the issues and manage the risk. I will not allow anyone in my family to use Chrome because the potential security leak could have dire consequences.
Go to Settings
Click on "Show Advanced Settings"
Click on "Managed Saved Passwords"
Click on a saved password
Click on "Show"
Write down or copy/paste/email the login in this fashion one-by-one.
If they are after a pile of logins, keep clicking "Show" all the way down the list. Capture the screen and email/print or simply take your smartphone and snap a picture.
Scroll through the entire login list to get it all.
Takes very little time to get all of someone's private login data in this fashion. An, since the vast majority of Internet users re-use login user id's and passwords across many services I would imagine it might not take long to identify this pattern and have access to every login.
Locking the workstation behind a password doesn't help either for a number of reasons, not the least of which is that workstation password removal, recovery or cracking tools are widely and easily available.
Either way, using the last 4 digits as 'security' is just stupid. You can get those from a receipt.
No, they did not have to break into the Amazon account.
> First you call Amazon and tell them you are the account holder, and want to add a credit card number to the account. All you need is the name on the account, an associated e-mail address, and the billing address. Amazon then allows you to input a new credit card. (Wired used a bogus credit card number from a website that generates fake card numbers that conform with the industry’s published self-check algorithm.) Then you hang up.
> Next you call back, and tell Amazon that you’ve lost access to your account. Upon providing a name, billing address, and the new credit card number you gave the company on the prior call, Amazon will allow you to add a new e-mail address to the account. From here, you go to the Amazon website, and send a password reset to the new e-mail account. This allows you to see all the credit cards on file for the account — not the complete numbers, just the last four digits. But, as we know, Apple only needs those last four digits. We asked Amazon to comment on its security policy, but didn’t have anything to share by press time.
Wow. That's really bad. I mean, it's stupid that Amazon allows that sort of thing (and it sounds like they may be working to fix it). But Apple going off just the last four digits? That's straight up retarded. Why isn't anyone asking about Apple's security policies? Thank Sagan I'm not an Apple customer.
I think npsimons was saying that it is stupid for Amazon to let you add a fake cc number and than take over an account using that same fake number. Not that they show the last 4 digits.
For the second question, I'd say Amazon should wait until the user "confirms" the credit card. That is to say, send the user an email stating "Hi! New credit card added to your account. Click here to verify".
Just because a hacker can get the last 4 digits by physically being near you so they can obtain your receipts, doesn't mean that it's therefore worthless to remove that capability from hackers who are not physically near you.
Besides, you should be shredding/burning your receipts anyway.
A sealed gizmo that shows a number just looks like an el-cheapo souvenier. Without knowing my username and password too, it really is worthless.
YubiKeys are relatively cheap and would provide a nice alternative to using a phone, IMO.
I'm sure I'm missing something, but I'm not sure what.
EDIT: I'll let the post stand but I need to read more clearly, I thought Google Authenticator was purely for Google services.
How is that "even longer" part supposed to work? I have a desktop Mac that prompt me every 30 days to re-logon to GMail in Safari. Is there a way to add it to the trusted computer list?
If it's an edge case, it seems like a trivial one for reducing your security so much. As your documented online data grows, the chance of being hacked only grows. And once you've been hacked, there's really no going back if the attacker decides to do a data-dump and now forever holds your information in perpetuity.
Seriously though, when you have to enter the PIN multiple times a day, it gets annoying.
If you don't have root on a box, consider it pwn3d with keyloggers listening to every juicy password you type. Take that as your friend's laptop, a library computer or even your parent's Windows XP box...
Trust no one, Mr. Mulder.
Don't underestimate how vulnerable you are when your email gets hacked - virtually every service you use can be accessed by the forgotten password mechanism when your email is breached. I'm pretty lazy and have procrastinated for a long time, but with the recent attacks and realizing what a mess I could face if hacked I finally implemented two factor auth and I have no regrets yet.
To access files in this situation, a better approach would have been to upload the file to a webserver. You can then safely download it from the library computer without anything being compromised.
I'll have to see if I can set up the Google Authenticator; I hadn't heard of that before.
It turns into four or five SMS every month, when I usually average zero (various computers, various browsers, etc.) So suddenly, there's this line item where there used to be none. I can't explain quite why it bugs me.
In any case, I hadn't heard of GA before. I've installed it and life is good.
You don't even need one of those, there are implementations of the same algorithm for other systems. I use my Nokia S60 with a J2ME application: http://ds3global.com/index.php/en/news-a-events/news/97-secu...
Mostly it's a downside for Americans, but one plus is that it means the caller's fee doesn't vary based on callee: unlike in some European countries (or Skype), calling a landline vs. a mobile phone doesn't charge the caller different rates.
That's the most bizarre thing I've heard in weeks. Honestly, I'm still laughing. BOTH for SMS and voice?!! God, that's just crazy. No wonder you Americans hate telco companies so much. And I though 0.25 cents (only for outgoing SMSs) that we pay here is absurd.
Paying both ways for SMS is a bit silly, though.
But I don't find paying more for calling a cellphone objectionable. A wireless call requires more resources and money for telco company than a wired one (they put wires in houses decades ago and have forgot about it (the maintenance cost is not huge), but they have to actively setup new towers for different locations in cities and change the old ones). It costs them more, so they charge more and I pay more.
I did. I grew weary of paying for text messages that I have no interest in receiving, so I simply called AT&T and told them to turn off SMS entirely. Since 95% of my phone messaging is via iMessage, and the other 5% is via free Google Voice SMS, I'm not giving up anything at all by turning off my carrier's SMS. I'm not interested in giving a single SMS-related penny to the telecom oligopoly.
That specific combination of attributes still bugs me.
I suspect Google is in a better position to judge how widespread account compromises are than you are. From my perspective, it definitely seems like security people are all saying that account compromises (keyloggers, phishing) have been the predominant threat for several years now because they're suitable for bulk attacks whereas social-engineering Apple is a more limited, if deeply disturbing, process.
There are a couple of problems with that reasoning. First off, I don't see where anything Google has said contradicts my point. Yes, MFA is a good idea. But that doesn't mean it's enough to prevent attacks like the one in question.
Secondly, Google is not an unbiased source on this matter. For cloud services to succeed (which Google is banking on), it is very important that people perceive that they (the people) have some kind of control over their own security. It is reassuring to hear "here are some steps you can take to make yourself safer". It is terrifying to hear "your security ultimately hinges on the competence of some of the lowest-paid employees of the faceless corporations you rely on".
Both of those statements are true, but you're never going to hear the latter emphasized by Google or any other company heavily invested in the continued success of cloud based services. (Which is not to imply that they are dishonest; bias is usually as more about delusion than deception)
> Yes, MFA is a good idea. But that doesn't mean it's enough to prevent attacks like the one in question.
It would have stopped this one, in several ways: according to Honan's writeup, it would have halted things at a key point in the chain of account compromises. Yes, it's true that you have to trust companies - but that's always been true, even 100% off-line, as any victim of identity theft could tell you. The key point is that having any sort of MFA schema would have contained the damage to one company, halting the cascade.
1) I immediately have to create a application specific password to actually read my mail on my iPhone.
2) If anyone ever gets access to that secret password, or any of the others I create, they have full access to my email and any password resets they generate.
3) I will have no idea this is happening since I would expect my mail to access that app password daily.
So your fancy two factor authentication still ends up resting on one piece of secret info as the weak point. Am I missing something?
Yes: that email password cannot be used to change your password, cancel your account, etc. and can be revoked easily without breaking anything else. This also means that you're not entering the password which can do all of those things on a daily basis, further reducing the odds of someone else being able to capture it even if they do manage the total local compromise or strong SSL MITM needed to get your ASP.
Security is all about incremental improvements, not silver bullets.
Before two-factor, were you really typing in your GMail password on a daily basis?
I mean, I certainly don't deny that two-factor is much safer if you can actually use it, like on the GMail site. I just worry about the big holes that application passwords punch in that wall. All it takes is one application sending your password in non-SSL when you are connected to an insecure wi-ifi, and you are hosed. Is every Google login for every service SSL only?
I have a policy where I will only add a generated application-specific password to really trusted applications (internal OS apps mail, calendar etc), and have gone as far as to sniff all traffic for each of these apps.
So, no, it isn't perfect, but it's a heck of an improvement. That is, if you believe your machine to be reasonably secure on day 1.
So, I'd say for absolute 2FA, you must give up Chrome browser profiles, device mail sync (till Google comes up with a compatible client) and Google Talk/any Jabber client. I don't care about Chrome browser profiles but I need/want my Android phone to have full connectivity viz. push mail and gtalk access to my account. I could always keep a separate browser window on the PC with my gmail signed in and IM notifications enabled for my third point.
Overall, I feel losing my Android connectivity is not worth the 2FA.
A vastly reduced, easily managed attack surface area that in practice results in overwhelmingly fewer account compromises.
Nothing says that number needs to be your mobile (or one that you have regular access to) but you do need to provide one.
If you are sufficiently paranoid there are probably call/sms-forwarding services available for a reasonable cost.
It's not worth it.
I don't run a business. I'm not a celebrity. I don't keep confidential information in my e-mail. And I don't register all of my various accounts at sites around the web to just one e-mail address. If someone got access to one of my e-mail accounts it would probably be a general-use one, and quite honestly it wouldn't affect me much.
It's also annoying to have to verify every time I log in. I probably log in more often than most people. When my browser session ends, all my cookies, cache and history are erased (not because i'm paranoid, but to help guard against CookieMonster, history probing and similar attacks on sites that don't do secure browsing right). Even though it may only be occasionally, having to go find my phone to authenticate the login takes away from my browsing experience, and I don't find the tradeoff worth the hassle.
It doesn't help that Google's authenticator medium is SMS. As a hacker, I find there's way too many avenues to intercept the token (not the least of which is an already-logged-in Google Voice session!). I like the idea of using a YubiKey, but if I have to stick the device into my computer, it's annoying. I prefer plain-old tokens like RSA's SecurID or the PayPal token (I got mine when it was still only $5). But it's not automatic. I have to do a bunch of work to set it up, and i'm lazy.
At the end of the day, even once you set up two factor, a good attacker will still get past it if they really want to. Separation of accounts will go a lot farther towards keeping your digital self safe than putting all your eggs into a two-factor single-account Google basket.
Edit: This post has encouraged me to pay the $20 for Bank of America's SafePass Card, which I consider to be much more secure than an app or sms.
SMS is not required (you can use the google Authenticator App).
The Authenticator app works just like a "plain old token".
Separation of accounts means squat if your passwords are intercepted. 2 factor auth requires physical access and reduces the possible pool of attackers from billions to hundreds.
SMS is just not secure. That's a general fact (it's not encrypted, it travels over many networks in the clear, phones can be cloned, google voice can be intercepted, and then there's alternative methods like this: http://williamedwardscoder.tumblr.com/post/24949768311/i-kno...). But then there's the App.
The App runs on a smartphone. Smartphones are computers. Computers run in software, and are subject to two flaws: network access and software bugs. Consequently, if you download the wrong app from the App Store, you could be installing a rootkit which can control your entire phone - including spying on your Authenticator App. Like i've mentioned elsewhere here, these rootkits have existed for years, and often it doesn't even take installing an App - plenty of exploits have been found in mobile browsers and other apps, not to mention the possibility of exploiting the OTA upgrade features many vendors and carriers build in.
A plain old hardware token is not vulnerable to network or software attacks. You have to physically steal it or read its display in a narrow window of time to circumvent it. The only ones for Google (that I know of) require a complicated tutorial set-up or a device plugged into the computer, and like I mentioned before, it's not worth it for me to do either.
Separation of accounts means squat if your passwords are intercepted
Uh, no. The whole point of separation of accounts is different passwords, so one intercepted doesn't compromise them all. Separation of accounts is incredibly important.
I don't think anyone realizes how much malware is in the Android marketplace. And that's beside the malware that vendors and carriers install on there by default. Do not trust your phone.
Not scared? How about this article from over a year ago, which details over 50 apps in the Marketplace using a rootkit which not only controls anything you do, but can download new code to keep changing at a whim?
Also, you only need the authenticator revolving token every 30 days.
(And yes, I don't keep my phone next to me when i'm at home. Half the time i'm trying to figure out where the hell I left it)
With adaptive authentication, you basically add a series of heuristics based on the browser's request to calculate a number. A ratio applied to that number determines the likelihood that a user is the same as the one who has logged in before. If the ratio is not close enough, challenge questions are asked of the user to verify they are the real user.
The number is cached both on the server side and in the browser. As long as the number stays the same, and the heuristics of the browser's request stay the same, no additional challenge questions are asked upon logging in again. This also times out after a period of time, so eventually the user must be challenged again.
The difference between that and Google's method is the idea that the SMS and/or App are "something you have" instead of an additional "something you know". But since the challenge questions can be anything (including made-up information that is fake and nobody would ever guess - like a second password), there isn't the same risk as with losing a traditional password, and it isn't something an attacker can find out by social engineering or research.
As we've seen before, you can intercept SMS/voice two-factor auth, and Android malware is rampant. But the only way to get a challenge answer is to use lead pipe cryptography or intercept it at the computer - and once they have your computer it's game over. How secure your authentication is comes down to how you implement it.
I will stick with my trusty dumb physical token and challenge questions as that is the most difficult method to attack.
Namecheap, I'm looking at you. DNS web apps are a huge possible attack vector.
Also, RE the Google one time use passwords for POP/IMAP. They are all lower case, alpha/numeric, and 8 chars long.
How secure are they against brute force? Why wouldn't Google offer 16 char options, or even longer? Is 8 good enough?
I too would rather them be longer, and involve at least some numbers if not specials... but they're not THAT short.
Time to go and generate some new passwords!
llll llll llll llll
Depends on how good their intrusion detection is.
The least they could do if offer IP whitelisting like Linode does.
Really: the company's got far too much personal information on me. Pick something else I can use. An OTPG (similar to the RSA keyfob), say.
Added bonus: this gives a pathway for other services to also offer 2-factor auth.
Granted Blizzard controls the entire experience, they're not dealing with 3rd party apps, but it seems like Google could make this easier. And once it's trivially easy to setup, then it can be made the default.
I've been using 2 factor on google for a year or so now. It's not perfect - especially the ways it can be disabled - but it's better than the status quo for now.
There are many complaints about how Microsoft didn't protect Windows users enough because everyone had administrator access as a default. But isn't that the same problem with these Google and Apple accounts? With your standard account, you can change your password, delete all data, and do many other damaging acts.
I don't really want to enter in multiple pins/passwords each time I read email. But I would be more than fine doing so before being given the ability to damage my account.
Which is more secure: LastPass with 2factor, or a gpg encrypted password safe on my home server accessed by a passphrase-locked rsa-encrypted key?
I've been trying to decide for the past few weeks. Copying and pasting passwords isn't as annoying as I thought it would be, and it seems like keeping my pwsafe locally reduces the attack vector of the LastPass servers.
Then again, it's in LastPass's absolute interest that my info never gets leaked, and they've built up a good reputation. Further, at a public terminal my usb drive would need to be connected while I unlock the key, thus possibly exposing my unencrypted key.
Specifically it exposed your email address, your password reminder, the list of sites you log into and the history of your logins, including which sites you logged into, the time and dates you logged into them, and the IP addresses you logged in from.
EDIT: I used to use LastPass but now I use a GPG encrypted file, which I sync between machines. I set up a simple helper script so I can just type for example "password facebook" at a terminal and it will do a gpg --decrypt on the text file, grab the facebook password, display it, and also copy it into my clipboard for ten seconds.
Combined with two-factor ssh auth for using a public connection, looks my gpg file is the perfect solution.
Also, if you lose your device, you're screwed, unless you've dropbox synced it of course. In which case, you lose the air-gap.
Two factor-auth, via SMS, may not have saved Matt Honan.
Or buy a prepaid phone, and don't use the number for anything else.
or does that defeat the purpose because it's not going to be a push notification? (if so, anyway to fix that?).
i'm not normally mobile. if i am travelling and need gmail, i will have my laptop. i don't have a smartphone and my dumbphone won't work abroad.
EDIT2: oops. ignore previous edit. that was using Google to connect to linux. Not vice-versa.
Also, Android can apparently be run in VirtualBox, but I haven't tried that yet, either:
the first link makes the valid point that it's not that smart to run this code on the same machine used to access the service (if that machine is compromised then the "two factor" aspect becomes a single, compromised factor).
so i guess maybe what i was planning is not so good an idea. on the other hand, maybe it's better than nothing.
And I have no clue how you managed to mess up your phone… By entering new passwords??
And why use a (relatively, before someone calls me out) high security measure for something unimportant in the first place? You wouldn't use a full biometric security scanner setup for your pantry either, would you?
Hopefully they figure out a nice way to make the rights more granular (so that a chat app can't mess with email or whatever).
So instead of losing access to your account, you just lose all your email (yay!).
Someone who previously always logged out might be exposing themselves to more risk by storing the app passwords, but I think that's about the only case where it is worse.
Google 2-step auth is very hard to use and for how hard it is to use it doesn't provide all that much protection. It protects against phishing (mostly) but not against someone who has your phone. Malicious ex-girlfriend trying to do you harm? Google 2-factor won't help you a bit as long as at some point she had access to your phone.
Any security improvement is better than no improvement so let's concentrate on the real issue which is ease of use.
1. Google 2-factor auth requires application specific passwords are deeply confusing
I founded Clickpass and I can only just get my head around this. One password per application? This is a very confusing concept and very difficult for the average person to understand. There's no indication of whether you can reasonably create one password and reuse it in all your apps (which I think you can).
Application specific passwords are very confusing and not that much more secure than one revokable password for all applications.
2. Application specific passwords are almost impossible to use on mobile apps
Ever tried copying a 12-digit long string into a keyboard which only shows you the last letter you entered and even then only for half a second? It's really hard. You can't copy and paste them and you have to have a computer nearby to do it (it's very hard to use the Google password-generator page on mobile)
Here is the list of the application-specific passwords that have to be individually entered (10+ characters each):
On my mobile
- iphone mail
- iPhone Google account (through browser)
- iphone work mail
- iPhone (work Google account through browser)
- iphone calendar
- iPhone calendar (work)
DUPLICATE ALL OF THE ABOVE FOR iPad
DUPLICATE ALL OF THE ABOVE FOR MacBook Air
Switch on 2-factor auth and you immeidately find all these apps go dead until you do this. It will take you about 15m at least to do this and you'll have to do it again if you change your password or get a new device. You can't copy and paste because the Google auth-token page is unusable on moble.
What we need is easy, incremental security improvement
The problem with Google 2-factor auth is that it was designed by security geeks. It takes 3m just to watch their setup video! The system needs to be designed by usability geeks and audited by security geeks.
2-factor auth is no use at all if it's switched off. Contrast my switched off 2-factor auth with my Facebook auth which texts me every time someone logs in from a new machine and you contrast a system which provides me with a bit more security (FB) and one which pertains to be secure (Google) but which adds nothing.
Google needs to rip the security guys out of their security team and put the user experience people in. End-user security is a UX problem and Google is in a powerful position to effect change.
[Edited above for (a little) brevity]
EDIT BELOW: for folks who feel this account is unfair:
I realise that if you keep a PGP encrypted file on another device that is necessary to do your password reset then yes, Google 2-factor auth is very strong indeed.
I also realise that you shouldn't tell someone your password. The point is though that resetting your password is something that only really needs your phone. The key elements to resetting your password usually involve sending a password or an out-of-channel token to another acccount. For most people that other account is their work mail or Facebook, both of which are usually accessible via their phone.
I'm not talking about the absolute strength of Google 2-factor authentication. I'm talking about how that type of process applies to the type of internet user who tries to log into Facebook through ReadWriteWeb:
Why do they (and your malicious ex) know the other half needed to login - your password?
Also, does the parent-commenter mistakenly believe that the authenticator code is all that's needed to log into an account? But maybe that underscores his point that the whole system may be overwhelming to the average user.
Can we not upvote bullshit? He's vocally ignorant. The one time key generator is useless without the password. For his situation to be an issue he must have already have given her the password.
I don't think promoting security advice from someone who gives out his plaintext password is the least bit responsible.
> A reset link that gets sent to a secondary account that my phone doesn't have access to with a
> unique password stored in a PGP encrypted file with a nice long passphrase only known to me.
> My security question has a gibberish answer.
I'll guarantee they don't have a firewalled second account.
Your post is buried and won't harm others. Move on.
My security question has a gibberish answer.
Not rocket science.
I completely agree that the overall UX needs serious improvement but … doesn't your mobile device support copy and paste? I do this from time to time and while it's a bit clunky it's a lot easier than typing the password in by hand.