One of the major security challenges of the internet over the last twenty years has consistently been the rather simple problem of securing user accounts. Right now, users have accounts with hundreds of websites, and dozens of passwords, leading to large<\/a> numbers<\/a> of hacks<\/a> as individual websites, often run by people not particularly skilled in the finer points of cryptography and internet security, find themselves exploited by increasingly clever hackers, and users frequently deal with the complexity of remembering hundreds of passwords by either making them simple<\/a> or making them all the same<\/a> – with often very unfortunate results<\/a>. Over time, a patchwork of ad-hoc solutions has certainly developed, including the use of one’s email account as a universal backup, and “password manager” software like Lastpass, though at high cost: such solutions either retain much of the underlying complexity of password-bsaed access or give centralized companies very high degrees of control over your online life.<\/p>\n There are many calls to get<\/a> rid<\/a> of<\/a> passwords<\/a>, but the question is: what do we replace them with? There are many ideas, ranging from “one single password to rule them all” to smartphone authentication to specialized hardware devices and biometrics and all sorts of multi-factor M-of-N policies, but even these more complex constructions so far have typically been application-specific: many banks now give you a specialized access device to log into your bank account, but if you trust its security you cannot also use it to access your email. In general, we see that the problem of how to best manage user access control and minimize key loss and theft risks is complex enough that it never will be solved “once and for all”, and so the best way to solve it is to allow a free market of solutions to flourish and let each user pick which ones work best for them; however, the way to make that actually happen is by unbundling<\/a> the “access control solutions” market from the “services” market. That is to say, exactly what we are to a large extent not<\/em> doing right now.<\/p>\n So how do we do that? The first step is to introduce some well-placed use of the ultimate abstraction: Turing-complete code. Rather than, at the protocol level, allowing users to specify a password, or providing a pre-selected set of providers, or even a standard which relies on talking to a server of the user’s choice, allow access policies to be specified in code to be executed in a deterministic virtual machine (where the EVM is a good a start as any). Code can include digital signature verifications using any<\/em> cryptographic algorithm (so you get forward-compatibility with quantum-safe crypto for free), potentially including keys held on the user’s computer, keys directly derived from a password<\/a>, keys held on a hardware device or any arbitrary policy including any combination of the above. This way, innovation can happen in access-control mechanisms without any need<\/em> for websites (or other systems requiring authentication) to do anything to accomodate new changes. Additionally, the system neatly allows organizations<\/em> to use the scheme using multi-person access controls right away, without any further need for integration.<\/p>\n The next step is Turing-complete operation-dependent code. For many applications, you want the ability to authorize some users to carry out some operations but not others; for example, you may want to authorize a sysadmin to change the IP address that a domain name points to, but not sell the domain outright. To accomodate this, the abstraction needs to change. A simple “Turing-complete-code as signature” setup might have the following form:<\/p>\n Where VM<\/span> is a virtual machine that runs code, taking a server-provided nonce and a signature as input, and the verification check is to see whether or not the output is 1. A simple example of code<\/span> that could be put in is an elliptic curve digital signature verifier. To allow different authorization requirements depending on the operation, you want:<\/p>\n A signature would need to be provided with every operation that the user wants to carry out (this has the benefit of providing definite, third-party-verifiable, proof that an operation was authorized); the operation data (imagine the function name and the arguments encoded in an Ethereum-style ABI<\/a>) would be added as an argument for the virtual machine, and the signature would have to be over both the nonce and the operation data.<\/p>\n This gets you quite far, but in some cases not far enough. One simple example is this: what if you want to give someone permission to withdraw small amounts of money but not large amounts, ie. a withdrawal limit? In that case, the problem that you must overcome is simple: what if someone limited by a withdrawal cap of $100 tries to evade it by simply running a script to withdraw $90 over and over again? To solve this, you need a smarter withdrawal limit; essentially, something like “maximum $100 per day”. Another natural case is key revocation: if a key gets hacked or lost, you want to replace it, and you want to make sure that the world finds out that your policy was changed so that attackers cannot try to impersonate you under your old policy.<\/p>\n To get past this last hump, we need to go one step further: we need Turing-complete operation-dependent stateful<\/em> policies; that is to say, operations should be able to change the state of the policy. And here is where not just cryptography, but specifically blockchains come in. Of course, you could just have a central server manage the whole thing, and many people are perfectly fine with trusting a central server, but blockchains are moderately valuable<\/a> here because they are more convenient, provide a credible story of neutrality, and are easier to standardize around. Ultimately, as it would be quite harmful for innovation to permanently choose “one blockchain to rule them all”, the thing that we want to standardize is a mechanism by which users can download modules to support any<\/em> blockchain or centralized solution as they wish.<\/p>\n For blockchain-based applications, having a stateful policy enforced right on the blockchain makes natural sense; there is no need to involve yet another special class of intermediaries, and people can start doing it right now. The abstraction of an “account” that Ethereum offers makes it extremely easy to work with this approach: if your application works with simple users holding private keys, it also works for just about every kind of individual, multiparty, hardware-driven, military-grade or whatever other policy users will come up with in the future.<\/p>\n For other applications, users may want privacy, both in the state-changing operations that they perform and even in the nature of their policy at any one particular time. For this reason, you likely want a solution like Hawk<\/a>, where the blockchain still ensures the security of the process but, thanks to the wonders of zero-knowledge-proof technology, knows nothing about what is being secured<\/em>; before Hawk is implemented, simpler forms of cryptography such as ring signatures may suffice.<\/p>\n
\n![\"\"](\"https:\/\/blog.ethereum.org\/images\/posts\/2015\/11\/kartenleser-mit-access-card.jpeg\")
\n
\nThe hardware access device to my UBS bank account. Remind me, why can’t I also use this to secure my domains on Namecheap?
\n<\/small>
\n<\/center><\/p>\nVM<\/span>(<\/span>code, server-provided nonce ++ signature<\/span>)<\/span> ?<\/span>=<\/span> <\/span>1<\/span>\n<\/span><\/code><\/pre>\n<\/div>\nVM<\/span>(<\/span>code, server-provided nonce ++ operation_data ++ signature<\/span>)<\/span> ?<\/span>=<\/span> <\/span>1<\/span>\n<\/span><\/code><\/pre>\n<\/div>\n