User accounts, passwords and proving who you are

A user account is a record on a system that represents one person: a username, a password (stored as a hash, never as plain text), and a set of access rights saying what that account may do.

Why not one shared login for the whole office? Three reasons, and each one is worth a mark:

• Accountability. Every action can be logged against a named account, so an audit trail shows who read or changed a record. With a shared login, nobody is answerable.
• Least privilege. Each account gets only the access its job needs — a receptionist does not need clinical notes, a temp does not need the payroll.
• Removal. When someone leaves or changes role, their account is disabled, and their access ends immediately. A shared password that ten people know can never be withdrawn.

Larger systems group accounts into groups (for example students, teachers, admins) and give rights to the group, so a new starter inherits the right access in one step.

A password is only useful if an attacker cannot guess it or crack it quickly.

Systems should also:

• store only a hash of the password (plus a random salt), so a stolen database does not reveal the passwords;
• lock the account or add a delay after a few failed attempts, to slow down guessing;
• never send the password itself in an email, and never display it on screen.

A digital signature is a block of data attached to a message that proves which key signed it and that the message has not been altered. It uses asymmetric encryption: a pair of keys, where one key locks and the other unlocks.

Each user keeps a private key secret and publishes the matching public key. Here is the whole process, step by step.

1. The sender computes a hash of the message — a fixed-length fingerprint of its contents.
2. The sender encrypts that hash with their private key. The result is the digital signature, sent with the message.
3. The receiver decrypts the signature with the sender's public key, recovering the hash the sender calculated.
4. The receiver hashes the message they received and compares the two hashes.
5. If the hashes match, the message is unchanged (integrity) and it must have been signed by the holder of the private key (authentication and non-repudiation — the sender cannot later deny signing it).

Two traps to remember:

• The public key verifies; the private key signs.
• Signing does not hide the message: anyone can read it. For confidentiality the message must also be encrypted, which is a separate step.