Reliable and convenient authentication technology for web
... At the moment, all authentication methods used in web applications are either not secure enough or too inconvenient to use. It is because of this that the global system of micropayments over the Internet has not yet appeared.
What exactly is the inefficiency of each of the existing methods?
Simple password: convenient, but there are several threats, and the most important is not so much an unauthorized familiarization with it, as the fact that approximately the same login / password combination can be used for many different services, some of which may not be sufficiently secure. One-time passwords: safe and relatively convenient (but, nevertheless, an extra device is added), but quite expensive. Digital signature certificates: safe, but very inconvenient (problems with cross-platform token support), and also expensive. Using the second communication channel for confirmation (usually a mobile phone): relatively safe, relatively convenient, relatively scalable (for now ...). OpenID: safe, but currently difficult to access due to the fact that 99% of people do not have a trusted web server.
However, it is already possible to aim a blow at the global authentication system, if we use a combination of 3 phenomena that have already become reality:
IPv6; OpenID; stable internet connection from a mobile phone / communicator. ')
Here she is:
Each mobile phone, while on the provider's network, will be permanently connected to the Internet and have a static IPv6 address, as well as a DNS of the form <phone number>. <Operator domain>. Each phone will have an embedded OpenID service. Thus, a person will only need to log in to his phone every morning in order to be able to authenticate automatically on any site. In such a system, of course, there appears a weak spot - the phone itself, in the case of which it is seized, attackers can impersonate it. But here, even at first glance, there are many ways to protect: 0. (not to mention blocking the phone by calling the operator); 1. for some sensitive transactions (for example, payments), you can do additional authorization in the form of, for example, a password (now two-factor authentication); 2. You can add biometric authentication or use an additional token, for example, an RFID key, which a person can wear on a keychain, neck or wrist, and which should be located no further, for example, 2 m from the phone for the OpenID service to work. I think there are other reasonable ways ...
In such a system, mobile operators can take the role of mobile micro-banks if payments are made directly from a personal account with an operator, or authentication service providers (now there are first attempts to implement this approach, but with proprietary authentication systems that do not have the prospect of scaling beyond individual payment systems).