Hacker News new | comments | ask | show | jobs | submit login
Please turn on two-factor authentication (mattcutts.com)
224 points by cleverjake on Aug 7, 2012 | hide | past | web | favorite | 258 comments



Something Google could to do drastically improve the security of their two-factor authentication system is to add the ability to give more granular permissions with the application-specific passwords.

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).


> 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)

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


They should at least go as far as create/read/delete.

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).


AFAIK it is still against Google's policies to have more than one gmail-account? That doesn't mean it won't work, of course, but you might end up with Google turning off all your accounts, with no real recourse to fix the situation.

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?


Just checked the TOS...it doesn't appear that it's an outright violation to have multiple GMail accounts:

https://mail.google.com/mail/help/intl/en/program_policies.h...

>> 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.


Yes, I believe you are right -- I can't find any general restrictions against multiple accounts, or service "subscriptions" either. I seem to recall things were different a while back. Now you can apparently create as many google logins as you like, and associate them with (among other services) gmail.

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?)...


For me, Android SMS Backup is definitely convenience over security.

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


Indeed. I have created a couple application passwords for "Verbs" IM on my iPad and my iPhone (though I rarely use chat, but added them just in case). I'd feel safer if I knew these guys can only see see my contacts and send/receive messages. Right now they can see all my emails and probably everything else that's on my google account.


I totally agree with this. I have to be careful where I use app-specific passwords. Currently, I only trust the keychain on my Apple devices, and would never store one of these passwords in plaintext.


I didn't think Chrome any longer required an ASP?


It still does; I had to go through this yesterday. I don't mind Chrome so much per se, but this also means you need an application-specific password for Chrome OS, at least for he initial sign-on, which I find oddly frustrating.


It does if you set up the sync account via the Settings page, but if you ignore the request to sign in, visit some Google page that requires login and log in, Chrome will produce a yellow bar at the top of the screen asking if you want to use that account for Chrome sync. Click yes and you don't need to sign in any further.


I was glad it does when I revoked the password for the chrome install on my old work computer when I changed jobs.


Chrome is experimenting with an OAuth flow but last I checked it isn't in stable yet.


Still did as of a month or two ago when I turned on two-factor.


I was worried this would be a major pain when I enabled it, but I have to say, it has been much more painless than I thought it would be. Most of the time, I don't even think about it. Most of my consumption of google mail is through clients on my laptops, iPhone, or iPad. So in that sense, it's not much different from a regular password. The difference is that someone else has a much harder time cracking my account. It's actually much less obtrusive than using lastpass (also highly recommended, but not as transparently usable).

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.


According to Matt (and, apparently, his hacker) you're wrong; two-factor would have saved him in this particular instance: "If I had some other account aside from an Apple e-mail address, or had used two-factor authentication for Gmail, everything would have stopped here." (http://www.wired.com/gadgetlab/2012/08/apple-amazon-mat-hona...)

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.


Agreed, I missed that tidbit. I guess I was focusing on the idea that someone can wipe your iPhone, iPad, and Mac without ever touching your gmail account. As a father of two year old and 4 month old girls, the photos are the part that of the story that I find the most distressing. Everything else is upsetting, but you can rebuild contact lists and things. Those pictures are completely irreplaceable and it is just gut-wrenching for me to think about that.


That is terrible. Though, I don't understand why anyone would turn on a "find my Mac" feature that has the potential to wipe your entire hard drive remotely unless you have thorough backups. Time machine is dead easy to use; try pluging in a usb hard drive and it will ask you if you want to use this as a backup drive. Arc is something that anyone on the mac should use as well for backing up priceless pictures and files. It encrypts the files locally and then sends them to your amazon S3 bucket as a backup. Easy and cheap too as you are only charged what you backup at the S3 rate(as of now it's ~0.125/GB/Month +a very small amount for put and get requests).


The "Find My Mac" feature is on by default. I just turned mine off in the iCloud settings


+1 for Arq (just posting this to note the correct spelling, for those who want to Google it).


Yeah it's Arq, iPad auto correct gets me way too many times.


I used two-factor authentication for about a year, and I just got so sick of it. I had no issue with the whole logging in and using the time-sensitive code from my Android phone. It was the support for all the other Google apps that drove me crazy. I got really tired of needing to generate new temporary passwords for access through iCal, Mail, and I think even sites like StackOverflow. Perhaps I was at a point in life where I had too many new devices and changes going on.

It's the typical security vs accessibility trade-offs. Accessibility won.


SO would not need a password generated. It would only require that you be authenticated with your Google account.

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.


Plus, don't the special passwords for specific apps (that don't use 2-factor auth) violate the whole point of 2-factor in the first place?

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.


The app-specific passwords are a feature and if you prefer the extra security over being able to use apps that don't support 2-factor, then you can choose not to use them, and get the full security benefits of 2-factor. It's just that, short of expecting every single third-party client app to implement 2-factor authentication or not allowing access to any that don't, there's no alternative to the app-specific passwords.

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.


Non-web apps don't have a UI for two-factor. App-specific password is a compromise, which is vulnerable if someone steals your local installation of the client to get its keys.


Right. Did I say something contradicting that? Google could have decided not to offer application-specific passwords at all, but from any individual user's perspective, that's exactly equivalent to just not using them. At least having application-specific passwords gives you the option, and is at least as secure as giving your master password away to every client application.

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.


Why wouldn't two-factor authentication protected Mat from at least his GMail account being hacked? Even if password-resets were being sent to the .Me account, wouldn't the hackers still need to generate the authentication token?


If you've spent your career with RSA SecurIDs hanging from your keys, this isn't much of a hassle. I didn't realize that LastPass and others can use the Google Authenticator.


I was just thinking that Google should open their service to others... Makes me think about switching from 1Password to Lastpass...


Yes, it would. The idea behind two factor authentication is that an attacker now needs two things to access your account: Your password and your phone. With two factor authentication, even if an attacker acquires or changes your password (which is what happened in Matt's case), they still won't be able to login to your account.


I literally could not enter the 2-factor code into my Galaxy Nexus running 4.1.1. The process asked for my password, then redirected to Chrome to finish the process, which asked me for a code. I then switched to the Authenticator app to get the code, but then I couldn't switch back to the place to enter it. Whhaaaaa??? I tried this 3 times looking everywhere.

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.


Several google tools don't have support for the standard 2-factor auth. Instead, you have to create a single use password for those devices. Watch the video on Cutts blog for info on how it works.


This was my android phone I'm talking about. It's clearly a bug in something on the phone. This isn't some "google tool".

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.


Same here, I just enabled it a few days back and it's much easier than I imagined it would be.


The reason I'm not using 2FA right now is twofold. First, because Google doesn't have half of their services using it for some undefined reason (for at least a year plus!). Also, the whole "app specific password" thing is a huge pain in the ass. (And appears to randomly stop working on say, IMAP mail).

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.


Yes, can someone explain why Google Chrome doesn't support 2FA on the desktop or iOS? It's bizarre.

(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.)


Dunno about iOS, but Chrome does on the desktop; it asks you for an application-specific password when you turn on sync.


OK, but it should be asking your for an authenticator code instead. It uses this bizarre "normal password + app specific password" requirement that isn't used anywhere else.


Your data is encrypted with the normal password, so it needs it to decrypt the sync data. The App-specific password is used to log in to the server to GET the sync data in the first place.


So again, why not have the authenticator instead of the app password?


I don't think your information is up to date. I have definitely been asked for a verification code when logging into Chrome 22. And yes, I mean the kind of code generated by the Google Authenticator app, not an app specific password.


I just logged out and back in to test this.. still get prompted for an app password. It's good to see they're rolling it out, though!


Am I the only person in the world who doesn't have a cell phone? It annoys me that the two-factor auth setups at sites (like Google) assume I have one and don't even have an option for "I don't have a cell phone, please stop nagging me about this."


Yes you are, and I suspect you know this. Even in most third world countries cell-phones are common.


Still, if I plan to use Google Authenticator, I don't want to give Google my phone number at all. When they insist to get the phone number from me, I don't like it.


I don't think you need to get them a phone number. I use Google Authenticator app on my iPhone, and didn't give them anything. It just scanned a barcode on a webpage IIRC.


The bar code was actually just a code to initialize the code generation (I think it is based on that randomly generated seed and the time, so that then server and client generate the same keys). You could have also typed in the code by hand.


You're absolutely right. My parent was talking about giving Google his/her phone number, which I was responding to :)


How do you get 2-factor auth enabled at all without entering a phone number? Their help page says that you can switch from phone-based to Google-Authenticator-based authentication after enabling 2fa, but I can't find a way to skip the phone step for turning it on in the first place. This is the screen I get when I click to enable: http://i.imgur.com/cm6Km.png


Sorry, a bit off-topic, but that reminded me of one fun fact.

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.


Iirc, even facebook nowadays (at least in India) requires you to complete SMS verification during account creation.


Buy a $20 used phone and get the cheapest pay-as-you-go plan you can find (you'll only be using the phone to receive text messages, so it should be really cheap) and consider it a somewhat impractical Google Authenticator hardware dongle.


Note that even a cheap, pay-as-you-go phone emits a breadcrumb trail of mobile network (and possibly GPS) location information. Unless you power it down between connection attempts. In which case it still emits breadcrumbs, though fewer.


Are you talking about Google Authenticator the Android app, or the SMS service?


Perhaps I meant it as a half-rhetorical question; I'm not the only person I know who doesn't have a cell phone, and if you take moment to consider it, I'm sure you'll realize that you know some people in the same position.

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.


> if you take moment to consider it, I'm sure you'll realize that you know some people in the same position.

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.


No he isn't. Some people (like me or he) are just not stupid enough to buy a device, which would be used on average only once a month.


You can use a YubiKey for Google 2-factor along with a helper app like Yubikco's "sidekick" for Windows [1] or my company's OneTime on Mac [2]. A YubiKey costs about $25 but is very portable, fast and convenient option.

[1] http://yubico.com/totp [2] http://zetetic.net/software-onetime


You can run the Authenticator app on an iPod.

But 2-factor does mean there in an expectation you will have to carry some kind of token device.


You shouldn't have to carry an electronic device, though: a list of codes on paper can work fine. That's how the NemID system works, for example (http://en.wikipedia.org/wiki/NemID): I have a big list of challenge/response codes that I carry in my wallet, and each is used once. I use that one successfully to log into my bank with two-factor authentication, but since I have no cell phone, iPod, iPad, or Android device, I can't use Google's version.

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...


You can print out more than 10, but only 10 are valid at any given time. There's a link at the bottom of the page with the codes to generate 10 more. I suspect they do this so people don't print out 1000 only to be using 10 (or less) at any given time.


There is a windows version, and various java versions, and still others:

http://en.wikipedia.org/wiki/Google_Authenticator#Implementa...


Oh cool, thanks; I was only looking at http://code.google.com/p/google-authenticator/ and didn't think to check Wikipedia.


You're not limited to 10 total, you're just limited to 10 at a time. Once you use those up, you just go get more.


>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.

Just install an android emulator, e.g. YouWave, and use that virtual android device to run GA.


Google Authenticator uses the standard OATH protocol (note, this is not OAuth): http://www.openauthentication.org/specifications


Although it looks like you can't enable the Google Authenticator method without first enabling the SMS method...

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, but you can only do that _after_ you've set up two factor authentication using SMS.


Why are you the only person in the world who doesn't have a cell phone? Why would you assume that super-large companies would consider your single-person use-case?


Did you know it can provide a one-time pad of ten verification codes to print out and store and it will provide another batch on request?


Buy a cheap used phone and a prepaid card, you should be able to get by just "recharging" 20$ of credit every 6 months or so.


I'm more curious about someone being on Hacker News who doesn't have a cell phone.


Doesn't want a cell phone.


No; I know dozens of people, including myself, who do not have cell phones, and have no intention of getting one. I find this an extremely obnoxious assumption by Google (and others) -- it's not like we're luddites; it's frequently the programmers I know who are least willing to carry a cell phone.


the assumption is made that 99% of customers would have a cell phone and thus invested engineering resources into it


I also don't carry a phone, and feel the same way as you about this


I'm always dumbfounded when these topics come up and a lot of people start saying how inconvenient it is, that it is all wrong. But these are probably the same people which later accuse Google that they didn't do enough to protect their accounts!

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!


Two-factor authentication improves security, but cannot solve the online security problem for most people, because the vulnerabilities are primarily CULTURAL: the average person does not understand the risks nor what they could do to ameliorate them.

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.


I do agree with you on the key analogy but there's a security breach there as well. Most of the keys are generally found on the same keyring. So, in effect it's identical to using a single password.


That's true only to some extent: people keep on their keyring only those keys they need for daily use. Less frequently used keys (e.g., keys to a safety deposit box at the bank, keys to a home safe, keys to a second home) are typically stored in a drawer, a closet, or a safe.

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.


On the other hand, typical house locks are (apparently) only locks by way of cultural convention.

(I say apparently because the ease of using things like bump keys is pretty widely publicized but I have never actually tried it myself)


Conventional locks are far less secure than most people would realize.

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.


In that respect it's like a bcrypted safe with a 4 character password and limited bandwidth.


I bet a lot of people would use the same key to open all those places if it were actually a plausible option.

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.


really surprised so many people that post here refuse to use google authenticator because its "annoying." is it a hassle? yes, but if you have ever had your email (and other accounts) compromised you understand why it is worth that small 5 second hassle when you login.

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


> 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.

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).


It's not a 5 second hassle. I don't get a cell signal in the steel gymnasium even though the wifi works fine. I physically have to go outside to get a code every time I want to log in. And then if my phone is not working, or I leave it at home, I'm screwed.


FTA:

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.

Also:

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.


Hm, can you generate new codes whenever you need to? It might be cool to use these 10 at a time as a one-time pad.


Yes, you can revoke those printed codes or issue more whenever you like.


You can create a new set whenever you want. However, generating a new set invalidates the previous set (so you can revoke access with those tokens if they are lost.


That's a fairly special case though right? The most common concern I hear (other than it's just too complicated) is privacy concerns. People are asking "why does Google want my cell"? What else is that number used for?


Leaving my phone home, or just having a dead battery, is not really a special case for me :)


Somebody should set up a website dedicated to listing organisations and what information is required in order to obtain access to an account at that organisation.


Like the second class citizens of the web we are, Nigeria does not have 2 factor authentication.

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.

https://accounts.google.com/b/0/SmsAuthConfig

http://oonwoye.com/2011/01/23/life-as-a-second-class-citizen...


> Why not Nigeria?

Can Nigerians use the Google Authenticator app?

If yes, then the answer is probably high SMS costs.


High SMS costs?

It is exactly why I put the range of countries above. Can we be in a worse situation than them all?


Then why? Lack of demand? Market not interested? Support costs too high?


All this talk about security and multiple authentication levels yet, your browser --if you use Chrome-- is the worst security leak in a persons digital life. It would take almost anyone a minute in front of a computer to fire-up Chrome and have every single login and password available in plain text.

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 think most people are aware that the passwords saved in their browser are, well, saved in their browser, and if someone unkind gains access to the browser they gain access to all the sites with saved passwords.


The point is that Chrome doesn't even make an attempt to slow down potential thieves. And, while I understand that absolute security is impossible, Chrome makes it so even a technology neophyte can steal your digital life with a few minutes of low-effort point-and-click action.

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.


Curious, could you point to a blog post or article that explains how to do this?


Here's what a thief could do:

Open Chrome

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.


I hear a lot of people advising to turn on two factor auth on Google because of this incident, but I haven't heard anyone say that we should be deleting our card details from Amazon. Well, I have, and you should too. Lots of places use the last 4 digits of your card as "authentication", and Amazon happily displays those details in your account.


Note that they had to break into the account in order to view those last 4 digits. You seem to be implying that they show them to anyone.

Either way, using the last 4 digits as 'security' is just stupid. You can get those from a receipt.


* Edit: Ah, technically they did break into the email account. The first time I read this I thought that they just had access to the account info page (doing things, such as purchasing or accessing account settings, requires password-entry by Amazon)

No, they did not have to break into the Amazon account.

http://www.wired.com/gadgetlab/2012/08/apple-amazon-mat-hona...

> 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.


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.


Why is it stupid for Amazon to show the last 4 digits? Let's say I have 3 cards on file. If I want to modify card #2 for some reason (billing address, expiry date) what do I do? Sure, I can look at the other details and take a guess, but we're on HN. On an average, the normal customer would get frustrated.


> Why is it stupid for Amazon to show the last 4 digits?

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.


Ah well, then I stand corrected. So, now the question becomes, should you be allowed to add credit cards over the phone? Or does it become, how long should Amazon wait until they accept the new credit card as a valid ID?

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".


They could do pre-authorizations on the card to make sure they are valid and match an address on file.


That's a good point. But wouldn't prepaid cards defeat this? I'm not an American so I don't know how the address verification on prepaid cards work.


Also, every recent credit card receipt printer puts at least the last 4 digits on paper receipts. A little dumpster diving could easily reveal that data.


I implied nothing of the sort.

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.


Deleting your card details from amazon does nothing since they happily display the last 4 digits in your invoice history anyways.


Is there a way to use a separate hardware device? Using my phone as the second factor is nice, but my phone is vulnerable to theft because of its value for resale.

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.


The linked article mentioned this: http://static.yubico.com/var/uploads/pdfs/Howto_GmailYubiKey...

YubiKeys are relatively cheap and would provide a nice alternative to using a phone, IMO.


I'm sure someone is probably working on this, but what about a service that generates a one off seed for the second stage of auth, married with either a desktop or smartphone app for generating it for the user. Lose your phone/laptop/PC simply cancel it remotely so it stops generating, same as you would if you lost your bank card.

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.


You can actually authenticate against the GA product from any system - hook it into PAM for sshd access, use it for another factor in OpenVPN, or even just wire it into Apache:

http://code.google.com/p/google-authenticator-apache-module/


Already on the market - YubiKey.


>Reality: You can tell Google to trust your computer for 30 days and sometimes even longer.

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?


The image linked from there says it's a new feature. I couldn't check it even by logging out of my account and logging in again (this doesn't deauth the computer? didn't know), so not sure if it's available for everyone yet.


I would add to that: Web developers, please implement two factor auth for your own apps as well. It takes minutes, literally, to add support for the Google Authenticator to your own app. I made a demo a while back inside of an hour. http://dendory.net/twofactors


That is very helpful. I'm going to be proposing this to work very soon thanks to you.


Two-factor auth gets old really fast when you have to use public computers in a setting like a college library. I had turned it on for a while, but turned it off when I had 5 minutes to print out a paper that I had emailed myself (yes, I still do that) and was fiddling with my phone to get the damn PIN. Never again.


Well, is that 5-minutes-to-print an edge case or a more than occasional situation? If the latter, how hard is it to create an alternate email account in which you send non-confidential emails/docs on the spur of a moment?

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.


Yeah, yeah, I should probably turn it on. And while I'm at it, I should probably eat more vegetables, less red meat and go to the gym. But I don't see those happening either ;).

