Every traveler knows the problem — you want to quickly check your emails in an internet cafe, and have a bad feeling when logging into your email client like Gmail. What if a key logger is recording your password, and the attacker can access your email account? Or, if you are using the same password for other services, e.g. Amazon, and the attacker access these services with your login credentials?
Of course, ideally, you have two-factor authentication activated. But what if not? And even if two-factor authentication is activated, it’s certainly is not ideal that the attacker knows your password and potentially can log in to other services where you use the same password and that might not have two-factor authentication. Similarly, one-time-passwords are not ideal as they don’t satisfy the requirement of having two separate mechanisms of authentication.
My students in the E-Business module did a great software project to tackle the problem. They developed a prototype of what we call One-Time Two-Factor Authentication (OTTFA). OTTFA combines the best of both worlds, i.e. from two-factor authentication and one-time passwords. OTTFA enables users, who believe a computer may have been compromised, to choose an alternative log-in method, i.e. the OTTFA login. In that case, the user first receives a ‘normal’ one-time-password e.g. to the mobile phone. Once the one-time password is validated, the user logs in with only the last few characters of the password. This mechanism ensures that potential attackers do not get access to the complete password.
In the remainder, you see the report of the students including URLs to the prototype (and solutions of two other teams who did the same project).
Users generally log into their online accounts with a username and a predefined password. For the sake of convenience, many people often use the same credentials across multiple accounts. However, this creates an extra security risk. Hackers can install malicious software on a device such as a keystroke tracker to save these credentials. Not only does this give the hacker access to the account currently being logged into. They can also gain access to all other accounts with the same login information.
Two-factor authentication and one-time passwords (OTP) were introduced to combat this security risk. Two-factor authentication works by sending a code by text or email to the user after they enter their username and password. This code must be entered into the website to gain access to the account. One-time password works similarly. Rather than entering the entire predefined password, the user can request a one-time password. This will be sent to either their phone or email. With both of these methods, the hacker must have two things in order to gain access to the account, the user’s login details and access to their phone or email.
The problem with these methods is that they don’t prevent the hacker from being able to phish the data. While the hacker may not have access to accounts protected by two-factor authentication, they can use the phished data on any other account with the same credentials. In the event of two-factor authentication being deactivated, the hacker can gain access to the account. One-time password may stop hackers from phishing the predefined password, but it removes the need to know some private information (the password). If the hacker gains access to the user’s phone, then they will have complete access to their account.
Reference to the original problem statement can be found at:
https://joeranbeel.atlassian.net/browse/STUD-20 (requires authentication)
Our goal was to develop a program where a user can login without entering their full password. Instead, the user enters only part of their password, for example, they could be asked to enter the 3rd, 6th, and 7th indexes of their predefined password. This method is more secure as even if a hacker phished this information, they will not know the entire password. They will also be sent an OTP by text. This must be entered into the website and verified in order to gain access to the account. This provides additional security by checking if the user has knowledge beyond access to the phone, and all the benefits of two-factor authentication.
Our project allows users to choose between a “secure” and “unsecure” login. The unsecure page is just the normal login process with a username and password. Secure can be used for extra security if the user does not fully trust the website. This is where the user will be asked to enter their mobile number so they can be sent their one-time password. After the OTP is entered, the user will be asked for random indexes of their predefined password. This provides all the benefits of one-time two-factor authentication with the additional security of a partial password, preventing hackers to be able to phish all the private information. The person logging into the account must not only know the whole password to be able to enter the random indexes, they must also have access to the account owner’s phone.
We decided to change the proposed order of events for the login solution to one we felt was more secure. Instead of having the user enter their partial password and then their OTP, our application asks for the OTP first before asking for the partial password. We felt this was more secure as by sending the OTP the user should get a text with the validation code and this will alert them that someone is trying to access their account. Twilio also has a request limit to prevent spamming. This provides an extra layer of security, as if the hacker does not guess the password within the given limit, they will not be able to receive any more OTPs. In short, we changed up the order of events in the login process to make hacking the account by brute force more difficult.
Another design decision we made was to integrate our own functionality into a premade react app by GitHub user, giorgi-m, the repository can be found here: https://github.com/giorgi-m/online-shop?fbclid=IwAR3LIAWiNSmhDrND2gkn0J8DgDUS9wG8azRLAf46fqVd29fSMTXhUK1Ezx0
We did this because we didn’t want to reinvent the wheel. Rather than spending time developing a whole new, fully functioning website, we felt it was more important to spend our time on the problem at hand. Our choice to do this was influenced by Professor Beel’s comments after our prototype demonstration. We followed the principles of MVP (lecture notes week 1 slide 25).
When the user clicks login they are initially brought to this page, as can be seen in the following screenshot. They are given the option to login as normal or click one of the links below to go register or choose the extra secure login for untrusted computers.
If the user opts to go for secure login, they are pushed to this page where they are required to enter just their email. They can also follow the link to find out more about secure logins.
Once the user enters their email and it is validated, an OTP is sent. They are then brought to this page where they enter the OTP received on their mobile device.
If the OTP is valid they are then pushed to this partial password page where they are prompted to enter specific indexes of their password.
If the user chooses to register, they are brought to this page and asked to enter their email, password and phone number.
We made use of alerts to let the user know their status for the current stage of the login process: e.g. that the OTP has been sent or login failed etc.
Demo & Source Code
Our project was published under the MIT license. All source code can be found within the GitHub page:
A live demo can be found at: https://ebusiness-project.herokuapp.com/
Full Project Report
You can download the students’ full project report here:
Two other teams developed a similar tool. These solutions can be found here (also very well done):