Ruslan Rakhmetov, Security Vision
In our work and everyday life, almost all of us face the need to authenticate, i.e. to verify the authenticity of our accounts using login credentials to websites, operating systems and applications - logins, passwords, one-time access codes, fingerprints or images. Successful authentication is followed by authorisation, i.e. defining and granting credentials to the user based on access policies and rules defined in the system. Authorisation is granted in the form of some access token or code in the form of a sequence of characters; in the case of web applications, such a token would be either a session cookie (session cookie is a traditional but more resource-intensive approach) or a web access token (e.g. a JWT token, which is issued by the authorisation server, contains signed information about the user's access rights and is provided to the web application when certain resources are requested). Nowadays, multi-factor authentication is widespread, account and access management has become a big business (e.g. for such giants as Microsoft, IBM, Oracle, Okta and others), and there is a trend towards passwordless authentication using hardware or software keys (e.g. FIDO2 devices, TPM chips, Apple iCloud Keychain, Google Password Manager, Samsung Pass, 1Password and others). However, this was not always the case, and many websites and applications still use some outdated authentication methods, including logins and passwords. In today's article, let's talk about the evolution of authentication methods, discuss the main vulnerabilities of different authentication methods and countering credential fraud.
In 1960, the Massachusetts Institute of Technology was the first to use passwords in the modern sense - to differentiate access to files between researchers on one of the world's first mainframe computers. Already in 1962, the first ever case of password theft was registered there - one of the employees wanted to use more of his allotted machine time to complete a work task on time, so he printed out the contents of a file with the passwords of his colleagues using his access to the mainframe and used their accounts. Thereafter, attitudes towards password security gradually improved: for example, at first there were cases of storing passwords in plaintext (for example, in the late 1960s in PDP-10 mainframes), password hashing was invented in 1974, and later the logic of working with passwords in *nix systems was improved - in them the /etc/passwd file originally contained hashed passwords, but was readable by all users, which with the growth of computer performance meant an increased probability of bruteforcing, so password hashes were moved to the /etc/shadow file, accessible only to the root superuser. Over time, the importance of correct authentication grew, so in 1986 RSA introduced the first two-factor authentication tool in the form of a keychain with a small screen displaying a numeric code. Today, most modern services and applications offer users to apply multi-factor authentication, which implies the presence of several factors that confirm the authenticated subject's identity, such as the knowledge factor (password, secret code, PIN code), the possession factor (hardware authentication device, e.g. Google Titan Security Key, YubiKey, Nitrokey USB tokens, or smartphone/SIM card that receives push notifications or SMS), biometric factor (fingerprint, facial photo, iris, voice), geographical and behavioural characteristics of the subject (location, speed of password entry, cursor movement on a web page, scrolling speed, etc.), technical characteristics of the device, technical characteristics of the device, technical characteristics of the subject (location, speed of password entry, cursor movement on a web page, scrolling speed, etc.). etc.), technical characteristics of the device from which the account login attempt is made (OS, screen resolution, browser version, etc.). However, even now, not all web services use modern authentication methods, often offering users unreliable ways to authenticate or restore access, such as:
1. ‘Secret questions": a set of questions, usually preset, to which the user is asked to give honest answers, which in theory should help the user regain access to the account in case of a forgotten password. For example, a typical question might be ‘mother's maiden name’, the answer to which attackers can find on social networks or through social engineering. If the site offers to answer such ‘secret questions’, the answers should be combinations of symbols (letters, numbers, special characters) of the same complexity and length as the main password.
2. Prohibition to use special characters when creating a password, limitation on password length and complexity, illogical site ‘recommendations’ for choosing a ‘complex password’: some sites for various reasons do not allow using certain characters in passwords or even automatically limit the length of the password being created without notifying the user.
3 Lack of possibility to create an arbitrary login, sending the created password by email to the user, assigning a default password (for example, consisting only of numbers), lack of possibility to change the password are also sometimes encountered on some web resources.
4. Password recovery without proper validation: some sites require the user's login or email to restore access, and simple POST/GET requests allow sending a one-time code or a link to restore access to an arbitrary email address, which is used by attackers. In addition, some sites do not use random long alphanumeric character sequences as recovery codes, but generate incremental values, as a result of which a recovery code of the form 123456 will be generated for the conditional user user1, and 123457 for user2, 123458 for user3, and so on.
5. Some websites by default allow users to authenticate only by SMS one-time passwords, and the password creation functionality is hidden deep in the account settings. What is wrong with the SMS-code option - let's discuss it below.
So, with the development of Internet commerce, websites and web applications began to process more and more important information - personal data, payment information, financial data. To protect access to such information, the introduction of two-factor authentication tools began - the first actively used methods were USB eToken devices (for example, Rutoken, JaCarta, Aladdin, SafeNet and others) in corporate local networks to authenticate users of operating systems and business applications, as well as SMS-alerts with one-time codes for Internet sites. SMS alerts became for some time the easiest way for the majority - for example, Google introduced SMS authentication for Gmail users back in 2011, and in Russia citizens faced SMS verification codes for online banking in the early 2010s. However, the second factor in the form of SMS code is not reliable for the following reasons:
1. SIM swap attacks are widespread - attackers using the victim's passport data and a forged power of attorney to re-issue a duplicate SIM card, apply to the telecom operator's office, where they receive a new SIM card with the number they are interested in, while the SIM card stops working for the real owner and everything looks like something happened to the mobile network or phone. If this happens at night or during a foreign trip, it will not be possible to correct the situation in the shortest possible time, and fraudsters will be able to receive all incoming calls and SMS. It should be noted that SIM card reissue attacks have been popular abroad as well - for example, the official Twitter account of the U.S. Securities and Exchange Commission was hacked just by reissuing a SIM card. At the same time, Russian mobile operators have recently been increasingly using a ‘cooling off period’, which is usually no more than a day - during this time the re-issued SIM card will not receive incoming messages. In addition, telecom operators notify banks about the facts of SIM card replacement, and can also control the change of the unique IMSI-identifier of the SIM card (which happens when it is replaced) and the change of the IMEI-identifier of the smartphone's cellular module (which happens when the user changes the phone or the fraudster inserts the SIM card into his phone). In addition to the described fraudulent scheme with a forged power of attorney, fraudsters often use the services of insiders - dishonest employees of mobile operators, who for money re-issue a SIM card without the necessary documents. Another common scheme is a fake court order, with which a fraudster posing as a law enforcement officer can approach a telecom operator; on the basis of the order, the telecom operator will provide all subscriber data, including call and SMS history, and can also provide access to this information online. A method of partial counteraction to the SIM card reissuance attack is to write an application in the office of the mobile operator to prohibit SIM card reissuance by proxy - as a result, SIM card reissuance can be performed only with the subscriber's personal presence in the operator's office.
2. trivial loss or theft of the phone can also be fatal: intruders can remove the SIM card from the smartphone and insert it into the phone to receive incoming SMS. To counteract this, you should set a custom PIN code on the SIM card.
3. The SS7 (common channel signalling system #7) protocol used in 2G/3G networks is insecure: studies show that attackers, using relatively limited resources, can implement an attack on SS7 and gain access to calls and SMS messages of a subscriber of interest. In addition, attackers can implement an attack on a cellular network and a specific subscriber using a fake base station or femtocell. Telecom operators are currently implementing solutions to detect attempts to exploit SS7 flaws. It should also be remembered that when using cellular communication there is a possibility to easily substitute the sender's name displayed in an incoming SMS message or the number of the calling subscriber in an incoming call, therefore, if you receive an SMS with a text about ‘request for authentication’ ostensibly from a bank or telecom operator, you should not send a one-time access code received in another SMS message in response.
4. mobile operators support the function of forwarding calls and SMS messages to third-party numbers: it is assumed that the subscriber will be able to set up forwarding to another number when going on a business trip, for example. However, this functionality can be used by attackers who gain access to a subscriber's personal account (e.g., by phishing or social engineering, forcing the subscriber to dictate the password to enter the account from an SMS) and make the appropriate forwarding settings in it. In addition, some mobile operators have a dangerous option ‘auto-entry’ - automatic entry to the subscriber's personal account without a password in case of using mobile Internet from this operator, which can also lead to unauthorised access to the personal account. The described options should be disabled in the personal cabinet, as well as set a complex password for access to it.
5. Infection of the smartphone with a virus will not save even in the case of using more advanced authentication methods, but access to incoming SMS is a ‘classic’ function of almost any virus for mobile devices. In addition, there are simple button phones on sale, which can contain malicious modules in the firmware, including those that send incoming SMS to intruders.
6. Finally, a SIM-card may simply fail, stop working far away from the nearest operator's office or for some reason it will not receive messages (for example, the SMS-centre of a Russian operator is unavailable from abroad). In this case, as well as when using some other authentication methods, the user can be helped by a backup method of restoring access with the help of pre-generated and saved in a safe place recovery codes; for example, Google offers to generate ten one-time eight-digit recovery codes in advance, save and print them.
To summarise, it is not safe to use one-time codes from SMS messages as a means of authentication. Fortunately, modern services offer to use applications on smartphones as a means of two-factor authentication. The most prominent examples of such software authenticators are Microsoft Authenticator, Google Authenticator, Yandex Key, Aegis Authenticator, andOTP and others. These applications can either generate one-time codes (based on the value of the secret key and the inbuilt counter or the current time) or display push notifications about the need to confirm account login. When adding such an authentication method, a website typically prompts you to first log in using your username and password, then launch a compatible application (the same Microsoft Authenticator or Google Authenticator) and scan a QR code displayed on the web page. This QR code contains a text string with a unique short-lived URL, following which the app communicates via HTTPS protocol with an authentication server and receives a secret key, which is placed in a secure section on the smartphone (e.g. Apple Keychain or Android Keystore). Then, when authenticating to a web service, after entering the login and password, the web page will either ask for a one-time numeric code, which will be generated by the customised application on the smartphone, or send a push notification requesting login confirmation.
This option is considered a more secure method of authentication, which, however, is not without disadvantages:
1. When using a software authenticator, web resources still require a login and password, which can be obtained by phishing or social engineering, and usually allow a fallback to a less secure method of authentication in case of a change of smartphone or lack of internet connection - including via SMS messages.
2. attackers, faced with the need to receive confirmation from the user, will ‘flood’ the application with push notifications (a technique called Push Bombing or MFA Fatigue Attack) in the hope that the user will think about a technical fault and at some point, tired of the requests, will still confirm the unauthorised access initiated by the attackers. In addition, some vendors, such as Microsoft, introduce an additional check - in the push message, a two-digit number must be specified, which is displayed on the web page to which the user is accessing - this is done to make it clear to the user which page he/she is confirming access to.
3. These methods do not protect against phishing: in the case of push notifications, attackers can use social engineering methods (e.g., calling the user on behalf of tech support and asking to confirm a supposedly ‘official’ login to the account), and in the case of one-time codes generated in an application or received via SMS, attackers use phishing sites where the user enters both login, password, and one-time code. Such phishing sites may have a reverse proxy (e.g., Nginx-based) that sends all the data (login, password, code) received from the user to the real website, receives a session cookie or JWT token from the website, which the attackers then use to gain unauthorised access to the site. The user, meanwhile, is on the page of the phishing resource, but sees in the web browser window the content of the familiar website (including all his files, mail, etc.), which is proxied by the attacker's server in order not to arouse unnecessary suspicions about the authenticity of the resource for the employee - such an attack can be realised, for example, through the freely distributed Evilginx utility. To counter such techniques, websites can control the simultaneous use of the same session cookies or JWT tokens from different geographical locations, from different IP addresses, as well as detect such Evilginx installations on the Internet due to multiple authentication requests from them.
As a result, we can conclude that the described methods of authentication with one-time codes will only protect the user from hacking or password mining (e.g., bruteforce, Password Spraying, Credential Stuffing), but not from phishing.
Besides, the increasing use of QR codes (for authentication, payment for services, clicking on links) causes users to have excessive trust in this technology. It should be remembered that a QR code can contain text (maximum 4296 alphanumeric characters) and a binary code (2953 bytes), and most often a QR code contains links indicating various protocols or URI schemes. Nowadays attackers use QR codes for quishing attacks (QR phishing), in which instead of usual text links users receive email messages with QR codes, which they are offered to click on under different pretexts, and the QR code contains a link to a malicious or fraudulent resource. Another attack technique is QRLJacking: attackers exploit the recently popular ‘Sign in with a QR code’ approach, patented by Google back in 2013. In normal use of this approach, a legitimate website (e.g., the Web version of a messenger) displays a QR code containing a session token, and the corresponding mobile application (messenger), when scanning this code in it, authorises (signs with its private key) this token to link the web session being set up with the messenger account being used - as a result, the user sees his chats and correspondence in the browser in the same way as in the mobile application. However, attackers can copy a QR code to authorise a web session controlled by them and offer the user to scan this QR code allegedly to add him as a friend or purchase goods at a discount in a closed chat - as a result, the user authorises this web session for attackers, within the framework of which they can get access to all correspondence and files of the user, disable the user's legitimate application and completely take over the account. To protect against such attacks, in addition to user vigilance, it is important for the creators of apps with QR code login functionality to display a notification to users that they are about to authorise a web session and this could lead to full control of their account.
Thus, the multi-factor authentication methods discussed above have some or the other drawbacks, but of course, there are also solutions on the market that are now considered to be quite secure and not susceptible to phishing attacks. NISTpublication SP 800-63B ‘Digital Identity Guidelines’ describes three Authenticator Assurance Levels (AALs):
- AAL1 - the first (lowest) level corresponds to simple password authentication or the use of only a one-time code for authentication;
- AAL2 - the second level requires the use of multi-factor authentication (e.g. knowledge+possession or possession+biometrics) or a combination of two single-factor authenticators (e.g. knowledge+knowledge and possession+possession);
- AAL3 - Level 3 requires the use of multi-factor authentication tools, including software and hardware devices with phishing protection.
Passkey - a form of passwordless authentication using software and hardware authenticators, such as FIDO2 devices, TPM chips (Windows Hello technology), Apple iCloud Keychain, Google Password Manager, Samsung Pass, 1Password, etc., offers phishing protection and eliminates the need for passwords. In essence, passkey is a certificate-based authentication technology (using asymmetric cryptography) with support for passwordless authentication, with wide functionality and support for new hardware and software authenticators. When using passkey technology for each website that supports the WebAuthn specification, a private-public key pair and a public key certificate are generated on a software or hardware user device: the public key is used by the website to verify the authenticity of the digital signature (created using the private key stored on the device) challenge-request of the website - if the verification passes, the user is successfully authenticated to the website. To access the private key stored on the device, the user must unlock the device: either by entering a PIN or by putting a finger on it - thus the requirement to provide the second factor is realised. Protection against phishing is achieved on the basis of the fact that passkey devices check the address in the browser with the address of the site specified in the certificate stored on the device, and do not authenticate in case of mismatch, which happens when entering a phishing resource. The main disadvantages of using passkey are limited support for passwordless login (so far, this method is supported by a few dozen major websites), possible compatibility problems between some devices and some websites, and the need to purchase a hardware device for maximum protection (you can choose, for example, Google Titan Security Key USB keys or the latest models of YubiKey or Nitrokey). In addition, not all sites allow to completely abandon standard authentication methods, so attackers can implement a Downgrade Attack, for example, due to the functionality of restoring access to the account in case of loss or breakage of the hardware device, which is often reduced to the same passwords and codes from SMS.
So, at the moment, it is unfortunately not possible to completely eliminate passwords on all websites, so it is still important to follow certain rules for working with passwords:
1. Create unique passwords for each website. If it is possible to set a user login, you can use the format userlogin_website, where userlogin is your unique username (make it as complex as your password if possible) and website is the address of the site where you are registering: in case the site leaks and user credentials are published on the Internet, this approach will help you to identify the leaked site and take appropriate precautions (e.g., delete all information from that site).
2. Do not use templates when creating passwords, e.g. website2024 (where website is the address of the site you are registering on). In case of a data leak from a website, all passwords are analysed by attackers who can understand what template/format you use to create passwords and can then find the password to your account on other websites.
3. When your password expires, change it completely, not just partially (e.g., just by adding one or two characters). Often sites require unscheduled password changes due to leaks, but if you only partially change your password, attackers will be able to find your new password based on your old password.
4. Check your credentials for leaked credentials, such as https://haveibeenpwned.com/, https://monitor.mozilla.org/, https://chk.safe-surf.ru/.
5. Use a strong password manager: not only will it help you create a complex and strong password, but it will only substitute it on genuine, not phishing websites. However, do not forget that a password manager is like a keychain that allows you to lose all your keys (passwords) at once; this can happen if a vulnerability is discovered in the password manager.
6. Don't forget that authentication and authorisation are different processes: successful authentication is followed by the transfer of a certain ‘secret’ (session cookie, web access token, Kerberos ticket) to the user, which can then be stolen or intercepted by attackers and used to gain unauthorised access to the user's resources. For example, one way to hack Telegram (even with two-factor authentication enabled) is to steal a user's session by accessing the folder with the installed Desktop version of the messenger on the computer, which stores the access token the user received after legitimate authentication. In this way, viruses on PCs and mobile devices will be able to gain unrestricted access to your accounts despite multi-factor authentication being enabled.
7. Be particularly vigilant about protecting accounts that can be used to log in to many websites: major Internet companies (Google, VK, Yandex, etc.) support OpenID Connect and OAuth 2.0 protocols for logging in to third-party sites with a single account (e.g. ‘Log in to the site via your VK profile’). It should also be remembered that, in addition to providing the described access functionality, such Internet giants can exchange data (purchases, actions, personal data) about ‘their’ users with these third-party sites.
.jpg)
