Synthesis: Deepa’s Bank Login

This is the synthesis exercise from Session 5. Work through it yourself first — try to answer each question before reading the answer below it. The goal is to connect every concept from Sessions 1 through 4 into one coherent walkthrough.

The scenario: Deepa has a brand new phone. She connects to her college Wi-Fi, opens Chrome, and logs into SBI net banking for the first time on this device to transfer ₹200 to Rohan.

Step 1 — Connecting to Wi-Fi

Question: When Deepa’s phone connects to the college Wi-Fi, what address does it get? Is this the address the rest of the internet will see?

Answer:

Her phone gets a private IP address from the college router — something like 192.168.10.45. This is her address on the local network.

The rest of the internet will see the college network’s public IP address — the address assigned to the college’s router by the ISP. Her phone and every other device on college Wi-Fi share this one public IP as far as the internet is concerned.

The college router uses NAT (Network Address Translation) to track which private device sent which request, and routes responses back to the correct device.

Concepts used: IP addressing, private vs public IP, NAT (Session 1)

Step 2 — The Browser Finds SBI’s Server

Question: When Deepa types onlinesbi.sbi into her browser, how does it know where to send her request?

Answer:

The browser makes a DNS lookup for onlinesbi.sbi. DNS resolves this domain name to an IP address — SBI’s actual server IP.

This lookup goes to the DNS server configured on the college Wi-Fi (probably the ISP’s resolver). The resolver asks up the DNS hierarchy until it gets an authoritative answer. The IP address comes back to Deepa’s browser.

Concepts used: DNS, name resolution, DNS hierarchy (Session 1)

Step 3 — Verifying SBI’s Identity

Question: Before the app exchanges any data with SBI’s server, it needs to verify that it is talking to the real SBI. How?

Answer:

The app initiates a TLS handshake with the server. The server presents its digital certificate — a document signed by a Certificate Authority (e.g., DigiCert) that says “this public key belongs to api.onlinesbi.sbi.”

Deepa’s phone:

  1. Checks that the certificate is signed by a CA in its trusted root list (pre-installed by Google in Android)
  2. Walks the chain of trust from the site certificate to the Intermediate CA to the Root CA
  3. Verifies the domain name in the certificate matches the server it connected to
  4. Verifies the certificate has not expired and has not been revoked

Only if all checks pass does the handshake continue.

Concepts used: TLS handshake, certificates, CA trust chain, PKI (Sessions 2 & 3)

Step 4 — Establishing Encrypted Communication

Question: After the certificate is verified, what happens next? Is the connection encrypted yet?

Answer:

The TLS handshake continues. The server sends its public key (from the certificate). Deepa’s phone uses this public key to encrypt a shared secret and sends it to the server. The server decrypts it with its private key.

Now both sides have the same shared secret — a symmetric session key. From this point forward, all communication is encrypted with this session key using fast symmetric encryption (typically AES-256).

Asymmetric encryption (public/private keys) was used to securely exchange the session key. Symmetric encryption is used for all the actual data that flows. This hybrid approach gives both security and speed.

Concepts used: asymmetric encryption, key exchange, symmetric encryption, TLS (Session 2)

Step 5 — Deepa Transfers ₹200 to Rohan

Question: Deepa logs in with her username and password, receives an OTP on her phone, and initiates a ₹200 transfer. What is happening at each step, and where does the security apply?

Answer:

Login — username and password: Deepa’s credentials travel over the encrypted TLS connection to SBI’s server. SBI does not store her password in plaintext — it stores only a secure hash. The server computes the hash of what she typed and compares it.

OTP step: Because this is a new device, SBI sends a One-Time Password to Deepa’s registered mobile number. This is 2FA — even if an attacker knew her password, they would be blocked here without her phone. The OTP is valid for only a few minutes.

Transfer: Deepa enters Rohan’s account details and the amount. SBI may send another OTP to confirm the high-value transaction. Once confirmed:

  1. SBI debits Deepa’s account
  2. SBI sends a transfer instruction to Rohan’s bank through the interbank network
  3. Rohan’s bank credits his account
  4. Both receive an SMS confirmation

The entire session is protected by the encrypted TLS connection established in Steps 3 and 4.

Concepts used: online banking login flow, 2FA, OTP, session security (Session 4)

Step 6 — A Threat That Did Not Happen

Question: Unknown to Deepa, someone on the college Wi-Fi was running a tool that intercepts network traffic. What did the attacker see from Deepa’s session?

Answer:

Almost nothing useful. Because the entire session was encrypted with TLS:

  • The attacker could see that Deepa’s device connected to an IP address (SBI’s server IP)
  • The attacker could see the domain name api.onlinesbi.sbi in the DNS query (DNS is not encrypted by default) — revealing that Deepa uses SBI YONO
  • The attacker could see the volume and timing of data transfers (not the content)
  • The attacker could not see: the credentials, the OTP, the transaction amount, or any account details

This is why HTTPS and certificate verification matter. The attacker on the network was powerless, because the encryption was correctly implemented and the certificate was verified.

If Deepa had been using an HTTP connection (no encryption), the attacker could have read everything.

Concepts used: MITM attacks, HTTPS protection, what encryption conceals (Sessions 2 & 4)

Full Picture

Deepa's phone
  → gets private IP from college Wi-Fi (Session 1)
  → DNS resolves api.onlinesbi.sbi to SBI's server IP (Session 1)
  → TLS handshake: SBI's certificate verified via chain of trust (Sessions 2 & 3)
  → Encrypted tunnel established with session key (Session 2)
  → Login with password + OTP (2FA): session token issued (Session 4)
  → Transfer: SBI debits Deepa, credits Rohan's bank over secure interbank connection (Session 4)
  → Attacker on Wi-Fi sees encrypted noise (Sessions 2 & 4)
  → Rohan receives ₹200 (everything worked as designed)

Every session contributed something to that ₹200 arriving safely. That is the point of the course.