Differences between Vulnerability/Source Code Scanning and Penetration Testing

Vulnerability and source code scanning are performed by automated scanning software. They are cost-effective and quick to execute but can only detect existing vulnerabilities, such as security issues in programming syntax.

Penetration testing, on the other hand, simulates hacker attacks through a combination of tactics to verify whether defenses can be breached. It is more costly but can detect the latest security vulnerabilities in real-time and provide recommendations for remediation. Therefore, penetration testing is more expensive and requires longer preparation.

Types of Penetration Testing

The following types are provided by Cloudflare:

• Open-box Pen Test: In an open test, hackers will be given some information about the target company’s security in advance.

• Closed-box Pen Test: Also known as a "single-blind" test, in this scenario, hackers receive no background information other than the target company’s name.

• Covert Pen Test: Also called a "double-blind" penetration test, in this situation, almost no one in the company is aware that a penetration test is being conducted, including IT and security professionals who would respond to an attack. In covert tests, hackers must clearly define the scope and other details of the test in writing beforehand to avoid legal issues.

• External Pen Test: In an external test, ethical hackers attempt to breach the company’s external technology, such as its website and external network servers. In some cases, hackers may not even enter the company’s building. This could mean they conduct attacks remotely or from a truck or van parked nearby.

• Internal Pen Test: In an internal test, ethical hackers perform tests from within the company’s internal network. This type of test can determine how much damage a disgruntled employee might cause from behind the company firewall.

Preparation Before Pen Testing

Before conducting penetration testing, it’s common to perform a "vulnerability scan" or "source code scan" and preemptively fix visible vulnerabilities before conducting a simulated penetration to verify if these known vulnerabilities can be exploited for an intrusion.

Additionally, since penetration testing is a form of "vulnerability probing" and involves intrusion into company property, unauthorized penetration testing may be illegal in many countries. Therefore, it is crucial to agree on the test targets (website or host) with the vendor and sign a contract and consent form to avoid legal disputes.

Pen Testing Process

The process of penetration testing includes:

1. Project Requirements Confirmation: Confirm the testing requirements and sign legal authorization, an essential step to ensure the tester's actions are legal.

2. Preparation Phase: Confirm the testing methods, scope, and time, and gather publicly available information about the target.

3. Information Gathering: Develop strategies, gather data, and analyze information according to the OSSYMM framework.

4. Data Analysis and Vulnerability Scanning: Use OWASP standards to perform risk scanning, pre-emptively eliminating known issues.

5. Target Penetration: Execute actual penetration actions to attempt to breach the system.

6. Vulnerability Reporting: After testing, write a report detailing various vulnerabilities and remediation recommendations.

After obtaining the report, the operations team will follow the report’s content to patch the system. Finally, according to the contract, discussions may be held to determine whether retesting is necessary.

Standard Items in Pen Testing

Currently, there is no unified mandatory standard for penetration testing, but tests are usually conducted following public security testing items like OWASP Top 10. Here, we provide three mainstream testing standards: OWASP, OSSTMM, and SANS.

OWASP Top 10

The Open Web Application Security Project (OWASP) is an international non-profit organization dedicated to web application security. All of their materials are freely available and easily accessible on their website, enabling anyone to improve their web application security.

The OWASP Top 10 is one of the most widely adopted security checklists globally, with the latest version being OWASP Top 10 2021.

• A01:2021 - Broken Access Control

• A02:2021 - Cryptographic Failures

• A03:2021 - Injection

• A04:2021 - Insecure Design

• A05:2021 - Security Misconfiguration

• A06:2021 - Vulnerable and Outdated Components

• A07:2021 - Identification and Authentication Failures

• A08:2021 - Software and Data Integrity Failures

• A09:2021 - Security Logging and Monitoring Failures

• A10:2021 - Server-Side Request Forgery (SSRF)

OSSTMM

The Open Source Security Testing Methodology Manual (OSSTMM) is a comprehensive framework covering areas such as vulnerability scanning, penetration testing, and social engineering. Below are the items listed under the Information Security Testing category:

• Footprinting: Identify and gather publicly available information about the target system or network.

• Scanning: Use tools and techniques to identify open ports, services, and vulnerabilities in the target system.

• Enumeration: Obtain detailed information about the internal structure of the target system or network, such as usernames, system names, and shared resources.

• Vulnerability Assessment: Analyze known vulnerabilities in the system and assess their potential impact.

• Exploitation: Attempt to exploit identified vulnerabilities to gain unauthorized access to the system.

• Post-Exploitation: After gaining system access, further explore and exploit other system resources or data.

• Reporting: Summarize the penetration test results, providing vulnerability descriptions and remediation recommendations.

SANS Top 20

The SANS 20 Security Controls, published by the Center for Strategic and International Studies (CSIS), are prioritized mitigation measures that can help improve cybersecurity. They include a set of 20 components to help you address common attack vectors and fix potential vulnerabilities.

• CSC 1: Inventory of Authorized and Unauthorized Devices

• CSC 2: Inventory of Authorized and Unauthorized Software

• CSC 3: Secure Configurations for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers

• CSC 4: Continuous Vulnerability Assessment and Remediation

• CSC 5: Controlled Use of Administrative Privileges

• CSC 6: Maintenance, Monitoring, and Analysis of Audit Logs

• CSC 7: Email and Web Browser Protections

• CSC 8: Malware Defenses

• CSC 9: Limitation and Control of Network Ports, Protocols, and Services

• CSC 10: Data Recovery Capability

• CSC 11: Secure Configurations for Network Devices, such as Firewalls, Routers, and Switches

• CSC 12: Boundary Defense

• CSC 13: Data Protection

• CSC 14: Controlled Access Based on the Need to Know

• CSC 15: Wireless Access Control

• CSC 16: Account Monitoring and Control

• CSC 17: Security Skills Assessment and Appropriate Training to Fill Gaps

• CSC 18: Application Software Security

• CSC 19: Incident Response and Management

• CSC 20: Penetration Tests and Red Team Exercises

In recent years, people have used two-step verification apps like Google Authenticator, OneAuth, and Aegis to help them pass TOTP authentication. People who needs cross-platform synchronization will choose Twilio Authy, which can sync accounts across iOS, Android, Mac, and Windows devices, eliminating concerns about restoring accounts after losing a phone.

However, some users consider Authy’s lack of export functionality a major concern for data autonomy. With Authy announcing the end of support for desktop applications (Mac, Windows) in March 2024, people started looking for alternatives. Currently, there are few 2FA software options that support both mobile and desktop applications and synchronization well. This brings us to the features of the Authman App we are introducing today (Which is released by our team).

Security is the Top Priority

During Authman's development, we decided to implement the strongest security mechanisms. We referenced the security mechanisms of password managers like 1Password and Bitwarden to design Authman’s encryption chain process.

First, all 2FA tokens are encrypted by your password (through the encryption chain), and your password is authenticated to the server using the Secure Remote Password (SRP) protocol, which means that the password is never transmitted to the server in plain text. This ensures that no Authman staff can see your account data. Even in the worst-case scenario where Authman’s database contents are leaked, hackers would be unable to decrypt your data. For this purpose, we even create and release our own modern SRP library and ES2020 bigint toolkit.

Next, we chose the most advanced encryption mechanisms available today, using Argon2 for key derivation and XSalsa20 for token encryption, reducing the chances of the encryption algorithm being cracked in the near future.

Additionally, Authman currently does not provide device detection and management to avoid leaking personal device information. However, it offers a global session expiration option, allowing you to log out of all devices with one click to prevent further damage from a lost device. (We do plan to implement device management via encryption mechanisms in the future, but it depends on that we can ensure that the device information can be fully de-identified.)

Finally, we painfully decided to give-up the password reset function (at least for now) to avoid social engineering attacks exploiting the password reset process.

Most importantly, Authman is open source, allowing anyone to review the code and encryption mechanisms to ensure no backdoors exist.

These mechanisms may not be as comprehensive as those of established password management companies, but as a newly launched small personal tool app, we believe it is capable of securing your accounts. For detailed encryption principles, please refer to the Authman FAQ.

Cross-Device Synchronization

Authman currently uses a simple REST API for communication between the app and server. Although it cannot be used offline effectively, all devices can synchronize the current account content from the server. You only need to download and install the mobile app and desktop software to enjoy the convenient account synchronization feature.

To further maintain account security, both the mobile and desktop versions have a screen timeout lock feature, requiring a password to unlock. To reduce the annoyance of the unlocking process, devices supporting biometric recognition (such as mobile phones or Mac Touch ID) can enable quick unlock via biometric recognition.

Currently, Authman supports Windows, macOS, iOS, and Android, with Linux support in our future plans.

Customization

Authman focuses not only on security but also aims to provide a pleasant user experience. All 2FA accounts can be customized.

After scanning the 2FA token, you can search for a FontAwesome icon or upload a picture to use as the account’s identification icon and change the icon color to quickly find the needed items among numerous tokens.

An interesting feature is that Authman supports pasting images from the clipboard. You can open a browser, search for the website’s logo, copy the image, and paste it into Authman, allowing users to create a beautifully organized account list.

Data Autonomy

Authman provides a complete account export and import functionality (though it does not yet support scheduled automatic backups). This means you don't have to worry about vendor lock-in; you can export all your 2FA tokens at any time and easily transfer them to other applications, or use them as a manual backup mechanism.

Another thoughtful feature of Authman is that we know some users register 2FA tokens with a secondary phone as a manual backup. Authman allows you to display the QR code for each 2FA token again, so you can immediately scan and back up each token with another phone.

Open Source and Self-Hosting

Authman is newly launched, and we have many tasks and to-do lists yet to be completed. Therefore, although we are open source, the installation documentation is not yet complete. Additionally, our team is still discussing and experimenting with how to replace necessary assets and variables like logos, titles, and API endpoints for self-hosting. Once these mechanisms are perfected, we will release detailed self-hosting documentation.

Of course, you can always clone the project and build it yourself if you can replace the necessary variables in the source code. And if you find any vulnerabilities or algorithm deficiencies or you want to suggest improvements, we welcome them.

For reporting or feature requesting, please goto GitHub Discussions or Issues.

Conclusion: Make Authman Your Account Security Tool

Although Authman, as a newly launched 2FA app, it is fully capable of daily use with its core 2FA TOTP authentication code feature. More importantly, it is one of the few 2FA apps on the market that supports cross-device synchronization with desktop software and has comprehensive encryption security mechanisms, making it a trustworthy choice. So don’t wait; try Authman now.

See also:

• "Authman is a very convenient and useful solution that should be more than enough for most users." - Softpedia

• "Authman, your companion for flawless 2FA" - Justgeek

About EME and Web DRM

In 2017, amidst controversy, W3C passed the Web DRM standard, also known as EME (Encrypted Media Extensions). EME is essentially a universal specification for different DRM manufacturers to communicate using the same standard, with each manufacturer implementing their own encryption and decryption technologies.

This standard has been in existence since 2012 as an unofficial standard among browsers, existing in a closed-source CDM (Content Decryption Module) form in browsers. Therefore, W3C's passage of the EME standard merely formalized and upgraded it to an official standard, despite significant controversy and skepticism from advocates of internet openness. See: "W3C Blog: On EME in HTML5."

If W3C did not recommend EME then the browser vendors would just make it outside W3C. If EME did not exist, vendors could just create new Javascript based versions. And without using the web at all, it is so easy to invite ones viewers to switching to view the content on a proprietary app. And if the closed platforms prohibited DRM in apps, then the large content providers would simply distribute their own set-top boxes and game consoles as the only way to watch their stuff.

— Tim Berners-Lee

Since EME is a standard, the actual identity verification and encryption/decryption are carried out by the CDM module specified in the standard, developed by individual DRM vendors. Under the EME standard, a website or application can use the same interface or keys to handle encrypted content from different DRM vendors, as long as the encryption format of the video is determined beforehand.

The main popular DRM vendors under the EME standard includes Microsoft's PlayReady, Google's Widevine, and Apple's FairPlay, each corresponding to different browsers:

• Chrome: Widevine

• Edge, IE11: PlayReady

• Firefox: Widevine

• Opera: Widevine

• Safari: FairPlay

There is also a ClearKey which does not depend on any vendors and it is cross-brower, you can implement it for development or testing use.

The advantage of using the EME standard is that you can encrypt your videos in multiple ways, and then decrypt them with the same key and program on different browsers, automatically recognizing the encryption method. CDM itself is closed-source, so hackers cannot access your decryption algorithm as they could with reverse-engineered JavaScript code. Therefore, compared to developing your own encryption/decryption mechanisms, security is further enhanced.

Start Using EME to Protect Video Resources

For businesses wanting to try EME protection, the fastest way is to choose an authorized third-party service provider, such as EZDRM, Axinom, castLabs, etc. You can find globally authorized manufacturers from the following DRM pages:

• Widevine: Widevine Training Partners

• PlayReady: Microsoft PlayReady Partners

Here are some third-party service providers we are aware of, listed without recommendation or in any particular order:

• Axinom

• BuyDRM

• CastLabs

• ExpressPlay

• EZDRM

• Inka Entworks

• Vualto

• Verimatrix

After signing a contract with these manufacturers, they will provide back-end or related SDKs, and enterprises can use their servers as content authentication hosts to verify users' video authorization range. They usually support multiple encryption CDM modules. They also provide video encryption methods. After encrypting the video with these tools, it is then distributed to users' browsers. The videos downloaded by the browser cannot be played by ordinary players but must be decrypted in real-time by the decryption module on your website.

If you simply want to host videos, there are also dedicated DRM platforms for video hosting. You just need to upload videos from their backend and embed them on your website to use them. These platforms even offer dynamic watermarking features, creating different video watermarks for each viewer to prevent recording. However, note that this real-time watermark creation mechanism is relatively more expensive.

• VdoCipher

• Flowplayer

• Muvi

• Nichevid

What Business Models Are Available

Most DRM and agents support several business models, which can be chosen according to enterprise needs:

• Pay by duration

• Permission based on authorization status

• Pay-per-use

• Short-term rental

• One-time purchase

• Ad-supported models

And video resources can be distributed in two common modes:

• Complete download

• Progressive download (download as you play)

These features, whether Widevine or PlayReady, are provided on major platforms with ready-made management modes and SDK packages, allowing developers to focus on the architecture for commercial logic.

Can I Set Up My Own Licensing Server?

If you prefer not to use third-party licensing providers and wish to set up your own Widevine or PlayReady server, it's possible but more complicated. For Google Widevine, general public access to the Server SDK isn't available. You need to apply to become their distributor and pass a test to get the server code. While PlayReady offers free server tools, you still must contact Microsoft to obtain the server SDK. Practically, it's often advised to start with a reputable DRM partner for faster business model implementation.

Can I Build My CDM Module Without DRM Vendors

The ClearKey protocol is available for any browser, you may simply implement ClearKey to build your own encrypt/decrypt logic for your media resources. However, you must know that ClearKey uses unencrypted keys to decrypt resources, it is not very safe to protect your data, so we recommend only using ClearKey for the test process.

Conclusion

EME and Web DRM provide a universal encryption mechanism across manufacturers, filling a gap in HTML5 environments akin to DRM mechanisms in Flash and Silverlight.

However, even with EME, it's not 100% piracy-proof. It increases the difficulty of unauthorized access and reduces the quality of the resources obtained. For instance, Widevine's L1 encryption has been claimed to be cracked by certain groups, but not publicly, while L3 encryption is more commonly broken into, albeit with lower quality.

As mentioned in the previous article, replay and recording attacks are undefendable since any content eventually needs to be converted into physical signals visible to the naked eye, and these signals can be recorded by additional devices.

Web DRM primarily verifies user payment and access rights to specific resources. For those intent on copying resources elsewhere, it remains ineffective.
If you're seeking to protect all your digital assets from being copied, EME can only increase the difficulty but cannot provide absolute assurance of perfect protection.

Related Links

• What is EME? (Google)

• Introduction to Encrypted Media Extensions (EME) For DRM Systems

• Encrypted Media Extension (EME) API, watching protected video content on the web

• How to Estimate SaaS DRM License Cost

Due to the open nature of the internet era, browsers cannot prevent users from accessing the source code. This makes protecting intellectual property on websites quite challenging. This article specifically introduces digital content protection strategies in the Internet age.

What is DRM?

For protecting digital intellectual property, the most common method is DRM (Digital Rights Management). In simple terms, it manages how and whether consumers can "copy" digital assets. People who are familiar with gaming will recognize DRM, as many modern games use it to prevent copying and require identity verification for play.

Early DRM mainly used streaming and real-time decryption, especially in DVDs. This involved encrypting DVD content, which was then decrypted in real-time by authorized devices during playback. In recent years, large games often use tamper-proof mechanisms, wrapping the game program in a layer that decrypts command codes in real-time, which can significantly reduce performance.

Since DVDs are usually decrypted quickly by hardware, this wasn't a big issue. However, in modern 3D games where CPU resources are maximized, DRM's impact on performance often draws complaints from players. This is why DRM is notorious in the gaming world.

Image: Assassin's Creed: Origins' was criticized by players for performance issues caused by its dual DRM protection. While Ubisoft denies this reason.

Various Forms of DRM

DRM isn't just real-time decryption. Practically, any technology that prevents the abuse of intellectual property is considered DRM. For example, some games don't use real-time decryption but require a constant internet connection to verify the player's identity.

Other common methods include:

• Serial number authentication.

• Connecting to a server for membership registration and identity verification.

• Server control over the number of devices a software can be installed on.

• Limiting the number of copies or downloads.

• Hardware to anti skimming or recording.

• Using specialized devices to view/access resources.

• Watermarks (yes, just a simple tracking of leaking data also considered as a DRM).

• Metadata (declaring copyright in the metadata of files or photos).

• Monitoring users' behavior and reporting to the backend.

• Detecting if software or resource content has been tampered with, and stopping operation if so.

• Using a central marketplace to sell resources and centrally verify identities (similar to the Apple App Store or Steam).

• Requiring an online download after purchase.

There are many methods, some even raising privacy concerns. However, due to commercial interests, many manufacturers still opt for these protection mechanisms.

How is Website DRM Implemented?

Let's talk about DRM on websites, which commonly protects audio-visual content, ebooks, software, or resource materials. However, implementing DRM on websites is generally ineffective.

Why is Website DRM Considered Ineffective?

