What security considerations are important in your ATM design?
Fast recall
Quick revision
Core answer
Security-aware design thinking—whether you consider threat models (PIN theft, man-in-the-middle, physical tampering) beyond just functional requirements
Only mentioning password encryption but ignoring session management, audit logging, or communication security
Mention specific attack vectors (shoulder surfing, card skimming) and how your design mitigates them, plus regulatory compliance (PCI-DSS) requirements
Interview-ready guide
Interview answer
I'd frame ATM security as a set of invariants the design enforces, not features bolted on afterwards. The first and most important is that you never store the PIN. The PIN comes in as a method argument, gets sent over an encrypted TLS connection to the bank server for verification, and is then discarded — there's no PIN field anywhere in the system, so it's eligible for garbage collection right after the call.
Second, I limit PIN attempts. After the configured number of failed attempts, the authentication service asks the issuer to block further attempts and records a masked security event. That stops brute-force guessing. Third, all communication with the bank server is encrypted with TLS, so nothing sensitive travels in plaintext. Fourth, sessions time out — if the customer exceeds the configured idle period, the machine ejects the card and returns to the idle state, so someone can't walk up to a session left open by the previous user. Fifth, there's a full audit trail: every transaction and state change is logged with a timestamp and a masked or tokenised card identifier, which supports fraud detection and compliance. The one rule there is that you audit the event, never the PIN or full card data.
The way I'd tie it together is that good class design makes the insecure states unreachable. A policy-controlled attempt limit and a session timeout reduce the dangerous paths and make their handling explicit, rather than relying on the operator to remember to handle them.
What security considerations are important in your ATM design
Direct Answer
Key security principles: (1) Never store PINs—verify immediately via BankServer and discard, (2) Encrypt all communication with BankServer using TLS, (3) Limit PIN attempts to 3 before locking the card, (4) Session timeout—eject card after 30 seconds of inactivity, (5) Audit trail—log every transaction and state change with timestamp and card number for compliance and fraud detection.
Code Example
record AttemptPolicy(int maxFailures) {}
class AuthSession {
private int failures;
int recordFailure() { return ++failures; }
void clearFailures() { failures = 0; }
}
class AuthService {
private final BankGateway bank;
private final AttemptPolicy policy;
AuthService(BankGateway bank, AttemptPolicy policy) {
this.bank = bank;
this.policy = policy;
}
boolean verify(AuthSession session, Card card, char[] pin) {
try {
boolean ok = bank.verifyPin(card.token(), pin);
if (ok) session.clearFailures();
else if (session.recordFailure() >= policy.maxFailures()) {
bank.blockFurtherAttempts(card.token());
AuditLog.record("AUTH_BLOCKED", card.maskedNumber());
}
return ok;
} finally {
Arrays.fill(pin, '\0'); // best effort for the local mutable buffer
}
}
}
The sample avoids persistent PIN storage and full card identifiers. A real ATM follows issuer and payment-network security controls.
Common Mistakes & Pitfalls
- Storing the PIN in a field or log — even briefly. Keep it as a local, verify, discard.
- Unlimited PIN attempts — apply the issuer's configured retry and blocking policy.
- No session timeout — a customer walks away authenticated and the next person withdraws.
- Logging sensitive data — audit the event and card number, never the PIN or full track data.
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.