How do you feel when you log in to an online service – protected or vulnerable? If you feel protected, this article is for you. Read it, and then answer the question again. If you don’t feel logging is a correct way to interact with a system, join me in my quest to educate people to demand better security mechanisms from online service providers.
How a system logs in a user
The login process consist of two steps: 1) authentication, and 2) session fabrication. The outcome of the authentication step is a mere true/false bit reflecting whether the user is who they claim to be. The outcome of the session fabrication step is a session object representing the authenticated user. Let me highlight a few things here: the system can fabricate a session for any user account. (Otherwise there would be users who could not log in.) The system does not need the authentication bit in order to fabricate a session – technically speaking it is only a matter of courtesy - the system contains code and resources sufficient to impersonate any user with or without the authentication bit.
Several things are scary here. First and foremost, password storage - while some systems store only numeric hashes of the passwords, other systems may store the actual passwords. Passwords may be encrypted or may be stored as plain text. If they are encrypted, the system must have the key to retrieve any password (for the authentication step). You can count on the fact that there is a system administrator who can read all passwords.
The second scary thing is the existence of the session fabrication functionality. It is possible that the session fabrication functionality is accessible without going through authentication. Then a person with local access, e.g. a system administrator, can launch a program that fabricates sessions, i.e. impersonates users.
Third, the system performs all the actions. A user places a request for a particular action, but it is the system that carries it forward. That requires the system to be able to process all the data in store, i.e. the system can read anybody’s data regardless of who the session user is. This is scary, because there are users with permissions to see other users’ data, e.g. customer support, management, administrators, etc. They can read your data without doing any hacks.
So far I’ve only mentioned employees of service provider organizations. Consider the millions of professional crackers as well as enthusiasts throughout the world. Once an attacker gets into such a system, they have all of it.
How to solve this
Whatever route the online industry takes to solve this problem, it will take decades to become noticeable. That is mainly due to the fact that online service providers are not impacted as deeply as consumers are. And consumers are hard to unite.
Anyway, is there an alternative to login? I dare say yes. I have not worked out the details, but here is the general idea. It is based on public key authentication - instead of storing a password at the system, a user shares their public key when they create their user account. There are no sessions – each request is authenticated individually. The authentication consist of verifying that the subject request has been signed with the user’s private key. User data is stored as units each of which has entered the system encrypted with the user’s private key. If there is any unencrypted metadata associated with actual data blobs, the system may utilize it in any way it needs to.
Here is how an online email system will look like. A user sends a signed request to view their mailbox. (Notice there is no need of a login.) The system verifies the request is signed with the user’s key. It pulls the list of metadata items – subject, sender, receive date, message size, etc., encrypts it with user’s public key and sends it back to the user. The user’s web browser sees a properly tagged encrypted blob, pulls the user’s private key (the browser may ask the user for the key’s location), decrypts the blob and renders it nicely for the user. When the user clicks on a specific email message, another signed request is sent to the system. In this case the system sends back the already encrypted body of the requested email message. The system can provide additional value by verifying whether each message has been signed with a key of a trusted sender and treat all unsigned messages as spam.
The first step towards that futuristic system is for consumers to start valuing their own privacy – create a private-public key pair, give the public key to potential recipients and demand their public keys in return, start signing all outgoing messages, and start reminding senders of unsigned messages to start signing. Only when a momentum toward user privacy is built, online service providers will consider giving up on their ability to spy on people’s private data.
No comments:
Post a Comment