1.1 What happens when you enter a password?
If the password is transmitted from the user to the server as plaintext (what you see is exactly what you get; it isn’t hidden in any way) – it could be intercepted as it travels across the network.
This is usually overcome by encrypting the communication between the user and the server. The most common form of encryption is the Transport Layer Security (TLS) standard or the older SSL standard (Secure Socket Layer). You’ll recognise that TLS or SSL is being used when you see ‘https’ at the beginning of a web page address instead of ‘http’, and by a padlock symbol in your browser. (You’ll look at encryption and TLS and SSL more fully in Week 4.)
Another problem occurs if a password is stored on a server as plaintext. In this case a successful attack on the server would not only reveal the user’s password, but all the passwords for all the users of the system. However, when a user enters a password the server needs to be able to confirm that this is the correct password for that user before it grants access.
This second problem can also be solved using a technique called hashing. A hash with salt is the result of processing plaintext to create a unique, fixed length identifier – you’ll find out more in Week 5. It cannot be used to reconstruct the original data – even if the hash falls into hostile hands. In this scheme, a hashing function is used to create a hash of a password, which is stored on the server – the password itself is discarded. When the user enters a password, this is sent over the network and hashed on the server using a copy of the same hashing function. The resulting hash is compared to the hash stored on the password server. Only if they match will the user be granted access. Some implementations of this scheme will hash the user’s password before sending it across the network to be compared with the hash stored on the server.
Almost all online services and computer systems store passwords as hashes – but surprisingly, errors still happen. The problems described in the following case study could have been avoided if hashing had been used.
Case study: RockYou
The game and advertising company RockYou suffered a major security breach in 2009 when 32 million user accounts were compromised, revealing that not only did the company store passwords in plaintext, it encouraged insecure passwords by only requiring them to be five alphanumeric characters long.
RockYou’s problems were made worse when it became clear that they had known that their database was vulnerable to an attack for more than ten years. The company had previously been criticised on privacy grounds for sending emails containing complete lists of their advertising partners, and for poor security in issuing passwords through insecure email.
Over the years many billions of accounts have been breached and the data collected by criminals. These criminals then try the same user name and password on other accounts. If you have reused the same password then they may take over your account.
In 2016, a list of 593 million unique email addresses together with multiple passwords for each address was being circulated by criminals. This list was known as ‘Exploit.In’
You can check to see if your own email has been part of a data breach by visiting. Later this week you will look at how to improve your password security.
Even when hashing and encrypted communications are used, there are still ways in which attackers can successfully learn your password.