5 ms·

I had a fright last time I changed phones. After restoring my backup onto the new phone, I was about to wipe the old one; I did a final pass through my apps jus

I had a fright last time I changed phones. After restoring my backup onto the new phone, I was about to wipe the old one; I did a final pass through my apps just in case... and saw that Google Authenticator configuration did not carry over to the new phone (which makes sens from a security perspective but is a PITA to manage). I had to re-enroll my device with all the services on which I use MFA. After this episode I made damn sure I had recovery codes stored in a safe place.

kkreamer 7y ago
Use Authy, which does carry over.
fencepost 7y ago
You can also have more than one device set up for TOTP - phone, previous phone or tablet, desktop using WinAuth or similar. Authy and the password managers will also track those seed values, though it's best to store them separately from your actual password storage. Another thing that will not migrate phone to phone is Signal conversations if you're inclined to keep those.
- laurentl 7y ago
  Yes, I lost my Signal conversation history as well and had to be re-added to all group conversations (another PITA). How do you store seed values in password managers? More specifically: how do you export them from Coogle Authenticator? (I’ve not found that option). And how do you import them again?
  - fencepost 7y ago
    I'm unaware of any options to export, that would be a security issue. To store the seed values, simply store the text provided for use if you can't use the qr code.
    - laurentl 7y ago
      ISTR at least one service (AWS or Google) asking for the first 2 codes after scanning the QR code, probably to sync. So I always assumed simply re-scanning the QR code wouldn’t be enough but maybe it is this simple.
      - fencepost 7y ago
        The underlying technology behind (almost?) all of these is TOTP (https://en.wikipedia.org/wiki/Time-based_One-time_Password_algorithm https://en.wikipedia.org/wiki/Time-based_One-time_Password_a...) which pretty much just depends on both systems having clocks that are reasonably close to synced. The initial value is basically a random number generator seed, and given the seed and a number of iterations (based on the time differential from a set starting point) calculating a code is fairly simple. There would be problems on fully-isolated systems experiencing clock drift, but on any modern Internet-connected system using NTP or on any cell phone with time synced to the network it shouldn't be a factor. The most likely problem scenario is probably a corporate network using only an internal time source that drifts. Doing a single code as validation only makes sense to catch transcription errors since in case of problems someone could end up locked out of an account.
jopsen 7y ago
Print the QR codes, put them inside a plastic bottle and bury them 6 feet down in your parents backyard under the cover of darkness. -- the more elaborate, the more cool you feel doing it :)
Silhouette 7y ago
When a family member had a phone stolen not long ago, the only major functionality on it that they couldn't quickly and securely disable was the Google stuff. The procedures for doing so seemed to be unnecessarily complicated and difficult to find when starting, ironically, from a Google search on another device. Worse, the security policies seemed to be fundamentally flawed, because they kept insisting on some form of authentication based on a trusted device when the purpose of the transaction was to notify them that the trusted device had been stolen. There has been an unhealthy trend recently of assuming that everyone has a mobile phone and that communications to that phone/number are a good method of authentication, without adequate thought to what happens if the physical device and/or the associated phone number are compromised, or to whether protocols like SMS are really suitable for this sort of application. And some of the really important things, like banks and government services and email providers (which are in practice a gateway to everything else you do online) are often among the worst offenders. I don't know what to do about this, but certainly raising awareness of this kind of problem would be a good start.
- drivebycomment 7y ago
  > Worse, the security policies seemed to be fundamentally flawed, because they kept insisting on some form of authentication based on a trusted device when the purpose of the transaction was to notify them that the trusted device had been stolen. Are you suggesting any random person without any authentication proof to be able to just sign people out of their devices ? That would be a broken security.
  - Silhouette 7y ago
    I'm suggesting that a security policy should actually be practical. There are any number of viable ways to handle this. Requiring someone to possess the device they are reporting stolen is not one of them.

kkreamer 7y ago

Use Authy, which does carry over.

fencepost 7y ago

You can also have more than one device set up for TOTP - phone, previous phone or tablet, desktop using WinAuth or similar. Authy and the password managers will also track those seed values, though it's best to store them separately from your actual password storage. Another thing that will not migrate phone to phone is Signal conversations if you're inclined to keep those.

laurentl 7y ago
Yes, I lost my Signal conversation history as well and had to be re-added to all group conversations (another PITA). How do you store seed values in password managers? More specifically: how do you export them from Coogle Authenticator? (I’ve not found that option). And how do you import them again?
- fencepost 7y ago
  I'm unaware of any options to export, that would be a security issue. To store the seed values, simply store the text provided for use if you can't use the qr code.
  - laurentl 7y ago
    ISTR at least one service (AWS or Google) asking for the first 2 codes after scanning the QR code, probably to sync. So I always assumed simply re-scanning the QR code wouldn’t be enough but maybe it is this simple.
    - fencepost 7y ago
      The underlying technology behind (almost?) all of these is TOTP (https://en.wikipedia.org/wiki/Time-based_One-time_Password_algorithm https://en.wikipedia.org/wiki/Time-based_One-time_Password_a...) which pretty much just depends on both systems having clocks that are reasonably close to synced. The initial value is basically a random number generator seed, and given the seed and a number of iterations (based on the time differential from a set starting point) calculating a code is fairly simple. There would be problems on fully-isolated systems experiencing clock drift, but on any modern Internet-connected system using NTP or on any cell phone with time synced to the network it shouldn't be a factor. The most likely problem scenario is probably a corporate network using only an internal time source that drifts. Doing a single code as validation only makes sense to catch transcription errors since in case of problems someone could end up locked out of an account.

jopsen 7y ago

Print the QR codes, put them inside a plastic bottle and bury them 6 feet down in your parents backyard under the cover of darkness. -- the more elaborate, the more cool you feel doing it :)

Silhouette 7y ago

When a family member had a phone stolen not long ago, the only major functionality on it that they couldn't quickly and securely disable was the Google stuff. The procedures for doing so seemed to be unnecessarily complicated and difficult to find when starting, ironically, from a Google search on another device. Worse, the security policies seemed to be fundamentally flawed, because they kept insisting on some form of authentication based on a trusted device when the purpose of the transaction was to notify them that the trusted device had been stolen. There has been an unhealthy trend recently of assuming that everyone has a mobile phone and that communications to that phone/number are a good method of authentication, without adequate thought to what happens if the physical device and/or the associated phone number are compromised, or to whether protocols like SMS are really suitable for this sort of application. And some of the really important things, like banks and government services and email providers (which are in practice a gateway to everything else you do online) are often among the worst offenders. I don't know what to do about this, but certainly raising awareness of this kind of problem would be a good start.

drivebycomment 7y ago
> Worse, the security policies seemed to be fundamentally flawed, because they kept insisting on some form of authentication based on a trusted device when the purpose of the transaction was to notify them that the trusted device had been stolen. Are you suggesting any random person without any authentication proof to be able to just sign people out of their devices ? That would be a broken security.
- Silhouette 7y ago
  I'm suggesting that a security policy should actually be practical. There are any number of viable ways to handle this. Requiring someone to possess the device they are reporting stolen is not one of them.