Seriously though, when you have to enter the PIN multiple times a day, it gets annoying.


If you're entering it multiple times a day due to using public machines then you really, really should be using two-factor auth as many systems you use may be compromised in one way or another.


Maybe it's just me but I only trust computers I control.

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.

/tinfoilhat


You trust computers you control? That's so cute.

http://cm.bell-labs.com/who/ken/trust.html


True, but you can only go so far down the rabbit hole until you think you've done enough due diligence to remove as much risk as you feel comfortable with.


Yeah, that would be great if the damn wireless printing worked in school. Sometimes you just have to log into a public machine.


You couldn't use a USB key instead?


Sure I could. Not denying that there are other ways to get access to the files I need, just that this has become a part of my workflow that two-factor auth disrupts.


I think having a second gmail address just for emailin yourself files for public computers might work for you. Keep your personal email safe, and forward what you need to the other address. It's a good compromise.

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.


The problem of having to type in your password on an unsecured machine still exists.

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.


You'd only have to type in the password for an email you don't care about from the unsecured computer, as long as you knew ahead of time to forward the things you needed to print from the library computer. The web server method seems a little less secure since rather than having your files behind a non-two factor email account, they're publicly available. How is that better?


How much "fiddling" do you have to do to get your PIN? Unlock code or symbol, select authenticator app, read PIN? On top of loading Gmail and entering your user/pass?


The authenticator app might be the game changer for me - in the depths of mordor (aka library), I hardly ever get a cell signal.


To me, the use case you describe would make me very happy to be using two factor auth - logging into a very important personal account using untrusted, public computers I don't control. I'd be glad for the extra hassle with that.


I did this a few months ago, but I'm thinking of turning it off. I know it's trivial, but there's something deeply annoying about being dinged $0.20 a pop for the SMS message to get the code.

I'll have to see if I can set up the Google Authenticator; I hadn't heard of that before.


Even without GA (which, if you have an Android or iPhone, I don't see why you'd have to be without) $0.20 a month seems an incredibly small price to pay for the benefit of 2-factor auth.


I know, it's irrational, but it adds an extra annoyance factor, far more than it should. I mean, I spend far more every time I take the subway somewhere. Driving across the GW bridge costs $12, and I don't worry myself about that.

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.


which, if you have an Android or iPhone, I don't see why you'd have to be without

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...


You pay for incoming SMS? How does that even work?


Standard American mobile billing is to bill both parties, both caller and callee, for both voice and SMS. Contrary to the European practice where caller/sender pays everything.

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.


> Standard American mobile billing is to bill both parties

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.


For voice I actually like it somewhat better: I hate the European system where the caller can be charged extra because the recipient happens to be on a mobile phone, which you can't always even know before calling. In some cases it can be large; I've been charged $0.30/minute calling a Greek mobile phone in the past, as the caller, when I didn't know I was calling a mobile phone (if it were a landline I would've been charged <$0.10/min). I much prefer the American system where the caller just pays the flat calling-out rate, and it's the owner of the mobile phone who's responsible for the extra cost of mobile.

