SASL Analysis, Part Five

Previous episodes have been devoted mainly to technical analysis and description of the algorithms used. The above algorithms have a large number of bottlenecks, which creates an interesting situation when it is necessary to choose the required algorithms. Because there is no perfect solution, the algorithms in this article are divided into groups with similar problems. Thanks to this, it is possible to get an idea of the whole situation and possibly make a decision based on the current situation.

Why are authentication algorithms so important?

The basic part of access to information is the authentication of the applicant. The applicant is reported to the system at the beginning, he identifies himself. In order to assign any permissions to the user, the system must verify him or her, i.e. check the validity of his or her identity. It is for this reason that authentication is a critical point in access to data, it must ensure the highest possible accuracy. Only after authentication is it possible to assign rights to the users, giving them the possibility to access the selected information.
Apart from the assumption for assigning permissions, authentication supports other properties. First, it is one of the forms of authenticity (authenticity, originality of data), which is related to a specific user. This proof of authenticity is provided by the system only in its area of competence. A general proof of authenticity can be a digital signature. Second similar property is non-repudiation, i.e. proof of the user's inseparable connection with specific data or activity.

Algorithm Problems

The previous four parts of the authentication mechanism analysis were intended to acquaint those interested with the technologies used in each algorithm. The reason is the need to provide adequate data for authentication by any reader interested in cryptography. Currently, there is a large increase in the number of attacks and also a significant increase in their quality. Current authentication algorithms are not able to adapt to this situation, they are practically past their zenith and substitutes are not available. Although the above mentioned mechanisms are at the basis of authentication. All problems found can be summarized in the following points:
- no cryptoprimitives.
- obsolete cryptoprimitives or obsolete methods of using the above cryptoprimitives.
- no or low resistance to attacks with the help of quantum computers.
- authentication mechanisms do not meet the conditions to protect the transferred data from repetition, redirection, hijacking of connections or falsification of communications, or they do not support forward secrecy (a communication captured in the past allows to derive the transferred information in the future).
- the authentication mechanism does not provide full protection of the transferred data and a link to other communications.
- the authentication check is performed by a logical barrier (condition), when compliance with the condition can be achieved by modifying the executed code.

Methods without cryptography

Authentication methods that do not use any methods of protection with cryptography cannot be considered safe. This is a necessary condition, but not sufficient, as will be stated below. Among the above mentioned algorithms it is possible to include:
- ANONYMOUS (there is no authentication).
- LOGIN.
- PLAIN (data transmitted as a Base64 coded string, there is no protection).
- OAUTH, OAUTH10A, XOAUTH (only for HTTP Basic Authentication).
- OAUTH2, OAUTHBEARER, OPENID2 (only for HTTP Basic Authentication).
- SAML (only for logging against SQL/NoSQL systems with web interface and HTTP Basic Authentication, for other systems supporting the PLAIN and LOGIN methods).
All the above methods require the use of transport encryption (SSL/TLS) and the enforcement of two-way authentication (mTLS – Mutual TLS). Otherwise it is possible to perform SSL inspection and to eavesdrop on the actual logging information transmitted. For the OAUTH2, OAUTHBEARER and OPENID20 methods it is to some extent supported to use JWT token encryption. Another Proof Key for Code Exchange (PKCE) method protects only Authorization Code Grant. Deployment of the above methods is therefore to some extent a security risk and it is necessary to ensure thorough authentication of the target systems.

Obsolete crypto-primitives or methods

A large number of designs have emerged during development that do not support new encryption algorithms. Similarly, there have been developments in the way algorithms and their protections are used, the width of the key material and other parameters. In this section, only methods are mentioned for which it is not possible to switch to the current algorithms or corresponding key widths. They are ranked here:
- 9798-U-DSA-SHA1, 9798-M-DSA-SHA1 (use of obsolete DSAs and SHA1).
- 9798-M-ECDSA-SHA1, 9798-M-RSA-SHA1-ENC, 9798-U-RSA-SHA1-ENC, SRP, SCRAM-SHA-1, SCRAM-SHA-1-PLUS (use of obsolete SHA1, SRP and SCRAM algorithms are still resilient).
- CRAM-MD5, DigestMD5 and Compuserve RPA (broken MD5, but in this case CRAM-MD5 is still resilient due to HMAC construction).
- PASSDSS, KERBEROS_V4 (obsolete DES).
- KERBEROS_V (use of obsolete or broken DES, 3DES, RC2, RC4) - NMAS_AUTHEN, NMAS_LOGIN (even in case of use of obsolete and broken MD5 and SHA1 the algorithm still resists thanks to the HMAC function).
- NMAS_SAMBA-AUTH, NTLM, SPNEGO, SPNEGO-PLUS, GS2-*, GSSAPI, GSS-* (when calling NTLM it is not possible to ensure security).
When using these algorithms it is again necessary to deploy transport encryption. Trust in these algorithms is not justified, they are rundown algorithms with limited use. In the case of SPNEGO, SPNEGO-PLUS, GS2-*, GSSAPI, GSS-* if only the KERBEROS-V5 protocol is available, not NTLM, this is a reasonable method of protection. Another, substantial detail with an impact on security is the use of the PLUS method, or 9798-M-*. These two methods provide a link to transport encryption using SSL/TLS and add an additional layer of protection. This can provide at least limited protection against the risk created by SSL inspection to some extent.

