Secure Remote Password (SRP)

Considering the value and avoiding pitfalls

I’ve been working on a penetration test of an application that is using the Secure Remote Password Protocol. I decided to dig in a bit deeper to see how this protocol works in detail and if I could find any weaknesses in the implementation.

This quest led me down a rabbit hole of poorly defined specifications, versions and documentation. After hunting through details, videos and blog posts, this is my conclusion, a simpler explanation, and things to check if you are using Secure Remote Password Protocol to help ensure your implementation is not vulnerable to attack.

⚙️ Check out my series on [*Automating Cybersecurity Metrics](https://medium.com/cloud-security/automating-cybersecurity-metrics-890dfabb6198). The [Code](https://github.com/tradichel).*

🔒 Related Stories: [*Secure Code](https://medium.com/cloud-security/secure-code-by-design-4ee8814021e6) | [Data Breaches](https://medium.com/cloud-security/data-breaches-5043d0a74cbb) | [Pentesting](https://medium.com/cloud-security/pentesting-and-bug-bounties-46bd69ef486d) | [Bug Bountie](https://medium.com/cloud-security/pentesting-and-bug-bounties-46bd69ef486d)s*

💻 Free Content on* [Jobs in Cybersecurity](https://medium.com/cloud-security/cybersecurity-careers-and-jobs-69c05616d2b4) | *✉️ Sign up for the [*Email List](https://2ndsightlab.medium.com/subscribe)*

Password Authentication Key Exchange (PAKE)

For starters, Secure Remote Password Protocol is a type of PAKE or Password Authentication Key Exchange. I’ll let you research all the references at the bottom of Wikipedia if you want to know the full history but basically people were trying to determine if and how they could authenticate users without actually sharing the password the user uses to log into the system. That protects the password from some, but not all forms of attack.

[embed]Password-authenticated key agreement - Wikipedia en.wikipedia.org

Side note — I found it funny that PAKE means Chinese in Hawaiian, but I digress.

How can you authenticate an identity without sharing the password?

The answer involves cryptography and encryption which is ultimately math. There are ways to derive encryption keys using passwords that can then be able to encrypt messages sent back and forth.

But it’s never simple. It’s easy to make simple logical flows that render encryption useless. It’s also possible to encrypt your data with a provably secure method but then leak some data that let’s attackers reverse engineer your encryption anyway. All the details matter and that’s why you often hear security professionals say, “Don’t roll your own crypto.” Use a standard library that has stood the test of time and had the vulnerabilities worked out. Hopefully.

That is until quantum computing comes along and makes it all useless, but we’re not there yet so let’s see how this protocol works.

Even if you use provable security the algorithms themselves depend on external inputs that must be handled securely and anything your security solution integrates with needs to be secure as well. That’s where the problem often arises.

Math

My forte is logic. I almost got 100% on GRE and perhaps it would have been 100% if I had more time. I had to guess on the last couple of questions. At any rate I was close.

Math, not so much. I mean, logic is the basis for math but when you throw all these symbols on top of the math my brain starts to spark from overload.

[embed]Secure Remote Password protocol - Wikipedia en.wikipedia.org

But if you explain the logic to me in plain English, I’d get it. Unfortunately the English in the specifications I’m about to share here are not so plain either. Hopefully I can make it simpler and help you ensure your SRP implementations are secure. Any person working in QA testing an application using SRP should check these things.

Here’s the thing. I think a lot of the math out there could be explained much more simply using simple words and straightforward logic. Then it would easier to comprehend. At least for me. Once you have the plain language explanation looking at the math itself becomes less daunting. Like what the heck is a and A and g and H and etc. etc. etc. above. I’ll try to sort some of that out below.

Sometimes I wonder if people are trying to obscure the math and logic so as not to allow you to spot a potential weakness of the implementation. Why are their thoughts not more organized and why isn’t the solution explained in a clear logical order? Perhaps they are intentionally trying to confuse you or their thoughts are just not based on the best logic.

Trying to use ChatGPT for security? Don’t.

Just for fun I went to ChatGPT and asked questions and the answers were abysmal. ChatGPT gave me a half-baked answer missing some of the most important calculations and said, “there’s a lot more to it” basically.

So I asked it to give the “a lot more to it” and I had to do that about 10 times and still never got a complete or correct answer.

In fact, one of my sources below outlines a vulnerability when a particular formula in the process is implemented. When I asked ChatGPT specifically for that formula — it give me the vulnerable version.

If you are using ChatGPT to find secure security implementations, DON’T.

I repeat: Do not count on answers from ChatGPT or any other non-deterministic source for answers to security questions. I wrote about the problems with non-deterministic sources in security in this post:

[embed]ChatBot Security Taking a look at the security risks associated with ChatBotsmedium.com

Verify the answers with other credible and hopefully *primary sources also known as original sources*.

Primary Sources

Hopefully you learned what original sources were in school, and this applies to more than just security in this day and age of blatant misinformation coming from politicians, foreign bot armies on social media, and malicious actors posting incorrect information on blog posts to get you to implement insecure systems and software.

[embed]What is a primary source? — Ask a Librarian ask.loc.gov

It is very important to use primary sources if you want to implement secure solutions. Then cross-reference the primary source with as many other sources as possible to find any potential vulnerabilities or weaknesses in the primary source. Always make sure you are using the most up to date guidance from a credible source.

So what’s our primary source in this case? It’s the specifications that define the protocol. The only problem is that the specifications are not well organized or clear for this particular topic. In addition to reading the specifications I scoured many other sources for days to understand the details and the history behind this specification.

Version confusion makes obtaining a primary source difficult

As I’m searching around for information I saw references to SRP version 1, 3, 6 and 6a.

I came across this version which seems to be the primary SRP protocol definition. But is it the latest version?

[embed]RFC 2945: The SRP Authentication and Key Exchange System This document describes a cryptographically strong network authentication mechanism known as the Secure Remote Password…datatracker.ietf.org

That particular specification above does not have any of those versions in it. Or at least I thought it didn’t the first time I searched for version in the document. But now I’m seeing this:

I’m not sure about the point on eavesdropping as I’m currently performing a MITM on my own session in Burp and it’s not stopping me from seeing anything except the user’s password during the authentication process. I can still easily steal the JWT token and use it for the particular application I’m testing. It may also be possible to derive the password if the implementation is weak due to the vulnerabilities described below.

There’s a version link on the side but it seems to only go up to version 3.

At this point, I’m wondering where the mystical version 6a is and why it is not clearly documented on Wikipedia and in the IETF Tracker.

So I had to hunt around to figure out where the latest primary source was for version 6a, the latest.

We find in the notes of RFC 5054 that it is version 6 of the SRP protocol but seems to be specifically related to TLS rather than authentication via a password in an application which is a bit confusing:

The version of SRP used here is sometimes referred to as “SRP-6” [SRP-6]. This version is a slight improvement over “SRP-3”, which was described in [SRP] and [SRP-RFC]. For convenience, this document and [SRP-RFC] include the details necessary to implement SRP-6; [SRP-6] is cited for informative purposes only.

[embed]RFC 5054: Using the Secure Remote Password (SRP) Protocol for TLS Authentication www.rfc-editor.org

Now when I search around I can’t actually find a specification for SRP version 6a. When I ask ChatGPT it points to a paper by Tom Wu and this link to some information at Stanford, which ironically has a failing TLS connection at the moment, at least on my home computer. It works on my mobile phone:

https://srp.stanford.edu/srp6a.pdf

I also had to ask ChatGPT like 5 times to get it to give me that link.

Apparently Tom Wu went to Stanford? This link is also insecure from my home computer for some reason.

http://www-cs-students.stanford.edu/~tjw/

Note that there are some posts out there from “Tom Wu” on non-Stanford URLs. I would be careful with those. Refer to original sources.

If you want to know why version 6a changed the formulas here’s answer:

If k is a constant, such as 3, it becomes possible to select a pair (N,g) such that the discrete log of k to the base g is known, which would enable the two-for-one guessing attack again.

[embed]Why does SRP-6a use k = H(N, g) instead of the k = 3 in SRP-6? I’ve been reading up on the Secure Remote Pasword protocol (SRP). There are a couple different versions of the protocol…crypto.stackexchange.com

But none of that is clearly documented in specifications on IETF. So this whole thing is very, very confusing and I think someone should address that. I’m not sure who is responsible for such things.

A simpler explanation of SRP

This presentation was one of the best descriptions of SRP I found. However, ironically someone called out during his demo that he forgot a step I’m going to explain below that you may be missing — verifying the shared secret value calculated by the client and the server.

[embed]

SRP Involves the following steps generally though there are some variations. And basically this is a variation of the Diffie-Hellman Key Exchange for those who are familiar with cryptography and encryption in transit. Diffie-Hellman is a way to exchange a secret between two parties without exposing it to anyone who might be listening on the wire and is the backbone of SSL and TLS (at the moment — watch for changes with quantum computing on the rise).

[embed]RFC 2631: Diffie-Hellman Key Agreement Method datatracker.ietf.org

Here’s a picture of Diffie Hellman from Wikimedia that’s a pretty nice representation.

https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

Although this is a variation of Diffie-Hellman, SRP does not include authentication of the server in the same way TLS does with an external certificate authority. More on that below.

Also, Diffie Hellman is used to create a shared secret that can be used for encrypted communications in transit. Although a shared secret is created in the SRP process it’s not clear how that is used for an authentication process. It seems like the important bit is to hash the password and some other information on the client side and send it to the server.

The password sent to the server is already protected by the hash so I’m trying to figure out why the secret session key is generated and what it’s used for if you’re also passing a JWT and not encrypting it with A and B — which seems like overkill since the communication is already encrypted in transit via TLS (or it should be). What am I missing? Still thinking about it.

But anyway, let’s take a look at the protocol in more detail.

Here’s a high level overview of the protocol. I have a more detailed walkthrough with screenshots of the actual specification below.

1. The user chooses a username and password
2. The user generates a hash (x) of username, password, and a random salt.
3. The client shares x with the server (The specification is unclear as to who generates the hash and almost sounds like the server does it but this is my interpretation since the server is never supposed to receive the password. In fact the client could calculate the verifier and send it to the server also, but this is all very unclear. In any case, the password should not be sent to the server).
4. The server calculates a verifier (v) from x.
5. The server stores either the hash or the verifier. This is also unclear in the specification. From most things I’m reading it sounds like the server stores v but it could also store x and calculate v as needed.
6. To authenticate the user generates a random number (a) and uses that to generate a public key A which it sends to the server.
7. The server generates a random number (b) which is uses to generate a public key B using the verifier (v) and sends it to the client.
8. The client calculates the session key (S) and hashes it (K) and then calculates (M1) with a specified formula and values known to it, encrypts M1 with B and sends it to the server.
9. The server calculates the the session key (S) and hashes it (K) and then calculates M2 with a specified formula and values known to it.
10. The server verifies that M1 = M2 which proves that the client has the same session key value as the server.
11. If the user wants to change their username or password, then a new hash needs to be calculated and passed to the server for use in a new calculation of the verifier for all further authentication operations.

Now…what can go wrong?

Improper implementation of calculations

This post explains how leaving the end off one particular calculation in the process leads to a vulnerability.

[embed]Exploiting two buggy SRP implementations In this blog we'll look at an interesting vulnerability in some implementations of a widely used authentication…www.computest.nl

Just out of curiosity I asked ChatGPT for this specific formula and it gave me the vulnerable version! When I told it the version was vulnerable it then gave me the correct version. It may be fixed in ChatGPT now but that doesn’t mean something else is not wrong that ChaGPT is giving you in regards to security solutions so do not use ChatGPT or any other ChatBot for security code or solutions.

[embed]ChatBot Security Taking a look at the security risks associated with ChatBotsmedium.com

Failure to use truly random values

Apparently this paper discusses the importance of some random values according to ChaGPT, but I can’t exactly read it. Any time you are using random values, you have to make sure the libraries and software generating the values do not have randomization flaws that lead to numbers that are easy to guess. Without random values your encryption is useless.

Vulnerabilities in libraries that implement SRP

Here’s some information about PARASITE, an attack on SRP with OpenSSH: https://eprint.iacr.org/2021/553.pdf

[embed]PARASITE: PAssword Recovery Attack against Srp Implementations in ThE wild eprint.iacr.org

You can watch the video on YouTube: https://www.youtube.com/watch?v=kGQxUyngAiI

A video also covers a few attacks mentioned that have affected other PAKEs in the past like Dragonfly and OPAQUE.

It also mentions a side-channel attack on an Apple PAKE implementation:

Here’s a nice image from the above and there’s an explanation if you watch the video, which I recommend. In a nutshell — and this is the important nut for this post which I will explain further below and why it matters:

• Client generates A and sends it to the server.
• Server generates B and sends it to the client.
• Client generates M1 and sends it to the server.
• Server verifies client using M1 and other stored information.
• Server generates M2 and sends it to the client.
• Client verifies server using M2 and other information.

In the end, Parasite is a cache-based side channel attack. This attack relies on attacking the client and is a bit complicated. It also involves an attack on OpenSSL which has been patched as noted above. Make sure you are using the most up to date version of OpenSSL if you use it — and that all the libraries and services that use OpenSSL are up to date. This vulnerability was discovered three years ago now so no one should still be using that version of OpenSSL.

Misconfigurations in relation to use of SRP that facilitate vulnerabilities

Note that OpenSSL must also be configured properly to avoid the vulnerability in the last section. The patch did not apply the fix globally because according to the OpenSSL project that would cause performance issues.

The fix for this vulnerability uses the first option.

Other libraries and applications were vulnerable as well as subsequently patched as noted in the presentation and this white paper:

https://eprint.iacr.org/2021/553.pdf

You can find a POC of this vulnerability here:

[embed]DE ALMEIDA BRAGA Daniel / PoC SRP - CCS21 · GitLab Proof of Concept of a vulnerability in OpenSSL's implementation of SRP (Secure Remote Password)gitlab.inria.fr

Missing validation of the correct keys in key exchange

When I was looking at the requests and responses going back and forth between the client and the server for the particular implementation of SRP I was inspecting on my penetration test, I could not find nay evidence of verification of the encryption keys generated by the client and server. That post above validates what I was seeing on this particular penetration test which uses AWS Amplify.

[embed]Cognito php password SRP verifier challenge returns incorrect username and password I have a PHP webpage in which I have configured the aws sdk and instantiated the cognito client The client is…stackoverflow.com

I scoured the documentation for references to M1 and M2 and couldn’t find any. It would be helpful, if calling something an SRP implementation, to align the documentation and implement to the terminology in the actual specification. Here’s the documentation from the actual specification. Note this particular version of the specification is RFC 2945

https://datatracker.ietf.org/doc/html/rfc2945

Next the server responds with its own value to prove that it has the correct client key.

The above statement is misleading. I do not believe it authenticates the server but rather proves that the particular entity the client is exchanging data with has the same session key.

With TLS or SSL, the certificate if validated by an external third party (the certificate authority) who validates the certificate is coming from the entity you think it is coming from.

The out of band verification is similar to the reason you verify signatures of GPG keys before sharing encrypted documents as I explained in this post:

[embed]Sharing Encrypted Documents How to share encrypted documents via email using GPGmedium.com

It proves that someone has not intercepted the keys in transit and swapped them out with their own keys so they can read your data in a man-in-the-middle attack.

[embed]Different Types of Man-In-The-Middle Attacks ACM.297 Different points of MITM attack and how they can affect victims and websitesmedium.com

That said, verifying M1 and M2 will hep ensure data was not altered in transit in some unexpected way. It verifies the integrity of the values that the two sides share and ensures the calculations of the values were correct.

The more I think about this, the more everything related to SSL and verifying the client breaks down, so I’m going to stop thinking about that for the moment and focus on adhering to this specification.

Vulnerabilities in calculations and leaked data

Seems like there have been quite a few vulnerabilities in this protocol over time. Hopefully the latest is secure but I’ll leave the math to the cryptographers. Here’s my main concern from a logical perspective, given the sample formulas I presented above. I’ll repeat them here:

A + B = C

What is B?

Good luck…

Ok how but this formula?

100 + B = 101

What is B?

Since we are not actually passing the password back and forth — is there a way for an attacker to derive the password given all the above math? How thoroughly has this math been vetted, given that I cannot find a version of the spec on the IETF Tracker that is clear and includes the latest fix to a hardcoded value? I’ll leave that up to those who manage specifications and all the cryptography experts out there. For now, I’m just attempting to validate that implementations actually follow the specification and the implementation is as secure as possible given what is known to me at this moment.

Although the password is never sent to the server questions would be:

• Can the password be derived if the verifier is leaked such as in a data breach of the username and password database?
• If the server sends its salt and the username back to the client, can the verifier or the password be derived from that?
• Since the password is involved via the verifier in the calculation of B which is sent to the client, is there some way to derive the verifier and along with that the password from B?

In other words, with all the information being passed back and forth do they provide clues for obtaining the password without the existence of the password in the request and response?

Here’s a general critique of the SRP protocol suggesting others are better. I haven’t dug into whether that’s true or not. It mentions that OPAQUE is better and upon subsequent reading, that’s because OPAQUE does not send the salt and some other information to the client. But as noted above, OPAGUE has also had some vulnerabilities so check all the sources as I’ve done in this post for SRP for the latest information on OPAQUE.

[embed]Should you use SRP? This page has some wonky notes about the Secure Remote Password protocol. TL;DR: I don’t like it. It’s also not…blog.cryptographyengineering.com

The speaker in this video below has more information on PAKEs and explains how OPAQUE doesn’t transmit certain data to the client the way SRP does.

The more information you give attackers related to the values in a formula, the easier it will be for them to reverse engineer and figure out the value they want to derive or steal.

[embed]

Replay attacks due to lack of CSRF token or nonce

One other thing I noticed in the implementation I’m looking at is that the initial value sent from the client multiple times using the same value for A (the public key of the client.) Then the server responds with different versions of B each time.

Well, you think, that’s no problem. It’s just B’s public encryption key. But that encryption key is derived from the verifier. How hard is it to reverse engineer the verifier given enough B’s? I’ll let the cryptanalysts in the room figure that out, but in general it’s a good idea to include a CSRF token or nonce in any request to prevent replay attacks.

Securing the verifier

The hash (x) and verifier (v) used in SRP specification should be protected. Note this comment in the 5054 specification.

[embed]RFC 5054: Using the Secure Remote Password (SRP) Protocol for TLS Authentication This memo presents a technique for using the Secure Remote Password protocol as an authentication method for the…datatracker.ietf.org

Now initially I thought the verifier was stored in the database, however, it could be that the hash is stored in the database and the verifier is calculated for each session. In any case both the verifier and hash need to be generated with secure algorithms and formulas and properly secured from prying eyes.

I read countless arguments on this point before I finally wrapped my brain around this. I think some of the arguments are brute forcing passwords on a site —by entering different user names and passwords into the webs site until you find a combination that works — which this SRP process does not protect against.

What you want to protect against in your SRP implementation is allowing an attacker to crack the password hash created by the client. You can do that by ensuruing you use a strong algorithm to create the hash. Some state that you want to protect the verifier. But the verifier is calculated from the hash. Ultimatey it’s the hash created on the client and sent to the server that matters. That’s what you don’t want to allow an attacker to crack.

The point is when the database is stolen, the attackers only get a hash (or a verifier), not an actual password stored in the clear which many web applications mistakenly do. By only sending the web application a hash, an attacker can’t steal the plain text password and use it in credential stuffing and password spraying attacks against a whole bunch of other websites — unless they can somehow reverse that hash back to a password.

If you are using a weak algorithm to generate a hash, then you’re not really protecting the password and that value is still subject to compromise. The initial specification uses some form of SHA-1 to hash the passwords but there are stronger methods to create the hashed value you pass to the server. SHA-1 is not a good hash to use for this purpose.

Trying to modify the SRP to make it more secure

One alternative to encrypting the verifier would be to figure out a way to make the verifier harder to crack or to add some other additional security steps within the SRP protocol. And that’s where mistakes can be made.

This is an interesting post on the topic from Secure Remote Password. It appears that they integrated their solution with some additional components — a key derivation function (KDF) to improve the underlying security of the original proposal.

[embed]Secure Remote Password (SRP): How 1Password uses it | 1Password Today we’re announcing that our Go implementation of SRP is available as an open source project.blog.1password.com

Apparently they had a flaw in their implementation at some point.

Due to an implementation choice in our version of Secure Remote Password (SRP), we weakened an important layer of security in the way we set up network connections. That’s due to a historical deviation from standard SRP we’ve made in all our apps and integrations. As a result, the vulnerability is unique to 1Password’s way of using SRP.

…

We’ve mitigated the identified issue to protect the 1Password apps and integrations from this vulnerability, and you can update to a newer version of 1Password to fix the issue on your devices. Moreover, we intend to remove our historical quirk completely, and in the future move to a different password-based authenticated key exchange (PAKE) mechanism altogether.

[embed]CVE-2022–32550 for 1Password apps and integrations support.1password.com

This would permit the malicious software to exfiltrate vault items, as well as obtain derived values used to sign in to 1Password, specifically the account unlock key and “SRP-𝑥”.

SRP-x is the password hash on the client side used in the calculations below.

[embed]CVE-2024–42219 for 1Password 8 for Mac Learn how to set up and use 1Password, troubleshoot problems, and contact support.support.1password.com

The page number in the design document has changed since that blog post was published and I presume this process differs from the design at the time of the vulnerability. I believe they may have swapped out the key derivation function.

Deriving two keys from two secrets

As discussed in “Account password and Secret Key”, 1Password uses two-secret key derivation (2SKD) so that data stored by us cannot be used in brute force cracking attempts against the user’s account password. The two secrets held by the user are their account password and their Secret Key.

From those two user secrets the client needs to derive two independent keys. One is the key that will be needed to decrypt their data and the other is the key that will be needed for authentication. We will call the key that is needed to decrypt the data encryption keys (and in particular, the user’s private key) the “Account Unlock Key (AUK)”, and the key that is used as the secret for authentication “SRP-𝑥”. [Recall that x is the hashed username, password, and salt]

The processes for deriving each of these are similar, but they involve different salts in the key derivation function. A user will have a salt that is used for deriving the AUK and a different salt that is used for deriving the SRP-𝑥.

In both cases, the secret inputs to the key derivation process are the user’s account password and Secret Key. Non-secret inputs include salts, algorithm information, and the user’s email address

Implementing a secure version of SRP is not simple and modifying the process may solve one problem but then lead to another.

This appears to be the Defcon talk related to the above issue. I don’t see any references to SRP in here but one of these values was apparently used in SRP calculations on the client, it seems. I would need to read through this in a lot more detail to sort that out. Since this is not my particular scenario (at first glance), moving on.

[embed]

Validating the correct session keys are calculated by the client and the server

Note the steps in the specification above:

• Client generates A and sends it to the server.
• Server generates B and sends it to the client.
• Client generates M1 and sends it to the server.
• Server verifies client using M1 and other stored information.
• Server generates M2 and sends it to the client.
• Client verifies server using M2 and other information.

This last part of verifying M1 and M2 is what I’m looking for in a particular implementation I’m reviewing and not seeing it. Perhaps they deemed it unnecessary or implemented a different mechanism but then this should not be called SRP. It should be called something else and explain that it is a new PAKE, if that’s what it is.

Does it even matter if M1 and M2 are verified?

The main thing validating M1 and M2 does is ensure that the values were not changed in transit or miscalculated. I would say this check is more for integrity than eavesdropping as explained above.

Here’s a post similar to the conclusion I came to before reading this based on a diagram posted in a question that looks very similar to what is described above.

There are other problems with this protocol. I assume it’s meant to be used to authenticate users. No information is transmitted besides what is basically just proof that Alice knows K.

The protocol functions a lot like a one time password scheme and has the same limitations. It doesn’t prevent MITM attacks, session hijacking, or server impersonation. It is not a full communication protocol.

Sometimes people comes up with schemes like this to control locks or appliances. It is unsafe to use such a protocol with “toggle” signals. An authentication request could be blocked, leaving a user’s device in the state opposite from the state they believe it is in.

It is also possible to combine blocking Alice’s requests with a replay attack. One could block Alice’s request to engage a lock, trespass, then play back Alice’s message to make it look like the lock was engaged the whole time.

Delayed playback can be solved by Alice instead sending MACK(NA || timestamp). (As long as Alice and Bob have trusted synchronized clocks.) An acknowledgment message could allow Bob to tell Alice that the command was received. The ack would needs its own authentication tag, otherwise it could be spoofed.

[embed]Why does a nonce prevent a replay attack? crypto.stackexchange.com

I’m not exactly sure if the above is one to one mapping onto SRP but it at least has some similarities. It would be easy to test if you could perform the attacks mentioned in that response. Maybe I’ll try those.

A closer look at the SRP calculations

As a reminder I’m using the last version listed here, though there seems to be a newer SRP-6 spec for TLS which references different values such as premaster secrets and a mystical SRP-6a which is apparently published on Stanford’s website.

https://datatracker.ietf.org/doc/html/rfc2945

The SRP specification is pretty mixed up. It gives you some formula and then it tells you what the values of the variables are after providing the formula and it’s not consistent on this point.

It would be clearer to first define all the values and then explain how they are used in the calculations — and this where ChatGPT really, really got mixed up. At first the response gave me a couple of calculations and basically said, “but there’s a lot more to it.” So I asked for the “a lot more to it” and got more information but it was still not complete. After doing this over and over again I never really did get a clear answer.

The initial step is to calculate x. This is not clear from the specification but since the server never has the password this apparently should be done client side.

Right? The specification is very unclear on this point because it says the host stores these values, but I believe this should say the host stores the hash of these values?

A pasword verfier (v) is calculated as follows:

In a lot of documentation I see information about the password verifier being stolen from the database but as I read this specification, it seems like the hash is stored and the password verifier should be generated at the point when the user is being authenticated.

Define N and g.

Calculate a random salt.

These values are shared in advance, or host sends to client in first message with a salt.

The client generates a random number (a).

The client calculates public key (A) using g and N.

The client sends their public key A to the server.

The server calculates A % N and aborts if the value is 0.

The server retrieves the stored verifier (v).

The server generates random value (b).

The server calculates a public key (B) using v, g, b and N.

The server sends their public key B to the client.

The client calculates B % N and aborts if the value is 0.

Both the client and the server can generate a session key with the information they have:

Note that in the above calculation it appears to be hashing a value with SHA — SHA what? SHA 1 or SHA 2? Is that properly protecting K from attack? Here’s where it says you can use alternatives for hashing the value.

The client calculates M1 and sends it to the server:

Note that other variations of this calculation are proposed in later documents such as the paper published by Stanford on the topic, making it very unclear what should actually be used here, but this is the version that exists on IETF. There’s a separate document for TLS which refers to premaster secrets and vaguely references M1 and M2 in version 3 of the SRP specification (2945).

The server calculates M2 (though it is not specifically labeled as such in the calculations) and sends it to the client.

Considering the value of SRP

The value of SRP is that your password is never sent to the server or stored in plain text or with a weak hash on the server. That way if a database for an application is stolen the attackers don’t have your password. But I can still see all this data going back and forth if I have the proper vantage point.

I log into the website using Burp and capture all the data as it is sent between the client and the server, as per usual so I can see any of the above values at they go back and forth. Therefore this protocol does not actually protect against man in the middle attacks. It is designed to not give your password to the server.

In addition, not sending the username and password to the server doesn’t mean they can’t be stolen by a phishing attack. An attacker can still set up a fake website that doesn’t use SRP (or does, it really doesn’t matter) and get a user to enter their credentials into that fake website. Then the attacker has the credentials and can then log into the website just as a normal user does using those credentials. SRP doesn’t protect against that. The only thing that really does is a hardware MFA key.

An attacker can still attempt to brute force a user name by entering guesses into a web application via an credentials stuffing or password spraying attack. There’s nothing in SRP that stops them from doing that. Hopefully you have rate limiting and other mechanisms to defend against that because SRP isn’t going to help.

Does SRP protect against cracking passwords is if the database is stolen? Not if the the information stored in the server database is hashed with a weak algorithm.

SHA1 in the specification has been broken for a while now so I really feel like someone should update the specification and the version numbers on the IETF website:

[embed]Announcing the first SHA1 collision security.googleblog.com

Just because the password is not present when the user goes through the process of authenticating to the server doesn’t mean your site can’t be attacked without it. Instead the attacker will steal a JWT or other session token or ID obtained after the authentication process was completed that is passed between the client and the server. I hear that this mechanism is on the rise with greater adoption of MFA and I’ve written about this before.

[embed]AWS CLI Session Compromise ACM.145 Threat-modeling AWS assume role temporary credentialsmedium.com

SRP may make it more difficult to scan your website with security tools since they have to go through a more complex authentication process. The tools need to have the appropriate libraries to calculate the values in the authentication process to obtain a token to perform security scans. The tools can no longer simply pass a username and password in the request to re-authenticate to the application to perform the scan — unless they have the ability to do so using JavaScript client side using your libraries on your site that perform the calculations. That said, the tools (and malware) can easily work around this given enough time if they have found a way to steal your credentials through other means.

Need help assessing your AWS security? Contact me on LinkedIn to arrange an AWS and application penetration test.

https://www.linkedin.com/in/teriradichel

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab