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

My brain isn't working right now... Can you tell me why something like google authenticator could not be executed as a website? Does it have to be an app?

Just wondering if there could be an easier non installed version that was always available.

Apologies if it's a really silly question!



You can run TOTP in javascript sure http://blog.tinisles.com/2011/10/google-authenticator-one-ti...

But how do you protect access to the website - with a username and password? Or do people now need to remember another code like "JBSWY3DPEHPK3PXP" to set up the authenticator everytime they visit?

Mobile apps were one way to solve this although the hardware U2F tokens like Yubikey provide another authentication factor in a usable way (and more secure than TOTP because you can't be phished to enter them on the wrong site).


That's right, in fact if people remember that secret then it's not a "second factor" it's just another part of their password. A "factor" in the context of authentication means one of the various ways that can be used to verify someone's identity: "something you know" (password), "something you have" (non-duplicatable object, eg a SIM card or OTP token containing a secret that cannot be easily guessed or extracted), or "something you are" (biometrics).


> in fact if people remember that secret then it's not a "second factor" it's just another part of their password.

This is more generous than it should be. Your TOTP secret is just another part of your password regardless of whether you personally remember it or not; what matters is that, if I would like to be you, I only need to know the secret.


TOTP has a secret which is basically the seed of the calculation. The security basically comes from that secret being only on the phone you have and not being copyable. Moving it to the server removes that proximity. At least thats how i see it, but you could do it very easily server side if you wanted with equivalent security loss.


Having the secret only exist on a single phone is the most secure, but keeping a backup of the secret for recovery if you lose the phone only lowers security a negligible amount if you are careful about it.

If it is an account you set up from home, probably the simplest thing to do is print the setup page before you scan the QR code for the secret. Even better, print the page, and then scan that QR code from the printout. Then store the printout where you keep other important papers (e.g., mine would go in my fire proof safe).

Another possibility is to scan the code on two devices. I scan on both my iPhone and my iPad. Nearly all realistic scenarios that involve me losing both of those at near the same time also involve me dying.


People chasing perfect security by only putting their TOTP codes in one place seems like perfect being the enemy of good. Back up you codes people! Put them in an encrypted file and back that file up in a bunch of places.

Encrypting a file is a bit arcane, but not difficult:

  openssl enc -aes-256-cbc -pbkdf2 -iter 1024 -in plaintext.txt -out cryptotext.dat
Decrypting is about the same:

  openssl enc -aes-256-cbc -pbkdf2 -iter 1024 -d -in cryptotext.dat -out plaintext.txt
I'd suggest writing a couple of shell scripts. You might also want to overwrite the plaintext file with /dev/urandom afterward and delete it.


Do you have one encrypted file with all the codes, or do you have one file per code?

I prefer one file per code. When I get a new code, I make a directory named after the account the code is for, save a screenshot of the QR code in there, save a text file with the text version of of the code and any one-time recovery codes the site provided. I then make a .zip for .tgz from that directory, encrypt that, and save a copy in the cloud and locally. The local copy is in a location that is included in offsite backups.

If you use one file per code, I'd recommend using a public key system for the encryption. That way you don't have to enter any secrets to encrypt a new code. You only enter anything secret when decrypting.

This has a few advantages.

1. Less chance of accidentally exposing the key.

2. If like most people you use the same key for all the files, no chance of unknowingly mistyping the key resulting in a file that you cannot decrypt later.

3. If you need to recover a code, you only need to decrypt that code.

If as you suggest you wrap this in shell scripts, you can address #2 there. Have a reference file encrypted with your symmetric key. For encryption, the script can ask for your key and verify it was typed correctly by using it to decrypt the reference file.

Also worth considering is using an encrypted disk image. I believe that all major desktop operating systems provide reasonably easy ways to create, mount, and dismount such volumes. Whether you use one file per code or all codes in one file, the file or files can live on an encrypted volume that you only mount when you are saving a new code or recovering an old code.

The advantage of that is that there is no need to use any arcane commands or install any extra software.


Having a simple encrypted file means you can stuff it on an online backup though. The point is to have the keys stashed in several places so the loss of any one or two devices doesn't lock you out of your life.

I prefer keeping it as simple as possible since the consequences of screwing it up are a whole lot of hassle and possibly being locked out of some accounts forever. One downside is when you add or change a code you have to update all of your backups. A second script that syncs all of the backup files is also helpful to have.




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

Search: