Consider this scenario: You have registered with a service on the internet. Some time later you are considering authenticating yourself to that service, and you are confident that your computer and your internet browser are inviolate. But that does not mean that you are out of danger.
The only way to be sure that you are not going to fall for either a Phishing or MITM attack is to make sure that the connection to the server is properly authenticated. Only then can you be confident that you are communicating directly with the right server. And you can be sure of that if the address of the server, as guaranteed by your browser, is the correct one. That address is displayed on the top line of browser. Obviously it should be same one with which you originally registered for the service. The browser can make its guarantee as it implements the well known TLS/SSL protocol, which also encrypts all communication between yourself and the server.
But there are a few problems. That address is not really prominently displayed on the typical browser. After all you are probably more interested in reading the webpage content than in forensically checking the address. Many attacks succeed by exploiting this, by attracting the victim to a fake look-alike website where the address, at a quick glance, looks OK, but isn’t. For example the address may vary by something as negligible as a plausibly placed hyphen.
A particularly insidious phisher technique is to display the URL as, for example https://www.google.com@www.miracl.com
You glance at it, it looks like you are going to some page on the google.com site. But you are not. The browser ignores everything before the @ symbol and takes you to miracl.com. Try pasting this into your browser and see what happens!
It really is quite surprising that modern browsers don’t take more care to assure their users that they have in fact landed on the intended page.
Once attracted to the fake site the victim is encouraged to authenticate themselves as usual – and the login page looks identical to the real one.
What happens next depends on the type of authentication. If the victim authenticates via a standard password, the attacker simply makes off with it. They now have your key which allows them to open the door to your account on that service, which they can enter any time they like.
That is what is known as a phishing attack.
As a defensive measure the real website, once a password is correctly entered, may choose to send a 6- digit SMS message to your registered phone, and get you to enter it to confirm your identity, and implement a form of two-factor authentication, as the phone is needed to complete the authentication. The attacker does not know your phone number, and so the basic phishing attack does not work. But its a bit of a hassle, and sometimes, infuriatingly, the SMS is delayed, or does not arrive at all.
A better idea is to use a more elaborate type of authentication which has the property of “zero-knowledge”. That is you authenticate by using your credential to respond to a large random challenge from the server. From your response the server can be assured that you do indeed possess the a valid credential, without actually needing to see it. The phisher can still issue their own challenge and get a response, but that will not help them gain access to the service, as the real server will never issue the same challenge again, and so the response that the phisher has captured is useless.
So by simply moving on from simple one-factor password authentication the phishing threat can be effectively dealt with.
But not so fast! Let us now consider the much more pernicious Man In the Middle (MITM) attack.
Here the attacker has no interest in capturing your authentication credentials. Rather than trying to capture your key, they will simply wait for you to open the door for them. To do this they might attract the victim to their fake site, while opening their own browser to the real service. Then they simply relay the messages associated with the authentication protocol (whatever it might be) between the victim and the real service. Once the door is opened, MITM then closes the victim connection, and continues on inside the victim’s account.
Note that the SMS two-factor method described above can also be MITMed, made easier by the fact that SMS messages are not encrypted.
So what to do? The only real defence against MITM is to make sure that the website being visited is in fact the real one. As we know, that guarantee is available from the browser. Unfortunately whereas we may be able to remember a password, we cannot also be expected to remember the exact spelling of the associated website. So some kind of computer assistance is going to be required to make sure we don’t make a mistake. The solution is conceptually quite simple – make sure to have the real website address stored alongside the credential. But stored where?
While trying to solve this problem, we need to be careful not to introduce others. After all being able to authenticate using only a secret password, stored only inside of our memory, really gave us the ultimate in security, privacy and flexibility. But as seen above, that’s just not going to cut it any more. But before we ditch the idea, recall an often overlooked property of simple memorised passwords. They work fine on all of our devices.
A standard solution is a password manager, as implemented in all modern browsers, and available from third parties as browser plug-ins. But outsourcing our credentials to external parties raises all kind of trust/security/privacy issues. For example most password managers store your credentials up in the cloud (in your “keyring”), so that they can be available from there across all of your devices. And the cloud is a dangerous and insecure place. Furthermore password managers often also store meta-data associated with you, as well as your passwords. In at least one popular product that meta-data included your browsing history.
A better solution? Store credentials locally on each of your devices. Use a zero-knowledge protocol. Make sure that the associated website is stored alongside those credentials and refuse to complete the authentication protocol with any other website. And ensure that one of your authentication factors still resides only in that most secure and private of repositories – your brain.
Now having your credentials for a particular website stored across multiple devices might sound a bit onerous. But in fact many service providers have a legitimate interest in knowing which device you are using. So tying the credential to the device might be considered as a feature.
Sounds a lot like M-Pin from MIRACL!