Paying both ways for SMS is a bit silly, though.


You pay a different price for calling a landline vs a cellphone? I'm still laughing. That's just crazy.


The reason I find it absolutely crazy is that you can't stop people from sending you messages. You can blacklist them (or use a whitelist) of course, but that's still "after" the offense. What happens if a millionaire prankster sends you 20 messages some day? You have t cough up something because of his prank? I find it unreasonable.

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.


> ... you can't stop people from sending you messages

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.


Back when cell phones weren't ubiquitous, I once worked at a start-up where one of the really rich technical leads thought it was unfair that he got charged when people called him on his cell phone. I guess he thought that the peons who could only afford land lines were supposed to subsidize him. Which I could have forgiven as plain old selfishness, but he also constantly complained about how unfair society was to the poor.

That specific combination of attributes still bugs me.


It is standard to pay for receiving as well as sending SMS in the US. Everybody knows this is insane.


It's not at all standard on smartphones though. Almost all data plans include at least several hundred texts per month.


Not on AT&T, as far as I can tell. It's either $20/month for unlimited messaging, or $0.20 each. So, unless you're sending or receiving more than 100 messages a month, you're better off without a plan.


I've got a 200 message/month plan from AT&T for $5 a month. My only complaint is that I can't share messages across the two lines on the account so each gets billed $5. (Also, no data plan.)


oddthink, I'd definitely check out Google Authenticator. It removes the need for any kind of SMS.


It's a good idea, but it's not the weakest link in user security right now. It does very little to solve problems like Apple positively identifying people based on totally insufficient and publicly available information.


