Security vs Usability
When it comes to authentication, any given system that doesn’t attain the state of balance between being sufficiently usable and secure is basically an impractical authentication system. Since the very beginning, the traditional credentials-based authentication system has taken dominance over any other alternatives. But not without many shortcomings, from risks like replay and phishing attacks to intrinsic problems like the "password fatigue” problem (in which a user is burdened with the need to remember an excessive number of passwords as part of his daily routine), we are left with non-trivial design flaws that need to be addressed.
Later on, new approaches have emerged to address these problems. One approach is the single sign-on system (a.k.a SSO), where a user can simply have one single account that enables him to authenticate to multiple services. This somewhat resolves the aforementioned "password fatigue” problem as a user no longer needs to burden himself with too many passwords to remember and no longer is tempted to develop bad habits like reusing the same password over and over again. But still it doesn’t come without its own shortcomings, as in this case, losing the one password will prevent access to all services associated with the SSO system; let alone the potential risk of mass account compromisation....
Another approach that has been introduced is what’s called “one-time password (OTP)”, which tries to mitigate many risks such as replay attacks and any potential of phishing attacks to some extend. But on the downside, these passwords are typically hard to memorise, and therefore, they require additional technology to be deployed.
Recently, a new SSO model that relies on QR-code-based one-time passwords has been introduced to further address such flaws. In a QR-code-based login, a user may only need to scan a QR code generated by the service he’s trying to authenticate to, and then a client app on a trusted device such as a smartphone would scan and transmit the QR code to an identity provider in order to validate it and further authenticate the user to the destination service. Hence conducting a seamless and safe login process even on a potentially compromised device. But as we explain in detail later––depending on the implementation––such approach can be easily abused to fool a user into authenticating a malicious attacker on behalf of himself to sensitive web services, defeating the whole point of such an approach!
