Security at JPRAXC

This page describes controls that are built into the software itself. How safe a particular installation is also depends on where and how it is hosted, on the school’s own settings, and on the accounts and devices of the people who use it. It is a summary, not a contract: the Terms of Service and the Privacy Policy set out what JPRAXC undertakes.

Signing in to the School ERP

• Passwords are stored only as one-way hashes. The ERP uses PHP’s password hashing: bcrypt, or Argon2id for passwords longer than 72 bytes. A password is never kept in a form that can be read back.
• A second sign-in step. After the password, the ERP can ask for a six-digit code from an authenticator app on the user’s phone (any app that follows RFC 6238, such as Google Authenticator or Microsoft Authenticator), or one of ten single-use recovery codes. The administrator must always use it, and so must any user the administrator sets to “Password + authenticator app”. By default the school’s policy also requires it, after a fourteen-day grace period, for every role that can change fees, payroll or accounts; the school can extend it to everyone. The JPX School ERP app asks for the same code as the web.
• Limits on wrong attempts. Six failed sign-ins for one account within ten minutes, or thirty from one network address, stop further attempts for ten minutes.
• Sign-in address register. The ERP records each network address that users sign in from. A user other than the administrator who signs in from an address that has not been approved is held until the administrator approves it. The administrator’s own sign-ins approve the address they use, and that approval is written to the audit log.
• Session protection. The session cookie is marked HttpOnly and SameSite=Strict, and Secure whenever the ERP is served over HTTPS. Every request that changes data must carry a token tied to the session, so a page on another site cannot submit changes on a signed-in user’s behalf.

Roles, permissions and the audit log

• Role-based permissions. Each role is given, module by module, any of eight permissions: view, create, update, delete, print, approve, export and invoice. The server checks the permission before each operation and refuses it when the role does not allow it. The school administrator has full access, and changes to access itself are reserved to the administrator.
• Audit log. The ERP records who did what and when: sign-in and access events, and changes across the modules, including fees, payroll, student and staff records, academics, report cards, transport, hostel, communication, backups and settings. The network address and browser of each entry are stored as SHA-256 hashes rather than in plain text. Roles allowed to view the Audit Log can read it by day or by month.
• Refunds need the password again. Before an online-payment refund is sent, the accounts user re-enters their current password, with its own limit on wrong attempts.

Stored credentials and sensitive fields

The School ERP encrypts the following with AES-256-GCM, using the school’s own private data key:

• payment gateway credentials;
• payroll payout beneficiary details;
• SMS and WhatsApp provider credentials;
• the authenticator-app secret behind each user’s second sign-in step (recovery codes are kept only as hashes);
• Aadhaar numbers, when the school’s data key is in place.

The data key is a 32-byte key kept in a file that the ERP requires to be outside the public web folder. This protects the fields listed above; it is not encryption of the whole database.

Licences and software updates

• Signed licences. Each licence and activation is signed by the JPRAXC Console with its private key (RSA with SHA-256). The ERP checks that signature with the public key installed with it, and refuses an activation that does not verify. When the Console creates its signing key, it is a 2048-bit RSA key pair.
• Signed updates. A software update is installed only when it comes with a signed release proof that matches the product, the edition, the version and the SHA-256 checksum of the package.

Backups

• What a backup holds. A backup contains the school’s database and its protected media files, and the SHA-256 checksum of every backup is recorded.
• When backups are made. The ERP starts an automatic backup when a user who is allowed to make backups opens the workspace and no backup has been made in the previous 20 hours. A backup can also be made at any time with “Back up now”.
• Cloud edition. Backups are uploaded to the JPRAXC Console, and only over HTTPS: the ERP refuses a backup address that is not HTTPS. The Console recalculates the SHA-256 checksum of what it received and rejects the upload if it differs. Each verified backup is recorded in a separate backup catalogue database as well as in the Console’s main records. The ERP keeps its local copy until the Console’s receipt matches the same backup, size and checksum.
• Restoring. Before a backup is restored, the ERP checks the SHA-256 checksum of the downloaded file against the Console’s record, checks every file inside it against its own checksum, and confirms that the backup belongs to the same school and activation.
• Offline edition. Routine backups stay on the school’s own computer and are not uploaded. Data leaves that computer only through a separate, explicitly authorised move to the Cloud edition.
• Downloaded copies. A backup copy the school downloads is sealed with AES-256-GCM to that school’s activation, so another school’s ERP cannot open it. Downloading it needs the backup approval permission.

Keeping its own copy remains the organisation’s responsibility, as clause 8 of the Terms of Service explains.

Payments

• On the gateway’s own page. Online fee payments in the School ERP, and payments to JPRAXC on its pay page, are made through Razorpay, Cashfree, PhonePe or Easebuzz, in the gateway’s own checkout window or page. Card numbers, CVVs, UPI PINs and net-banking passwords are entered there. The JPRAXC software has no field for them and does not receive them.
• Parents do not choose a gateway. When a parent pays school fees, the school’s default gateway opens. If it cannot open a checkout, the ERP tries the school’s other enabled gateways in turn.
• The JPRAXC pay page. A buyer first accepts the Purchase Terms and then picks one of the gateways offered. Each payment link has an expiry time and a limited number of opens, and its forms carry a session token.

Mobile apps

• App lock. JPX Parent, JPX Staff and JPX School ERP can be locked with a four-digit App PIN, and with fingerprint or face where the phone supports it. The PIN is kept only as a salted SHA-256 hash in the phone’s secure storage (Android Keystore or iOS Keychain).
• Wrong PINs. After five wrong PINs the app signs out, and the user must sign in again with their full credentials.
• Saved sign-in. The apps keep their saved sign-in in the same secure storage. When the school administrator sets a new password for an ERP user, that user’s phone sessions end.

The Mobile App Privacy Policy describes what each app stores on the phone and the permissions it asks for.

JPRAXC’s own systems

Licences and Cloud backups are handled in the JPRAXC Console, and orders in the JPRAXC Sales Portal. Both are used only by JPRAXC staff.

• JPRAXC Console. Every sign-in needs the password and a second step: an e-mailed one-time code or a code from an authenticator app. Wrong passwords slow down further attempts for that sign-in and network address. Passwords are stored as bcrypt or Argon2id hashes, the session cookie is HttpOnly, SameSite=Strict and Secure over HTTPS, changes need a session token, and staff actions are written to an audit record.
• JPRAXC Sales Portal. Administrators confirm each sign-in with an e-mailed one-time code or an authenticator code. Other staff can sign in only from network addresses an administrator has approved. Sign-in includes a check question and limits on wrong attempts, staff activity is logged, and the session cookie is HttpOnly, SameSite=Lax and Secure over HTTPS.

Privacy

How JPRAXC collects, uses, keeps and protects personal data, and the rights you have under the Digital Personal Data Protection Act, 2023 and the Information Technology Act, 2000, are set out in the Privacy Policy, including its section on security and breach notice. The Mobile App Privacy Policy covers the apps. Privacy requests and complaints can be made through the Complaints & Grievances page.

Reporting a security issue

To report a vulnerability or a suspected breach, email support@jpraxc.com with “Security” in the subject. Say which product and address are affected, what you saw and when. Email can be sent at any time; support works Monday–Saturday, 10:00–19:00 IST.

For a concern about personal data, you can also use the direct privacy request form, which needs no sign-in or prior ticket, or write to the Grievance Officer at grievance@jpraxc.com.