Recent Hacking Attempt

[Chthon]

I would use the 2FA if it weren't an app. There is a specific security flaw in making it an app. This is why Twitter, Google, and many others instead now send text messages instead.

You are misunderstanding how 2FA works.

Getting 2-Step Authentication codes via SMS is NOT proper 2-Factor Authentication. It is not second factor because it is not "something you have". You have to be sent the code by the site in order for that to work and SMS can and has been re-directed for the purposes of account takeover.

Proper 2-Factor Authentication requires either an app (such as Authy, FreeOTP, or Google Authenticator) or a device (such as a Yubikey) because a proper 2FA involves running an algorithm, usually a TOTP algorithm.
2FA using TOTP does not require the service to send you anything (aside from maybe a message telling the app to generate a code for you for convenience), because the code is generated on both sides using a combination of the current time and a shared secret key that created when the 2FA was first set up.
Simply intercepting the generated codes is more difficult because they only need to be sent one-way and even if you can intercept them they would only work for individual login sessions. It's not practical to find the secret key using the generated codes because the algorithm used to generate codes from the secret key is very efficient going forward but requires an impractical amount of computing power and time to reverse.
In order to generate a valid code you need the secret key, which stays on the user's device and never needs to be sent over the network and because of that it can serve as an actual "something you have" second factor.
It even works offline provided device has its clock set correctly (try using a 2FA app without a network connection, it still works).

Technically Steam is doing 2FA correctly by using an app.

What Steam is doing wrong with 2FA, at least in my opinion, is that they've insisted on only using their own app rather than using an already established standard used by other 2FA apps.
If Steam did not stubbornly insist on using their app then users could choose whatever 2FA app they wanted (like Authy, FreeOTP, or Google Authenticator) and it would be much more convenient, especially for those of us who use 2FA regularly and already have already chosen an app we prefer.


Also, if anyone was wondering, account takeover via [redacted] does not involve 2FA in any way as it's taking over the account using a completely different mechanism that Steam and other sites really need to better secure.
In fact, part of the reason [redacted] has recently become a more common method of account takeover in some cases is because proper 2FA works so well that it's easier to find another way in rather than to try to attack the 2FA directly.

Just because you or anyone you know hasn't admitted to figuring out a way through doesn't mean it doesn't exist. Many people keep quiet for various reasons. I this case the Steam 2FA app does not actually work securely, and if you decompiled it and tried to understand what it was doing, you'd realize why and how you could break it. That is the risk of making the program public. Security relies on two things to work best, 1) the secret key remains secret, and 2) the method of using the secret key remains secret. If the second part becomes public it is still difficult, but much less so. However the app fails in that it has keys on how the secret key is created in it's source, so it even fails the first part, opening up a gaping hole in the 2FA system they use.

edit: Just going to give an example of what I mean here:
Steam has given you the hashing algorithm to determine the secret key in their program. If they use a good input to the program though, this doesn't matter. They didn't use a good input, so I will give you examples of good and bad inputs, none of which Steam actually uses, and why they would be good or bad.

Using your browsing history from the last week -- Good Input
This is good because it is unlikely that even you, the user, can replicate your browsing history exactly even a week later. The exact configuration of your browsing history will be lost permanently some time after the key was generated, and can't be predicted.

Using your contact list -- Bad Input
This is bad, because your contact list does not change much, and comes from a small pool of people. Unless you remove a contact, and all references to that person from your life, social media, and the internet archive, the total number of keys possible from this is the number of contacts you have factorial, and if the hacker has information about you, this information could reduce this further.

Using secret questions -- Bad Input
This is a bad input, and I'll tell you why. These secret questions may seem to be known only to you, but they come out of a pool of questions given in the app, and if someone knows you, chances are they will know your answers to many of these questions. If someone hacks into one of your other accounts, they may be able to leverage that to find out the answers to these things as well.

Current date -- Bad Input
It is possible to find out approximately what date someone starts using one of these 2FA programs. As a result it greatly reduces the key pool to try when looking for the right key.

In short, a good input to a key hash has to be something that cannot be easily replicated because it's unpredictable. Steam's input is actually predictable in some way, which I won't get into. Because of that a hacker can figure out what key was generated when you started using 2FA. As such, the two services that I mention actually still have better 2FA models with the text messaging. I just meant Steam would have been better off with that.

If Steam wanted to improve their app, they would chose something unpredictable. Something so unpredictable, that even knowing what they use won't limit the key pool in any significant manner.

