Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I use the Google Authenticator app, which makes the token only available to that specific device, rather than through SMS. This gets around the problem of cloning a phone number.

iOS: http://itunes.apple.com/us/app/google-authenticator/id388497...

Android: https://play.google.com/store/apps/details?id=com.google.and...



I use this too, but I don't think it actually prevents the attack described in the article, at least in my case. When I setup my 2-factor auth for my Google account, I also setup a series of backups in case I lost access to my phone. One of them was my phone number, and another was a phone number of a trusted friend.


It prevents human engineering of the phone company. One might hope that Google would be better at the security implementation (i.e. the BT operator apparently "validated" an incorrect password, which indicates to me that it was a quick hack, probably just a field in the customer record about which the operators weren't trained).

Also: I'd hope that Google wouldn't allow a complete account reset based solely on the backup device. That should be a backup for your second factor only, you should still need the password.


You can remove your number as a backup source and restrict it to only use the app and the printed backup numbers.


Does the app notify you when authentication is attempted? The reason I still use SMS is that I will instantly get notified if someone has my password and attempts to access my account.


I was worried about someone getting into my account so I made this: http://blog.jgc.org/2011/06/my-email-canary.html


Whilst a cunning idea if it catches some unsophisticated crook who just dives in and starts looking for goodies, I'd expect that it's common enough knowledge (e.g. image-bugs dropped in spam to check account liveness) that a serious attacker would either slurp your account via IMAP/POP and browse with external resource loading disabled, or just enable that setting in your gmail account itself, which exists for exactly the reason mentioned above.

The main improvement I can see you've made is that it's real-time enough that you should be able to jump on it straight away and do something rather than the batch processes I suspect spammers use.

There was a cunning|creepy trick used by Facebook I recall reading about not that long ago[1] that relied on Outlook autoloading bgsound attributes despite image loading settings, but I don't know of any comparable holes in gmail.

[1] http://pandodaily.com/2012/03/06/facebook-knows-when-you-ope...


Since I already get a text message each time I authenticate, I'd even be in favor of one that just texted me each time I authenticated a new computer. That way I could use the security of the app, but the notification of sms.

I believe Facebook used to do just the notification part with some optional security feature where you had to name each new computer you used. They have 2 factor now, of course.


You cant log in without the App from an untrusted computer, the app is not connected to the internet, there are no notifications.


So it's basically similar to an RSA token, but as an app (and capable of addressing multiple accounts).


You can still press "don't have your phone?" and send a code through SMS, unless there's a way to disable that.


Yes. You can disable it.


Wait what? What good would receiving an SMS be if you don't have your phone?


It goes to a backup number you add that is the phone number of a friend or other phone number you specify.

Don't do what I did and stupidly use your google voice number. facepalm



Is it possible that the app runs in sandbox? Or is that already the case?


> Is it possible that the app runs in sandbox? Or is that already the case?

Why does that matter?


So that other applications cannot steal the generated code. I think the easiest way to steal the code is to OCR a screenshot.


If you remember the great HN "iOS is faster; you're wrong because Android isn't slow" debate of a few months back, the primary reason that android runs slower than you'd expect is that apps have absolutely no access to each other's frame buffers. Apps can't take screen shots of other apps (for exactly this reason)


Does anyone know how this works? It reminds me of a RSA SecurID but since it's only in software, can't it be reverse engineered?






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

Search: