5 ms·

It's rife in the industry. The drama this week is that my wife can't log in to Facebook because their code generator just doesn't work. The number in the app sh

by hnick 6y ago

It's rife in the industry. The drama this week is that my wife can't log in to Facebook because their code generator just doesn't work. The number in the app shows up, she types it, but she can't log in because apparently it's just wrong. Due to their marvelous design, you need a personal account to run an advertising account for your place of work. Luckily she hasn't been logged out on her work laptop yet or she couldn't do a large part of her job. Business support? Yeah good luck, try googling and you'll get pages of dead links or suggestions to click something when you're already logged in.

JimDabell 6y ago
If you haven’t already, check the time / date / timezone on the device that is generating the codes. Facebook uses TOTP for this, which is time-based. If the time on your device is wrong, the codes will be wrong. I would expect this problem to pop up more frequently this time of year due to errors relating to daylight saving time.
- kokx 6y ago
  DST has nothing to do with TOTP. The TOTP spec specifies that unix time has to be used as the time source, which does not have DST.
  - JimDabell 6y ago
    That doesn't matter, DST-related events can still break TOTP. Example: Device is set to the wrong timezone. It’s nearby, but the difference between the two timezones is that one has DST and one doesn’t. DST comes along, either the time changes by an hour when it isn’t supposed to, or it doesn’t change when it is supposed to. The most visible thing that looks broken to the user is not the timezone, but the time. So they adjust the time. The user-visible clock is now “correct” for the next six months as far as the user sees, but the system clock – including UNIX timestamps – is incorrect by an hour. This results in broken TOTP.
    - kokx 6y ago
      I find this awfully thin. About every device that does TOTP by default takes its time from the network provider, and lets the user set the correct timezone, and makes it even really easy to do so. Since most DST settings for timezones in the world are quite predictable (yes I am aware that there are few that have last-minute changes, but most don't, especially not in developed nations), most people never have to adjust their timezone because of DST. Though I do suspect that Google Authenticator even has some logic to reduce these problems, since you can "sync" its time in the settings.
      - JimDabell 6y ago
        “Lets the user set the correct timezone” is where this falls down. The user doesn’t always get this right. Once that happens, the time looks correct for a while, then looks wrong all of a sudden. So they go into their settings and manually change the time. At that point taking time from the network provider no longer happens, because they overrode that. The predictability of DST doesn’t help, and “most people never have to adjust their timezone” isn’t relevant either. Perhaps you didn’t fully grasp what was happening in the example? All of the machinery works correctly, it’s just the first time they set up the computer the timezone was wrong, or they moved. Everything after that point can work correctly, but if that thing is wrong, UNIX time will be wrong even if the time looks right to the user. I’ve literally had to fix this problem for people. “Correct” time, incorrect timezone. It’s not a theoretical example.
- justinclift 6y ago
  > check the time / date / timezone on the device that is generating the codes. Sounds like that'd be on the FB infrastructure side though?
  - remus 6y ago
    The clocks on both devices (i.e. fb's server and your phone) need to be fairly closely synchronised. TOTP effectively encrypts a timestamp using a shared secret then decrypts it on the other side and checks you're within some bound. If either clock is out it won't work.
  - ncallaway 6y ago
    TOTP generates the codes on both the client and server sides. The user enters the client generated code and the server validates it. So if the time on the client device is wrong (perhaps it was manually set and not updated for daylight savings), then the server will disagree with what the code should be.
- hnick 6y ago
  It's the FB app on a new iPhone, set to Sydney where we live. There are no DST options I assume "it just works" covers all that. There is an option to resync inside the FB app, which refreshes and... doesn't change a thing. Your advice is appareciated though and I'll keep it in mind for the future. Back to my original comment though. Want support? Maybe you will go to https://www.facebook.com/business/help https://www.facebook.com/business/help and read the part that says "Find answers or contact support" and click the button. This brings up an overlay with the usual SaaS buffet of simple answers for simple questions and not too much else. Click on one, don't find your answer, but wait! There is a message under it! "Need more help? Contact support." Yet no link. No button. Just dead text. This is how multi-billion dollar companies operate in the 21st century.

by hnick 6y ago

JimDabell 6y ago

If you haven’t already, check the time / date / timezone on the device that is generating the codes. Facebook uses TOTP for this, which is time-based. If the time on your device is wrong, the codes will be wrong. I would expect this problem to pop up more frequently this time of year due to errors relating to daylight saving time.

kokx 6y ago
DST has nothing to do with TOTP. The TOTP spec specifies that unix time has to be used as the time source, which does not have DST.
- JimDabell 6y ago
  That doesn't matter, DST-related events can still break TOTP. Example: Device is set to the wrong timezone. It’s nearby, but the difference between the two timezones is that one has DST and one doesn’t. DST comes along, either the time changes by an hour when it isn’t supposed to, or it doesn’t change when it is supposed to. The most visible thing that looks broken to the user is not the timezone, but the time. So they adjust the time. The user-visible clock is now “correct” for the next six months as far as the user sees, but the system clock – including UNIX timestamps – is incorrect by an hour. This results in broken TOTP.
  - kokx 6y ago
    I find this awfully thin. About every device that does TOTP by default takes its time from the network provider, and lets the user set the correct timezone, and makes it even really easy to do so. Since most DST settings for timezones in the world are quite predictable (yes I am aware that there are few that have last-minute changes, but most don't, especially not in developed nations), most people never have to adjust their timezone because of DST. Though I do suspect that Google Authenticator even has some logic to reduce these problems, since you can "sync" its time in the settings.
    - JimDabell 6y ago
      “Lets the user set the correct timezone” is where this falls down. The user doesn’t always get this right. Once that happens, the time looks correct for a while, then looks wrong all of a sudden. So they go into their settings and manually change the time. At that point taking time from the network provider no longer happens, because they overrode that. The predictability of DST doesn’t help, and “most people never have to adjust their timezone” isn’t relevant either. Perhaps you didn’t fully grasp what was happening in the example? All of the machinery works correctly, it’s just the first time they set up the computer the timezone was wrong, or they moved. Everything after that point can work correctly, but if that thing is wrong, UNIX time will be wrong even if the time looks right to the user. I’ve literally had to fix this problem for people. “Correct” time, incorrect timezone. It’s not a theoretical example.
justinclift 6y ago
> check the time / date / timezone on the device that is generating the codes. Sounds like that'd be on the FB infrastructure side though?
- remus 6y ago
  The clocks on both devices (i.e. fb's server and your phone) need to be fairly closely synchronised. TOTP effectively encrypts a timestamp using a shared secret then decrypts it on the other side and checks you're within some bound. If either clock is out it won't work.
- ncallaway 6y ago
  TOTP generates the codes on both the client and server sides. The user enters the client generated code and the server validates it. So if the time on the client device is wrong (perhaps it was manually set and not updated for daylight savings), then the server will disagree with what the code should be.
hnick 6y ago
It's the FB app on a new iPhone, set to Sydney where we live. There are no DST options I assume "it just works" covers all that. There is an option to resync inside the FB app, which refreshes and... doesn't change a thing. Your advice is appareciated though and I'll keep it in mind for the future. Back to my original comment though. Want support? Maybe you will go to https://www.facebook.com/business/help https://www.facebook.com/business/help and read the part that says "Find answers or contact support" and click the button. This brings up an overlay with the usual SaaS buffet of simple answers for simple questions and not too much else. Click on one, don't find your answer, but wait! There is a message under it! "Need more help? Contact support." Yet no link. No button. Just dead text. This is how multi-billion dollar companies operate in the 21st century.