Notes - obsolete cryptoprimitive:
- MD5 function hash, finding a collision in under one minute, HMAC structure safe for now.
- SHA1 hash function, finding a collision in a matter of days, HMAC structure safe for now.
- RC4 stream cipher, successful attack can be realized in 12s according to the volume of data.
- DES, 3DES have a block width of only 64b and have a vulnerable structure. Attack can be realized in a matter of hours according to the volume of data.
- RC2 has an obsolete structure and is a rundown algorithm.
- DSA has an obsolete structure and is a rundown algorithm.

Resistance to quantum computers

There are only a few algorithms within SASL that are able to withstand quantum computers. This is the KERBEROS_V5 method using the aes256-cts-hmac-sha384-192 and camellia256-cts-cmac algorithms. Under certain conditions, the EXTERNAL method could also serve this purpose if there is verification e.g. at the SSL/TLS level using algorithms resistant to quantum computers. However, due to the possibility of downgrade to weaker protective mechanisms, relying on other layer methods is rather unfortunate.
Notes - Quantum computer resistance:
- Current asymmetric algorithms are not able to withstand quantum computers.
- Current symmetric algorithms can withstand quantum computers if the key length is at least 256b.

Methods of protection of transmitted data (credentials)

Depending on the algorithms used and the ability to protect the transmitted information, it is possible to divide the algorithms in different ways.
- Unpredictable. One of the protection mechanisms is the use of a random prompt, time stamp or number of logins to change the content of the transmitted data. This ensures a certain degree of randomness, which can help in the protection, unfortunately it is not self-saving. This is an extensive list of methods 9798-M-DSA-SHA1, 9798-M-ECDSA-SHA1, 9798-M-RSA-SHA1-ENC, 9798-U-DSA-SHA1, 9798-U-RSA-SHA1-ENC, CRAM-MD5, DIGEST-MD5, EAP-AES128, EAP-AES128-PLUS, ECDH-X25519-CHALLENGE, ECDSA-NIST256P-CHALLENGE, EXTERNAL, GS2-*, GS2-KRB5, GS2-KRB5-PLUS, GSS-SPNEGO, GSSAPI, KERBEROS_V4, KERBEROS_V5, NEGOEXT, NMAS_AUTHEN, NMAS_LOGIN, NMAS-SAMBA-AUTH, NTLM, PASSDSS, Compuserve RPA, SCRAM-SHA-1-PLUS, SCRAM-SHA-256, SCRAM-SHA-256-PLUS, SPNEGO, SPNEGO-PLUS, SRP and SXOVER-PLUS.
- Authentication bond between server and client. It allows the connection to the communication channel between the client and the server. These protective mechanisms are minimal. It is used to protect the communication channel from hijacking during authentication. These are the PASSDSS, SRP, ECDH-X25519-CHALLENGE and SXOVER-PLUS methods.
- Double-sided authentication that not only verifies the client, but also the server to which it logs in. The condition is the availability of information that provides the possibility to verify the server. These technologies are hardly used, only PASSDSS, SRP, ECDH-X25519-CHALLENGE and SXOVER-PLUS methods support them.
- Protection against channel counterfeiting by forward secrecy protects the ability to separate past messages from future ones. This makes it impossible to attack and decrypt new transmissions based on knowledge of past answers. Thorough processing of these protections is minimal and they are only supported at the SSL/TLS level.
- The link between the authentication and the transmission channel as protection against connection hijacking is only available for PLUS methods. These are the methods 9798-M-DSA-SHA1, 9798-M-ECDSA-SHA1, 9798-M-RSA-SHA1-ENC, EAP-AES128-PLUS, GS2-KRB5-PLUS, SCRAM-SHA-1-PLUS, SCRAM-SHA-256-PLUS, SPNEGO-PLUS, SXOVER-PLUS.

