Reading Time: 14 minutes

A few years ago, I left the Offensive and switched to the Defensive side, and together with my team, I am trying to achieve one of the main goals of the Application Security department – to prevent mass account hijacking and the most difficult thing – targeted hijacking. And, as it turns out, if your service has web authentication and tens or hundreds of millions of users per month, you fall into the trap of a lack of secure and affordable user authentication approaches. Let’s take a look at everything in order – let’s go through the current mechanisms, highlight issues, and make a conclusion, how we could fix the current situation.

Account hijacking can happen at different stages:

  1. Login to account
  2. The user has already been logged in and the session is hijacked
  3. Account recovery process

Make sure that the same user came to me as the one who registered

Authentication in a Typical Web Application

1. Login to the account

Obviously, to hijack an account, you can provide what the service believes so that we are login under the desired user

And we started with passwords

From an understandable mechanism to the user, known from ancient times. At the very beginning, in the 90s, it worked well. But then we faced the followed issues:

  • Simple passwords. Users want them, but we began to annoy them and force them to add special characters, numbers, not repeat them, and so on. Hooray, at least we realized that the frequent change of passwords is, in the end, is bad. For “old” services life is not good and they need to prohibit simple passwords for existing users, they come up with a solution to check passwords on changing them or logging into an account (since they are already stored hashed) and flag the user that he has a simple password and force him to change.
  • Credential stuffing. Okay, the user remembered one complex password and started using it everywhere. Attackers began to hack less protected resources and use passwords on linked mails and other services. Services, for their protection, began to collect leaked password databases to themselves and block users, prohibiting compromised passwords. Users began to add to their old, complex, compromised password, “1” or “2” at the end or at the beginning. The attackers began to do the same. The defenders also began to mutate the leaked passwords. And so in a loop.
Attackers try to intimidate users through leaked password databases. They earned over $500,000
  • Fight against brute force attacks. The unsolved issue for any company with a mass service. The least expensive and most effective method is “supercookies”, blocking any logins at all except devices from which there was already any successful logins before (we call it trusted devices), has disadvantages:
    • The obvious assumption of “supercookie” and such kind of devices
    • The ability for an attacker to block login to an account from any other, non-trusted device
    • The blocking of non-trusted devices must be removed later and the account could be be brute-forced again
    • Doesn’t work on protocols without cookies – for example, IMAP
  • Phishing. Browsers allow user to send the same password to a different origins. This assumption itself is only needed for acceptable UX, but it is incompatible with security. Moreover, the services themselves often teach the user to be vulnerable – they make a bunch of auth forms on the main domain, on subdomains, and even it happens on completely different second-level domains. Some teams were able to fix this terrible assumption of the past and host the auth form on the auth | account | login domain, also adding a cookie that this user was on this domain and the user entered the password (we will return to this later), but this is a lot of work.
  • Password managers. A terrible dirty hack we invented to fix the problems above. Mass services could be secured only by forcing two-factor authentication for all users, without exception, and we already see that it works – for example, on Steam. Password managers will continue to be a solution only for geeks and advanced users, of which, in the best scenario, no more than 5-10%. If I were an investor, I would not have invested (or invested only for a short time) in the projects of password managers.
I am using 1password, but would really like not to
  • Storing passwords in a secure way is a difficult engineering task, using Bcrypt / Scrypt / Yescrypt with the “correct” settings is not enough, there is a good article about it. I do not agree with it in some points, but, at least, pay attention to the approach of password verification without select rights to the column with the password hash, through stored procedures. This approach is not supported in any of the popular development frameworks – WordPress, Django, or others, we can assume – that almost no one in the world stores passwords securely to this day. Only a few services will tweak the coefficients of hashing functions in the future, we’ll talk about this in a separate article.

SMS has arrived

WhatsApp can be called the first mass service with SMS authentication, and SMS login changed the rules of the game. It is convenient for users, it has become more difficult for cybercriminals (how many friends you know who had WhatsApp hacked?). It seemed that only business owners suffered, for SMS began to rise in price, cellular operators want to somehow make money on them due to the general transition of users to instant messengers. But then the rumor begins that SMS is not safe either! Is this true and are users hacked through them? Let’s also analyze all the ways how it possible to intercept SMS:

Reissue of SIM cards

