Security
What actually protects a Buhata account, in the words of the code that does it. Everything on this page is a thing the server does, not a thing we intend to do.
Signing in
Passwords are hashed with scrypt at N=32768, well above the current OWASP floor, with a random salt for every account and a version marker so the work factor can be raised later without locking anybody out. Comparisons are constant-time, so a wrong password takes the same time to reject whatever it is wrong by.
Most people never set one. Signing in is a six-digit code sent to your address, or Google, Microsoft or Apple. Codes are single use, expire, and are rate limited. There is a one-tap link in the same email and it spends the same grant, so tapping the link on your phone kills the code sitting in a browser tab.
Sessions
Every session is a row on our server, not a token we cannot take back. Signing out revokes it there, and so does deleting the device from Settings. Sessions carry an audience: a session made for the Help Center cannot read your app data, and a session made for the app cannot act as you in the Help Center. That separation is checked on every request rather than assumed at sign-in.
What the server refuses to do
Two rules are enforced in code rather than in policy, which means they hold whether or not anyone reads this page.
- Money never enters a shared document. Not a household, not a team, not on any plan, and no setting changes it.
- Health is held the same way. Weight, water, medicines and appointments stay with you inside every group you are part of.
Sharing a plan with another adult gives them the plan. It does not give them your entries, your balances or your history.
In transit and in the browser
Everything is HTTPS, with HSTS covering the domain and its subdomains, so a browser refuses to speak to us in plain text after the first visit. The API sets a content security policy, denies being framed, refuses content-type sniffing, and sends no referrer. Links that hand you between our own pages are one-shot, hashed where they are stored, and refuse to be spent from inside a frame.
How little we run
The server has five third-party runtime dependencies. Five. Most of what a product like this normally imports is written here instead, which is slower to build and much smaller to attack: every dependency is somebody else's code running with your data, and the honest way to reduce that risk is to have less of it. The fifth is the Postgres client, added when the database moved off a single file so the service could run more than one copy of itself.
There is no analytics package, no advertising code, and no tracker on any page. Not as a setting. There is none in the bundle.
Deleting an account
Deletion is real and it cascades. Sessions, backups, devices, group membership, subscriptions, notification subscriptions and anything else keyed to you are removed together, and the sweep runs on a schedule rather than when somebody remembers. A job application, if you ever sent one, is deleted with everything else and is separately deleted twelve months after you sent it whether you ask or not.
Who else touches your data
Four companies, because the app has to run somewhere. The privacy policy names each one and says exactly what it receives. Nothing you write is sold, rented or handed to an advertiser, and there is no version of Buhata where that changes.
What we do not have
Security pages usually stop before this part. Ours should not, because you are being asked to trust a small company and the useful thing is an accurate picture rather than a flattering one. Buhata does not have:
- A SOC 2 or ISO 27001 audit. Both are real audits by real auditors and we have not done either.
- A published penetration test or a bug bounty program.
- Encryption at rest on the database volume, beyond what our host provides.
- Two-factor authentication on your account. This is the gap we consider a product gap rather than a paperwork one, and it is the one we intend to close first.
- Single sign-on or SCIM, which are enterprise features Buhata is not built for.
If any of those are things you need, a household productivity app from a one-person company is probably the wrong choice today, and we would rather say so here than let you find out later.
Reporting a problem
Send it to [email protected] with enough detail to reproduce it. You do not need to prove impact, and you will not be asked to sign anything before we look. We acknowledge within two business days, tell you what we found within ten, and tell you when it is fixed. We do not pay a bounty and we will not pretend otherwise, but we will credit you by name if you want that.
Machine-readable details are at /.well-known/security.txt. What runs on every push, how long a patch takes, and what we deliberately do not claim are in SECURITY-POLICY.md.
What we ask of you
Test against your own account. Do not run automated scanners against the live service, do not access anybody else's data, and do not degrade the service for people using it. Give us a reasonable window to fix something before you publish it. If you reach somebody else's data by accident, stop and tell us: we will not pursue anybody who reports in good faith.