Password validation methods (validation)

With one exception, all methods currently used use the method of validation by logical constructs. SRP In simple terms, this is the condition where if side A is the same as side B. The user is admitted to the system. In contrast, the cryptographic system provides proof of the ability to decrypt certain data. For validation, it is sufficient to provide proof of the ability. If the user does not provide an adequate answer, he is not admitted to the system. To some extent, this is a procedure similar to ZKP (Zero Knowledge Protocols). In this case, evidence is provided that must not in any way provide information leading to the discovery of data capable of providing such proof. The sentence is difficult to understand, but an example is finding a word in a book. You are supposed to provide evidence of finding a specific word in a book of your choice, without the possibility for the opposing party to be able to determine which book or page of this book it is. The solution is quite simple. A word-sized hole is cut out in the box and you show the chosen word through this hole. The opposing party has no chance of knowing the name of the book or the page number. Similarly, authentication information can be verified. In the case of password validation, this exception is the SRP method.

EXTERNAL, GS2-*, GSS-*, GSSAPI, SPNEGO, SPNEGO-PLUS and NEGOEXT

With these methods, it is difficult to determine which mechanisms will be chosen, because the methods are negotiated first, and the password validation later. For the reasons given, it is not possible to unambiguously determine the security properties.

OTP, SKEY and SECUREID

The above methods serve as supporting methods suitable for MFA and cannot be used on their own. The key materials used have too low entropy and can be detected with a reasonable number of attempts. All three methods are available with the old cryptoprimitives MD5 and SHA-1 as well as with the current versions using SHA2-256. If the above technologies must be used, it is advisable to use the current versions of cryptoprimitives. Due to the design, it is currently possible to deploy OTP using TOTP or HOTP algorithms, but the SKEY and SECUREID methods are currently outdated. In the case of SKEY, this is an easy denial attack because the token without power loses information about previous iterations of hash functions. In the case of SECUREID, there have been several problems with token synchronization in the history, seed (generating information) leaks and several MITM vulnerabilities. Time and counter tokens are significantly more vulnerable in this way than Challenge-Response tokens or tokens requiring more complex handling. On the other hand, they are extremely easy to use. This makes them easy to use.

Methods OAUTH, XOAUTH, OAUTH2, OAUTHBEARER, XOAUTH2, OPENID20, SAML

The above methods are not mentioned in the previous paragraphs for a simple reason. The above algorithms provide authorizations based on simple authentication mechanisms. Authentication, which is only a part of the services, occurs when redirected from the application. The client (user) is redirected by this application to an authentication server, providing identity authentication, hereafter only tokens are used. The above solution has a large number of advantages and disadvantages, so it is necessary to mention the limitations of these mechanisms separately. Due to the complexity of the protocol, especially in the case of OAUTH2 and similar, there are significant risks roofed:
- Session Fixation, a bug allowing hijacking of the authenticated connection. It is based on using the same Session ID. The attacker has thus obtained the victim's permission.
- Weaknesses in the processing of the authentication token. allows its hijacking during the initial negotiation. To protect the token, it is necessary to use its encryption with the PKCE (Proof of Key for Code Exchange), it should not be used in a purely textual form. Furthermore, the token can leak even if it is stored locally with the client. If it is stored in localStorage, it can be retrieved by XSS attack. If the token is passed directly in the URL, a typical example is ImplicitFlow, it can be retrieved directly from the referrer logs (Implicit flow should not be used and replaced by Authorization Code Flow together with PKCE). SecureCookies can be used as a defense in this case, defining scopes and the like.
- The unlimited validity of Access Tokens is obviously an inappropriate approach. If they leak, then it is not possible to invalidate these tokens, or it is a long time. For practical reasons, it makes no sense to have the validity of the token longer than 10-15 minutes, in extreme cases half an hour.
- Like Access Tokens, Refresh tokens are vulnerable. They should be stored securely and rotated regularly.
- Missing digital signatures in the JWT token. These tokens generally allow to significantly increase the security of communication against text tokens, but the condition is the corresponding use of cryptography. For this reason, it is extremely inappropriate to use the "none" algorithm, which allows the transmission of unencrypted information.
- By controlling the application. A legitimate application controlled by an attacker allows to obtain sensitive information. This can be used to attack JWT tokens (JWT_private_key). This error was found in the course of 2024 and removed in the beginning of 2025, resulting in a change in the processing method.
- Malignant applications that pretend to be legitimate applications allow to obtain Access tokens. For this reason, it is necessary to use Client Registration, this is information about the applications being used (ideally Client ID and secret access) and the permission to request tokens.
- Phishing is a matter related mainly to e-mails, but its targeting of specific users allows access to authentication data. These are usually errors on the part of users, therefore it is necessary to use MFA to ensure appropriate authentication by another channel. In addition, it is advisable to authenticate the target servers for authentication for client applications, using for example OAUTH state.
During the development, OAUTH2 has seen a significant change of the whole working group with interesting consequences. This group of people criticized the new standard because of the following problems, where most of them have still not been satisfactorily solved and some of them will be implemented in the upcoming OAUTH2.1. At the same time, these problems describe the security weaknesses of the whole system and still represent a significant criticism of the whole standard. More in the link under [1].

Authentication for OAUTH and XOAUTH

The OAUTH and XOAUTH methods allow authentication only by means of mechanisms such as HTTP Basic Authentication, Digest Authentication, or with the possibility of additional authentication using OTP or FIDO2. Authorization tokens are also provided on the basis of authentication. Since the technology is not able to provide adequate protection of user passwords, it is necessary to protect it with SSL/TLS. Unfortunately, this protection is not perfect either, as there is no two-way system authentication. For this reason, the method is vulnerable using SSL inspection (border firewalls).
Protection against Relay attack: The condition is a link to the server certificate (two-way authentication using mTLS – Mutual TLS). This type of attack is not prevented by MFA.
Protection against Replay attack: With the exception of HTTP Basic Authentication, it is possible to defend against replay attack and MFA supports this defense.
Forward secrecy: Only possible at SSL/TLS
Crypto-primitives: In case of using Digest Authentication, it is possible to use MD5, SHA1 and SHA256, where MD5 and SHA1 are obsolete.
No crypto-primitives are used for HTTP Basic Authentication, this is pure plaintext.
Quantum computer resistance: Possible only if SSL/TLS is used, with support for quantum computer resistant mechanisms.
Zero Knowledge Protocols: No support for SRP or other similar mechanisms.

Authentication for OAUTH2, OAUTHBEARER, XOAUTH2 and OPENID20

The OAUTH2, OAUTHBEARER, XOAUTH2 and OPENID20 methods allow authentication only with mechanisms such as HTTP Basic Authentication, Digest Authentication, or with the option of additional authentication using OTP or FIDO2. From today's perspective, it is an obsolete method to send the name and password directly in the POST request directly (Resource Owner Password Credentials). Another, but rare, method is to send the name and password in an encrypted JWT, this method is not commonly used. Authorization tokens are also provided on the basis of some of the above authentication options. Since the above technology is not able to provide adequate protection of user passwords, it is necessary to protect it with SSL/TLS. Unfortunately, this protection is not perfect either, as there is no two-way system authentication. For this reason, the method is vulnerable with SSL inspection (frontier firewalls).
Protection against Relay attack: A condition is a connection to the server certificate (two-way authentication with mTLS – Mutual TLS). This type of attack is not prevented by MFA.
Protection against Replay attack: With the exception of HTTP Basic Authentication, it is possible to defend against replay attack and MFA supports this defense.
Forward secrecy assurance: Only possible at SSL/TLS
Crypto-primitives: If Digest Authentication is used, it is possible to use MD5, SHA1 and SHA256, where MD5 and SHA1 are obsolete.
Without cryptography: No crypto-primitives are used for HTTP Basic Authentication, this is pure plaintext.
Immunity against quantum computers: Only possible if SSL/TLS is used with support for quantum computer-resistant mechanisms.
Zero Knowledge Protocols: No support for SRP or other similar mechanisms.

Authentication for SAML

This method covers and uses other methods, so it can work with a wide range of possible mechanisms. It depends only on the properties of the Identity Provider (IdP, i.e. Authentication server). The following can be used as an authentication server:
- LDAP, where LDAP supports SASL mechanisms.
- Active Directory (LDAP+DNS+Kerberos), where AD supports primarily KERBEROS.
- User database in SQL/NoSQL systems, where login uses mostly HTTP interfaces and TTP Basic Authentication mechanisms, Digest Authentication, or with the possibility of additional authentication using OTP or FIDO2.
- External authentication systems (OAuth 2.0, OpenID Connect, Kerberos, RADIUS). OAUTH20 or OPENID20 have been mentioned, and KERBEROS is also clear. For AAA systems (Authentication, Authorization, Accounting) such as RADIUS, TACACS+ and DIAMETER, it depends on the support of authentication mechanisms. As systems usually support EAP mechanisms, it is necessary to use the gateways for transmitting information (SAML-to-RADIUS, SAML-to-TACACS+, SAML-to-DIAMETER).

Even in the case of SAML, there is a risk of unauthorized access to data. Possible attacks include:
- Assertion Replay attack. The message is intercepted by the attacker and sent again. As a precaution, it is possible to set the assertion lifetime in the order of units, up to tens of minutes. Furthermore, strictly use nonce and timestamp, outside of this set the One-Time Use Policy tokens for all SAML tokens. Information about assertion status can be checked in the dump saml:Conditions NotBefore and NotOnOrassertion.
- Manipulation assertion. If the assertion is not digitally signed and encrypted, the attacker can manipulate it. Therefore, plaintext assertion should not be used at all. All transmitted information should be encrypted, signed (ideally including metadata) and only messages containing a valid signature should be received.
- XML External Entity (XEE). This is a bug caused by the parser for an XML document, which allows additional content to be inserted, for example, by a server-side request forgery (SSRF). Components should be tested and ideally run in a dedicated environment.
- E-mail forwarding. This is a bug related to attribute verification in SAML (saml:Attribute), where insufficient system control of the e-mail's domain affiliation can create an awkward situation. Thus, under certain conditions, a valid e-mail can be used by the first user to gain access to the other user's data. Although the Identity Provider (authentication server) returns the correct information, the problem is due to faulty authentication on the Service Provider side (SP, usually an application).
- XML Signature Wrapping (XSW) Attack. The message is intercepted and modified by the attacker, who adds a modified element to the XML. This can obtain different permissions or another user ID. The protection is the XPath validation setting.
- Signature Stripping Attack. This is a setup error, messages must always be checked for a valid signature. If the specified check is not used, you can either modify and send the modified request, or modify the token and leave the signature in its original form.
- SAML Response Spoofing. Here, a modified new message with different user permissions is created. If the description is not verified correctly, you can obtain rights beyond the definition. The solution is a consistent signature check and Audience Restriction in SAML assertion.
- Relay Attack on SAML Single Logout (SLO). This is a malicious attack, where the logout request is modified. This prevents the attacker from logging off, but another user. The protection is to enforce Channel Binding and digital signature even for logging off, and to check who the requests are really intended for.
- Account Takeover using SAML Injection. If the content of a SAML request can be modified and the application does not verify the trust of the source, the attacker can gain access to other data. Therefore, it is necessary to validate all attributes and enforce the digital signature.
- Man-in-the-Middle (MITM) Attack. This is only the case when the message is not adequately protected. Therefore, it is necessary to use at least SSL/TLS.
- Phishing is a matter related mainly to e-mails, but its targeting to specific users allows access to authentication data, as with OAUTH mechanisms. These are errors on the part of users, therefore it is necessary to use MFA to ensure appropriate authentication via another channel. And as with OAUTH, it is advisable for client applications to authenticate target servers for authentication.

Mechanism support on the part of individual libraries

The overview also includes information on current and past support of mechanisms in some known libraries. The overview can be an interesting guide in case of selection. From the information available, an unpleasant situation is obvious. There is not much choice, only combinations meeting at least the minimum authentication security requirements are sought.

Conclusion

From the point of view of the current deployment of mechanisms, the problem is how to provide adequate protection. The available technologies are maturing and are completely unprepared for changes around 2030. There is a lack of mechanisms providing two-sided authentication (i.e. client and server side authentication), a lack of technologies providing ZKP (Zero Knowledge Proof), technologies using up-to-date cryptoprimitives or algorithms resistant to quantum computers. Because of the weaknesses of OAUTH/OAUTH2-based technologies, it is advisable to avoid them, but the technologies using SAML are promising and allow the system side to define the corresponding algorithms and their protection. This partially eliminates their weaknesses.
From the current perspective, it still makes sense to use technologies such as SCRAM, SRP or SXOVER. Of the commonly used ones, KERBEROS_V5 is either directly or via available interfaces such as GSSAPI or GS2. Here I would argue for a move away from all NEGO algorithms that allow fallback on NTLM. Another option is SAML, for example, but its configuration is extremely demanding. The reward can be a relatively high level of security in case of a suitable configuration. In the case of Microsoft environment, SAML is not available via SSPI, but it can be used by ADFS (Active Directory Federation Service) or AAD (Azure Active Directory).

Autor článku:

Jan Dušátko

Jan Dušátko has been working with computers and computer security for almost a quarter of a century. In the field of cryptography, he has cooperated with leading experts such as Vlastimil Klíma or Tomáš Rosa. Currently he works as a security consultant, his main focus is on topics related to cryptography, security, e-mail communication and Linux systems.