[Draco18s]

Just because you or anyone you know hasn't admitted to figuring out a way through doesn't mean it doesn't exist. Many people keep quiet for various reasons. I this case the Steam 2FA app does not actually work securely, and if you decompiled it and tried to understand what it was doing, you'd realize why and how you could break it. That is the risk of making the program public. Security relies on two things to work best, 1) the secret key remains secret, and 2) the method of using the secret key remains secret. If the second part becomes public it is still difficult, but much less so. However the app fails in that it has keys on how the secret key is created in it's source, so it even fails the first part, opening up a gaping hole in the 2FA system they use.

2) is not critical. In fact, having point 2 be true is actually more of a vulnerability because decompiling the code and reverse engineering it isn't hard.  Then the attacker is the only one who has the ability to analyze the code for flaws.

Whereas having point 2 be an open and public method, then thousands upon thousands of cryptoanalysts and security code experts can examine it for flaws and report them, making the system much more secure.

[Chthon]

Just because you or anyone you know hasn't admitted to figuring out a way through doesn't mean it doesn't exist. Many people keep quiet for various reasons. I this case the Steam 2FA app does not actually work securely, and if you decompiled it and tried to understand what it was doing, you'd realize why and how you could break it. That is the risk of making the program public. Security relies on two things to work best, 1) the secret key remains secret, and 2) the method of using the secret key remains secret. If the second part becomes public it is still difficult, but much less so. However the app fails in that it has keys on how the secret key is created in it's source, so it even fails the first part, opening up a gaping hole in the 2FA system they use.

2) is not critical. In fact, having point 2 be true is actually more of a vulnerability because decompiling the code and reverse engineering it isn't hard.  Then the attacker is the only one who has the ability to analyze the code for flaws.

Whereas having point 2 be an open and public method, then thousands upon thousands of cryptoanalysts and security code experts can examine it for flaws and report them, making the system much more secure.

What you are suggesting is stronger is simply the extreme case of not 2. What you are suggesting that I was saying was actually the mild case of not 2. 2 is when no one except the maker of the software knows how or what it does. You on the other end have no clue how the key is generated, but just that it is your key. That is in fact the safest.

Nor did my argument hinge on that fact either. I was simply mentioning it because it makes you go from what is in effect most secure, to something that in effect is at least a tiny bit less secure at best, and at worst much less secure depending on the implementation.

[Professor Paul1290]

I would use the 2FA if it weren't an app. There is a specific security flaw in making it an app. This is why Twitter, Google, and many others instead now send text messages instead.

You are misunderstanding how 2FA works.

Getting 2-Step Authentication codes via SMS is NOT proper 2-Factor Authentication. It is not second factor because it is not "something you have". You have to be sent the code by the site in order for that to work and SMS can and has been re-directed for the purposes of account takeover.

Proper 2-Factor Authentication requires either an app (such as Authy, FreeOTP, or Google Authenticator) or a device (such as a Yubikey) because a proper 2FA involves running an algorithm, usually a TOTP algorithm.
2FA using TOTP does not require the service to send you anything (aside from maybe a message telling the app to generate a code for you for convenience), because the code is generated on both sides using a combination of the current time and a shared secret key that created when the 2FA was first set up.
Simply intercepting the generated codes is more difficult because they only need to be sent one-way and even if you can intercept them they would only work for individual login sessions. It's not practical to find the secret key using the generated codes because the algorithm used to generate codes from the secret key is very efficient going forward but requires an impractical amount of computing power and time to reverse.
In order to generate a valid code you need the secret key, which stays on the user's device and never needs to be sent over the network and because of that it can serve as an actual "something you have" second factor.
It even works offline provided device has its clock set correctly (try using a 2FA app without a network connection, it still works).

Technically Steam is doing 2FA correctly by using an app.

What Steam is doing wrong with 2FA, at least in my opinion, is that they've insisted on only using their own app rather than using an already established standard used by other 2FA apps.
If Steam did not stubbornly insist on using their app then users could choose whatever 2FA app they wanted (like Authy, FreeOTP, or Google Authenticator) and it would be much more convenient, especially for those of us who use 2FA regularly and already have already chosen an app we prefer.


Also, if anyone was wondering, account takeover via [redacted] does not involve 2FA in any way as it's taking over the account using a completely different mechanism that Steam and other sites really need to better secure.
In fact, part of the reason [redacted] has recently become a more common method of account takeover in some cases is because proper 2FA works so well that it's easier to find another way in rather than to try to attack the 2FA directly.

Just because you or anyone you know hasn't admitted to figuring out a way through doesn't mean it doesn't exist. Many people keep quiet for various reasons. I this case the Steam 2FA app does not actually work securely, and if you decompiled it and tried to understand what it was doing, you'd realize why and how you could break it. That is the risk of making the program public. Security relies on two things to work best, 1) the secret key remains secret, and 2) the method of using the secret key remains secret. If the second part becomes public it is still difficult, but much less so. However the app fails in that it has keys on how the secret key is created in it's source, so it even fails the first part, opening up a gaping hole in the 2FA system they use.

edit: Just going to give an example of what I mean here:
Steam has given you the hashing algorithm to determine the secret key in their program. If they use a good input to the program though, this doesn't matter. They didn't use a good input, so I will give you examples of good and bad inputs, none of which Steam actually uses, and why they would be good or bad.

Using your browsing history from the last week -- Good Input
This is good because it is unlikely that even you, the user, can replicate your browsing history exactly even a week later. The exact configuration of your browsing history will be lost permanently some time after the key was generated, and can't be predicted.

Using your contact list -- Bad Input
This is bad, because your contact list does not change much, and comes from a small pool of people. Unless you remove a contact, and all references to that person from your life, social media, and the internet archive, the total number of keys possible from this is the number of contacts you have factorial, and if the hacker has information about you, this information could reduce this further.

Using secret questions -- Bad Input
This is a bad input, and I'll tell you why. These secret questions may seem to be known only to you, but they come out of a pool of questions given in the app, and if someone knows you, chances are they will know your answers to many of these questions. If someone hacks into one of your other accounts, they may be able to leverage that to find out the answers to these things as well.

Current date -- Bad Input
It is possible to find out approximately what date someone starts using one of these 2FA programs. As a result it greatly reduces the key pool to try when looking for the right key.

In short, a good input to a key hash has to be something that cannot be easily replicated because it's unpredictable. Steam's input is actually predictable in some way, which I won't get into. Because of that a hacker can figure out what key was generated when you started using 2FA. As such, the two services that I mention actually still have better 2FA models with the text messaging. I just meant Steam would have been better off with that.

If Steam wanted to improve their app, they would chose something unpredictable. Something so unpredictable, that even knowing what they use won't limit the key pool in any significant manner.

So what you are saying is that Valve rolled their own form of "random" generation for 2FA secret keys.
You also seem to imply that they generate the secret keys client-side, as you mention that this can be found by de-compiling the app.

Am I reading that correctly?

Those are some pretty serious claims. If they are true then it shows some rather extreme incompetence on Valve's part.

Assuming this is true, this would be the first I've heard of this.
Has Valve been made aware of his problem? What sort of disclosure practice/policy is being applied here?

[Chthon]

So what you are saying is that Valve rolled their own form of "random" generation for 2FA secret keys.
You also seem to imply that they generate the secret keys client-side, as you mention that this can be found by de-compiling the app.

Am I reading that correctly?

Those are some pretty serious claims. If they are true then it shows some rather extreme incompetence on Valve's part.

Assuming this is true, this would be the first I've heard of this.
Has Valve been made aware of his problem? What sort of disclosure practice/policy is being applied here?

That is not a serious claim. That is actually a trusted way to do so if done right. What is the serious claim is that the way they generate the key can be predicted if certain things are known. And to be honest, it's not initially obvious that it can be predicted, because said predictions require knowing your target in a way that most hackers would not. (This now applies to Chris though, as maybe they have found out what they would need to know)

As someone else mentioned some would prefer generation of keys client side to be the normal, as then you do not have to transmit the key and risk it being intercepted. If Valve generated the key themselves, they would still have to send it to the client so that the client would know how to generate the codes, and that can be intercepted. This is a problem that people have fought with, safely transporting encryption keys, since Julius Caesar.

The alternative that I suggest is that valve only sends the codes to you, and not the key itself. However then the code can be intercepted and someone can use it, but even still that is only good for one session.

The true optimal way would be for the user to have a shared key with Valve set up once a month using public key exchange algorithm that works through (x^y)mod q = (a^(x*y)) mod q = (y^x) mod q, where a is a primitive root of q, and x and y are relatively prime to q. This key will be used to decrypt through their app a code sent from Valve when you need to use the device. In this case the hacker would need to know when and where to intercept the code from Valve to get into a session, and figure out your shared private key which cannot be figured out through interception with this model.

