Download the PHP package delight-im/otp without Composer
On this page you can find all versions of the php package delight-im/otp. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download delight-im/otp
More information about delight-im/otp
Files in delight-im/otp
Package otp
Short Description One-time password (OTP) implementation for two-factor authentication with TOTP in accordance with RFC 6238 and RFC 4226
License MIT
Homepage https://github.com/delight-im/PHP-OTP
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 otp
PHP-OTP
One-time password (OTP) implementation for two-factor authentication with TOTP in accordance with RFC 6238 and RFC 4226
Requirements
- PHP 5.6.0+
- OpenSSL extension (
openssl)
- OpenSSL extension (
Installation
-
Include the library via Composer [?]:
- Include the Composer autoloader:
Usage
Creating a new secret key, shared secret or seed
After creating the new secret, you need to store the string (in your database) and associate it with the user that it was generated for. The secret must be unique per user, i.e. newly generated and not re-used between users. Next, the secret must be presented to the user once to transfer it to the client application that will be used to generate one-time passwords, i.e. to their authenticator application. Always use a secure channel, e.g. HTTPS or TLS, to share the secret between server and client.
Presenting the secret to set up an authenticator application
Use the stored secret along with the name of your service or application and the user’s account name to let the user set up an authenticator application on the client side:
Now you can encode the key URI as a QR code, preferably on the client side, and ask the user to scan it using their authenticator application.
Additionally, you should allow the user to view the stored secret (which is a string in Base32 encoding) once during setup and allow them to enter it in their authenticator application manually, in case they are not able to scan a QR code with their authenticator application.
Both forms of transferring the seed from the server side to the client side must only happen once, during setup.
Now that server and client have a shared secret, that secret can be used to generate one-time passwords safely.
But before completing the setup of two-factor authentification and enabling the use of one-time passwords for the user, you should require successful verification of one initial one-time password as shown below, to make sure the user completed the setup correctly.
If you want any custom configuration for the user’s one-time passwords, such as a different length of one-time passwords (e.g. 8 characters instead of 6) or a non-standard interval after which one-time passwords refresh, this point during setup is the time to set this up. The custom configuration can be provided to the user’s authenticator app via additional parameters in the key URI, but unfortunately, these are not all supported by every authenticator application. So make sure the configuration that the server expects, and stores for the user, is consistent with what the user’s client-side authenticator application is going to use.
Important: You should generate and store a few random codes, consisting of at least 8 characters, e.g. using PHP-Random, to be used as backup codes. Present these to the user once during setup.
Verifying a one-time password
Just provide the one-time password that the user entered, along with the shared secret stored during setup, to verify whether the one-time password entered by the user (which they got from their authenticator application) is valid for the secret stored on the server side:
To account for slight clock skews, network latency and user delays during input, a few older and newer one-time passwords are accepted, providing a good balance of security and usability.
Important: You must prevent brute-force attacks using throttling on the server side. The user must not be allowed more than a few attempts to enter a one-time passwords for a given period.
Important: When a one-time password has been verified as correct, you need to prevent replay attacks using a denylist, e.g. by tracking successfully used one-time passwords per user in your database and preventing them from being used again. The one-time passwords tracked in the denylist should expire after a few minutes. That expiry time must be adjusted when you use custom validity periods or refresh intervals for your one-time passwords, or when you allow for more past or future one-time passwords to be accepted.
If you provided any custom configuration to the user’s client-side authenticator application during setup earlier, you must use the same configuration now when verifying one-time passwords received from the user:
Contributing
All contributions are welcome! If you wish to contribute, please create an issue first so that your feature, problem or question can be discussed.
License
This project is licensed under the terms of the MIT License.