The most common method mentioned in discussions. One of the most popular ways of intercepting SMS, in fact, until now, is the reissue of SIM cards in service branches. The question is about the amount of a bribe or a deception of a consultant (where passport data will be required, which attackers can find in any other way) or some other ways to provide fake proofs for SIM card re-issue and the SIM card is ready. How the industry is trying to prevent it:

  1. Cellular operators are trying to solve the problem organizationally – by complicating the re-issue process and trying to increase the responsibility of their employees. There are quite a few criminal cases after such situations
  2. Cellular operators prohibit SMS receiving for the first day or two after the SIM card was reissued. In this case, the real owner notices the problem and can have time to return the number to himself
  3. You can monitor the reissue of SIM cards through сellular operators but it costs too much and usually, it will work only for a few countries

SMS interception using hardware and software systems

This method requires the attacker to be physically close to the “victim”:

  1. The attacker is next to the victim and uses SDR to listen to the broadcast
  2. The attacker sends “silent SMS” to the “victim” number – a special type of SMS that comes to the device. Using it, the attacker obtains the TMSI (Temporary Mobile Subscriber Identifier) ​​- a special temporary identifier that is used to register a subscriber in the network
  3. The attacker requests an SMS that needs to be intercepted
  4. SMS arrives at the device of the “victim”
  5. The attacker needs to quickly decrypt the traffic between the base station and the victim’s phone – for this, there are ready-made free tools, all that is required is a specially formed file weighing 1.6 TB (rainbow tables) and a more or less fast computer
  6. Done, SMS decrypted

Of the “minuses” for the attacker, the “victim” will see this SMS. Also, the method itself requires a “noise” that will switch off 3G / 4G / 5G in an area, which is not so difficult, but also an additional step. By the way, about GSM security there is a resource, where enthusiasts collect the state of security for each country and operator and from whom it is easier or more difficult to intercept an SMS or a call. The data is not entirely up to date, but it is useful to look at the approaches and analytics in the past.

SS7 Attacks

There were a lot of articles about SS7 attacks. In short, there is a system that is used all over the world. By connecting to it, i.e. in fact, set by the cellular operator (they say, it costs 20-50k + euros), you can tell another cellular operator that now a specific user is in your roaming. And forward all SMS and calls to yourself. The result is SMS interception. Some hacking groups do not buy access, but hack operators, of which there are many and not all of them are engaged in security, the main goal is access to SS7


Everything is clear and understandable. Or an iPhone is jailbroken with a Trojan, or Android, where there is an application that has access to SMS, which sends everything to attackers.

Exotic Attacks

