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

Two-factor authentication should make it much harder for somebody to break into your email account (secret or otherwise) and reset your passwords.

Instead of memorizing horrible passwords, have you tried making a non-horrible passphrase by rolling dice and picking words out of a dictionary? Arnold Reinhold calls it Diceware:

http://world.std.com/~reinhold/diceware.html

It isn't easy to develop these habits, but my data is priceless to me. I know that too well because I've lost some of it, and it still hurts. So I've made it a tradition to chip away at it on daylight savings sundays: update clocks, check smoke detectors, work on backups, shame friends into doing same....



While two-factor authentication may be a good idea to gain access to sensitive information, I'm not sure it would be practical to use it for remote wiping devices. Typically the device you would want to wipe is one of the two factors.

(Which underlines the point that you need to do backups...)


Google's 2-factor auth comes with a list of onetime disposable keys one can use in place of not having their smartphone. I've had to use one specifically because I flashed a new Rom onto the Android device I was using before I thought about how I would setup the new Rom as a new device, which required me to log into my Google account. Almost the same idea as having the device get remote wiped unexpectedly. I keep a printed list of these keys in my fire safe at home with other important documents, like my birth certificate and passport.


Google will also call your home phone number and audibly speak a code to you if desired.

(Incidentally, you can backup and restore /data/data/com.google.android.apps.authenticator2/databases/databases via adb pull/adb push and you don't have to do the "painful" restore. It's slightly less secure, but I keep a copy on my SD card.)


Giant-flashing-neon-warning: if your phone's rooted (needs to be to pull /data), an attacker can pull it too. Use a passcode and enable full-device encryption (passcodes don't block recovery) to defend against this. If you're making full-image backups, wherever they're stored (on-device or elsewhere) needs to be secure too.

PS: even if you aren't rooted, if your device can be rooted w/o a wipe, should consider yourself just as vulnerable and enable FDE as well.


Yup, absolutely. I run FDE mostly just out of a personal policy that anything that someone can pick up and walk off with is encrypted, but this is a very good point.

The DB is a Sqlite3 database containing plaintext tokens and the account names they are used with, so while the attacker would still need your password, they can generate new tokens with that data.

Good policy upon losing any device that contains 2FA information is to use one of your backup codes to log into your account, remove the 2FA, and re-add it, thereby invalidating the old token secret. Thus, even if someone has your unprotected DB, they can't generate tokens for your account.


I like diceware a lot. The only drawback is that the pass phrases are too long for some sites.


Any site which has low upper bounds for password lengths is not to be trusted.


Certainly, I agree, but half the web is still that way. Many banking sites even.


I think it's a bit hyperbolic to call it half the web. Only a small handful of sites cap password lengths. They might happen to be sites you use, but it's not nearly as common a practice as you seem to think.


I don't think you're correct. Anyone who's storing a password in plaintext is probably going to use a fixed-width field to do so. I'd bet half the internet stores plaintext passwords. A lot of the web is one-off e-commerce systems that no one should trust anything with.


My bank caps at 12 chars -- silently. I couldn't login until i only typed the first 12 chars.


Are they actually using all that password length, or are they just allowing people to enter long passwords and truncating them?


I've used a system at work that truncates passwords when setting them, but not when checking them. It doesn't fill me with confidence.


The problem is that sites can truncated your password without telling you. Hard to make the call not to use a site if you don't know it is doing that.


I suppose you could attempt to log in while omitting the last character of your password to test against truncating.


True, good point.




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

Search: