Download the PHP package windwalker/srp without Composer
On this page you can find all versions of the php package windwalker/srp. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download windwalker/srp
More information about windwalker/srp
Files in windwalker/srp
Package srp
Short Description A modern PHP/JS package of SRP-6a (RFC5054). Contains server and client part to help developer use on any cases.
License MIT
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package srp
PHP SRP (Secure Remote Password) [PHP/JS]
SRP Package (PHP)
Windwalker SRP Package PHP | JS
This is a modern PHP/JS package which provides an implementation of SRP-6a (RFC5054). The PHP / JS side both have server and client part to help developer use on any cases.
This package passed the srptools Test Vectors, it means that this package is fully implement the RFC5054 spec, and you can use this package to work with any other packages which is also fully adheres the RFC spec. The main difference is that this package will pad value to fit the length of g (prime) value before hash, however, most of the SRP packages will probably not pad them before hashing.
We also provide a way to disable the padding behavior if you want to use this package with another package that does not pad values before hashing.
Installation
PHP
JS
See the JS package documentation here.
Getting Started
You must prepare a large safe prime, a generator and a key, the prime and generator is base 10, and the key is hex (base16) format. This package also provides a default safe prime, you can directly use it.
these value can be BigInteger format, we use brick/math as the BigInteger library.
Use createFromConfig() if you set the config in an array.
Use create() to ignore all parameters, this package will use the prepared default secure config.
There has some more configure options:
Sample Code
Here we use both PHP server and client to run a sample SRP flow. You can replace the client part as JS. All values generated by SRP package is a BigInteger object, you can convert it to hex by $v->toBase(16) for storing to DB or transfer by HTTP request.
The full description of this flow is under the next chapter.
The SRP Flow
The definitions and processes of SRP-6a are dispersed in RFC 2945 and RFC 5054; this is an attempt to integrate them for an overview. Please follow strictly to the RFC-specified procedures without custom modification, and do not transmit any variables unnecessarily to avoid security breaches.
Definition
| Variable | Name | Send | Calc |
|---|---|---|---|
I, identity |
The main identity (username or email). | C=>S | |
N |
A large safe prime, All arithmetic is done modulo N. | X | |
g |
A generator modulo N | X | |
k |
Multiplier parameter | X | SHA1(N \| PAD(g)) |
s |
The user salt. | C<=S | random() |
v |
Password Verifier | X | g^x % N |
x |
The hash of salt + identity + password. | X | SHA1(s \| SHA1(I \| ":" \| P)) |
a, b |
Client & server secret key | X | random() |
A |
Client public key | C=>S | g^a % N |
B |
Server public key | C<=S | k*v + g^b % N |
u |
The value to prevent attacker who learns a user's verifier | X | H(PAD(A) \| PAD(B)) |
S (client) |
Pre master secret (The secure common session key) | X | (B - (k * g^x)) ^ (a + (u * x)) % N |
S (server) |
Pre master secret (The secure common session key) | X | (A * v^u) ^ b % N |
K |
The session key hash for used to generate M | X | H(S) |
M1 |
Evidence message 1, To verify both side generated same session key. | C=>S | H(H(N) XOR H(g) \| H(U) \| s \| A \| B \| K) |
M2 |
Evidence message 2, To verify both side generated same session key. | C<=S | H(A \| M \| K) |
Registration
When an app (web/mobile) start registration flow, it may display a identity (I) (username or email) and password (P) field to user. They entered their username and password, then click the register button. The SRP client will generate a random salt (s), and a password verifier (v) which is generated from salt, identity and password.
Then app will send only the salt, verifier and identity to server and do not send password. It is a protocol violation and security bug if the raw password is accidently transmitted to the server even if it is ignored by the server.
You can save the user info and salt, verifier to DB when server receive the registration request. It is optional if you want to encrypt the salt and verifier before saving, make sure you encrypt it by a key which is only known by server.
Login
Hello and Server step1
When a user start login process, they may enter their identity and password on form fields, and click the login button. The SRP client will send a Hello request with identity to server. Server should check user exists by this identity, and get salt and verifier from user data. Next, server will generate a random private b and a public B, and remember them by DB, session or cache storage that we will need them in the further steps, then, return the salt, B back to client (Server Hello). This process is similar to a handshake, to create a connecting session for both side.
Some package calls client Hello as
challengeaction, and theBis server challenge value.
Client step 1 & 2
After receiving the B and salt, Client runs step 1 to generate a and A, and then , runs step2 to use all of the above values to generate a client proof M1. It will be sent to server with A (authenticate action). Server side also use all the generated values to generate a M1 and compare it. If compare failure, server will report an error, and if compare success, server will generate a server proof M2 and back to client. To this step, the authenticate actions is done, you can simply redirect user to login success page.
There is an optional Client step3 is that you can verify the M2 to authority server is trusted and make sure both side generate a same session key (S). If you done this step3, it means you complete the authenticate handshake and did a two-way authentication. If you want to run the step3 to complete all the process, you can redirect user after step3 done.
About the S and M
When client and server generating M, they will both generate a premaster secret (S). The S should be same, even if the 2 sides did not send S to another. The M1 and M2 is a verifier to make sure both side have a same S. So, S can be a trusted session key or encryption key if you want to do some other cryptography behavior in the future.
Some Important Notes
- You don't need to use AJAX to implement SRP flow. You can simply use form post to do all the steps. For example, you may separate username and password into 2 steps on your website, and store values in hidden inputs. Make sure you stored
aandbin your browser and server cache that can use them cross steps and do not accendently send them to remote side. - The
verifieris generated from identity and password, which means you must re-create a new verifier to replace old one if user changes either ofidentityorpassword. - Always make sure you don't send any unnecessary values to each side, even if server or client ignore them, it is considered as a protocol violation and security bug. Also, the MITM attacker is able to use these sensitive data.
- Always clear values when restart an authenticate process. Generally, you can reload page so that all values and JS object will be reset. If you are developing a SPA app, wrap whole process in a function and do not cache values to object properties, and create a new client JS object every time.
- SRP should not replace HTTPS, you should always use SSL/TLS on your app and enable the Cookies HttpOnly and secure settings.
Contribution
If you want to report bug, simply open an issue. Any PR is welcome and can speed up the fixing process.
If you have a security issue, please send to [email protected] (Simon).