An example of such an attack is research from shubs from Australia in 2014 (

  1. Use the victim’s phone number on password restore or login
  2. Wait 30-60 seconds, there probably will a button “Didn’t receive SMS? Call me and dictate the code”. Don’t (!) press it
  3. At this moment attacker calls the victim, the phone line is now busy
  4. Now attacker press the button at step 2 and the call goes to voicemail since the line is busy
  5. An attacker can spoof a victim’s phone number (which costs $ 1- $ 5) and call the number to read the voice mail. Or could brute force a pin code for the voice mail (most often there are no rate limits for this, as in the article above)
  6. Read the mail, hijacking the code

Infrastructure vulnerabilities

There are applications from cellular operators that allow SMS redirection and there are vulnerabilities (or in business services ). Developers can accidentally log codes from SMS somewhere along the way. Also from real cases – this is hacking gateways through which SMS are sent to companies and all security ultimately comes down to the security of these gateways. To effectively and cheaply send SMS around the world, you need to connect more than 30-50 such gateways if you have a popular resource

But is everything so bad with SMS? The count of hacks is getting smaller

1. Logging in via SMS is evil and bad, you don’t need to do that, they are “easy” to intercept

All potential vectors above are already available for attacking and hacking users on any popular service and give access to the account (!). Almost everywhere (of course, in an account without a 2-factor), with a linked phone number, you can restore access by phone number, request an SMS, and get into your account. It’s already available

2. It seems like yes, but it requires a change of password or a push about a new login (Telegram) will come, there will be a logout (WhatsApp), this is more noticeable

Let’s compare the impact. Even when logging in via SMS, even when restoring access to the account and changing the password – the user (or the attacker) gets into the account and gains access to the data, the difference is only a few seconds and you must first think about it. This is exactly what is discussed in the article.

Most often, an account is hacked due to an unreliable or stolen password and they can be saved by logging in without a password, incl. code via SMS. But still:

  • It’s expensive
  • Doesn’t work offline
  • Relying on someone else’s infrastructure
  • There is still a possibility of brute-force code, as direct – brute for a specific user, so and horizontal – brute force of millions of users with the same code. Engineering work is needed – for example, increasing the length of the code from 6 to 8-9 characters in case of anomalies, etc.
  • Entering the code is still vulnerable to phishing

If you have a question – were the users hacked in the ways above? Yes, they did, and most often they were targeted attacks. Every user who thinks at least for a minute that he can be hacked in the ways above should enable two-factor (and we must convey this idea).

To summarize, SMS is already working everywhere as a factor that allows you to access your account, and hacking through it requires resources or a target for a specific audience or person. Therefore, all global services considered it to be more secure than a password and allow you to log in with it or restore your account, but this does not mean that it is our final solution due to the problems above.

Email Login

A great way, as long as you are not an email service yourself 🙂 But let’s see what ways to log in are:

  • Sending TOTP code, issues:
    • Direct brute force
    • IP rotation brute force
    • Horizontal brute force (one code to a bunch of emails)
    • Phishing
  • Secret link from the email with a sufficiently brute-resistant token – login in the current tab with a link. Issues:
    • Poisoning the host header (and spoofing links that the user will click on)
    • Phishing (theoretically)
    • CSRF to login
    • UX – the user actually wanted to log in in a different browser and device
  • Secret link from the email with a sufficiently brute-resistant token – logs in in the original tab, where the user tried to log in. Isssues:
    • Bulk mailing of such links (rotation of IP addresses). There is a chance that someone could click and some of the accounts will be hijacked
    • Phishing (theoretically)

Obviously, if the mail is hacked, then the account is hacked. This can be accepted on a variety of services, and again, as long as you are not an email service yourself.


In general, this is a great way, similar to the previous one. The most common mistake when logging in through an external service is the lack of CSRF protection when linking an account and that an attacker can start linking himself and give a link from the last step to the “victim” and link his account to the victim’s account. This was described by Egor back in 2012, but still relevant.


Of course, the absolute leader in terms of security:

  • Protected against phishing
  • Protected against brute force
  • Convenient

But there are many issues:

  • Authenticators on devices, like Touch ID on Mac or Windows Hello, only work as additional sign-in devices. And they are not for registering an account, they are not mobile
  • Portable FIDO2 Authenticators, like Yubikey, the destiny of a fraction of a percentage of Internet users. And then, it is necessary that the user at registration would have two of them at once! One primary and one backup, if the first is lost or out of order
  • Both types of authenticators require a purchase of at least $20 per portable authenticator. How soon will we see the sale of Fido2 keys next to the key sharpening near the MRT?

Are there any solutions? Of course:

  • Google should release Android, which will turn every device into a Fido2 compatible Bluetooth / USB dongle. Then we will receive millions of Fido2 keys that we can use immediately upon registration. Now Android can already (sometimes) be used as “like a Fido2” authenticator for logging into a Google account along with Chrome, but they do not give this API to other sites, and there (at least earlier) there was a not entirely honest scheme – an Android device still had to have internet access
  • Apple should release the appropriate iOS version and turn their devices into Fido2 Authenticators

Then and only then will we be able to not ask for passwords at all at registration and use the only FIDO2 with the prohibition of the fallback for other factors. But this is still not a solution to our problem, since we made one terrible mistake on the web

We equated checking multiple factors, maybe the secure ones, to some kind of random token in Cookie and we believe it at every step after logging into an account.

Game Over

2. Capture an existing session

As we can see, the current mechanisms either make it easy to make mistakes in implementation, or depend on another platform, and this is not what we want to see as a technology that should be alienated and enough by itself. Contender number 1 – of course, FIDO2, but we are waiting for Apple and Google. However, the session is created and the account takeover can be done through it. Session – random values ​​in a cookie (or localstorage, for desperate people who are not afraid of XSS)

Session confusion

One of my any examples is an old bug from the 2000s of some shared hosting, which can shoot in the modern world.

  • You have, where you log in with your user_id = 1 and get session abcdef123456. The site is on shared hosting
  • There is, which uses the same CMF / CMS and looks at the specific fields like the user_id in session, and uses the same shared hosting
  • We take the session abcdef123456 and substitute it in the cookie, but already when making a request on, getting the session under the desired user

If the hosting has not isolated sessions for each client, we get the opportunity to craft sessions between sites. Of course, this was fixed a long time ago, but in this report is exactly what happened. There was a partner site where you could come with a cookie from the main site and obtain random, other people’s accounts. And all because for some reason we use random values ​​for authentication after checking all the factors


We all understand that this is theoretically possible, but it happens in practice. It is almost impossible for a web service to fight malware, but the main problem here is that a Trojan can steal a cookie at least once and an attacker can use it before it expires (usually several months).


In the end, everyone relies on the session and would like to protect against cases when they leaked. The most obvious solution in the world has come up with sudo sessions – for all critical actions, ask for a password again. Well, we remember about passwords, right? You can also redirect to a domain like, in which we set a supercookie when the user entered the password, but this is a partial solution to the problem. Rather, the days of HTTP and eventual MitM.

3. Account recovery

How many reports have you seen on how to do account recovery correctly?

How many reports have you seen on how to break account recovery? (Most likely a little more)

No one has the correct instructions on how to properly restore accounts and not have a zero retention rate, and everyone comes up with their own solution.

Interesting reading is available in Wired article, 2012, but it is still relevant. There are also mistakes in business logic, for example, on one popular service it was possible to change step = 2 to step = 5 in a cookie and go to the final step of account recovery and change the password.

We could nullify account hijacking through recovery by being able to connect a sufficient number of technical devices (including FIDO2) at registration, but this is still killing conversion for now. The main thing to remember is you cannot use security questions.

Everything was invented before us

You may be surprised, but the solution to most of the problems of vectors 1 and 2 was implemented in browsers 15 (?) years ago. With a number of issues, of course, but this is Client Certificate Authentication, which you practically cannot find on the Internet and will not be found in any popular service. How does it work?

  • You generate a pair of private and public keys and import them into the browser Keystore
  • When you enter the site, it tells you that it wants key authentication from you
  • The browser makes a handshake and each of your subsequent requests authenticates
This image has an empty alt attribute; its file name is image.png
Example of requesting a certificate in a browser


  • Obviously UX. Where does this key come from? You need to generate it (this is how the good old TeamSpeak3 client does it, by the way) and somehow share it with the service
  • There is no possibility of logging out. Chose a certificate and that’s it – the browser will be stupid to use it every time, you can reset the state only through settings, opening incognito, or completely restarting the browser. Just like basic auth, we figured out how to authenticate and forgot that we need to support how to log out users
  • Malware. While the key on the file system can be stolen, but it can already be used, for example, Yubikey and the Trojan will not be able to steal the key. Still, no support of in-build HSM but we hope it will be fixed soon

Keyless Certificate Authentication. Via mobile devices too

Analyzing all the security and UX issues, it seems obvious that all we need to still prevent, at some maximum, the problem of account hijacking, is to combine all the best that we already know how:

  • Turn each mobile device not into FIDO2 keys, but into a TLS ticket generator, similar to how Keyless SSL on Cloudflare. Store the private key in the HSM (available in any modern device) and transfer these tickets to the PC, if necessary. We have already a similar mechanism in Paywave / Paypass when paying by phone or watch. This is how desktop WhatsApp works, you sharing session keys from your mobile device and while it is nearby, you are logged in. Now, this is implemented inconveniently. After login using session keys, it would be possible to link the key to the HSM of the current PC or laptop and make a permanent session.
  • Implement the header in browsers like Extension-Policy: none, which will prohibit the use of extensions that have the right to interact with the current Origin, at least on specific pages
  • Of course, this should all work origin-based and be resistant to phishing

Imagine a world in which there is no brute force, it is difficult for a service developer to make a mistake in user authentication, each user request is authenticated by the same factor that was used to log into the account. Trojans can still get into the user’s account, but only as long as the Trojan is running on the user’s device. Someday we will see this world, but when? I don’t know, making predictions is a thankless task, but for now, we need to work with what browsers can do and what Google, Apple, and Microsoft have given us.

Leave a comment

Leave a Reply