Security and privacy — NBS Signal Tool

Your password

Stored as PBKDF2-HMAC-SHA256 at 600,000 iterations with a 16-byte random salt per account. Slow on purpose — that is the entire point of a password hash.
Compared with a constant-time comparison, so a timing difference cannot be used to guess it a byte at a time.
Login says the same thing for "no such account" and "wrong password", and takes the same time either way. Different messages let anyone harvest a list of the real users of a site.
Failed attempts are rate-limited per email and per IP address.
Minimum length 10 characters, because length beats complexity rules. A short phrase is stronger than a short scramble.

There is no email-based password reset. That needs a mail service, and a half-built reset flow is a way in rather than a feature. Until one exists, a locked-out account is reset by the owner, by hand — which also signs out every session that account had.

Your session

The session token is 32 random bytes, and only its hash is stored. Someone who reads the user file still cannot impersonate a logged-in user with it.
The cookie is HttpOnly, so no script can read it, and SameSite=Lax, so it is not sent from another site. Over HTTPS it is also marked Secure.
Sessions expire after two weeks, and expired ones are pruned rather than left lying in the file.
Changing a password or disabling an account kills every session that account had, immediately.

Your Zerodha connection

This is the part that deserves the most care, because a Kite access token can read positions and place orders.

This tool places no orders. There is no order code in it at all. The token could, which is exactly why it is treated as a credential rather than as a setting.
It is stored only in the server's user file — the same file as the password hashes, written with owner-only permissions.
It is never rendered into a page, never logged, and never sent to a browser. The connect screen shows your Zerodha user id and the time you connected; it does not show the token.
It is deleted with your account. Token and user live in the same record specifically so that one cannot outlive the other.
You can disconnect at any time from the connect page, and revoke this app from Zerodha's own side independently.
It dies every morning regardless. Zerodha clears every access token around 07:30 IST, whenever it was issued.

Your session is used only for your own data. Signals are computed under your token, on a feed that starts when you open the page and stops a few minutes after you close it — so nobody else's activity touches your rate limit, and yours does not touch theirs.

What is stored, in full

Item	Where	Note
Email	user file	your identifier, nothing else
Password hash	user file	PBKDF2, salted, never reversible
Session hashes	user file	expire after two weeks
Kite access token	user file	dies each morning; deleted with the account
Kite user id	user file	so the connect page can say which Zerodha login this is
Created / last login	user file	so the owner can see a dormant account
Closed trades	trade file	the tickets this server issued, not tied to a person

There is no analytics, no third-party script, and nothing is loaded from another domain — the pages you are reading declare a content security policy that forbids it. No payment details are collected anywhere, because nothing here is sold.

What the owner can do

Being honest about this matters more than sounding reassuring. Whoever runs this server can create accounts, disable them, delete them, and set a new password on one — that last one being how a locked-out user gets back in, since there is no email reset. They can also read the file those things live in.

They cannot read your password, because it is not stored. They can, in principle, read your stored Kite token off the server, which is the honest reason to treat "who runs this server" as a question worth asking before connecting a broker account to it — here or anywhere else.

NextHow access works ThenQuestions