As of yet, I don't know any 2FA systems that use this level of encryption. Valve's isn't terrible mind you, it just is if you have had any other successful identity theft in the past. Once the attacker knows the right things about you, he can then move in to reduce the complexity of duplicating your 2FA key.

[Professor Paul1290]

What is the serious claim is that the way they generate the key can be predicted if certain things are known. And to be honest, it's not initially obvious that it can be predicted, because said predictions require knowing your target in a way that most hackers would not. (This now applies to Chris though, as maybe they have found out what they would need to know)

That was the part I was referring to as "serious".

This implies that Valve decided to cobble together their own flawed method of generating random secret keys rather than using existing implementations that are already known to work properly.
This would mean they did more work than necessary to re-invent something in a way that doesn't actually work, rather than sticking with what already works.

That would show some pretty severe incompetence on Valve's part and would be reason enough to make them aware of the issue, or perhaps even resort to the "full disclosure" option should they just shrug it off without acknowledging it.

As someone else mentioned some would prefer generation of keys client side to be the normal, as then you do not have to transmit the key and risk it being intercepted. If Valve generated the key themselves, they would still have to send it to the client so that the client would know how to generate the codes, and that can be intercepted. This is a problem that people have fought with, safely transporting encryption keys, since Julius Caesar.

Generating a secret key for 2FA client-side does not remove the need to transmit the key, it just means you end up having to send it in the other direction so the server can generate matching codes to check against.

The alternative that I suggest is that valve only sends the codes to you, and not the key itself. However then the code can be intercepted and someone can use it, but even still that is only good for one session.

This ends up having the same problem as 2-Step via SMS in that it's verifying that you have the network "address" of the device rather than whether you have the correct device itself, and those are not necessarily the same thing.

After initial setup, 2FA using TOTP is much closer to verifying that the user has the correct device in more cases.
It also allows the option of device holding the secret key simply not having network connectivity at all (such as with devices like Yubikey), which is helpful for those who have more severe threat models.

Also, so far the real world has shown the latter to be much more effective, as attacks on SMS-based 2-Step Authentication are now well known enough that there is already a consensus that SMS-based 2-Step should eventually be phased out in favor of TOTP-based 2FA where practical.

The true optimal way would be for the user to have a shared key with Valve set up once a month using public key exchange algorithm that works through (x^y)mod q = (a^(x*y)) mod q = (y^x) mod q, where a is a primitive root of q, and x and y are relatively prime to q. This key will be used to decrypt through their app a code sent from Valve when you need to use the device. In this case the hacker would need to know when and where to intercept the code from Valve to get into a session, and figure out your shared private key which cannot be figured out through interception with this model.

As of yet, I don't know any 2FA systems that use this level of encryption.

Unless I'm mistaken, you're asking for Valve to re-implement a Diffie-Hellman key exchange for the purpose of sending 2FA secret keys.

2FA systems don't do this by themselves because most 2FA is part of authentication for systems that have to have that part already covered at Transport Layer out of necessity, which is usually using something just as good if not better.
In that case it's pointless because if that layer of security is compromised then the data being served post-login would be compromised anyway.

Even ignoring that, there's the problem of having to roll yet another implementation, even if it is using a well known algorithm.
If Valve can't get key generation right as you've mentioned earlier, I seriously doubt that their "key exchange for 2FA" implementation is going to protect secret keys more reliably than the TLS/SSL they're already going to be transmitted through anyway.
It's not even a matter of understanding how the algorithms work, it's a matter of demonstrating the reliability of a specific implementation over the course of time.
Implementing crypto for research projects and for learning purposes is one thing, but doing so unnecessarily for real world usage is not something you want to encourage.

Valve should ideally stick to using existing implementations that have already been shown to work.

[x4000]

Holy thread explosion, Batman!

Few notes, just to some of the commentary at large:

- Regarding the [redacted] element, Professor Paul1290, it's in many ways not as bad as it sounds.  Yes you guessed the general shape of it well, but the way that they abused that was really novel.  It's something that Valve is now aware of, and I think it will not be something that works a second time against anybody.

- Regarding the 2FA in general, the text message to me saying "by the way, we removed this phone number from being involved" was the saving grace here.

- Regarding their app, that does sound serious in terms of a flaw.  I don't think they're likely to move away from having an app, though.  And they don't really listen to me on things like that.  The app wasn't an issue at all in this case, thank goodness.

- All of which is not to say there aren't a dozen other ways to get around this sort of thing.  But this one just didn't use them.