> It's a good idea, but it's not the weakest link in user security right now

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.


>I suspect Google is in a better position to judge how widespread account compromises are than you are.

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)


My point was simply that Google sees enough attempts to compromise Gmail accounts that I believe them when they claim widespread attacks using valid passwords are common enough that passwords are broken.

> 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.


OK, so I turn on two-factor authentication for GMail, but...

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?


> 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.


>This also means that you're not entering the password which can do all of those things on a daily basis,

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?


Exactly. Let me know if you find an answer to this.

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.


You only type that application specific password once. You're not typing it to log in via wifi at coffee shops, airports, etc. You're not typing it every day for a keylogger to pick up, should your machine be compromised in the future. You're not typing it into borrowed machines or net cafe machines in some hotel business center.

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.


Calling it an "application specific password" is actually a misnomer. WE create the app-labels. For all practical purposes it's a backdoor entry into your account.

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.


> So your fancy two factor authentication still ends up resting on one piece of secret info as the weak point. Am I missing something?

A vastly reduced, easily managed attack surface area that in practice results in overwhelmingly fewer account compromises.


I've been avoiding doing this, and I'm not certain the reason is valid - I don't want Google to have my mobile phone number. Perhaps I'm being overly cautious, but the fact Google already collects such a huge amount of data on me, coupled with the increasing insistent requests to enable two-factor with my mobile phone number, has made me not do it. I got so sick of being pestered about it that I stopped using Gmail a little while ago.


You don't need to enter your phone number to use Google's two factor. You can use their smartphone application to generate codes. If you don't want to do that, the algorithm is free and open-source so you can probably find an alternate implementation that works fine.


As far as I'm aware, it's not available on Windows Phone 7.


Not GA itself, but there are compatible implementations: http://www.windowsphone.com/en-US/apps/021dd79f-0598-e011-98...


Unless I am mistaken, they won't let you do two-factor auth at all unless you put a phone number first.


I don't think they need a phone number if you use the Google Authenticator app on your phone. The pin for that is generated based on an initial random seed and the current date/time, not your cell number.


They do require it. If you remove it 2-factor-authentication is disabled.

Nothing says that number needs to be your mobile (or one that you have regular access to) but you do need to provide one.


Does that mean that you could use a Google Voice number? Presumably they already know that one, so "divulging" it shouldn't be an issue. ;^)


I can guarantee you that google knows your mobile number already. Do you have friends? do they know your number? do they have you saved as a google contact? game over.

If you are sufficiently paranoid there are probably call/sms-forwarding services available for a reasonable cost.


It's more than a little likely that they already have your number. They have your email address, and chances are that more than a few of your friends have a contact in their google contacts that has that same address alongside your phone number. You could argue that they can't be certain, but aggregated across however many of your friends have those same details stored for you they can make some pretty safe assumptions.


This is the same reason I avoid it. They were insistent about getting my phone number when it was just to verify after a lockout. They've been extremely insistent about it lately regarding 2-factor authentication, which leads me to believe there's a motive here beyond just getting everyone more secure. Until someone can alleviate me of that concern I think I'll have to pass.


Here's why I don't use two-factor authentication for my Google accounts.

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.


Please, please, please, please RTFA before ranting.

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.


Actually, neither of Google's methods require physical access, it's just easier if you have physical access.

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.


You still need to hunt for phone (on top of that you must have one) to log in...


That, and I don't trust "an app." The whole reason I want a second factor is to get away from computers as primary authentication mediums, and a smart phone is a computer.

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.


The Authenticator app is open-source [1] and extremely minimal. It doesn't run with permissions to access any data on the phone, or even communicate over the network; all it does is read the system clock every 30 seconds and compute an HMAC.

[1] http://code.google.com/p/google-authenticator/


The app isn't what worries me, it's what else is running on the phone. Android malware comes in the form of a rootkit, usually, which means it has total control over your device.

Not scared? How about this article[1] 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?

[1] http://www.guardian.co.uk/technology/blog/2011/mar/02/androi...


Be honest. When was the last time you were sitting at your (or any other) machine while away from your mobile phone?

Also, you only need the authenticator revolving token every 30 days.


What do you mean you only need it every 30 days? You keep the same session active for 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)


It will remember that it's authorized across multiple logins/logouts as long as you don't delete the cookie.


So it's basically the same security as adaptive authentication (aka challenge questions) but with the added annoyance and security flaws of using either SMS or an app.

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.


I accept your criticisms of SMS for authentication (I recently switched from SMS to the Android app), but I like two factor better than the approach you describe. If I log on to GMail from a public computer at a library with a keylogger installed, they will obtain my password but not enough to log in as me after I have signed out. Under the scenario you describe, I'd also type the answer to a challenge question, and they'd have both the password and the answer to the challenge question. That would leave me in a significantly worse position.


