Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Warning: Google Authenticator upgrade loses all accounts

news.ycombinator.com

Post reply on HN
Print view View original

51–60 of 176 posts

Re: Warning: Google Authenticator upgrade loses all accounts

#51

Post by ketralnis »

kibibu wrote: post #47
cdman wrote: post #38

Earlier quoted context omitted.

You had me until "backups are encrypted with PBKDF2". PBKDF2 is not encryption, it is a Key Derivation Function (it says so right in the name - KDF). Given that one of the developers is claiming that they are "encrypting" using PBKDF2 (which is in the same category as claiming that they are encrypting using MD5!), dissuades me from ever using it or recommending it.

I may be totally wrong, but isn't PBKDF2 useful exactly as a way to generate an encryption key from a password?

Sure, in the same way that MD5 is (although you'd want to use PBKDF2 instead of MD5). But you can't actually encrypt with PBKDF2 itself, much like you can't with MD5

Re: Warning: Google Authenticator upgrade loses all accounts

#52

Post by phlo »

kibibu wrote: post #47
cdman wrote: post #38

Earlier quoted context omitted.

You had me until "backups are encrypted with PBKDF2". PBKDF2 is not encryption, it is a Key Derivation Function (it says so right in the name - KDF). Given that one of the developers is claiming that they are "encrypting" using PBKDF2 (which is in the same category as claiming that they are encrypting using MD5!), dissuades me from ever using it or recommending it.

I may be totally wrong, but isn't PBKDF2 useful exactly as a way to generate an encryption key from a password?

You're perfectly right. PBKDF2 (Password-based Key Derivation Function 2) takes your password as an input, derives a key from it and outputs that. This key is then fed into an encryption algorithm like AES in order to actually encrypt anything.

Re: Warning: Google Authenticator upgrade loses all accounts

#53

Post by skeletonjelly »

noveltyaccount wrote: post #23

When I add sites to Authenticator, I take a screenshot of the QR code and tuck it away in an encrypted document (OneNote for the record, which uses uses AES to encrypt).

Have you tested this? Are the barcodes not time pertinent?

Re: Warning: Google Authenticator upgrade loses all accounts

#55

Post by markwakeford »

skeletonjelly wrote: post #53
noveltyaccount wrote: post #23

When I add sites to Authenticator, I take a screenshot of the QR code and tuck it away in an encrypted document (OneNote for the record, which uses uses AES to encrypt).

Have you tested this? Are the barcodes not time pertinent?

otpauth://totp/johndoe@google.com?secret=SECRETKEY1234567

Re: Warning: Google Authenticator upgrade loses all accounts

#56

Post by icecreampain »

I cannot fathom why people still rely on Google for their core business needs.

At my last place of work I built an SMS system to be used as the second factor in the intranet login. I _could_ have used a 3rd party 2FA, but the most _logical_ reason to have our own system was ... well.. we didn't want to rely on anyone except ourselves.

Didn't take me long and the most difficult part was finding enough USB-connected phones to be used as SMS senders.

Guess what? The system still works today, why Google is broken.

Re: Warning: Google Authenticator upgrade loses all accounts

#57

Post by markbao »

skeletonjelly wrote: post #53
noveltyaccount wrote: post #23

When I add sites to Authenticator, I take a screenshot of the QR code and tuck it away in an encrypted document (OneNote for the record, which uses uses AES to encrypt).

Have you tested this? Are the barcodes not time pertinent?

(I've studied two-factor authentication using HOTP and TOTP, and built a node.js implementation of it.)

The QR codes simply divulge a URI with the secret key for generating tokens. They look like:

  otpauth://totp/[keyname]?secret=[secretkey]
The secret key is used in the app in conjunction with a moving factor (usually 30-second intervals of time) to generate a numerical hash of sorts for that interval of time, which is then truncated to 6 characters.

The QR code itself doesn't have any sort of time limit on them; they only serve to transmit the secret key.

Re: Warning: Google Authenticator upgrade loses all accounts

#58

Post by lalc »

devx wrote: post #54

This is the sort of "nightmare scenario" I'm afraid of, and why I'm still not using 2FA. I'd rather risk having only a weaker password, than risking losing my accounts for good. You can't get back into your accounts if something like this happens, right?

To get back into your account you're provided backup codes that you're supposed to store somewhere safe. Otherwise, if your phone were stolen you'd be out of luck, yes.

Re: Warning: Google Authenticator upgrade loses all accounts

#60

Post by noveltyaccount »

markbao wrote: post #57
skeletonjelly wrote: post #53

Earlier quoted context omitted.

Have you tested this? Are the barcodes not time pertinent?

(I've studied two-factor authentication using HOTP and TOTP, and built a node.js implementation of it.) The QR codes simply divulge a URI with the secret key for generating tokens. They look like: otpauth://totp/[keyname]?secret=[secretkey] The secret key is used in the app in conjunction with a moving factor (usually 30-second intervals of time) to generate a numerical hash of sorts for that interval of time, which…

This. I scanned one QR code with a regular QR code reader and came to the same conclusion...

I haven't actually tested it though. :-/

Post reply on HN