The reason is that web browsers are open environments. The JavaScript code isn't compiled, so anyone can see the source code. In such an environment, any encryption program, if executed on the browser side, can be easily cracked.

Moreover, all content viewed in a browser—audio, video, images, text—must be downloaded to memory to display, and browsers easily allow users to open and save these resources.

This image shows how easy it is to capture a video's original file from a website using a browser.

Due to this openness, any encryption can't prevent the final action of saving files from the record, making it pointless to encrypt resources.

What Other Methods Exist for Web DRM?

As mentioned before, DRM isn't just about encryption. Any method that can prevent copying or make stealing more difficult is considered DRM. Here are some common DRM methods used online, none perfect, but they make illegal copying harder.

For Graphic and Text Resources

• Locking right-click to block copying.

• Converting text into images.

• Verifying member identity for access.

• Server outputs a small chunk of graphics and text at a time, with identity verification for each access.

• Using specialized devices or software to view graphics and text.

• Embedding watermarks in images.

• Automatically adding copyright statements when copying text.

For Downloadable Resources (Software or Virtual Assets)

• Controlling the allowed times of downloads.

• Allowing downloads only after member identity verification.

• Attaching a time-limited certificate to the download URL, so it expires after a certain period.

• Allowing unlimited downloads, but requiring online serial number or identity verification.

For Audio/Video Resources

• Attaching a time-limited certificate to the audio-visual access URL, so it expires after a certain period.

• Embedding trademarks or member account watermarks in the audiovisual content.

• Using live streaming to play audio/video (downloading content as it plays, not storing the entire file in memory).

• Splitting audio-visual content into chunks, each lasting about 5 seconds to the browser, makes copying extremely difficult.

• Encrypting audio-visual content, with each member having a unique key for decryption, preventing sharing.

These are some of the more common anti-copying measures on the market. However, they mainly increase the difficulty of copying but can't completely stop someone who really wants to steal them. In addition, using server output instead static file access is a common solution because the server can verify identity with each access.

Image: Limiting times of downloads is a common DRM mechanism, The screenshot is DatavideoVirtualset website.

Common Methods of Cracking DRM

Intercepting or Stealing the Decryption Keys

Whether by hacking, reading from memory, or leaks from internal employees, owning the decryption key means directly unlocking the confidential asset and then copying it into another unencrypted version.

Exploiting Software and Hardware Vulnerabilities

Software and hardware can have vulnerabilities, especially in closed systems where flaws are not publicly known or fixed. Usually, privilege escalation is used to obtain the key.

Removing Watermarks

Rough protection methods are broken by rough methods if the stealer doesn't matter the image or audio-visual quality.

Recording or Replay Attacks

This major method of cracking DRM involves recording content during post-decryption transmission. Alternatively, all graphics and text can be screenshotted, and all audio and video can be recorded. Even if we have the hardware anti-recording protection, a smartphone can easily record the content. However, this method is not suitable for games, where the main purpose is the interactive experience.

Conclusion

Although DRM is important for protecting commercial interests, it can't 100% protect digital assets from stealing in the real world. It's mainly used to broadly verify whether purchasers have access rights. Anti-theft still requires media manipulation and legal deterrence to be effective.

Additionally, despite being easily cracked, DRM persists partly due to business and political factors. Companies selling digital resources might need to assure shareholders or original creators that the resources won't be leaked. Claiming to have DRM technology is a good way to gain trust from licensors and to some extent, take responsibility for protecting assets.

Image: For instance, "The Witcher 2" removed DRM a few days after its release due to its significant impact on performance.

As for website anti-theft, in the open culture of the Web era, all browsers can't prevent content from being copied and extracted. Thus, DRM can only control that un-purchased users can't access resources, but copying elsewhere after purchase is almost unstoppable. Creating more anti-theft features is a trade off, that may lead to additional costs and losses. For example, the developer of "The Witcher 2" released an update to remove DRM a few days after launching the game, recognizing its significant impact on performance.

However, for audio-visual resources, there are solutions. In 2017, the W3C approved a standard for Web DRM: EME (Encrypted Media Extensions), which can encrypt and decrypt audiovisual content in browsers. Although it's new and not widely used, big companies like Netflix and Spotify have already started using it. It could be a potential solution for audio-visual content theft prevention.

If you want to know more about EME, please see our next article.

The Nested set model is a data model designed for efficiently handling tree node structures. It allows us to retrieve nodes, calculate node counts, or load whole tree data without traversing the entire tree.

About Traditional Adjacency List Model

First, let's discuss the traditional design for handling nested structures, using a data table that contains a parent_id for its tree structure.

Table: `tree`

| id | parent_id | title |
|----|-----------|-------|
| 1  | 0         | ROOT  |
| 2  | 1         | four  |
| 3  | 1         | node  |
| 4  | 2         | node  |
| 5  | 2         | node  |
| 6  | 3         | node  |

As we can see, each record has a parent_id pointing to its parent node. To retrieve child nodes, an SQL query would look like this:

SELECT * FROM `tree` WHERE `parent_id` = 1;

This method is straightforward and easy to understand. However, its downside is evident when trying to fetch multi-level data or calculate the number of nodes, as it requires recursive operations, heavily burdening the database.

Solution: Nested Set Model

The Nested Set Model is an excellent solution to this issue.

Let's examine the tree structure of the Nested set model. Each node has a left and right key, usually named lft and rgt. Assume we start with a root node A:

        A (1,2)

When we add a node B under A, it changes to:

        A (1,4)
           |
           |         
        B (2,3)

Then, adding a node C:

        A (1,6)
           |
    ---------------
    |             |
B (2,3)        C (4,5)

Clearly, the left and right keys of B and C are wrapped within A. To retrieve B and C, an SQL query would be:

-- Assuming a typical workflow, we might first 
-- retrieve A's data using ORM

SELECT * FROM `tree` WHERE `id` = 1;

-- Then, using A's lft and rgt to query all children

SELECT * FROM `tree` WHERE `lft` > 1 AND `rgt` < 6

-- To include A, add equals sign

SELECT * FROM `tree` WHERE `lft` >= 1 AND `rgt` <= 6

-- This approach can implementable in any programming language

The advantage here is evident, using lft and rgt keys, we can easily retrieve whole children nodes. Refer to the following image:

Using lft > 1 AND rgt < 22, we can retrieve all nodes at once, whereas the traditional adjacency list model might require up to 5 queries to fetch or calculate all child nodes.

Initializing a Tree

Now, let's dive into some real-world examples.

A key point of Nested set is to always have a root node, which is the starting point for all nodes and generally not used. Initially, we need to create a table with parent_id, lft, rgt. The parent_id is used for upward queries. Additionally, to easily control query levels, we can add a level column to track the current level.

Initializing a category table:

| id | parent_id | title | lft | rgt | level |
|----|-----------|-------|-----|-----|-------|
| 1  | 0         | ROOT  |  1  |  2  |   1   |

Here's a simple creation syntax:

CREATE TABLE IF NOT EXISTS `categories` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `parent_id` int(10) UNSIGNED NOT NULL DEFAULT '0',
  `lft` int(11) NOT NULL DEFAULT '0',
  `rgt` int(11) NOT NULL DEFAULT '0',
  `level` int(10) UNSIGNED NOT NULL DEFAULT '0',
  `title` varchar(255) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_left_right` (`lft`,`rgt`)
) DEFAULT CHARSET=utf8;

INSERT INTO `categories` VALUE (1, 0, 'ROOT', 1, 2, 1);

Preparing Example Data

Here, we prepare some example data, including category and article tables:

Category

| id | parent_id | title | lft | rgt | level |
|----|-----------|-------|-----|-----|-------|
| 1  | 0         | ROOT  |  1  |  10 |   1   |
| 2  | 1         | A     |  2  |  7  |   2   |
| 3  | 2         | B     |  3  |  4  |   3   |
| 4  | 2         | C     |  5  |  6  |   3   |
| 5  | 1         | D     |  8  |  9  |   2   |

Articles

| id | title      | catid |
|----|------------|-------|
| 1  | Article 1  |  1    |
| 2  | Article 2  |  2    |
| 3  | Article 3  |  3    |
| 4  | Article 4  |  3    |
| 5  | Article 5  |  4    |
| 6  | Article 6  |  5    |

Some Simple Query Examples

Retrieve all articles under all categories of A (very useful for blog categories):

SELECT `a`.*, `b`.* 
    FROM `articlea` AS `a`
    LEFT JOIN `categories` AS b ON `a`.`catid` = `b`.`id`
WHERE
    `b`.`lft` >= 2 AND `b`.`rgt` <= 7

-- OR

    `b`.`lft` BETWEEN 2 AND 7

Limiting Levels:

SELECT `a`.*, `b`.* 
    FROM `articles` AS `a`
    LEFT JOIN `categories` AS b ON `a`.`catid` = `b`.`id`
WHERE
    `b`.`lft` >= 2 AND `b`.`rgt` <= 7 
    AND 
    `b`.`level` < 2

Reverse Query to Find All Ancestors of Node B:

SELECT `categories`.* 
    FROM `categories` AS `node`, `categories` AS `parent`
WHERE
    `node`.`lft` BETWEEN `parent`.`lft` AND `parent`.`rgt`
    AND `node`.`id` = 3

Adding a Node Before B:

-- First, make room, all rgt, lft + 2

UPDATE `categories` SET
    `rgt` = `rgt` + 2,
    `lft` = `lft` + 2
where
    `lft` > 2

-- Then insert the node

INSERT INTO `categories` VALUE (:id, 'New Article', 2, 3, 4, 3);

This approach can be easily implemented in any language.

Extending Neste Set Model

Generally, only the parent_id, lft and rgt are required fields in Nested Set Model. Furthermore, additional fields can be added to extend various functions. For example, in this article, we add level to control the node levels. Some implementation will add an alias and path field, which looks like parent/parent2/child/child2. This is useful in the application itself for quickly comparing node levels.

You may also create a Multi-Tree Neseted Set Table, Just add a root_id or master_id to hold the ROOT node ID for every node, then adding this where control to every query:

WHERE `root_id` = :rootId

that you can limit every read / write operation under a root node.

Conclusion

Nested set model has pros on the loading and retrieving performance. However, the downside is that adding or moving nodes requires traversing the entire tree to rebuild the index, which is not very efficient.

For general applications, it's like trading back-end storage operation performance for front-end reading performance, which is also a solution in high-traffic systems.

Related Links

• Windwalker ORM

• Joomla Nested Set Guide

• Laravel Nested Set

• Doctrine Hierarchical Data

This brings us to our topic: Can PHP source code in PHP be encrypted or compiled? The answer to this question involves not only the confidentiality of the code but also the performance and security of web applications.

The Basic Working Principle of PHP Source Code

To answer this question, we first need to understand the basic working principle of PHP. PHP is an interpreted language, meaning it is read and interpreted line by line by the PHP interpreter at runtime, rather than being pre-compiled into machine language. When a user requests a PHP page, the PHP interpreter on the server interprets and executes the PHP source code of that page, sending the generated HTML content to the user's browser.

This working method has a drawback: the source code can be viewed by anyone with access to the server. If your code contains sensitive information, such as database passwords, or if you don't want your business logic to be understood by competitors or hackers, this can be a problem.

Encrypting PHP Source Code

To address this issue, developers can choose to encrypt their PHP source code. Common PHP source code encryption tools include:

• Zend Guard

• ionCube

• Source Guardian

• PHP Shield

• PhpBolt

• Swoole Compiler

These tools can convert PHP source code into a form that is difficult for humans to read, thereby protecting the privacy of the source code.

The basic principle of using these tools is to encode the source code into a binary format or obfuscate its syntax structure, making it difficult to understand or modify. Then, when running the encrypted code on the server, a corresponding decoder or loader is needed to convert the encrypted code back into executable PHP code. This way, even if someone obtains your PHP code, they cannot understand or use it unless they have the key to the decoder.

Zend Guard

Zend Guard is a professional PHP encryption product offered by Zend Technologies (a company founded by Zeev Suraski and Andi Gutmans, creators of PHP). It is used to protect and encode the source code of PHP applications, preventing unauthorized use and reverse engineering. Zend Guard provides strong code encryption and obfuscation capabilities, encrypting PHP source code into a form that is difficult to read and modify, thereby protecting the intellectual property rights of developers.

ionCube

ionCube is a powerful PHP encryption tool that can effectively protect PHP source code from piracy or unauthorized modification. With ionCube, developers can encode PHP code into a binary form that can only be decoded through the ionCube Loader. ionCube also supports various PHP versions and seamlessly integrates with most web servers, making it widely acclaimed among PHP developers.

Source Guardian

SourceGuardian is a professional PHP encoding and encryption software, mainly used to protect PHP source code from being copied, modified, or pirated. With SourceGuardian, developers can encrypt their PHP programs to ensure the security of their intellectual property. In addition to encryption, SourceGuardian also offers features like expiration date restrictions and domain limitations, helping developers control the deployment and distribution of their programs.

PHP Shield

PHP Shield is an encryption tool for protecting PHP source code. It compiles PHP code into bytecode and then encrypts it to prevent the source code from being viewed or modified. PHP Shield offers an easy-to-use interface, making the coding and encryption process quite simple and straightforward. Moreover, the encrypted code it generates can run on various platforms, requiring only the free loader from PHP Shield.

PhpBolt

PhpBolt is a PHP extension for encrypting scripts, offering high performance with minimal impact on execution speed. It stands out for its compatibility with various PHP versions and its robust security features like domain and IP restrictions. Unlike some other encryption tools, PhpBolt focuses on ease of use and efficient execution, making it ideal for securing commercial PHP applications without compromising functionality.

Swoole Compiler

Swoole Compiler is an encryption and client authorization solution for PHP code launched by the official Swoole team. It compiles PHP programs into binary instructions to protect your source code. Unlike traditional PHP encryptors like Zend Guard, Swoole Compiler does not have a software interface; it provides an API, allowing Swoole Compiler to be integrated into your packaging and distribution platform, making it fully programmable.

Enhancing System Security

Many enterprises worry about source code leakage, not just for intellectual property rights, but also for the risk of information security breaches. The maintrend view in recent years is that any sufficiently robust software should be secure even if its source code is fully known to outsiders. For example, strong encryption algorithms, high-standard security management, and user access control are all important aspects. With the right development philosophy, even if outsiders obtain the source code, they should not be able to access any functionality of the system. If they can, it indicates the existence of a "backdoor," which should not happen.

For companies using PHP, it's worth considering these aspects of security policy and strengthening the security management of the development team, such as implementing automated regular vulnerability scanning and source code quality control.

Conclusion

PHP source code can be encrypted using encryption tools, thereby enhancing its confidentiality. However, since PHP is an interpreted language, it cannot be directly compiled into machine language like compiled languages.

Whether you need to encrypt PHP source code depends entirely on the specific needs of your enterprise. If your PHP code contains sensitive information or involves unique business logic, and you are concerned that its disclosure could pose a business risk, then trying to encrypt PHP source code might be a good choice. Alternatively, starting from the source of development for information security management to ensure that the system has no backdoors is also an appropriate solution.

See Also

• Source Code Protection Techniques in PHP

• Using PHP Encoders to Safeguard Source Code: A Walkthrough with phpBolt

• Is there an easy way to protect PHP Code?

Website security is crucial for protecting users' personal information. Most account theft incidents stem from hackers stealing passwords to access websites. Therefore, to protect both users and their own interests, many international websites have started to implement different modes of identity verification, replacing simple password authentication.

About 2FA and MFA

Weaknesses of Simple Passwords

Passwords are our most common security verification method, but simple password systems have many flaws. First, the strength of a password largely depends on the user. If a user sets a simple password (such as 123456, or using personal information like birthdays), it can be easily guessed and breached by hackers. Secondly, even if a user sets a strong password, it cannot completely avoid threats like Website Phishing or Man-in-the-middle (MITM) attacks, as these often deceive users into revealing their passwords. Lastly, many users often reuse the same password across different websites, putting other accounts at risk if these passwords are leaked on any site.

The Importance of Identity Verification

Advanced identity verification methods, such as two-factor authentication (2FA) and multi-factor authentication (MFA), can significantly reduce the risk of password breaches. Even if hackers know the password, they cannot pass the second or additional layers of verification, thus protecting the user's account.

These advanced verification methods usually require users to provide three types of information:

Something you have (e.g., a mobile device to receive a verification code) Something you know (e.g., a password) Or something you are (e.g., a fingerprint or facial recognition) to confirm their identity. In this way, even if hackers know one type of proof, they cannot easily obtain the others, greatly increasing account security.

The Concept of 2FA and MFA

Therefore, in recent years, internet security has gradually adopted more robust verification methods, known as two-factor authentication (2FA) and multi-factor authentication (MFA).

2FA, or two-factor authentication, means adding a second layer of security verification to the traditional password authentication during the login process, such as SMS codes, email verification, fingerprint recognition, etc., greatly enhancing account security.

MFA, or multi-factor authentication, adds two or more verification methods during the verification process. These methods may include passwords, biometric recognition, behavioral characteristics, etc.

By using these two verification methods, we can effectively enhance website security, preventing unauthorized access and data theft.

What is 2FA (Two-Factor Authentication)?

Two-factor authentication (2FA) is a method of enhanced security verification that requires users to provide two different forms of identity proof for authentication. These two proofs typically come from the following three categories: information the user knows (such as a password), an object the user possesses (such as a mobile phone receiving a verification code), and the user's physical characteristics (such as fingerprints or facial recognition).

How 2FA Works

When a user attempts to log in or perform certain sensitive operations, the system first asks them to provide one form of identity proof, usually a password. Then, the system requests a second form of proof, such as a verification code sent via SMS to the user's mobile phone, or data from a biometric device (like a fingerprint scanner). Only when both forms of identity proof are correct will the system authenticate the user.

Common 2FA Verification Methods

1. SMS Verification: The system sends a verification code to the user's mobile phone, which the user must enter on the system to proceed.

2. Email Verification: Similar to SMS verification, but the code is sent to the user's email.

3. Biometrics: Includes fingerprint recognition, facial recognition, or retina scanning.

4. Hardware Security Token: Such as YubiKey or Google Titan, where users need to insert these physical keys into a computer or contact them with a mobile phone via NFC for identity verification.

Advantages of 2FA

1. Enhanced Security: As it requires two forms of identity proof, even if one is known to hackers, they cannot proceed, thus enhancing account security.

2. Reduced Identity Theft: Even if the password is cracked by hackers, they cannot mimic the user's biometrics or obtain physical security keys, significantly reducing the risk of identity theft.

Disadvantages of 2FA

1. Reduced Convenience: Users need to complete two verifications, which may be troublesome, especially in situations requiring frequent logins.

2. Additional Device Needed: Some 2FA methods (such as biometrics or physical security keys) may require specific devices, potentially increasing usage costs.

What is MFA (Multi-Factor Authentication)?

Multi-factor authentication (MFA) requires users to provide more than two forms of identity proof to enhance account security. These proofs still originate from the following three categories: information the user knows (such as a password), an object the user possesses (such as a mobile phone or security key receiving a verification code), and the user's physical characteristics (such as fingerprints or facial recognition).

How MFA Works

Similar to 2FA, when a user attempts to log in or perform sensitive operations, the system asks them to sequentially provide multiple forms of identity proof. Each proof must pass before the system authenticates the user. By requiring users to provide more types of identity proof, MFA offers multiple layers of security.

Common MFA Verification Methods

1. SMS Verification + Password + Biometrics: A very common MFA method where users need to provide these three proofs to log in.

2. Hardware Security Token + Password + Biometrics: This method is often used in high-security environments, such as government or military facilities.

Advantages of MFA

1. More Security: As it requires multiple forms of identity proof, even if hackers obtain one or two proofs, they cannot pass all verifications, greatly enhancing account security.

2. More Comprehensive Protection: MFA, by combining various forms of identity proof, can combat different threats, providing more comprehensive protection.

Disadvantages of MFA

1. Reduced Convenience: Similar to 2FA, MFA requires users to complete multiple verifications, which may make the login process cumbersome.

2. Additional Device Needed: Some MFA methods may require specific devices, such as biometric devices or physical security keys, potentially increasing implementation costs.

Does My Website Need 2FA or MFA?

When to Use 2FA or MFA

If your website stores or processes sensitive data, such as personal information, credit card details, or other data that can be maliciously used, you should consider using 2FA or MFA. Especially in the current climate of rampant cyber attacks, using advanced verification methods to protect your website and your users is essential.

2FA and MFA Applications on Different Websites

Various types of websites can benefit from 2FA or MFA. For example, e-commerce sites can use 2FA or MFA to protect customer payment information; social networking sites can use it to prevent account theft; medical websites can use it to ensure patient medical records are not accessed by unauthorized individuals.

How to Implement 2FA, MFA on My Website

Setting up and implementing 2FA or MFA may require professional technical knowledge. Fortunately, many third-party services, such as Google Authenticator, Authy, or Duo Security, offer easy-to-implement solutions. You can choose the right service to implement 2FA or MFA based on your needs and budget.

2FA and MFA play a key role in enhancing website security. Although they may reduce convenience, it is worth it compared to protecting user information security.

Regardless of your business size or website scale, its security should be taken seriously. If you want to learn how to implement 2FA, MFA on your website, or if you plan to build a new website and value its security, you are very welcome to consult with us. UniAuth and LYRASOFT has many years of experience in enterprise-level website development and can build a strong and complete website platform for you.

In the digital world, protecting personal and corporate information security is a crucial aspect of our daily lives. Over the years, corporate security policies have often advised us to regularly change passwords, every 60 to 90 days, to ensure the safety of our online accounts. This concept believes that regularly changing passwords can prevent long-term unauthorized use of our accounts. However, this practice has some issues in today's security environment.

Problem of Frequently Changing Passwords

Frequent password changes lead users to choose simple, easy-to-remember passwords or to make minor modifications to existing ones, such as adding a number at the end or slightly changing the order of letters. In such cases, even with regular password changes, security is greatly reduced as simple or slightly altered passwords are easier to crack.

Moreover, to remember different passwords, users might write them down, increasing the risk of severe password leakage. Some might prepare 3-4 sets of passwords to rotate, which defeats the purpose of changing passwords.

The Burden on Corporate Organizations

Often, corporate security policies are designed just to comply with legal or audit requirements without considering practical operation. When the password change cycle comes around in large corporations, there can be a huge spike in password change requests, slightly impacting work productivity for that week.

Also, systems that lock accounts after multiple incorrect attempts can lead to a massive influx of help requests to the IT department at the start of the password change cycle, creating additional management issues for the organization.

New Idea 1: Strong Passwords

In recent years, the cybersecurity community has begun to question whether forcing users to regularly change passwords truly benefits information security. In 2017, the National Institute of Standards and Technology (NIST) in the USA advised against mandatory regular password changes. Instead, NIST recommends changing passwords only if they are known to be stolen and suggests using 'strong passwords' instead of frequently changing them.

A 'strong password' is hard to crack, typically consisting of 12 or more characters (some organizations require 16 or more), including uppercase and lowercase letters, numbers, and special symbols. A strong password should avoid any words found in the dictionary, personal information (like birthdays or names), or common password patterns (like 123456 or abcdef). For example, Pc29_hJ/EfuZ*3ao is a 16-character strong password.

By increasing the length and complexity of passwords, the time and resources needed to crack them are significantly increased, thus enhancing account security. Enterprises can consider using Single Sign-On (SSO) where a central employee system manages all employee passwords to meet the standards.

Password Managers

Another approach within organizations is the introduction of password managers like 1Password, Lastpass, or Passpack. These managers facilitate the management of multiple strong passwords and prevent users from writing down passwords. While there are concerns about password manager breaches, the general consensus is that the risk of content leakage from managers is not as high as using the same password across multiple sites, which could lead to a breach on one site affecting all.

New Idea 2: Two-Factor (2FA) or Multi-Factor Authentication (MFA)

In some cases, two-factor authentication (2FA) can be more effective and address concerns about password manager leaks. 2FA requires two forms of proof to confirm identity, such as a password (knowledge) and a mobile phone (possession), or a fingerprint (biometric). Thus, even if a password is stolen, the thief cannot truly access the account.

For more information on 2FA, please see: What are 2FA and MFA, Does my WebSite Need This?

New Idea 3: Passwordless Authentication

Widespread passwordless authentication methods include mobile app scanning, fingerprint or facial recognition, OAuth, or third-party authentication. The authentication methods used in 2FA and MFA, such as biometrics or USB keys, can also serve as primary authentication methods.

The main concept of passwordless is that by using an entity that has already authenticated your identity (such as a website, organization, or mobile device), this authentication is granted to another software or website that requires login, thus confirming your identity without re-entering username and password.

Common passwordless strategies include QRCode scanning or app scanning for login.

Conclusion: Enterprises Should Rethink Password Management Strategies

As cybersecurity concepts evolve, enterprises need to rethink their existing password management strategies. Over-frequent password changes are not a silver bullet for information security. Instead, we should focus on creating strong passwords and applying two-factor authentication when appropriate. Such strategies can ensure our online safety while reducing the burden on users.

UniAuth and LYRASOFT has extensive experience in website backend development and can implement systems such as SSO, OAuth, 2FA, MFA for enterprises. If your business has related needs, please feel free to contact us.

Secure Remote Password (SRP) protocol is a method of secure authentication designed to safely verify a user's credentials without transmitting the password over the network.

Unlike traditional password hashes, which rely on a password being sent to the server and then compared to a stored hash, SRP will never transmit or store a user's password on the server, significantly reducing the risk of interception or server compromise. The benefits are that it stops different types of attacks like MITM (man-in-the-middle) attacks, doesn't need a password change if user data leaks, and lets both the user and server confirm each other's identity.

Major companies like Apple and 1Password have adopted SRP as part of their authentication mechanisms. Apple, for instance, has implemented SRP in its iCloud Keychain to securely synchronize passwords across devices without exposing them. Similarly, 1Password uses the user's master password and the secret to encrypt data, and both the password and secret use SRP to authenticate accounts and ensure that they won't transmit to the server.

About This Article

This article aims to explain each step of SRP-6a and provides a combined overview of RFC-5054 and RFC-2945. It also maps each calculation formula in the variable introduction and the sample code later in the article. This will be particularly helpful for developers who are new to SRP and want to understand how it's implemented in the RFCs, ensuring they can follow every calculation step mentioned.

Not all open-source packages follow the RFC standards completely, which means some may not work well with others. This article strictly follows SRP-6a, using the implementation in windwalker/srp as a model. By following this example, your implementation should easily work with other packages that are fully RFC-compliant.

If you are interested in finding more packages that are fully implemented SRP-6a, see this SRP implementations list.

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

Registration

When an app (web/mobile) start the registration flow, it may display a identity (I) (username or email) and password (P) field to user. They entered their username and password and then clicked 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 the 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 receives 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 that is only known by server.

Login

Hello and Server step1

When a user starts the 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. The 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 sides.

Some package calls the client Hello as challenge action, and the B is the server challenge value.

Client steps 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 compared failure, server will report an error, and if compared success, server will generate a server proof M2 and back to client. To this step, the authenticate actions are done, you can simply redirect user to the 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 sides generate the same session key (S). If you have done this step3, it means you completed the authenticate handshake and did a two-way authentication. If you want to run the step3 to complete all the processes, 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.

The Example Code

Here is a pseudo-code to show how SRP server-side and client-side cross works.

const server = SRPServer.create();
const client = SRPClient.create();

// Register
const identity = '...';
const password = '...';

// Register: generate new salt & verifier

// random()
const salt = client.generateSalt();
// (SHA(s | SHA(I | `:` | P)))
const x = client.generateX(salt, identity, password);
// (g^x % N)
const verifier = client.generateVerifier(x);


// Send salt and verifier to Server store


// Login start
// AJAX:hello?{identity} - Server step (1)
// salt & verifier has already stored on user data, server can get it from DB
// b & B must remember on session, we will use it at following steps.

// random()
const b = server.generateRandomSecret();
// ((k*v + g^b) % N)
const B = server.generateB(b, verifier);


// Server returns B & salt to client


// Client step (1)

// random()
const a = client.generateRandomSecret();
// (g^a % N)
const A = client.generateA(a);
// (SHA(s | SHA(I | `:` | P)))
const x = client.generateX(salt, identity, password);


// Client step (2)

// H(PAD(A) | PAD(B))
const u = client.generateU(A, B);
// ((B - (k * g^x)) ^ (a + (u * x)) % N)
const S = client.generateS(a, B, x, u);
// H(S)
const K = client.hash(S);
// H(H(N) xor H(g), H(I), s, A, B, K)
const M1Client = client.generateM1(identity, salt, A, B, K);


// AJAX:authenticate?{identity,A,M1} - Server step (2)
// Send identity & A & M1 to server and compare it.
// The salt & verifier stored on user data, get it from DB.
// The b, B stored in session state, get and clear them.

// H(PAD(A) | PAD(B))
const u = server.generateU(A, B);
// ((A * v^u) ^ b % N)
const S = server.generateS(A, b, verifier, u);
// H(S)
const K = server.hash(S);
// H(H(N) xor H(g), H(I), s, A, B, K)
const M1Server = server.generateM1(identity, salt, A, B, K);

// Do compare
if (!crypto.timeingSafeEquals(M1Client, M1Server)) {
  throw new Error('Invalid client session proof.');
}

// Now create a M2 as server proof
// H(A | M | K)
const M2Server = server.generateM2(A, M1Server, K);

// Server returns M2 to Client
// Client step (3) (optional)

// H(A | M | K)
const M2Client = client.generateM2(A, M1Client, K);


// Do compare
if (!crypto.timeingSafeEquals(M2Client, M2Server)) {
  throw new Error('Invalid server session proof.');
}

// If all passed, should not throw any exceptions.

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 a and b in your browser and server cache that can use them cross steps and do not accidently send them to remote side.

• The verifier is generated from identity and password, which means you must re-create a new verifier to replace old one if user changes either of identity or password.

• 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 can 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 if you are using an SRP library, always re-create the library objects when user retries.

• SRP should not replace HTTPS, you should always use SSL/TLS on your app and enable the Cookies HttpOnly and secure settings.

Related Links

• thinbus-srp (JS SRP implementation)

• artisansdk/srp (PHP/JS SRP implementation)

• windwalker/srp (PHP/JS SRP implementation)

• More SRP implementation List

Images via windwalker/srp