I really hope other services start offering it as a feature.

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 make it 4 blocks of 4 random alphanumerics each, which is a pretty big search space.


I'm getting 16 character app specific passwords having just turned it on on one of my Google Accounts (all lowercase alpha though).


the application specific passwords are 16 characters long. Four blocks of four lowercase characters.

I too would rather them be longer, and involve at least some numbers if not specials... but they're not THAT short.


Really? I was sure it was only 8 when I went through the process 2 weeks ago. 2 lots of 4.

Time to go and generate some new passwords!


Hmmm... I generated a batch about 2 months ago and another batch last week. In both cases, they were of the form

    llll llll llll llll
(l: [a-z])


Happy to stand corrected. My apologies all round.

Thanks everyone!


They've been 16 chars for at least several months.


> Is 8 good enough?

Depends on how good their intrusion detection is.


> Namecheap, I'm looking at you. DNS web apps are a huge possible attack vector.

The least they could do if offer IP whitelisting like Linode does.


Doesn't help if they target your provider:

  http://slashdot.org/story/12/03/02/0059202/linode-exploit-caused-theft-of-thousands-of-bitcoins


Just answer me this: why does Google insist on using a phone for this?

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.


From what I understand, a phone number is close to a primary key to people in the US these days.


I did this but was expecting more from Google. As an example, it was easier to add two factor auth to my Blizzard account (and install their authenticator) than it was for Google. These are the steps for Google: - Add mobile phone to account - Enter code from SMS - Generate random passwords for multiple apps which don't support two factor auth (this took awhile). - I wasn't given any instructions on how to switch from SMS to Google Authenticator app so I had to search for those instructions and then set that up.

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.


The difference is, as you mention, that for your Blizzard account there is one app that needs to be changed to use 2FA, whereas with Google you are using your account from dozens of apps that they do not control and that can not be made to support the 2FA login process. It's an unfair comparison.


Browser compromises are the one I worry about. A remote attack that reveals everything your browser has or knows.

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.


I'll propose a sideways solution: implement an "Administrator" mode on these accounts that requires separate authentication--perhaps enforcing two-factor authentication there.

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.


Quick question for all you security experts:

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.

Any ideas?


LastPass is only one persistent XSS flaw away from having your password store completely compromised. I found a non-persistent one last year which exposed a lot of information about you, but not your password:

https://grepular.com/LastPass_Vulnerability_Exposes_Account_...

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.


Thanks for the detailed info!

Combined with two-factor ssh auth[0] for using a public connection, looks my gpg file is the perfect solution.

[0] http://news.ycombinator.com/item?id=3029680


At the absolute best, I'd say using an app like Pocket (on Android) on a non-network connected device is probably the safest setup. Granted you'd have to type the passwords in manually, but nothing beats air-gap security, and you'd need to remember just one password.

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.


Sigh, OK. I'm turning it on today. Was going to do it right now, but then I realized that I'm at Starbucks right now... probably not the best time to be messing with passwords.


Do you trust the minimum wage customer service reps of your phone company to not be susceptible to social engineering?

Two factor-auth, via SMS, may not have saved Matt Honan.


Use the app, it's not vulnerable to such an attack.

Or buy a prepaid phone, and don't use the number for anything else.


I use 2FA, but it's an absolutely frustrating experience. Most apps just don't support it. Google Music Manager requires a trip to accounts.google.com for a new App Specific Password every time I restart my computer, whereas Swiftkey just loses its ability to offer suggestions until I manually re-authenticate, which takes several minutes every time it happens, while I wait for an SMS and switch between apps.


Sounds like something is wrong with your computer. I set up Music Manager months ago on two different computers and they have been humming along fine ever since.


It seems to work well with Firefox and Safari, but I've found that two-factor auth doesn't work well with Chrome if you've set it to clear cached files (not cookies) on exit. For some reason, that setting causes Chrome to lose the 30-day permission, so every time Chrome crashed or I rebooted my machine, I'd have to go through the SMS dance. Doesn't happen with the similar setting in Firefox.


Well I turned on two-factor authentication and then updated Sparrow (iOS and OS X) with the new password and everything was fine... Until the iOS version constantly kept telling me I had an incorrect password. I tried various troubleshooting tips online but to no avail. Until I can use this with everything I can't use it at all.


The only time I regret turning on TFA is when I'm laying in bed with my laptop and my phone is slightly out of reach.


turned it on. was so annoying that i removed google accounts.


What's the status of Google's two-factor authentication with Sync (Exchange)? Last time I tried it was a mess and the added security was not worth the hassle of not having everything pushed and kept up to date.


I'm glad this is on the front page again. I just set mine up. thx internet.


is there an authenticator that can run on my computer? i see an android app - is there something similar that can run on linux?

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.


Here are a few implementations that supposedly run on Linux, but I haven't tried them yet:

https://code.google.com/p/cuteauthenticator/

https://github.com/mclamp/jauth

http://blog.jcuff.net/2011/02/cli-java-based-google-authenti...

Also, Android can apparently be run in VirtualBox, but I haven't tried that yet, either:

http://www.buildroid.org/blog/?page_id=121


thanks.

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.


Question: How many designers/UX people were in the first meeting about two-factor authentication at Google? How many security engineers?


I turned it on. Had been meaning to for ages, but never did. Thank you, Mr. Article Writer.


I just turned two-factor authentication on and it forced me to set "program specific" passwords for like 10 different apps and seriously messed up my phone. I had to deactivate it. What's with the hassle?


Not everything supports the 2-factor auth. And of course you have to set up specific passwords for those. ONCE! You wont have to do that again. What did you expect? That it magically made everything work? Some people -.-

And I have no clue how you managed to mess up your phone… By entering new passwords??


Why can't they just use my "old" password? I don't want to set up 10 new passwords. And yes, I was expecting it to magically work by just enabling it and enter the SMS code. This is too much hassle for something I don't really care about (I don't keep anything of value anywhere online or in my computer/phone).


Why? Maybe because that would defeat the whole purpose?

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?


For the second factor to mean anything, all the apps that don't support it need a password that has less rights.

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).


Do those passwords have less rights? I figured that if any of those passwords got compromised, you were screwed (until you found out which one and revoked it).


A little less. They can't be combined with the 2nd step verification to make changes to settings that require 2 step verification.

So instead of losing access to your account, you just lose all your email (yay!).


This has always been the part I don't like about Google's 2-factor auth. Right now, I have one strong password that would have to be compromised to access my email. If I enable 2-factor, suddenly I have (last time I tried it) about 20 new passwords, any one of which could yield access to my email. That does not really seem more secure.


I think the more important question is whether it is less secure. It does make it harder to seize control of the account (which might be a lame consolation, but backups are a good idea either way), and it is (potentially) more convenient in the event that one device is lost or misplaced.

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.


It decreases the severity of a breach but increases the likelihood. Per-app passwords can't be used to take over an account. But they can be used to read my email. I think just shifting the permissions a little so that I can "authenticate" without also giving out the creds to my email would be acceptable.


Yeah, unfortunately it seems like the only rights it is missing is "update account information". Which is not much good when you are trying to protect your data.


How does it work with pop3/imap?


You can generate specific password for applications: http://support.google.com/accounts/bin/answer.py?hl=en&a...


did it today :)


I'm really frustrated with Google and this 2-factor authentication. They are in such a great position to really change the way in which people secure themselves and they've completely missed the trick [edit: FOR THE AVERAGE USER].

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:

http://www.readwriteweb.com/archives/facebook_wants_to_be_yo...


> it won't protect you from someone stealing your phone and opening your authenticator to login to your account

Why do they (and your malicious ex) know the other half needed to login - your password?


They don't need to know it. To reset your Google password you need your backup email account (Facebook / Work email ) or your telephone number or text. All of these are almost invariably accessible without further authentication via your phone. The protection that 2-factor authentication adds doesn't apply in the event that someone has the second factor. We're talking about the incremental improvement rather than the protection granted by your password.


Yeah, I'm sorry...I understand the parent post's rants, but to even bring up this scenario is absurd. If your nemesis knows your password, then you've royally screwed up, nevermind the problem with her having your phone.

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.


>Google 2-step auth is way too 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.

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.


How would you reset your password on your Google account Parfe?


  >   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.
How do you think the average person resets their password? I'm not talking about 2-factor auth as it applies to someone who keeps a PGP encrypted file on their machine I'm talking about it as it applies to the type of person who complains they can't log into Facebook through this page:

http://www.readwriteweb.com/archives/facebook_wants_to_be_yo...

I'll guarantee they don't have a firewalled second account.


Next time you ask a question don't act like the answer doesn't count just because it doesn't fit your stupid narrative. If you wanted to talk about how you think average people are too stupid to use 2-factor auth then just say it.

Your post is buried and won't harm others. Move on.


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.

Not rocket science.


> 2. Application specific passwords are impossible to use on mobile apps

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.


It does but it's almost impossible to access the Google auth page on the mobile and get the passwords.


I feel your pain, slightly, but isn't the majority of this list caused by the fact that Apple's software stinks? There's no way for apps on iOS to share the account details. You don't need to do any of that junk on Android. And you wouldn't have to do any of it on a Chromebook, either.


You don't have to do it on ios either (assuming your using the built-in mail/calendar/contacts). Ignoring that that OP was setting up multiple unique gmail logins (personal and work), the scenario he outlines requires entering exactly 1 app specific password per gmail account in the "mail, calendar and contacts". I have no idea why he's talking about using them in the browser, normal 2FA works fine there.

More

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: