Sooooo, Steam stole my account

[A Meat Popsicle]

When you're locked out of an account because Steam authenticator is so ♥♥♥♥ that it denies the authentication code it just sent to your damn cell phone. Check and mate, I guess? You can have the account if you want it that bad!

[voidCaster]

引用自 cinedine：

引用自 Gematria：

They'd have to communicate somehow, otherwise you could just plug in any random value when Steam asks for a Guard Code.

Uhm, no.
There is a slight delay between the generation and the timecode used (if you are fast enough to input, your code is actually still invalid). Both use Unix time anyway. So yes, your device shouldn't be off too much, but there is no need to communicate between server and generation device. Standalone 2FAs are completely offline.

Try reading and responding to whole posts. Also try not talking about things you don't really understand. It's obvious and rude to everyone else.

[Quint the Alligator Snapper]

引用自 Gematria：

引用自 Quint the Alligator Snapper：

FYI cell phone authentication codes are actually not sent to the phone, but generated independently on the phone, presumably according to a proprietary algorithm that's dependent on the user account, the device, and the current time, as far as I know. I think it still works even if the phone's connections to the outside world are severed completely.

They'd have to communicate somehow, otherwise you could just plug in any random value when Steam asks for a Guard Code. The "current time" factor for example would demand that both devices be synced with the same NTP Server. It's pretty trivial for Steam to be able to query any NTP Server anywhere, but if the phone had been offline for as little as 20-30 minutes there's going to be "drift." All drift means is that a computer can only account for time by the number of processor cycles or ticks that occur, and at the speed modern CPUs run there's always going to be some float value remainder when you divide the number of ticks that have passed by the number of ticks the CPU generally makes per second. There are other factors, but that's a big one. I can't see how either end could reliably generate a code and have the other recognize it without some kind of synchronization between the two.

They just need to be in the same time zone. And have any time drift corrected (which standardly happens on any device that is already internet-enabled).

The mobile app basically is an automaton that has been given a formula to use to spit out auth codes. The formula is a function of the account and the time, and outputs a string of characters that appears random but is always the same at any given time and for the same account. It is also presumably a complicated function, making it hard to replicate, for security reasons. But anything that knows this formula can replicate the "correct answers".

[Ogami]

Make sure that your phone and Steam client run at the exact same time.
More then a minute or so difference and the code will not work.

[Muppet among Puppets]

引用自 Quint the Alligator Snapper：

It is also presumably a complicated function, making it hard to replicate, for security reasons. But anything that knows this formula can replicate the "correct answers".

It is based on a secret "passphrase", but the required result is changing in time.

Its not harder to replicate than the passphrase itself.
Just the user can not hand this one out, i mean, he could, but he is not told to keep it.

[Tito Shivan]

引用自 Quint the Alligator Snapper：

The mobile app basically is an automaton that has been given a formula to use to spit out auth codes. The formula is a function of the account and the time, and outputs a string of characters that appears random but is always the same at any given time and for the same account. It is also presumably a complicated function, making it hard to replicate, for security reasons. But anything that knows this formula can replicate the "correct answers".

Probably a lot of users are too young to remember or have used one, but Steamguard codes are not much different of the old RSA SecurID keychains.
https://en.m.wikipedia.org/wiki/RSA_SecurID
Of course those keychains were totally offline code generators. Just like the Steamguard codes work.

And you get a Steam notification with the code you have to input not because it's sent to you but Steam simply sends a push notification to the app to display whatever code the algorythm is outputting at that very moment.
One can put their phone in airplane mode and it'll still generate codes and they still work.

[voidCaster]

引用自 Quint the Alligator Snapper：

引用自 Gematria：

They'd have to communicate somehow, otherwise you could just plug in any random value when Steam asks for a Guard Code. The "current time" factor for example would demand that both devices be synced with the same NTP Server. It's pretty trivial for Steam to be able to query any NTP Server anywhere, but if the phone had been offline for as little as 20-30 minutes there's going to be "drift." All drift means is that a computer can only account for time by the number of processor cycles or ticks that occur, and at the speed modern CPUs run there's always going to be some float value remainder when you divide the number of ticks that have passed by the number of ticks the CPU generally makes per second. There are other factors, but that's a big one. I can't see how either end could reliably generate a code and have the other recognize it without some kind of synchronization between the two.

They just need to be in the same time zone. And have any time drift corrected (which standardly happens on any device that is already internet-enabled).

The mobile app basically is an automaton that has been given a formula to use to spit out auth codes. The formula is a function of the account and the time, and outputs a string of characters that appears random but is always the same at any given time and for the same account. It is also presumably a complicated function, making it hard to replicate, for security reasons. But anything that knows this formula can replicate the "correct answers".

Just on the first sentence: They don't really need to be in the same timezone. All timezones are just an offset from GMT or UTC. They really just need to work with the same timestamp data, but it has to be exactly the same data - that is 64 bits must be identical on both ends. So you can turn any time value into UTC if you know the timezone that value was generated for, as long as both ends are synchronized as far as system time goes.

On the second sentence: This was the point of what I was responding to. It's why I quoted a post before writing my remarks. Someone said "the phone could be completely cut off from the internet and it would still work" and that just isn't realistic or true where computers of differing speeds are working with timestamps. As you say, any given system tends to synchronize with an NTP server frequently enough to prevent time drift in the first place. You absolutely need internet for that.

It's possible that it doesn't even use a timestamp. I'm not going to pretend I know exactly how the devs built that app. It might be functional even after the phone is offline for a week straight. If so though, I don't see how it could be done using a timestamp on either end. Using local system time, even correcting for timezone to UTC, both systems would have to be using the same NTP server.

引用自 Tito Shivan：

Probably a lot of users are too young to remember or have used one, but Steamguard codes are not much different of the old RSA SecurID keychains.
https://en.m.wikipedia.org/wiki/RSA_SecurID
Of course those keychains were totally offline code generators. Just like the Steamguard codes work.

And you get a Steam notification with the code you have to input not because it's sent to you but Steam simply sends a push notification to the app to display whatever code the algorythm is outputting at that very moment.
One can put their phone in airplane mode and it'll still generate codes and they still work.

Using that method is different from just grabbing a timestamp as a random generator seed, but I'm pretty sure those key algorithms still rely on system time for something. As noted previously, the system would have to be offline for awhile before any timestamp drift occurred. So did you test this by putting the phone in airplane mode and trying a guard code immediately, or did you wait half a day or more to give the offline system time to lose a few milliseconds?

[Muppet among Puppets]

Just set the same time manually, if you have to.

[cinedine]

引用自 Gematria：

Just on the first sentence: They don't really need to be in the same timezone. All timezones are just an offset from GMT or UTC. They really just need to work with the same timestamp data, but it has to be exactly the same data - that is 64 bits must be identical on both ends. So you can turn any time value into UTC if you know the timezone that value was generated for, as long as both ends are synchronized as far as system time goes.

On the second sentence: This was the point of what I was responding to. It's why I quoted a post before writing my remarks. Someone said "the phone could be completely cut off from the internet and it would still work" and that just isn't realistic or true where computers of differing speeds are working with timestamps. As you say, any given system tends to synchronize with an NTP server frequently enough to prevent time drift in the first place. You absolutely need internet for that.

Again: no.
Codes are generated in intervalls, are a bit in the future and are valid for a certain timespan. unix time uses milliseconds. The diference between two machines won't exceed seconds in years. So the delay and validity more than compensates for this.
There is absolutely no communication or synchronization needed between device and server and there are devices which are not even capable of connecting to the internet.

There are three reasons why a verification can fail:
- you are too quick with your input (can happen for automated processes unlikely for human users)
- you are too slow with your input
- your device is not registererd to this account (or vice versa)

[voidCaster]

引用自 cinedine：

引用自 Gematria：

Just on the first sentence: They don't really need to be in the same timezone. All timezones are just an offset from GMT or UTC. They really just need to work with the same timestamp data, but it has to be exactly the same data - that is 64 bits must be identical on both ends. So you can turn any time value into UTC if you know the timezone that value was generated for, as long as both ends are synchronized as far as system time goes.

On the second sentence: This was the point of what I was responding to. It's why I quoted a post before writing my remarks. Someone said "the phone could be completely cut off from the internet and it would still work" and that just isn't realistic or true where computers of differing speeds are working with timestamps. As you say, any given system tends to synchronize with an NTP server frequently enough to prevent time drift in the first place. You absolutely need internet for that.

Again: no.
Codes are generated in intervalls, are a bit in the future and are valid for a certain timespan. UTC uses milliseconds. The diference between two machines won't exceed seconds in years. So the delay and validity more than compensates for this.
There is absolutely no communication or synchronization needed between device and server and there are devices which are not even capable of connecting to the internet.

There are three reasons why a verification can fail:
- you are too quick with your input (can happen for automated processes unlikely for human users)
- you are too slow with your input
- your device is not registererd to this account (or vice versa)

You're just wrong because you don't really understand what computer times are or how they work. You probably aren't even aware that NTP services are in use, or if you are aware then your grasp of the concept is about as deep as an armpit.

"UTC" is just "GMT." It's the time of day at the prime meridian on the real, actual earth. It's a timezone. It's not technical or digital or controlled by the decay of radioactive isotopes.

So-called "atomic clocks" are technical and digital and controlled by the decay of radioactive isotopes, and they typically align with GMT - which is why Greenwich Mean Time gets that snazzy new moniker Universal Time Coordinated. There's nothing special about UTC as a timezone except that it's become a baseline for recording agencies.

Network Time Protocol is a service run for coordinating time across networked devices. You either have one on your local area network or you're using one from the internet or your physical PC is keeping its own time. Typically a LAN NTP service will in turn synchronize with an internet based NTP service offered by an atomic clock agency, such as the US Navy. When your computer keeps its own time, it does so with a degree of inaccuracy that expands over time.

Spend some time researching these terms before you go spitting out nonsense about how UTC has anything to do with anything except as a pre-defined and mutually-agreed variable value in computing worldwide.

You may be right that a phone or PC doesn't have to be online for the Steam Guard app to generate a code that will be recognized by Steam Servers, but it has nothing to do with whether UTC recognizes "milliseconds" or not because UTC doesn't. Every computer that keeps time, by NTP or by itself, will in fact return a 64-bit timestamp value that includes smaller-than-millisecond values typically expressed as "ticks" or CPU operational cycles. Where modern CPUs are rated in kilohertz (thousands of ticks per second) or gigahertz (millions of ticks per second) you have to perform long division to keep time using a computer. There's always a remainder which is most sensibly (but not always) rounded down when you convert from System Time to Human Readable Time.

When you're not connected to the internet (and/or not configured to use NTP services in the first place) your computer will lose milliseconds per hour. Period. Reality. Quit lying to people. Thanks!

[☕ Grüntherspöth 🍟]

pretty sure the guy is already logged back,
He typically act like those guys ranting like it's the end of the world before actually trying anything...
*tilt* how did he even post with his account if he cant connect?

[Quint the Alligator Snapper]

引用自 Gematria：

When you're not connected to the internet (and/or not configured to use NTP services in the first place) your computer will lose milliseconds per hour. Period. Reality. Quit lying to people. Thanks!

FYI the Steam mobile authenticator codes last 15+ seconds -- the code stays up for about 15 seconds, and then afterwards, there's an additional leeway time of at least several seconds.

If we go by what you're saying -- "your computer will lose milliseconds per hour" -- this means that, for every 1 ms/hr that the computer goes off track, and for every day that passes, the computer can go a maximum of 24 milliseconds off track -- assuming that it all goes off track in the same direction.

So if we assume a rate of 10 ms/hr of deviation (in the same direction), and pass 10 days, we will be off by 2400 ms -- or just 2.4 seconds.

For us to get a 15 second deviation we need to be off by 1 ms/hr (In the same direction) for 625 days, or off by 625 ms/hr (over half a second every hour) for a day, or some other multiplicative combination (e.g. off 25 ms/hr in the same direction for 25 days straight).

[Cigarette]

引用自 A Meat Popsicle：

When you're locked out of an account because Steam authenticator is so ♥♥♥♥ that it denies the authentication code it just sent to your damn cell phone. Check and mate, I guess? You can have the account if you want it that bad!

Best chance is steam support, Complaining here wont help. (Sorry for Rudeness)

[voidCaster]

引用自 Quint the Alligator Snapper：

引用自 Gematria：

When you're not connected to the internet (and/or not configured to use NTP services in the first place) your computer will lose milliseconds per hour. Period. Reality. Quit lying to people. Thanks!

FYI the Steam mobile authenticator codes last 15+ seconds -- the code stays up for about 15 seconds, and then afterwards, there's an additional leeway time of at least several seconds.

If we go by what you're saying -- "your computer will lose milliseconds per hour" -- this means that, for every 1 ms/hr that the computer goes off track, and for every day that passes, the computer can go a maximum of 24 milliseconds off track -- assuming that it all goes off track in the same direction.

So if we assume a rate of 10 ms/hr of deviation (in the same direction), and pass 10 days, we will be off by 2400 ms -- or just 2.4 seconds.

For us to get a 15 second deviation we need to be off by 1 ms/hr (In the same direction) for 625 days, or off by 625 ms/hr (over half a second every hour) for a day, or some other multiplicative combination (e.g. off 25 ms/hr in the same direction for 25 days straight).

Mostly right. It's academic and frankly off-topic. This derailment began when I made a clarifying comment answering the statement "It will even work if your phone is totally disconnected from the outside world." It may. I don't know! There was also a comment that it uses a timestamp though, and if that's true then the longer your phone is offline the more its internal timer will deviate from whatever an online server is using.

"milliseconds per hour" is more than 1ms per hour. Exactly how many ms per hour your system deviates depends on the speed of your CPU in khz or ghz.

So either
A) it doesn't use a timestamp at all
or
B) it will quit working after your device is offline for awhile.

The only possible C would be if it was using the day/month/year and hour portion of the timestamp only. That millisecond drift turns into full seconds and those turn into minutes really quickly, and cutting off those fine details from any timestamp would nerf any legitimate security the method provided in the first place.

I've seen Windows systems with identical CPUs drift by 3-5 minutes over just a few days of runtime, without an NTP service.

[cinedine]

引用自 Gematria：

"UTC" is just "GMT." It's the time of day at the prime meridian on the real, actual earth. It's a timezone. It's not technical or digital or controlled by the decay of radioactive isotopes.
[...]
When you're not connected to the internet (and/or not configured to use NTP services in the first place) your computer will lose milliseconds per hour. Period. Reality. Quit lying to people. Thanks!

Yeah, sorry. But you rambling on about GMT an UTC cause me to mistype. I of course menat unix time. I have corrected it now.
Anyway, I'd appreciate if you don't tell me what I know or call me lying. It's nice that you read about NTP services yesterday, however, that has nothing to do with 2FA.

BTW: synchronizing with an NTP server doesn't automatically mean two systems will have the exact same time. It is used to minimize offset, that's all. How it works is you'll receive several timestamps to determine the communication delay and take more or less the average of the offset to reset the system time.

引用自 Quint the Alligator Snapper：

For us to get a 15 second deviation we need to be off by 1 ms/hr (In the same direction) for 625 days, or off by 625 ms/hr (over half a second every hour) for a day, or some other multiplicative combination (e.g. off 25 ms/hr in the same direction for 25 days straight).

Also the codes are still valid after the 15 second periods. Normally 30-60 seconds. As I said, the offset is compensated by design.
Also your phone doesn't completely desync if kept offline. Some of you might remember the time before smart phones and you only had to reset the time for Summer/Winter if even.

[Muppet among Puppets]

Both devices need the same time.
Set the time to the same minute.

Not sure where the problem is.