Why Shared-Device Security in F&B Is a Different Beast — and How We Solved It with PIN Auth

If you've ever stood behind the counter of a busy cafe during the lunch rush, you know how fast everything needs to move. Orders stack up, the line grows, and the cashier's focus should be on the customer — not on typing a password.

But behind that speed lives a security challenge that most software ignores: the POS tablet is a shared device. Unlike office laptops where one person owns one machine, a single tablet in an F&B business might be used by three to five different cashiers in a single day. And every person who touches it needs to be accountable — who processed this transaction? Who applied that discount? Who voided that order?

This is the story of why we take shared-device security seriously at CrescendPOS, and how PIN-based auth was born from real-world constraints.

The Problem: Email + Password Doesn't Work for Cashier Switching

Picture this: morning shift, the cafe is packed. Cashier A finishes a rush and needs to hand off to Cashier B for a break. With standard email + password auth, Cashier B would need to:

• Log out of Cashier A's account
• Navigate to the login page
• Type their full email address
• Type their password (which they might not remember since they rarely type it manually)
• Wait for the page to load

Meanwhile, the customer in front of them is waiting. The queue is growing. Cashier B is stressed. What happens in practice? They don't log out at all — and every transaction for the rest of the shift gets attributed to Cashier A. Accountability is gone.

From our conversations with cafe owners, this isn't a hypothetical scenario. It's everyday reality. We've heard repeatedly that cashiers end up sharing a single account all day because the login process is too cumbersome to repeat between every handoff.

And that's not the cashier's fault. That's a design failure.

The Solution: Two Auth Layers That Complement Each Other

In CrescendPOS, we separated authentication into two distinct layers because they serve fundamentally different purposes:

Layer one: Email + password (via Devise) — this is for owners and managers. They log in once at the start of the day, and their session persists as long as the tablet is active. This is the heavyweight layer — email, password, and optionally two-factor authentication (TOTP via authenticator app) for extra security.

Layer two: 4-digit PIN — this is exclusively for cashiers. No email, no password. Cashiers are a completely separate data model from Users. All they need is a name and a 4-digit PIN to switch in.

Why this architecture? Because the tradeoff between speed and accountability has to be resolved at the system design level, not papered over with UX shortcuts.

How PIN Auth Works Under the Hood

A cashier PIN isn't just four digits checked with a simple comparison. There are several security layers behind it:

• Bcrypt hashing — PINs are stored as bcrypt digests, the same algorithm used for passwords. Even if the database were compromised, the raw PINs can't be read directly.
• Escalating lockout — after 5 incorrect attempts, the cashier account locks for 5 minutes. Keep getting it wrong? The lockout escalates: 10 minutes, 15 minutes, up to a cap of 60 minutes. This blocks brute-force attacks without punishing a cashier who genuinely mistyped once or twice.
• Network-level rate limiting — we cap PIN attempts at 10 per IP per minute via Rack::Attack, layered on top of the per-account lockout. Even if someone tries to circumvent the lockout, there's a separate fence at the network layer.
• Clean audit logging — PIN digests are redacted from the audit log. We record who logged in and when, but never expose sensitive credential data.

From the cashier's perspective, the flow is fast: tap your avatar on the grid, type 4 digits on the PIN pad, and you're in. No email form, no password field, no page reload. Switching between cashiers takes seconds.

Fast Switching Without Losing Context

One design decision we're particularly proud of: there are two distinct sign-out paths.

Switch Cashier — this clears only the cashier session, but the underlying Devise session (owner/manager) stays active. The next cashier just picks their name and enters their PIN. The tablet doesn't need to go through a full login cycle.

Exit to Admin — this is a full logout. Both the cashier session and the Devise session are cleared. This is for end of day, or when the tablet is being moved to a different station.

The distinction matters. When Switch Cashier is fast and frictionless, cashiers have no excuse to skip the handoff. And when they don't skip it, every transaction gets attributed to the right person.

Manager Overrides: Sensitive Actions Require Approval

Not every operation in the POS should be available to everyone. Some actions are high-risk if left unguarded:

• Voiding a completed order
• Applying discounts above a certain threshold
• Cancelling an order that's already been sent to the kitchen
• Cash withdrawals or deposits from the cash drawer
• Closing a shift with a large cash variance

For these actions, CrescendPOS requires manager PIN approval. Here's how it works: when a cashier attempts a sensitive action, a dialog appears requesting the manager's PIN. The PIN is pre-verified in real time before the main form submits — so if the PIN is wrong, the dialog stays open and the cashier can retry without losing context.

Why does pre-verification matter? Without it, a wrong PIN would redirect to a different page, forcing the cashier to re-open the cart, re-open the item editor, and re-open the approval dialog. That kind of context loss makes the flow feel broken — even though it was just a typo. We hit this exact problem during development and built the pre-verify pattern specifically to solve it.

Every approval is logged in the audit trail with the approving manager's identity and their stated reason. This isn't just about preventing fraud — it's about having a clear paper trail when questions come up later.

Shifts: Binding Transactions to Accountability Windows

PIN auth and manager overrides secure individual actions. But there's a broader accountability layer: shifts.

Every cashier must open a shift before they can process any transaction. A shift records:

• Which cashier is working
• When the shift was opened
• The opening cash balance
• Every order processed during the shift
• Every cash movement (deposits, withdrawals, refunds)
• The closing cash balance and its variance against the system's expected total

When a shift closes, the system automatically calculates the expected balance based on all cash transactions and drawer movements during the shift. The cashier enters the actual balance — how much money is physically in the drawer. The difference is immediately visible.

If the variance exceeds a threshold, closing the shift requires manager approval. This ensures that when there's a significant cash discrepancy, a second person knows about it and signs off.

Here's what makes this powerful: every order is bound to exactly one shift, and every shift is bound to exactly one cashier. There are no orphan transactions without an owner. If there's ever a question about a specific sale, you can trace it: this transaction, this shift, this cashier, this time window.

Audit Trail: Every Action Leaves a Trace

None of the layers above would mean much without proper record-keeping. In CrescendPOS, every mutation on an Order and OrderItem is recorded in the audit log with clear cashier attribution:

• opened_by_cashier — who created the order
• closed_by_cashier — who completed the transaction
• cancelled_by_cashier — who cancelled it
• discount_applied_by_cashier — who applied the discount
• added_by_cashier / removed_by_cashier — per line item, who added or removed it

This isn't a technical log only developers can read. It's data that the business owner can access through the dashboard to review activity by cashier, by shift, by day.

Design Born from Real Constraints

Every decision above came from a single question: how do you let cashiers switch in under 3 seconds while making every rupiah accountable?

The answer isn't one feature. It's complementary layers: PIN auth that's fast but secure, manager overrides for sensitive operations, shifts for time-bounded accountability, and an audit trail for full transparency.

If you're evaluating a POS system for your F&B business, don't just ask what features it has. Ask: how does this system handle the reality of 3 cashiers sharing 1 tablet in a single day? The answer will tell you whether the system was actually designed for restaurants, or whether it's office software in a tablet wrapper.